Use --version-path and --version-key when available, in Keystone 1.0.9.2318 and later

chrome/installer/mac/keystone_install.sh

 #!/bin/bash -p
 
 # Copyright (c) 2011 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # usage: keystone_install.sh update_dmg_mount_point
 #
 # Called by the Keystone system to update the installed application with a new
 # version from a disk image.
@@ skipping 359 matching lines @@
 
 # Returns 0 (true) if ksadmin supports --brand-path and --brand-key.
 ksadmin_supports_brandpath_brandkey() {
   # --brand-path and --brand-key were introduced in Keystone 1.0.8.1620.
   is_ksadmin_version_ge 1.0.8.1620
 
   # The return value of is_ksadmin_version_ge is used as this function's
   # return value.
 }
 
+# Returns 0 (true) if ksadmin supports --version-path and --version-key.

[TVL, 2011/05/18 17:57:31]

for some reason I thought this had been around a long time

[Mark Mentovai, 2011/05/18 18:10:42]

TVL wrote:
It’s been around in the Keystone trunk for about a year, but it didn’t actually
make it into any releases until 1.0.9.2318.

+ksadmin_supports_versionpath_versionkey() {
+  # --version-path and --version-key were introduced in Keystone 1.0.9.2318.
+  is_ksadmin_version_ge 1.0.9.2318
+
+  # The return value of is_ksadmin_version_ge is used as this function's
+  # return value.
+}
+
 usage() {
   echo "usage: ${ME} update_dmg_mount_point" >& 2
 }
 
 main() {
   local update_dmg_mount_point="${1}"
 
   # Early steps are critical.  Don't continue past any failure.
   set -e
 
@@ skipping 677 matching lines @@
     )
   fi
 
   if ksadmin_supports_brandpath_brandkey; then
     ksadmin_args+=(
       --brand-path "${ksadmin_brand_plist_path}"
       --brand-key "${ksadmin_brand_key}"
     )
   fi
 
+  if ksadmin_supports_versionpath_versionkey; then
+    ksadmin_args+=(
+      --version-path "${installed_app_plist_path}"

[TVL, 2011/05/18 17:57:31]

so my fear here is user installs where they drag it to a new place.  Do we need
to update this path in our user ticket each time chrome is launch or will this
end up pointing at something that no longer exists?

[Mark Mentovai, 2011/05/18 18:10:42]

TVL wrote:
If the plist at --version-path doesn’t exist, ksadmin will use the version
embedded in the ticket.

I agree it’d be best to get an updated registration framework so that we can
maintain these fields in the user ticket at registration time (app launch). I’ve
asked Alex about getting a 1.0.9.2318 registration framework, but he said he’s
been holding off on the release because of some other concerns, and will get
back to me later today. That’s why this is “on ice” and not ready for checkin
yet.

+      --version-key "${KS_VERSION_KEY}"
+    )
+  fi
+
   note "ksadmin_args = ${ksadmin_args[*]}"
 
   if ! ksadmin "${ksadmin_args[@]}"; then
     err "ksadmin failed"
     exit 11
   fi
 
   # The remaining steps are not considered critical.
   set +e
 
@@ skipping 173 matching lines @@
 
 # Check "less than" instead of "not equal to" in case Keystone ever changes to
 # pass more arguments.
 if [[ ${#} -lt 1 ]]; then
   usage
   exit 2
 fi
 
 main "${@}"
 exit ${?}