January 2007 - Installer-dev

Re: modify IFPkgFlagRestartAction behaviour during installation process
by Peter Bierman 29 Jan '07

29 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com At 12:03 PM +0100 1/29/07, Andreas Niemeyer wrote: There is an existing enhancement request: <rdar://problem/4694508> ER: conditional restart/logout from the dist -pmb _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I would like to modify the `IFPkgFlagRestartAction' behaviour on demand during the installation process - but failed. The changing of the value from `NoRestart' to `RequiredRestart' didn't work: This is not possible. The reads this flag early in the installation process and it can not be changed on the fly. This email sent to site_archiver(a)lists.apple.com

1 0

Change internet helper settings?
by Chris Waldrip 29 Jan '07

29 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com How can I add/remove/modify the default internet helpers? -Chris _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com I need to add a custom internet helper, and using GUI tools like More Internet isn't an option. smime.p7s

1 0

modify IFPkgFlagRestartAction behaviour during installation process
by Andreas Niemeyer 29 Jan '07

29 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: InstallationCheck / mpkg / 10.4
by Peter Bierman 26 Jan '07

26 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com -pmb Thanks, -Julian _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/bierman%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… You've pretty much described in a nutshell why 10.4 introduced distribution scripts, which puts all of these UI decisions under your control. I'd create a distribution script for your 10.4 and later users, and then use the InstallationCheck and mpkg mechanisms for 10.3. At 9:32 AM -0600 1/26/07, Julian Devlin wrote: I have an mpkg. It has two sub-pkgs. Neither one is required. One of the sub-pkgs has an InstallationCheck which returns 112 (stop installation). On 10.3.9, running the mpkg displays my error and stops the installation (as I would sort of expect). On 10.4.8, running the mpkg silently (unless you happen to look in the log) disables the sub-pkg with the InstallationCheck, and displays "The software was successfully installed". If the user happens to click Customize, they will see that the sub-pkg has been turned off, and cannot be selected. I guess I understand the reasoning to some degree - the sub pkg can't be installed, and since it's not required, the mpkg continues to install. So I guess in 10.3.9, the user would have to figure out which sub pkg wasn't able to install, and customize the mpkg installation to exclude it, which is probably more work than the user should have to do... But at the very least on 10.4.8, the failure should cause the "Customize" view to be exposed so the user has some chance of knowing what's going on. (and it would also be nice if the error could be seen by selecting the sub-pkg - so the reason for it being disabled would not be mysterious). In my pkg, the InstallationCheck doesn't fail because it can't/shouldn't ever be installed on the computer, it's because of a condition that could be fixed and then the install could succeed. So it's important for the user to at least know that the sub pkg hasn't been installed, even if the mpkg install does continue. Am I missing something? Is there some other way to get the error to appear? (without making the sub pkg required)... This email sent to bierman(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

InstallationCheck / mpkg / 10.4
by Julian Devlin 26 Jan '07

26 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thanks, -Julian _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I have an mpkg. It has two sub-pkgs. Neither one is required. One of the sub-pkgs has an InstallationCheck which returns 112 (stop installation). On 10.3.9, running the mpkg displays my error and stops the installation (as I would sort of expect). On 10.4.8, running the mpkg silently (unless you happen to look in the log) disables the sub-pkg with the InstallationCheck, and displays "The software was successfully installed". If the user happens to click Customize, they will see that the sub-pkg has been turned off, and cannot be selected. I guess I understand the reasoning to some degree - the sub pkg can't be installed, and since it's not required, the mpkg continues to install. So I guess in 10.3.9, the user would have to figure out which sub pkg wasn't able to install, and customize the mpkg installation to exclude it, which is probably more work than the user should have to do... But at the very least on 10.4.8, the failure should cause the "Customize" view to be exposed so the user has some chance of knowing what's going on. (and it would also be nice if the error could be seen by selecting the sub-pkg - so the reason for it being disabled would not be mysterious). In my pkg, the InstallationCheck doesn't fail because it can't/shouldn't ever be installed on the computer, it's because of a condition that could be fixed and then the install could succeed. So it's important for the user to at least know that the sub pkg hasn't been installed, even if the mpkg install does continue. Am I missing something? Is there some other way to get the error to appear? (without making the sub pkg required)... This email sent to site_archiver(a)lists.apple.com

1 0

RE: Version numbering
by Aaron London 25 Jan '07

25 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcdAu9RL9DGY627MQO2GHUCpvoS1/AAAPMxw Thread-topic: Version numbering http://developer.apple.com/documentation/DeveloperTools/Conceptual/Softw areDistribution4/Concepts/sd_pkg_version_info.html **************************************** _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Version numbering
by Andy O'Meara 25 Jan '07

25 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com /////// SNIP use strict; use POSIX qw(ceil floor); die "$0: Must be run from Xcode" unless $ENV{"BUILT_PRODUCTS_DIR"}; my $version = $REV; $version =~ s/([\d]*:)([\d]+).*/$2/; $version =~ s/([\d]+).*/$1/; # Removes trailing letters die "$0: No Subversion revision found" unless $version; $pointVersion =~ s/[^\d]//g; $pointVersion = ".$pointVersion"; my $base10Version = int( 100 * ( $baseVersion + $pointVersion ) ); # # Compute the build date (days elapsed since 1/1/1900 -- see SSTime.h) # my @currentTime; @currentTime = localtime( time ); my $yearDays = $currentTime[ 7 ]; my $year = $currentTime[ 5 ] - 100; my $DAYS_1900_TO_2000 = 36524; # # Generate the new header string # # # Write out the new header # my $HEADER = "$ENV{SRCROOT}/src/BUILD_NUMBER.h"; my $curFileStr = ""; /////// SNIP # /usr/bin/perl -w # LAST UPDATED: 22MAR06 # Xcode auto-versioning script for Subversion # Replaces BUILD_NUMBER with the subversion rev number in Info.plist use strict; die "$0: Must be run from Xcode" unless $ENV{"BUILT_PRODUCTS_DIR"}; my $version = $REV; $version =~ s/([\d]*:)([\d]+).*/$2/; $version =~ s/([\d]+).*/$1/; # Removes trailing letters die "$0: No Subversion revision found" unless $version; # Read in Info.plist open(FH, "$INFO") or die "$0: $INFO: $!"; my $info = join("", <FH>); close(FH); # Find and replace BUILD_NUMBER with a real value $info =~ s/BUILD_NUMBER/$version/g; # Write out the new plist file open(FH, ">$INFO") or die "$0: $INFO: $!"; print FH $info; close(FH); /////// SNIP On Jan 24, 2007, at 5:00 PM, Walter wrote: Is there a better way to do version numbering that I'm not finding? Does anyone know how the installer actually compares version numbers? Thanks, Walter This email sent to andy(a)soundspectrum.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… Here's two perl scripts that may serve as a good starting point for you that we use in Xcode's script run phase. The first is the first run-phase script that writes a a simple C .h file containing a couple #defines, and it gets its info from subversion and the current time stamp. The second script is the last phase the execute and simply does a find/replace for the token BUILD_NUMBER in Info.plist. Credit goes to Daniel Jalkut for help developing these scripts. # /usr/bin/perl -w # Xcode auto-versioning script for Subversion # This script generates BUILD_NUMBER.h based on the subversion rev and the current timestamp. # Last modified: 12OCT06 # Get the current subversion revision number and use it to set the CFBundleVersion value my $REV = `/usr/local/bin/svnversion -n ./`; # Separate the version into the value before the first point, and the value after my ( $baseVersion, $pointVersion ); ( $baseVersion, $pointVersion ) = ( $ENV{APPLICATION_VERSION} =~ /(\d +)([^\d][\d\.]*)/ ); my $BUILD_DATE = $DAYS_1900_TO_2000 + $yearDays + ( 365 * $year + floor( ( $year + 3 ) / 4 ) ); my $newFileStr = "#define BUILD_NUMBER \"$version\"\n#define BUILD_VERSION \"$ENV{APPLICATION_VERSION}\"\n#define BUILD_VERSION_BASE10 $base10Version\n#define BUILD_DATE $BUILD_DATE\n"; # Read in the current BUILD_NUMBER.h so we can see if it's different (below) if ( open(FH, "$HEADER") ) { $curFileStr = join("", <FH>); close(FH); } # Only write a new one if the contents aren't what we want (otherwise, we'll cause the project to rebuilt each time!) if ( $curFileStr ne $newFileStr ) { open(FH, ">$HEADER") or die "$0: $HEADER: $!"; print FH $newFileStr; close(FH); } # Get the current subversion revision number and use it to set the CFBundleVersion value my $REV = `/usr/local/bin/svnversion -n ./`; my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Contents/ Info.plist"; Does anyone else have problems with the Apple version numbering scheme? My software business model works in a different manner than Apple's and I don't find the version numbering sufficient. Each and every build that we make is a release candidate. Every bug fix needs to be built individually. I can't go back and change the version numbers after a build has been verified by QA. This leaves 100 bug fixes before I need to increment the major version number. Since not every bug is truly fixed the first time, the number of bug fixes between major releases is even smaller. Currently we don't worry about it and our current version is 5.13.59, however I've noticed issues with the installer where some components are not properly updated. I'm assuming that the installer is getting confused with attempting to store 13 & 59 as a BCD and then shoveling that value into a byte. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/andy% 40soundspectrum.com This email sent to site_archiver(a)lists.apple.com

1 0

Version numbering
by Walter 24 Jan '07

24 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcdAAxeyVi6KvKv2EduvcQAWy8yhdA== Thread-topic: Version numbering User-agent: Microsoft-Entourage/11.3.3.061214 Does anyone else have problems with the Apple version numbering scheme? My software business model works in a different manner than Apple's and I don't find the version numbering sufficient. Each and every build that we make is a release candidate. Every bug fix needs to be built individually. I can't go back and change the version numbers after a build has been verified by QA. This leaves 100 bug fixes before I need to increment the major version number. Since not every bug is truly fixed the first time, the number of bug fixes between major releases is even smaller. Is there a better way to do version numbering that I'm not finding? Currently we don't worry about it and our current version is 5.13.59, however I've noticed issues with the installer where some components are not properly updated. I'm assuming that the installer is getting confused with attempting to store 13 & 59 as a BCD and then shoveling that value into a byte. Does anyone know how the installer actually compares version numbers? Thanks, Walter _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

RE: conventions for command line utils
by Handloser, Fred (LightScribe) 24 Jan '07

24 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: Acc/2kwhVDh/JOMgTl6/DW4Al/gp+QAAID9w Thread-topic: conventions for command line utils Our group builds a few install packages that target Linux and Mac OSX. We have been using a tool named epm that reads a manifest and builds a "native" package for the target machine. This allows us to maintain one manifest while building a ".pkg" package for the Mac and a ".rpm" and a ".deb" package for our Linux targets. We do have some slight differences in the installed footprint, but epm allows us to use and include mechanism in the manifest to include the customized parts based on machine on whiche we are building our package. This may not be a good solution for everyone, but it has worked well for us. Epm also comes with source code so you can (and probably will need to) modify bits of it to get the package to be built the way you want it to build. For example, I had to add "rootvolumeonly" as a directive to the osx.c epm source so I could add the "%rootvolumeonly true" directive to our manifest to generate the "<key>IFPkgFlagRootVolumeOnly</key> <true/>" entry in the Info.plist file that is built during are automated builds. Take a look at http://www.easysw.com/epm/faq.php?all if you are intereseted. It is free. -----Original Message----- From: installer-dev-bounces+fred.handloser=hp.com(a)lists.apple.com [mailto:installer-dev-bounces+fred.handloser=hp.com@lists.apple.com] On Behalf Of John Clyne Sent: Wednesday, January 24, 2007 9:08 AM To: installer-dev(a)lists.apple.com Subject: conventions for command line utils Hi, I have some questions re installation conventions used in the Mac world when porting multi-component applications from other unices. I have an app that consists of a GUI, several command line utilities, shared libraries depended upon by both the GUI and CLUs, header files, doc, etc. I'd like to provide the package via an installer that is familiar to Mac users, and minimizes setup required prior to using the tools. In Linux, for example, the installer would be a shell script allowing the admin to specify a target installation directory. Setup would consist of yet another shell script that users could source to configure execution paths, shared library paths, etc. The notion of Mac Bundles, with their drag-and-drop installation, is obviously a much more elegant way to handle software distribution. However, it's not clear that Bundles are at all appropriate for packages composed of multiple CLUs with shared library dependencies: how would one resolve the shared library paths? So I guess my questions boil down to 1. Are there any best practices for CLU installation? Put them in a well-known location (e.g. /usr/local/{bin,lib,include}) where they will hopefully automatically appear on the appropriate search paths, or provide the flexibility to install anywhere and use some other mechanism to resolve setup issues (paths)? 2. What tools are recommended for building an installer for a multi- component application such as i'm describing? Thanks for any guidance! cheers John Clyne National Center for Atmospheric Research 303.497.1236 (w), 303.809.1922 (c) clyne(a)ucar.edu _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/fred.handloser%40hp .com This email sent to fred.handloser(a)hp.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

conventions for command line utils
by John Clyne 24 Jan '07

24 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi, So I guess my questions boil down to Thanks for any guidance! cheers John Clyne National Center for Atmospheric Research 303.497.1236 (w), 303.809.1922 (c) clyne(a)ucar.edu _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I have some questions re installation conventions used in the Mac world when porting multi-component applications from other unices. I have an app that consists of a GUI, several command line utilities, shared libraries depended upon by both the GUI and CLUs, header files, doc, etc. I'd like to provide the package via an installer that is familiar to Mac users, and minimizes setup required prior to using the tools. In Linux, for example, the installer would be a shell script allowing the admin to specify a target installation directory. Setup would consist of yet another shell script that users could source to configure execution paths, shared library paths, etc. The notion of Mac Bundles, with their drag-and-drop installation, is obviously a much more elegant way to handle software distribution. However, it's not clear that Bundles are at all appropriate for packages composed of multiple CLUs with shared library dependencies: how would one resolve the shared library paths? 1. Are there any best practices for CLU installation? Put them in a well-known location (e.g. /usr/local/{bin,lib,include}) where they will hopefully automatically appear on the appropriate search paths, or provide the flexibility to install anywhere and use some other mechanism to resolve setup issues (paths)? 2. What tools are recommended for building an installer for a multi- component application such as i'm describing? This email sent to site_archiver(a)lists.apple.com

1 0