May 2005 - Installer-dev - lists.apple.com

Re: 10.4.1 Installer problem
by Michael Krugman 12 May '05

12 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Ken: Mike On May 12, 2005, at 8:09 AM, Ken Hawkins wrote: doesn't fix a potential problem but will give you a work around! ken; On May 11, 2005, at 7:54 PM, Michael Krugman wrote: Sincerely, This email sent to rosewoodblues(a)mac.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.… I did try to use a postflight script to set them. The problem is that if they are wrong, Tiger will give an error message. If you choose Fix, the permissions are set correctly, then the system will hang during restart. If the postflight script sets the correct permissions, the error message does not occur, but the system hangs during restart anyway. have you tried using a postflight script to properly set the file permissions? you could do that..... I am working on a G5 iMac with Tiger 10.4.1 (both updates) installed. We have been using PackageMaker as our installer for our aMac Digital Radiography OS X software. PackageMaker was working perfectly under 10.3 and some of the developer versions of 10.4. In the last pre-release version of Tiger (the same one that was released to the public), we discovered a problem with PackageMaker installing a file to the /Library/StartupItems folder. We did file a bug report, number 4112817 which has not yet been responded to. The problem is this: When our application is installed, a restart is required. After the installation is complete, and the Restart button within Installer is clicked, the computer begins to shut down. All of the icons disappear the the Finder is closed. At this point, the system hangs and will not continue to shut down the rest of the way, or restart, unless I manually turn the computer off via the on off switch and manually turn the computer back on again. As I said, this problem did not exist on any other OS X version, except 10.4 and now 10.4.1. One other thing we discovered...if the permissions of the installed file in /Library/StartupItems are not exactly the same as the /Library/StartupItems folder, Tiger will throw an error that says the security settings of a file in /Library/StartupItems must be repaired. It gives the option to fix, decide later or disable. Clicking fix gives a dialog that the repair was complete and you must restart. Clicking the restart button gives the exact same results....icons disappear, finder closes and system hangs until I manually turn the computer off, then on again. If the permissions are correct, the error dialog does not appear, but the system hangs as I explained earlier. Can someone give me a suggestion as to what I can do, if anything, to either stop this problem or work around it? Most of our clients have upgraded to Tiger and it doesn't go over with them very well with respect to manually turning the computer off, then back on again. Help on this is appreciated. Mike Krugman President and Chief Developer aMac Digital Radiography _______________________________________________ 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/rosewoodblues% 40mac.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: 10.4.1 Installer problem
by Stéphane Sudre 12 May '05

12 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com jeudi 12 mai 2005, à 01:54 AM, Michael Krugman a écrit : 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.… I am working on a G5 iMac with Tiger 10.4.1 (both updates) installed. We have been using PackageMaker as our installer for our aMac Digital Radiography OS X software. PackageMaker was working perfectly under 10.3 and some of the developer versions of 10.4. [...] One other thing we discovered...if the permissions of the installed file in /Library/StartupItems are not exactly the same as the /Library/StartupItems folder, Tiger will throw an error that says the security settings of a file in /Library/StartupItems must be repaired. It gives the option to fix, decide later or disable. Clicking fix gives a dialog that the repair was complete and you must restart. Clicking the restart button gives the exact same results....icons disappear, finder closes and system hangs until I manually turn the computer off, then on again. If the permissions are correct, the error dialog does not appear, but the system hangs as I explained earlier. Can someone give me a suggestion as to what I can do, if anything, to either stop this problem or work around it? Most of our clients have upgraded to Tiger and it doesn't go over with them very well with respect to manually turning the computer off, then back on again. Help on this is appreciated. 1. It can't be a problem with PackageMaker since PackageMaker does not install Packages, it just builds them. 2. It's probably not a problem with Installer.app because when the permissions are incorrect, you're not seeing the problem from what I understand. BTW "funny" discovery in Tiger, the /Library is now 1775 when it was 775 on previous versions. 3. Are you installing a Kernel Extension in /Library/StartupItems? Because what you're describing looks like a freeze caused by a wrong mutex lock (that's what I was seeing yesterday when testing some mutex locking). Depending on how your startup script is written, your startupitem may get launched on shutdown and your kext may get loaded. This email sent to site_archiver(a)lists.apple.com

1 0

Re: 10.4.1 Installer problem
by Peter Bierman 12 May '05

12 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Does the system hang happen at a blue screen? Is there a small animated "gear" at the bottom center of the screen? How long have you left the machine in this state before removing power? -pmb Sincerely, Mike Krugman President and Chief Developer aMac Digital Radiography _______________________________________________ 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.… 10.4.1 has not been released, and discussion of such on a public mailing list is a violation of your NDA. However, your bug does not appear to be related to 10.4.1, so let's just forget that for now and focus on 10.4.0 :-) Can you reproduce this without using the installer? What happens if you use 'ditto' or 'cp' to install various parts of your software? Please contact me privately with these responses and I will try to make sure your bug report is directed to the appropriate engineers. At 6:54 PM -0500 5/11/05, Michael Krugman wrote: I am working on a G5 iMac with Tiger 10.4.1 (both updates) installed. We have been using PackageMaker as our installer for our aMac Digital Radiography OS X software. PackageMaker was working perfectly under 10.3 and some of the developer versions of 10.4. In the last pre-release version of Tiger (the same one that was released to the public), we discovered a problem with PackageMaker installing a file to the /Library/StartupItems folder. We did file a bug report, number 4112817 which has not yet been responded to. The problem is this: When our application is installed, a restart is required. After the installation is complete, and the Restart button within Installer is clicked, the computer begins to shut down. All of the icons disappear the the Finder is closed. At this point, the system hangs and will not continue to shut down the rest of the way, or restart, unless I manually turn the computer off via the on off switch and manually turn the computer back on again. As I said, this problem did not exist on any other OS X version, except 10.4 and now 10.4.1. One other thing we discovered...if the permissions of the installed file in /Library/StartupItems are not exactly the same as the /Library/StartupItems folder, Tiger will throw an error that says the security settings of a file in /Library/StartupItems must be repaired. It gives the option to fix, decide later or disable. Clicking fix gives a dialog that the repair was complete and you must restart. Clicking the restart button gives the exact same results....icons disappear, finder closes and system hangs until I manually turn the computer off, then on again. If the permissions are correct, the error dialog does not appear, but the system hangs as I explained earlier. Can someone give me a suggestion as to what I can do, if anything, to either stop this problem or work around it? Most of our clients have upgraded to Tiger and it doesn't go over with them very well with respect to manually turning the computer off, then back on again. Help on this is appreciated. This email sent to bierman(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

10.4.1 Installer problem
by Michael Krugman 11 May '05

11 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Sincerely, Mike Krugman President and Chief Developer aMac Digital Radiography _______________________________________________ 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 am working on a G5 iMac with Tiger 10.4.1 (both updates) installed. We have been using PackageMaker as our installer for our aMac Digital Radiography OS X software. PackageMaker was working perfectly under 10.3 and some of the developer versions of 10.4. In the last pre-release version of Tiger (the same one that was released to the public), we discovered a problem with PackageMaker installing a file to the /Library/StartupItems folder. We did file a bug report, number 4112817 which has not yet been responded to. The problem is this: When our application is installed, a restart is required. After the installation is complete, and the Restart button within Installer is clicked, the computer begins to shut down. All of the icons disappear the the Finder is closed. At this point, the system hangs and will not continue to shut down the rest of the way, or restart, unless I manually turn the computer off via the on off switch and manually turn the computer back on again. As I said, this problem did not exist on any other OS X version, except 10.4 and now 10.4.1. One other thing we discovered...if the permissions of the installed file in /Library/StartupItems are not exactly the same as the / Library/StartupItems folder, Tiger will throw an error that says the security settings of a file in /Library/StartupItems must be repaired. It gives the option to fix, decide later or disable. Clicking fix gives a dialog that the repair was complete and you must restart. Clicking the restart button gives the exact same results....icons disappear, finder closes and system hangs until I manually turn the computer off, then on again. If the permissions are correct, the error dialog does not appear, but the system hangs as I explained earlier. Can someone give me a suggestion as to what I can do, if anything, to either stop this problem or work around it? Most of our clients have upgraded to Tiger and it doesn't go over with them very well with respect to manually turning the computer off, then back on again. Help on this is appreciated. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Tiger’s Installer deletes files during an update
by Christopher Ryan 11 May '05

11 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On May 11, 2005, at 2:39 AM, Jens Adam wrote: Christopher, thanks for replying quickly. Unfortunately, your answer contradicts my findings. The name matching was what I guessed. But the pre-Tiger installers did not remove items. This irritates me even more. My packages have the same name but different bundle identifiers. According to your explanation, the different identifiers should prevent Tiger from even looking at the package name. The rules for upgrade in Tiger are: Can I overwrite the default behaviour? I assume you could have a hint that says: <array> <string>/*</string> <string>dontobsolete</string> </array> Thanks, Jens _______________________________________________ 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 combined several package into a meta package to install an application. Later, I made an updater, again combined *.pkg in a *.mpkg. The updater contains changed and new items only. The Installer has always obsoleted files that were in the old package but not the new package, that is how upgrades work. As I wrote in my original message, my updater works in pre-Tiger system versions. That is, items are replaced and added but no item is removed because it is erroneously considered obsolete. It worked in the past with Jaguar and Panther, I verified it today with OS X 10.3.9. The removal happens only with the Tiger installer, so something must have changed. There is no real support for an "updater" package, the only way to do it (and the way Apple does it for Software Updates, unfortunately) is to change the name of the package (for Panther) and the bundle identifier of the package (for Tiger). Note that previous to Tiger, the name of the package is what what made two packages the same (for upgrade behavior). As of Tiger, the Installer uses the bundle identifier. To be compatible with old packages which may not have expected the bundle identifier to be used, the name is also consulted if there are more then one package installed with the same bundle identifier (and if there is no bundle identifier). Well, this is the catch. Because some developers just starting using bundle identifiers (they weren't told otherwise), we had to match on either or. If the name and identifier of a package matches only 1 receipt, then it uses that receipt for upgrades. If not, then check to see if any 1 receipt matches the package identifier, if so, use that receipt for upgrades. If not, then check to see if there is 1 package with the same name, if so, use that receipt for upgrades. Otherwise, it is a clean install. The idea is to switch everyone over to bundle identifiers for Tiger, but since we cannot change packages that have shipped in the past (and since bundle identifiers weren't used in the past), there needs to be a "compatibility" mode For most software projects, this automatic upgrade behavior is what they what, so it is the default behavior. Yes, although I could find no public documentation. Do a search for "Hints.plist" in your receipt directory (find . -name "Hints.plist" - print). You will see a number of Apple packages which use the hints mechanism to prevent obsoletion in some cases. Basically saying don't obsolete anything (although you will have to try that out and see if it works). The problem is, that in the future when you do want upgrade behavior (to remove old files) it will see your "update package" which only contains a few files and you will have a hard time removing all the pieces of the original install on upgrade (if they are truely not part of your product anymore) without writing a script to do it by hand, since the last receipt for a given package is all that sticks around. This worked well on pre-Tiger systems. If the Installer shipped with Tiger is used for the update, all files installed by the original package but not contained in the update package are deleted. The application is completely ruined. The installer log of the updater contains lines talking about the removal of obsolete files. Who decides which files are obsolete? Shouldn’t that be the package author? Is it possible to prevent this kind of damage by other means than * putting everything into an updater, thus making it a full installer? * changing package names, thus damaging the idea of receipts? Please let me know if you would like me to provide my packages for your inspection. Please send me the packages privately (or how to get them) I would like to see why you are not seeing upgrade behavior on Jaguar/ Panther, but are on Tiger. Chris This email sent to site_archiver(a)lists.apple.com

1 0

Re: Tiger’s Installer deletes files during an update
by Jens Adam 11 May '05

11 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) Christopher, thanks for replying quickly. Unfortunately, your answer contradicts my findings. As I wrote in my original message, my updater works in pre-Tiger system versions. That is, items are replaced and added but no item is removed because it is erroneously considered obsolete. It worked in the past with Jaguar and Panther, I verified it today with OS X 10.3.9. The removal happens only with the Tiger installer, so something must have changed. The name matching was what I guessed. But the pre-Tiger installers did not remove items. This irritates me even more. My packages have the same name but different bundle identifiers. According to your explanation, the different identifiers should prevent Tiger from even looking at the package name. Can I overwrite the default behaviour? Chris Is it possible to prevent this kind of damage by other means than * putting everything into an updater, thus making it a full installer? * changing package names, thus damaging the idea of receipts? Please let me know if you would like me to provide my packages for your inspection. Jens _______________________________________________ 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 combined several package into a meta package to install an application. Later, I made an updater, again combined *.pkg in a *.mpkg. The updater contains changed and new items only. The Installer has always obsoleted files that were in the old package but not the new package, that is how upgrades work. There is no real support for an "updater" package, the only way to do it (and the way Apple does it for Software Updates, unfortunately) is to change the name of the package (for Panther) and the bundle identifier of the package (for Tiger). Note that previous to Tiger, the name of the package is what what made two packages the same (for upgrade behavior). As of Tiger, the Installer uses the bundle identifier. To be compatible with old packages which may not have expected the bundle identifier to be used, the name is also consulted if there are more then one package installed with the same bundle identifier (and if there is no bundle identifier). For most software projects, this automatic upgrade behavior is what they what, so it is the default behavior. This worked well on pre-Tiger systems. If the Installer shipped with Tiger is used for the update, all files installed by the original package but not contained in the update package are deleted. The application is completely ruined. The installer log of the updater contains lines talking about the removal of obsolete files. Who decides which files are obsolete? Shouldn’t that be the package author? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Tiger’s Installer deletes files during an update
by Christopher Ryan 10 May '05

10 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Jens, Hi, Chris Jens _______________________________________________ _______________________________________________ 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 combined several package into a meta package to install an application. Later, I made an updater, again combined *.pkg in a *.mpkg. The updater contains changed and new items only. The Installer has always obsoleted files that were in the old package but not the new package, that is how upgrades work. There is no real support for an "updater" package, the only way to do it (and the way Apple does it for Software Updates, unfortunately) is to change the name of the package (for Panther) and the bundle identifier of the package (for Tiger). Note that previous to Tiger, the name of the package is what what made two packages the same (for upgrade behavior). As of Tiger, the Installer uses the bundle identifier. To be compatible with old packages which may not have expected the bundle identifier to be used, the name is also consulted if there are more then one package installed with the same bundle identifier (and if there is no bundle identifier). For most software projects, this automatic upgrade behavior is what they what, so it is the default behavior. This worked well on pre-Tiger systems. If the Installer shipped with Tiger is used for the update, all files installed by the original package but not contained in the update package are deleted. The application is completely ruined. The installer log of the updater contains lines talking about the removal of obsolete files. Who decides which files are obsolete? Shouldn’t that be the package author? Is it possible to prevent this kind of damage by other means than * putting everything into an updater, thus making it a full installer? * changing package names, thus damaging the idea of receipts? This email sent to site_archiver(a)lists.apple.com

1 0

Tiger’s Installer deletes files during an update
by Jens Adam 10 May '05

10 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi, Is it possible to prevent this kind of damage by other means than * putting everything into an updater, thus making it a full installer? * changing package names, thus damaging the idea of receipts? Jens _______________________________________________ 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 combined several package into a meta package to install an application. Later, I made an updater, again combined *.pkg in a *.mpkg. The updater contains changed and new items only. This worked well on pre-Tiger systems. If the Installer shipped with Tiger is used for the update, all files installed by the original package but not contained in the update package are deleted. The application is completely ruined. The installer log of the updater contains lines talking about the removal of obsolete files. Who decides which files are obsolete? Shouldn’t that be the package author? This email sent to site_archiver(a)lists.apple.com

1 0

Re: meta-package created on 10.3 won't install on 10.2
by Matt DeFoor 09 May '05

09 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Have you tried using root auth instead of admin? This seems to have fixed the install problem on 10.2. Cheers, Matt _______________________________________________ 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 only difference is _supposed_ to be that users in the admin group won't have to enter their password, but it wouldn't be the first time some other side effect crept in. This email sent to site_archiver(a)lists.apple.com

1 0

Re: requirements
by Stéphane Sudre 07 May '05

07 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com samedi 7 mai 2005, à 06:26 PM, Chuck Soper a écrit : If you want to restrict installation to 10.4 and later, you can: _______________________________________________ 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 afraid that having the requirement may prevent other users from installing and buying my software. Perhaps, I should remove the requirements dictionary from my installer entirely. Is it hurting more than helping? What do you think? IMHO, I think it's super useless for the following reason: it won't prevent users on 10.1 and 10.2 from installing your package since Requirements are available for 10.3 and later. - use a VolumeCheck script: you can find a lot of these things in Apple's packages. That's what I'm using for a package since Mac OS X 10.1.1 and it has yet to fail me. - create a distribution script package. This way, it might not even be possible to start installing it on OS prior to 10.3. I really wish that the PackageMaker application had a simple interface to specify at least the minimum OS version and that it worked > reliably. There's something like this I think for Distribution Scripts but I don't remember if it's for the destination volume or the running OS. The installer should be a developer's friend. It took a while to figure out how to add this requirements dictionary and the only thing it seems to have accomplished is to prevent potential customers from installing my demo software. Well, you know, with every installation solution, the motto is: "Build once, test everywhere". This email sent to site_archiver(a)lists.apple.com

1 0