September 2007 - Installer-dev

Re: packagemaker update problems
by Bill Coderre 10 Sep '07

10 Sep '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com And here's my policy on installer names and IDs. _______________________________________________ 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.… On Sep 10, 2007, at 2:06 PM, Stéphane Sudre corrected me: If there IS a receipt with the same name, and the receipt has a version (noted in IFMajorVersion and IFMinorVersion of the Info.plist) that is newer than the one being installed, the installer prevents installation with an error. Just to be "pointilleux", AFAIK, it depends on whether the AllowRevert flag is enabled or not in the package. I've also found that if the package is part of a metapackage, it does not prevent installation on 10.4.10 for instance, it just marks the package as being skipped. Ah, I neglected those details. (Assumed you guys wouldn't be doing mpkgs, which is a bad assumption.) If an installer contains the complete software package, I call it a "full installer" and give it a name like iMovie.pkg. If an installer contains a partial set of software, I call it an "update installer" and give it a name like iMovie_701.pkg. Hmm, I might be terribly cautious but when doing an updater (updater installer), I also change the CFBundleIdentifier. In the case I'm thinking about, I append a ".updater." to the CFBundleIdentifier. I forgot to mention that my CFBundleIdentifier is always com.apple.pkg.<packagename>, so com.apple.pkg.iMovie or com.apple.pkg.iMovie_701 This email sent to site_archiver(a)lists.apple.com

1 0

Re: packagemaker update problems
by Stéphane Sudre 10 Sep '07

10 Sep '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On lundi, septembre 10, 2007, at 10:08 PM, Bill Coderre wrote: So the name you choose is particularly important. And here's my policy on installer names and IDs. My €0.02 _______________________________________________ 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.… [...] When the installer is going to install, it looks for a receipt with the same name as the current package about to be installed. If there is none, it installs the files in the BOM (if there's a bundle with a newer version as noted in BundleVersions.plist, it will skip that bundle, and put a note in the log). The Install button will be titled "Install." If there IS a receipt with the same name, and the receipt has a version (noted in IFMajorVersion and IFMinorVersion of the Info.plist) that is newer than the one being installed, the installer prevents installation with an error. Just to be "pointilleux", AFAIK, it depends on whether the AllowRevert flag is enabled or not in the package. I've also found that if the package is part of a metapackage, it does not prevent installation on 10.4.10 for instance, it just marks the package as being skipped. If not, the installer goes into "upgrade mode." The Install button will be titled "Upgrade." Also, the installer will find all the files/bundles in the receipt that are not in the package being installed, and "obsolete" them (delete them) during installation. If an installer contains the complete software package, I call it a "full installer" and give it a name like iMovie.pkg. If an installer contains a partial set of software, I call it an "update installer" and give it a name like iMovie_701.pkg. At the risk of offending people by saying this is a "good" scheme, let's just say it seems to work OK for me. Note that if there ARE files to be gotten rid of, I have to do that with an additional script. But I have a script to do that, and the list is simple enough to generate during build. Hope This Helps. Hmm, I might be terribly cautious but when doing an updater (updater installer), I also change the CFBundleIdentifier. In the case I'm thinking about, I append a ".updater." to the CFBundleIdentifier. With both the package name and CFBundleIdentifier name changed, I tend to believe Installer.app will not think that this is the same product. This email sent to site_archiver(a)lists.apple.com

1 0

Re: packagemaker update problems
by Bill Coderre 10 Sep '07

10 Sep '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com So the name you choose is particularly important. And here's my policy on installer names and IDs. Hope This Helps. Lying to the installer by hacking the BOM is a very bad idea. -pmb From: Robert Carroll <robc(a)total.net> Date: Sun, 9 Sep 2007 23:50:29 -0400 To: <installer-dev(a)lists.apple.com> Subject: packagemaker update problems Thanks for your reply Stephane. replace or change anything elsewhere on the computer. Is this a known issue? Is there a safer and more reliable way to accomplish this kind of update? Regarding the permissions issues: - Which OS version is the update run on when it does not work? Regarding the "does not runt at all" issue: This is a valid concern. I don't currently check the installed file location, which would obviously foil the update. > best wishes, Robert Carroll RSM Records Toronto http://www.rsmrecords.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/bc%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.… So, being the Troy McClure of Apple updaters -- you may remember me from such updaters as iWeb 1.1 (which made iWeb smaller on disk) or iPhoto 6.0.3 (which had Combo and Delta versions). I'll be giving you some helpful tips on installer behavior today... When the installer is going to install, it looks for a receipt with the same name as the current package about to be installed. If there is none, it installs the files in the BOM (if there's a bundle with a newer version as noted in BundleVersions.plist, it will skip that bundle, and put a note in the log). The Install button will be titled "Install." If there IS a receipt with the same name, and the receipt has a version (noted in IFMajorVersion and IFMinorVersion of the Info.plist) that is newer than the one being installed, the installer prevents installation with an error. If not, the installer goes into "upgrade mode." The Install button will be titled "Upgrade." Also, the installer will find all the files/ bundles in the receipt that are not in the package being installed, and "obsolete" them (delete them) during installation. If an installer contains the complete software package, I call it a "full installer" and give it a name like iMovie.pkg. If an installer contains a partial set of software, I call it an "update installer" and give it a name like iMovie_701.pkg. At the risk of offending people by saying this is a "good" scheme, let's just say it seems to work OK for me. Note that if there ARE files to be gotten rid of, I have to do that with an additional script. But I have a script to do that, and the list is simple enough to generate during build. On Sep 10, 2007, at 11:19 AM, Peter Bierman wrote: The behavior you're confused about is actually the basis of the existence of the installer as opposed to just using tar or zip. When the installer detects that a different (not just older) version of the "same package" is already installed, it will remove any files that were installed by the previous version that are no longer part of the new version. At 10:40 AM -0500 9/10/07, Steve Stockman wrote: Does your updater have the same name and bundle ID as the full installer? I'm not sure whether this behavior is actually documented anywhere, but we've found that when you install a new package that has the same name as an old package already in /Library/Receipts, if the .bom file in the old package lists any installed files that do not exist in the new package's .bom file, the Installer will often delete such files (presumably under the assumption that the files are obsolete). The solution was simple: Build both the full installer and the updater, and then replace the updater's .bom with a copy of the full installer's. And the Installer never seems to complain about files named in the .bom that don't exist in the archive. ---------------------------------- Steve Stockman Software Architect Consumer Products - Macintosh Symantec Corporation www.symantec.com ---------------------------------- One cause of the problem with the updater has been somewhat identified. The full installer of my application bundle includes a folder inside "Resources" with a set of sound files. Since these files do not change with the updates, I do not include them in the updater package. In testing on my machines, if I don't at least leave the empty "Sounds" folder in the Resources folder, the update appears to delete this folder and its contents. Leaving the directory structure in place, correctly leaves the required sound files post update on my machine, but seems to still remove these files on some user's machines. I am trying to verify this. On Sep 8, 2007, at 3:05 PM, installer-dev-request(a)lists.apple.com wrote: The updater is set up to replace the app file in the MacOS folder of the client's currently installed version. It shouldn't touch any other files in the same package (ie. resource files or the encrypted registration info) and doesn't not - Which authorization are you requiring? I'm requiring administrator privileges to run either the installer or the updater. The files in the package mostly show me as the owner, read-only privileges or read-execute for others. Is it normal to leave myself as the owner, or more common to set this as root or something else? The resources folder must have read-write privileges for everyone, since the app will write encrypted registration data to this folder on its first run. It's possible this would be better if it was in the application support folder, but I prefer the concealed location in the app package. - Do you use a default location that is not '/'? No. - Do you take into account the fact that the application may have been moved by the customer? - Do you use a Locator to look for the location of the application? - Do you use Resource Fork for resources in your application? If so, do you split fork when you're creating the packages? I'm not using resource forks, however the sound files still have resource fork data. I would like to confirm that this data is not essential. At the moment the resource fork data is being preserved in the installer & updater pkgs. _______________________________________________ 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 This email sent to bierman(a)apple.com This email sent to bc(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: packagemaker update problems
by Peter Bierman 10 Sep '07

10 Sep '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Lying to the installer by hacking the BOM is a very bad idea. -pmb Does your updater have the same name and bundle ID as the full installer? I'm not sure whether this behavior is actually documented anywhere, but we've found that when you install a new package that has the same name as an old package already in /Library/Receipts, if the .bom file in the old package lists any installed files that do not exist in the new package's .bom file, the Installer will often delete such files (presumably under the assumption that the files are obsolete). From: Robert Carroll <robc(a)total.net> Date: Sun, 9 Sep 2007 23:50:29 -0400 To: <installer-dev(a)lists.apple.com> Subject: packagemaker update problems Thanks for your reply Stephane. The full installer of my application bundle includes a folder inside "Resources" with a set of sound files. Since these files do not change with the updates, I do not include them in the updater package. In testing on my machines, if I don't at least leave the empty "Sounds" folder in the Resources folder, the update appears to delete this folder and its contents. Leaving the directory structure in place, correctly leaves the required sound files post update on my machine, but seems to still remove these files on some user's machines. I am trying to verify this. On Sep 8, 2007, at 3:05 PM, installer-dev-request(a)lists.apple.com wrote: the client's currently installed version. files or the encrypted registration info) and doesn't not replace or change anything elsewhere on the computer. accomplish this kind of update? Regarding the permissions issues: - Which OS version is the update run on when it does not work? Regarding the "does not runt at all" issue: moved by the customer? you split fork when you're creating the packages? I'm not using resource forks, however the sound files still have resource fork data. I would like to confirm that this data is not essential. At the moment the resource fork data is being preserved in the installer & updater pkgs. best wishes, Robert Carroll RSM Records Toronto http://www.rsmrecords.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/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.… The behavior you're confused about is actually the basis of the existence of the installer as opposed to just using tar or zip. When the installer detects that a different (not just older) version of the "same package" is already installed, it will remove any files that were installed by the previous version that are no longer part of the new version. At 10:40 AM -0500 9/10/07, Steve Stockman wrote: The solution was simple: Build both the full installer and the updater, and then replace the updater's .bom with a copy of the full installer's. And the Installer never seems to complain about files named in the .bom that don't exist in the archive. ---------------------------------- Steve Stockman Software Architect Consumer Products - Macintosh Symantec Corporation www.symantec.com ---------------------------------- One cause of the problem with the updater has been somewhat identified. The updater is set up to replace the app file in the MacOS folder of It shouldn't touch any other files in the same package (ie. resource Is this a known issue? Is there a safer and more reliable way to - Which authorization are you requiring? I'm requiring administrator privileges to run either the installer or the updater. The files in the package mostly show me as the owner, read-only privileges or read-execute for others. Is it normal to leave myself as the owner, or more common to set this as root or something else? The resources folder must have read-write privileges for everyone, since the app will write encrypted registration data to this folder on its first run. It's possible this would be better if it was in the application support folder, but I prefer the concealed location in the app package. - Do you use a default location that is not '/'? No. - Do you take into account the fact that the application may have been - Do you use a Locator to look for the location of the application? This is a valid concern. I don't currently check the installed file location, which would obviously foil the update. > - Do you use Resource Fork for resources in your application? If so, do This email sent to bierman(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: packagemaker update problems
by Steve Stockman 10 Sep '07

10 Sep '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcfzwO5DLNpBwl+0EdyQxwADk3wqpg== Thread-topic: packagemaker update problems User-agent: Microsoft-Entourage/11.3.6.070618 Does your updater have the same name and bundle ID as the full installer? I'm not sure whether this behavior is actually documented anywhere, but we've found that when you install a new package that has the same name as an old package already in /Library/Receipts, if the .bom file in the old package lists any installed files that do not exist in the new package's .bom file, the Installer will often delete such files (presumably under the assumption that the files are obsolete). The solution was simple: Build both the full installer and the updater, and then replace the updater's .bom with a copy of the full installer's. And the Installer never seems to complain about files named in the .bom that don't exist in the archive. Steve Stockman Software Architect Consumer Products - Macintosh Symantec Corporation www.symantec.com From: Robert Carroll <robc(a)total.net> Date: Sun, 9 Sep 2007 23:50:29 -0400 To: <installer-dev(a)lists.apple.com> Subject: packagemaker update problems Thanks for your reply Stephane. One cause of the problem with the updater has been somewhat identified. The full installer of my application bundle includes a folder inside "Resources" with a set of sound files. Since these files do not change with the updates, I do not include them in the updater package. In testing on my machines, if I don't at least leave the empty "Sounds" folder in the Resources folder, the update appears to delete this folder and its contents. Leaving the directory structure in place, correctly leaves the required sound files post update on my machine, but seems to still remove these files on some user's machines. I am trying to verify this. On Sep 8, 2007, at 3:05 PM, installer-dev-request(a)lists.apple.com wrote: >> >> The updater is set up to replace the app file in the MacOS folder of >> >> >> the client's currently installed version. >> >> >> It shouldn't touch any other files in the same package (ie. resource >> >> >> files or the encrypted registration info) and doesn't not >> >> >> replace or change anything elsewhere on the computer. >> >> >> >> >> >> Is this a known issue? Is there a safer and more reliable way to >> >> >> accomplish this kind of update? >> > > > > Regarding the permissions issues: > > > > > > - Which authorization are you requiring? I'm requiring administrator privileges to run either the installer or the updater. The files in the package mostly show me as the owner, read-only privileges or read-execute for others. Is it normal to leave myself as the owner, or more common to set this as root or something else? The resources folder must have read-write privileges for everyone, since the app will write encrypted registration data to this folder on its first run. It's possible this would be better if it was in the application support folder, but I prefer the concealed location in the app package. > > > > > > - Do you use a default location that is not '/'? No. > > > > > > - Which OS version is the update run on when it does not work? > > > > > > Regarding the "does not runt at all" issue: > > > > > > - Do you take into account the fact that the application may have been > > > moved by the customer? > > > > > > - Do you use a Locator to look for the location of the application? This is a valid concern. I don't currently check the installed file location, which would obviously foil the update. > > > > > > - Do you use Resource Fork for resources in your application? If so, do > > > you split fork when you're creating the packages? > I'm not using resource forks, however the sound files still have resource fork data. I would like to confirm that this data is not essential. At the moment the resource fork data is being preserved in the installer & updater pkgs. best wishes, Robert Carroll RSM Records Toronto http://www.rsmrecords.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

packagemaker update problems
by Robert Carroll 10 Sep '07

10 Sep '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: packagemaker update problems
by Stéphane Sudre 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On vendredi, septembre 7, 2007, at 01:35 PM, Robert Carroll wrote: HI, Regarding the permissions issues: - Which authorization are you requiring? - Do you use a default location that is not '/'? - Which OS version is the update run on when it does not work? Regarding the "does not runt at all" issue: - Do you use a Locator to look for the location of the application? _______________________________________________ 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'm new to this list, so please excuse me if this has been previously covered. I am using packagemaker built installers for both the full install and the updates for my software. So far, the installer works as expected on all client machines (with a couple of minor exceptions). The updater on the other hand, fails on about 25% of user's machines. That is, the updater process appears to work and exits correctly, but the updated app usually has lost the user's authorization, or just will not run at all. The updater is set up to replace the app file in the MacOS folder of the client's currently installed version. It shouldn't touch any other files in the same package (ie. resource files or the encrypted registration info) and doesn't not replace or change anything elsewhere on the computer. Is this a known issue? Is there a safer and more reliable way to accomplish this kind of update? - Do you take into account the fact that the application may have been moved by the customer? - Do you use Resource Fork for resources in your application? If so, do you split fork when you're creating the packages? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Distribution script format second (stupid) question
by Stéphane Sudre 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On jeudi, septembre 6, 2007, at 11:14 PM, Peter Bierman wrote: On mardi, septembre 4, 2007, at 09:39 PM, Peter Bierman wrote: I can't beat that hi-score. _______________________________________________ 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.… At 10:58 PM +0200 9/6/07, Stéphane Sudre wrote: <installer-gui-script> was the element name initially, but was simplified to <installer-script> before 10.4 went GM. Unfortunately, a lot of Apple software is built from templates, and things that aren't actively broken are low on the priority list for fixing. Then the templates get copied, and things like this linger for years. Well, maybe it will bee sooner than later since I filed a bug report against it... But having seen bug reports in some parts of the OS being addressed more than 3 years after their submission, I don't have great expectancies though. It's a question of priorities. Do we change (and re-test) something that isn't causing an actual problem, or do we fix a bug that's bothering someone? As you say, it depends on priority. But on the other hand, as people are using Apple's made packages as templates to create their own, you might end up with a bunch of externally made packages that include the incorrect tag and then you will have to support it even longer as if you break the backward compatibility, there will be someone filing a bug report or a DTS incident. Imagining that Apple was to release a new major OS version in a few months and a new format would be used for packages (as publicly stated on http://xarchiver.blogspot.com/ and in a post on the xar mailing list), wouldn't it be a great opportunity to deprecate this erroneous tag for new packages in this new format? These "correctness" bugs can end up languishing for years. The oldest one in my own queue is from 1995 (and yes, still relevant, sigh.) On the other side of that, I just had a bug returned to me to verify as fixed that I filed in 1998. This email sent to site_archiver(a)lists.apple.com

1 0

packagemaker update problems
by Robert Carroll 07 Sep '07

07 Sep '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: Distribution script format second (stupid) question
by Peter Bierman 06 Sep '07

06 Sep '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On mardi, septembre 4, 2007, at 09:39 PM, Peter Bierman wrote: But all bug reports are appreciated, even the low priority ones. -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.… At 10:58 PM +0200 9/6/07, Stéphane Sudre wrote: <installer-gui-script> was the element name initially, but was simplified to <installer-script> before 10.4 went GM. Unfortunately, a lot of Apple software is built from templates, and things that aren't actively broken are low on the priority list for fixing. Then the templates get copied, and things like this linger for years. Well, maybe it will bee sooner than later since I filed a bug report against it... But having seen bug reports in some parts of the OS being addressed more than 3 years after their submission, I don't have great expectancies though. It's a question of priorities. Do we change (and re-test) something that isn't causing an actual problem, or do we fix a bug that's bothering someone? These "correctness" bugs can end up languishing for years. The oldest one in my own queue is from 1995 (and yes, still relevant, sigh.) On the other side of that, I just had a bug returned to me to verify as fixed that I filed in 1998. This email sent to site_archiver(a)lists.apple.com

1 0