October 2005 - Installer-dev

Installer.app and Package, Locked flags on a Folder
by Stéphane Sudre 05 Oct '05

05 Oct '05

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.… Is there something specific to make Installer.app set back the Folder flags for a Folder which had the following flags: Locked, Package? I'm manually creating a package and these flags are not set back after installation. I ran SplitForks (on 10.4.2) on the Folder itself but it looks like it's not enough. I had a look at the resulting AppleDouble file by removing the pax call, but the lack of a good documentation on the AppleDouble file format prevented me from finding whether the FolderInfo struct was correctly saved or not. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Install/Upgrade depends on CFBundleIdentifier?
by Christopher Ryan 05 Oct '05

05 Oct '05

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com The rules for matching are as follows: Of course you could also specify Which says not to obsolete anything. Chris Regards, Phill _______________________________________________ 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 The dependency on CFBundleIdentifier is on purpose. The Installer has switched to using an identifier (in this case the CFBundleIdentifier) for the upgrade logic. The name is to fragile and caused too many collisions. Imagine the scenario where two developers create a package of the same name (MusicApp.pkg). The results would be tragic. This created the need for the transition to an identifier. We still use the names in the case where CFBundleIdentifiers are not specified. 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. You are trying to make an upgrade only package. This concept doesn't officially exist (although it should and hopefully will in the future). To do what you are doing, you can use the Hints mechanism, however. Although I have found no Public documentation on such, this is how you use "hints" to do what you want. Check out some of the Apple receipts, they use a file named "Hints.plist" to specify a "hint" about a given file. In your Hints file you can specify that you do not want to obsolete (delete) a path (or a group of paths). Here is the example of a Hints.plist file that should be placed in the Resources directory of a package: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http:// www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <array> <array> <string>/Applications/My.app/Contents/Resources/English.lproj*</ string> <string>dontobsolete</string> </array> <array> <string>/Applications/My.app/Contents/Resources/French.lproj*</string> <string>dontobsolete</string> </array> </array> </plist> This says when installing, never obsolete the contents of the English and French .lproj. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http:// www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <array> <array> <string>/*</string> <string>dontobsolete</string> </array> </array> </plist> Remember, when you start playing that game, the day you want to actually obsolete files when you have a newer version of the app, you will need to do it via a script. Again, this limitation is known and we hope to have something better in the future. I used to believe that Installer made its "install vs upgrade" decision solely on whether there was a package of the same name in /Library/Receipts. To quote from the relevant page: "Installer uses the presence or absence of a receipt on the installation volume to determine whether an installation is an install or an upgrade. That is, Installer assumes software is being installed for the first time if there is no receipt with the same name as the package being installed. If there is such a receipt, the installation is an upgrade." To that end, whenever I have built an updater I have made sure that the installer package has always had a different name from what has gone before. However, when testing an updater package last week, I was surprised to find that even though (a) my package had a name of the form "product_1.2.3_updater.pkg" and (b) there was no receipt of that name in /Library/Receipts, the Installer presented me with the "Upgrade" button. There was a receipt with the name "product_1.2.2_updater.pkg". If I removed that from /Library/Receipts, Installer presented me with the "Install" button. If I returned "product_1.2.2_updater.pkg" to /Library/Receipt, Installer went back to "Upgrade". If I renamed "product_1.2.2_updater.pkg" to "Fred.pkg", Installer still presented me with "Upgrade". By trial and error, I reached the conclusion that the name of the receipt didn't matter but that Installer was looking at the value of CFBundleIdentifier in the packages' Info.plists. In the past, I have set the value of CFBundleIdentifier to be the same as the identifier of the application that the package is updating (previously via the PackageMaker GUI but these days by the -i parameter passed to the command-line packagemaker). By changing the value of CFBundleIdentifier to embed the version number (eg com.company.product_1.2.3_updater), I have been able to overcome this problem so that packages that are meant to update an existing application always show "Install", thereby only ever adding or replacing files (which is all my updater packages contain) and never attempting to delete any files on the assumption that non-presence in the updater package implies "no longer needed" as opposed to "no change". Has anyone else encountered this apparent dependence on CFBundleIdentifier or am I missing something? smime.p7s

1 0

Install/Upgrade depends on CFBundleIdentifier?
by Phill Kelley 05 Oct '05

05 Oct '05

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com I used to believe that Installer made its "install vs upgrade" decision solely on whether there was a package of the same name in /Library/Receipts. To quote from the relevant page: "Installer uses the presence or absence of a receipt on the installation volume to determine whether an installation is an install or an upgrade. That is, Installer assumes software is being installed for the first time if there is no receipt with the same name as the package being installed. If there is such a receipt, the installation is an upgrade." To that end, whenever I have built an updater I have made sure that the installer package has always had a different name from what has gone before. However, when testing an updater package last week, I was surprised to find that even though (a) my package had a name of the form "product_1.2.3_updater.pkg" and (b) there was no receipt of that name in /Library/Receipts, the Installer presented me with the "Upgrade" button. There was a receipt with the name "product_1.2.2_updater.pkg". If I removed that from /Library/Receipts, Installer presented me with the "Install" button. If I returned "product_1.2.2_updater.pkg" to /Library/Receipt, Installer went back to "Upgrade". If I renamed "product_1.2.2_updater.pkg" to "Fred.pkg", Installer still presented me with "Upgrade". By trial and error, I reached the conclusion that the name of the receipt didn't matter but that Installer was looking at the value of CFBundleIdentifier in the packages' Info.plists. In the past, I have set the value of CFBundleIdentifier to be the same as the identifier of the application that the package is updating (previously via the PackageMaker GUI but these days by the -i parameter passed to the command-line packagemaker). By changing the value of CFBundleIdentifier to embed the version number (eg com.company.product_1.2.3_updater), I have been able to overcome this problem so that packages that are meant to update an existing application always show "Install", thereby only ever adding or replacing files (which is all my updater packages contain) and never attempting to delete any files on the assumption that non-presence in the updater package implies "no longer needed" as opposed to "no change". Has anyone else encountered this apparent dependence on CFBundleIdentifier or am I missing something? Regards, Phill _______________________________________________ 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: Package Maker cpio+pax errors
by Stéphane Sudre 04 Oct '05

04 Oct '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On mardi, octobre 4, 2005, at 02:21 AM, Dimi Shahbaz wrote: Hi, [...] .... 2005-10-03 17:02:05.019 PackageMaker[5087] done (0) _______________________________________________ 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 attempting to use PackageMaker from the command line. My command line resembles: One reason could be that one of the owner or group for the files is a user-id or a group-id with a negative value (nobody | nogroup) or a value greater than 2^16-1. This email sent to site_archiver(a)lists.apple.com

1 0

Package Maker cpio+pax errors
by Dimi Shahbaz 04 Oct '05

04 Oct '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi, What could cause this? Thanks, Dimi _______________________________________________ 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 attempting to use PackageMaker from the command line. My command line resembles: /Developer/Applications/Utilities/PackageMaker.app/Contents/MacOS/ PackageMaker -build -p '/Users/dimi/source/MyPackage.pkg' -f '/Users/dimi/source/dist/' \ -r '/Users/dimi/source/resources/' -i '/Users/dimi/source/Info.plist' \ -d '/Users/dimi/source/Description.plist' And outputs: 2005-10-03 17:02:04.748 PackageMaker[5087] ** building a package at / Users/dimi/source/MyPackageOSX.pkg ** pax: Cpio header field is too small to store file . pax: Cpio header field is too small to store file ./Setup.app pax: Cpio header field is too small to store file ./Setup.app/Contents pax: Cpio header field is too small to store file ./Setup.app/ Contents/Frameworks pax: Cpio header field is too small to store file ./Setup.app/ Contents/Info.plist pax: Cpio header field is too small to store file ./Setup.app/ Contents/MacOS pax: Cpio header field is too small to store file ./Setup.app/ Contents/MacOS/Setup pax: Cpio header field is too small to store file ./Setup.app/ Contents/PkgInfo pax: Cpio header field is too small to store file ./Setup.app/ Contents/Resources pax: Cpio header field is too small to store file ./Setup.app/ Contents/Resources/__boot__.py pax: Cpio header field is too small to store file ./Setup.app/ Contents/Resources/__error__.sh .... 2005-10-03 17:02:05.019 PackageMaker[5087] done (0) This is with PackageMaker 1.1.11. I found someone with a similar problem here, but with no answers: http://lists.apple.com/archives/installer-dev/2005/Apr/msg00000.html I should mention that this only happens when one particular user tries to run the above command line. I can get it to work with a different user(!) My confusion runs deep. This email sent to site_archiver(a)lists.apple.com

1 0