September 2005 - Installer-dev

Re: How to Cancel an install when Search Methods don't find anything
by John Kirkham 26 Sep '05

26 Sep '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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to Cancel an install when Search Methods don't find anything
by Mark Krenek 26 Sep '05

26 Sep '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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to Cancel an install when Search Methods don't find anything
by Stéphane Sudre 26 Sep '05

26 Sep '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On dimanche, septembre 25, 2005, at 08:17 PM, Mark Krenek wrote: Possible workarounds: * Ugly: set the default location to be /tmp. This won't prevent the installation from being run but: - the update won't be installed somewhere the user can see it - if it does not find it, it just displays an alert. _______________________________________________ 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 short question: Is there any way to prevent an installation from continuing if one of the search methods (BundleIdentifierSearch, CommonAppSearch, etc.) fails to find an applicable target? [...] - you can check in a postflight script for the presence of some of your files in /tmp. Since this is quite an improbable location, you can be quite sure that when the files are installed in /tmp, this means the original application was not there. * Not too bad: Use a metapackage to do something similar but to avoid installing any real files in /tmp. - You would need one package which will just contain the folder of your bundle (let's hope you're using a bundle app) and which installs it by default in /tmp. You would need a search path to locate the location of your previous version. - The second package will have a preinstall and a preupgrade script which will look for the presence of the folder of the first package in /tmp. If it's in /tmp, this means there is no previous version and so you can fail the installation with a return code. Note: Somehow you need to remove the folder in /tmp at one point with the 2 former somutions so that you can later launch the installation with no surprises. * Complex but a bit smart: Create a small Cocoa or Carbon bundle application which looks for the location of your previous application using the LaunchServices API. - if it finds the previous version, it launches the installation by "opening" the package You can cheat by using a package standard icon for this tool and adding the real package in the Resources of this little application. This email sent to site_archiver(a)lists.apple.com

1 0

How to Cancel an install when Search Methods don't find anything
by Mark Krenek 25 Sep '05

25 Sep '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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Apple's installer and background.tif
by Christopher Ryan 18 Sep '05

18 Sep '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Stéphane, 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 can't speak for the developers who created the package, but my guess is that they did not want the default background picture shipped with that specific OS, so they just put a blank on in. A waste? Probably, maybe that means here should be an option for no background. Is there any reason to add a 1MB transparent background.tif image to a package? I'm looking at the iPod Updater 2005-06-26 for Jaguar and there's a 1MB completely transparent background.tif file in the Resources folder. Does the presence of a background picture add some features to installation on Jaguar? smime.p7s

1 0

Apple's installer and background.tif
by Stéphane Sudre 17 Sep '05

17 Sep '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 any reason to add a 1MB transparent background.tif image to a package? I'm looking at the iPod Updater 2005-06-26 for Jaguar and there's a 1MB completely transparent background.tif file in the Resources folder. Does the presence of a background picture add some features to installation on Jaguar? This email sent to site_archiver(a)lists.apple.com

1 0

iTunes 5.0 package
by Stéphane Sudre 07 Sep '05

07 Sep '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com the permissions on /Library are set to drwxrwxr-x. But this reminded me about this point: _______________________________________________ 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 iTunesX.pkg for iTunes 5.0 is interesting from a certain point of view: The fact is that the permissions for /Library are/shall be drwxrwxr-t (because of Mac OS X Tiger). This has no influence since the IFPkgFlagOverwritePermissions is NO. Is there still no Technote or QA or documentation describing what the permissions shall be for the common folders? I haven't found one yet. BTW, is the "requiredSLA" key a private key to state that if the update is made via Software Update it's required to display the Software Licence Agreement? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Permissions - OS 10.3.7 - PackageMaker
by Pavol Markovic 05 Sep '05

05 Sep '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Sep 3, 2005, at 12:22 AM, Stéphane Sudre wrote: On vendredi, septembre 2, 2005, at 11:32 PM, Pavol Markovic wrote: On Aug 31, 2005, at 10:53 PM, Peter Bierman wrote: To overwrite directory permissions. It may not work if the requested privileges are not the proper one. This option shall probably not be used if: - you're not 100% sure about the permissions Pavol Markovic _______________________________________________ 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.… If you insist on packaging existing system directories into your package, then you'll have to be sure that you get the owners, groups, and permissions correct on those directories. And if Apple changes them (or any other developer doing the same thing), then there will be inconsistencies, and users will need to use repair permissions (which more or less just looks at Apple packages to settle the disagreements.) So what's the purpose of "Overwrite Directory Permissions" checkbox in PackageMaker? This doesn't make sense for me. - the archive files are relocatable (because you can't be sure the final location is the one you think it is). Another reason not to use it even if you know what you're doing is that the team responsible for the directory permissions of Mac OS X is playing a funny game which consists to change the permissions of some common folders without any warning between 2 major releases: for instance in Mac OS X 10.4, the /Library folder now has a sticky bit which it didn't have before. In Mac OS X 10.3, items in StartupItems were not all root and wheel, now they need to be, etc... If you're not 100% sure about what you're doing, you should not be using it IMHO. My $0.02 Thanks, I understand the problem from this side. I'm just expecting that the permissions will stay unchanged if I leave the checkbox off. But that's not true when I have directory structure included in package. That's what I consider fuzzy. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Permissions - OS 10.3.7 - PackageMaker
by Stéphane Sudre 02 Sep '05

02 Sep '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On vendredi, septembre 2, 2005, at 11:32 PM, Pavol Markovic wrote: On Aug 31, 2005, at 10:53 PM, Peter Bierman wrote: To overwrite directory permissions. It may not work if the requested privileges are not the proper one. This option shall probably not be used if: - you're not 100% sure about the permissions 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.… If you insist on packaging existing system directories into your package, then you'll have to be sure that you get the owners, groups, and permissions correct on those directories. And if Apple changes them (or any other developer doing the same thing), then there will be inconsistencies, and users will need to use repair permissions (which more or less just looks at Apple packages to settle the disagreements.) So what's the purpose of "Overwrite Directory Permissions" checkbox in PackageMaker? This doesn't make sense for me. - the archive files are relocatable (because you can't be sure the final location is the one you think it is). Another reason not to use it even if you know what you're doing is that the team responsible for the directory permissions of Mac OS X is playing a funny game which consists to change the permissions of some common folders without any warning between 2 major releases: for instance in Mac OS X 10.4, the /Library folder now has a sticky bit which it didn't have before. In Mac OS X 10.3, items in StartupItems were not all root and wheel, now they need to be, etc... If you're not 100% sure about what you're doing, you should not be using it IMHO. This email sent to site_archiver(a)lists.apple.com

1 0

RE: Installing a shared library
by Jay Prunty 02 Sep '05

02 Sep '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kFZ6A/uGMz1z2fU0xmChp4nFcRSPg1ZGG3nBiJdHGqnhltvJkCgc2g2rQnMb2b7EBo21ANYJt2FYm8nzQDe/6K+IdVrwPTQjCOh6dCZBbt8DP3gXkcK/BM7Gz/Yfs1gPq4G/sqFOFGWETPVw31Y6rhuW7AhcnDxM0m6r6Gjrb7Y= ; The library was a fat binary, so clicking the Install Fat binary option in the configuration tab solved this. Thanks Jay >I'm trying to make an installer using package maker >that installs an application and a shared library. >The problem is when the shared library is installed, >it is 20k smaller and seen as a document and not a >shared library. > >Thanks > >Jay __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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