Binary differential (delta) updates: keystone_install dmgpatcher support

Binary differential (delta) updates: keystone_install dmgpatcher support.

There is no standalone dmgpatcher tool because the operation is tied too
closely to Keystone update application, but keystone_install is now able to
perform the dmgpatcher operation as an inverse to what dmgdiffer does when it
creates patch update disk images given an "old" and "new" existing disk image.

If keystone_install detects a .patch directory, it applies the dirpatches that
are contained therein using dirpatcher and goobspatch.  keystone_install
expects two dirpatches: one for the versioned directory, and one for the outer
app bundle.  These two dirpatches correspond exactly to the two rsyncs that
keystone_install performs when updating from a full-install disk image.

BUG=45017
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=49805

[TVL, 2010-06-15 12:32:18]

http://codereview.chromium.org/2832005/diff/11001/12001
File chrome/installer/mac/keystone_install.sh (right):

http://codereview.chromium.org/2832005/diff/11001/12001#newcode38
chrome/installer/mac/keystone_install.sh:38: # 77  (unused) try installation
again later
i forgot about these, good addition.

http://codereview.chromium.org/2832005/diff/11001/12001#newcode263
chrome/installer/mac/keystone_install.sh:263: if [[ "${-}" =~ e ]]; then
should 'e' be quoted?

http://codereview.chromium.org/2832005/diff/11001/12001#newcode450
chrome/installer/mac/keystone_install.sh:450: err "patch_dir must be an absolute
path"
do we really need to repeat all these absolute checks since you did it with
update_dmg_mount_point?  I guess it doesn't really hurt.

http://codereview.chromium.org/2832005/diff/11001/12001#newcode472
chrome/installer/mac/keystone_install.sh:472: patch_dir=
what could get here?

http://codereview.chromium.org/2832005/diff/11001/12001#newcode678
chrome/installer/mac/keystone_install.sh:678: elif [[ "${old_version_app}" !=
"${update_version_app_old}" ]]; then
i believe you also wrote out the old keystone version, worth checking that also?

http://codereview.chromium.org/2832005/diff/11001/12001#newcode791
chrome/installer/mac/keystone_install.sh:791: # render the versioned directory
unusable even for an instant.
worth a tweak to point out the case above where we directly diffed into the new
locaitons so update_version_dir is blank as no work is needed here?

[Mark Mentovai, 2010-06-15 14:33:41]

I addressed some of these in comments. New version up.

http://codereview.chromium.org/2832005/diff/11001/12001
File chrome/installer/mac/keystone_install.sh (right):

http://codereview.chromium.org/2832005/diff/11001/12001#newcode263
chrome/installer/mac/keystone_install.sh:263: if [[ "${-}" =~ e ]]; then
TVL wrote:
> should 'e' be quoted?

Good catch. Interesting story.

This is a weird one. =~, since bash 3.2 (used on both 10.5 and 10.6), behaves
differently when the second argument is quoted. Unquoted, you get a regular
expression pattern search. Quoted, you get a substring search.

In this case, e as a substring has the same meaning as e as a regular expression
pattern, so you wouldn’t notice a difference if it were quoted. You might also
think that it’s doing a RE search (because that’s all the man page says), and
you might try to change this to a real RE or write code elsewhere that uses a
real RE and quotes it, and you’d be wrong. (Unless you set the compat31 shopt.)

I personally think that the behavior in bash 3.2 is a misfeature, but it’s the
way it is, and in order to ensure script compatibility I haven’t been quoting
regular expressions.

http://tiswww.case.edu/php/chet/bash/CHANGES, changes in bash-3.2-alpha, 3.f:

    Quoting the string argument to the [[ command's  =~ operator now forces
    string matching, as with the other pattern-matching operators.

http://codereview.chromium.org/2832005/diff/11001/12001#newcode450
chrome/installer/mac/keystone_install.sh:450: err "patch_dir must be an absolute
path"
TVL wrote:
> do we really need to repeat all these absolute checks since you did it with
> update_dmg_mount_point?  I guess it doesn't really hurt.

The logic here is: “what if, one day, someone changes things to use an alternate
path for these?” I tried not to go too crazy. I check update_dmg_mount_point,
patch_dir, update_app, and installed_app. I’m more confident that other paths
will at least be relative to one of the above.

http://codereview.chromium.org/2832005/diff/11001/12001#newcode472
chrome/installer/mac/keystone_install.sh:472: patch_dir=
TVL wrote:
> what could get here?

if [[ -d ]]
  # patch_dir is a directory - treat as is_patch
elif [[ -e ]]
  # patch_dir exists but is not a directory - error
else
  # patch_dir does not exist - treat as not is_patch, ordinary full app dmg

Do you think it needs comments like this in the code?

http://codereview.chromium.org/2832005/diff/11001/12001#newcode678
chrome/installer/mac/keystone_install.sh:678: elif [[ "${old_version_app}" !=
"${update_version_app_old}" ]]; then
TVL wrote:
> i believe you also wrote out the old keystone version, worth checking that
also?

I wrote it out for completeness, but it’s irrelevant for the purposes of the
dirpatches. The dirpatches are based on the app version. Recall that the
Keystone versions are only included in the outer .app’s Info.plist. As unlikely
as it is, we’re equipped to wind up in a world where the KS and app versions
don’t match, and if we wind up in that world, we may also wind up having a
single update apply to multiple old KS versions in the same way that it might
apply to multiple old KS channels.

[TVL, 2010-06-15 14:43:11]

lgtm