February 2009 - Installer-dev

Re: Understanding RunAtStartup
by Fred Licht 14 Feb '09

14 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com -Fred On Feb 14, 2009, at 4:10 AM, Iceberg-Dev wrote: On Feb 14, 2009, at 1:56 AM, Fred Licht wrote: IIRC, this script is launched on the next restart. It is only launched if: - you required root authentication for the package - the package requires a restart. _______________________________________________ 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.… Thanks for the replying. I know and understand what this RunAtStartup purpose is. I am asking if anyone knows what the installer does to the system to prepare for the script to run at start. Does it create a startup item, enable a launchd script, put the script in a special location for the reboot to use. Hey Everyone, I know that Apple's installer will respect the "RunAtStartup" script for an installer script. Does anyone know what actually happens with that script and where it is placed to be run at boot time? For the location, you can use fs_usage to check where the file will get installed. This may require a remote connection as Installer.app may or may not copy this file after the user has been logged out. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding RunAtStartup
by Iceberg-Dev 14 Feb '09

14 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=slIdawW+Xeqg3/6dFEJiAClAZvIPLKB/ryC0ftLu3kY=; b=B6KA+z3lLcJLY2dt+MxCR2w9D4rVbDzjGM+D7LdY986C9G3HPxP6KvU5zjQGSJGF3z oaM3u/Sqt6gFvEhetKypyqpRIA/i9Tlm0HGctk2z93WrNiGOYTeW28keo8kFvxeidIyr 1emsa3gqAmqzD3rz/2Mq5Uf2jrZv3fMb/D4Ug= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=oDxP//T/5mVkJSWZbPPsijoEuQLuszG9zzwhD+MaF0rvwZWnE5iIfCT5QwRs9BWfez SA24ExhoJ3Jtx45vVa6qQzpb+SZDQGRl7v9yWVQjFq025Yiq+YB7a+3ksVAgNZSbyrqe ockMBHi2gcRaMpMgPrB6DzWexuMBP6ric6ypc= On Feb 14, 2009, at 1:56 AM, Fred Licht wrote: IIRC, this script is launched on the next restart. It is only launched if: - you required root authentication for the package - the package requires a restart. _______________________________________________ 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.… Hey Everyone, I know that Apple's installer will respect the "RunAtStartup" script for an installer script. Does anyone know what actually happens with that script and where it is placed to be run at boot time? For the location, you can use fs_usage to check where the file will get installed. This may require a remote connection as Installer.app may or may not copy this file after the user has been logged out. This email sent to site_archiver(a)lists.apple.com

1 0

Re: updaters
by Piotr Rychlik 14 Feb '09

14 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Feb 13, 2009, at 7:00 PM, Greg Neagle wrote: It depends on what you mean by updater. _______________________________________________ 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.… An installation package that checks for a certain previous version of an application, then installs the changed files/directories, is an effectively an updater and is certainly possible with PackageMaker. If you mean something that actually patches files ala diff/patch, then, no, you can't do that easily with PackageMaker (you _could_ with a postflight script, but that's really violating the spirit of install packages) By updater I mean an installation package that replaces old files. I have no idea how to get rid of interface components such as Introduction, Destination Select, Installation Type, etc. I want the updater to immediately start updating and showing the progress. I don't know what should I specify as "Install Destination". I guess none of the listed options (Volume selected by user, System volume, User home directory) should be checked. I also guess that "Destination" field for each file that is going to be updated should be blank. This email sent to site_archiver(a)lists.apple.com

1 0

Understanding RunAtStartup
by Fred Licht 14 Feb '09

14 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thanks, Fred _______________________________________________ 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.… Hey Everyone, I know that Apple's installer will respect the "RunAtStartup" script for an installer script. Does anyone know what actually happens with that script and where it is placed to be run at boot time? This email sent to site_archiver(a)lists.apple.com

1 0

Re: updaters
by Iceberg-Dev 13 Feb '09

13 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:in-reply-to :references:content-type:message-id:content-transfer-encoding:from :subject:date:to:x-mailer; bh=Ek3ouluZrk53VsSYDXOitJ39ykoDagHKdUwIqEL90Jo=; b=TzGaH7PBpYfsdRVzrLIW2Xs9J+Uswl7EUL8WuRw/Eue7geo/8kg2mrrc/eZvjuv9D6 /h/hFRdGpMzklkC4HYE6QbLYQqrub23TPqkSzzKni8j/fuqmZvRoXl306XtwX42HROXX CDhjCvCaGMeDX7qy7ghhOQZ3JmpiVlIr6h1UY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer; b=NjJtoP68YoBTVwqd5G19ve5M9qdOs/xlcMzD+XLdewJ54ogWaurHdlzJ94zZBZNOIx eZ5lKiLWYA5YJvqYPtL8D0FgG+U6v8nlLVLqSEfyoAjxUVhfXuYCNtyP3Ac0So80hxAx lozmeFFsHmcH3unZlyVBorVLFdZbeTO1kz5b8= On Feb 13, 2009, at 7:00 PM, Greg Neagle wrote: It depends on what you mean by updater. _______________________________________________ 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.… An installation package that checks for a certain previous version of an application, then installs the changed files/directories, is an effectively an updater and is certainly possible with PackageMaker. If you mean something that actually patches files ala diff/patch, then, no, you can't do that easily with PackageMaker (you _could_ with a postflight script, but that's really violating the spirit of install packages) I can't run on Leopard to check this but I tend to remember that there is a patch feature in PackageMaker 3. This email sent to site_archiver(a)lists.apple.com

1 0

Re: updaters
by Greg Neagle 13 Feb '09

13 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com It depends on what you mean by updater. -Greg On Feb 13, 2009, at 9:51 AM, Piotr Rychlik wrote: Hi, Piotr Rychlik _______________________________________________ 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/greg.neagle%40disneyan… _______________________________________________ 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.… An installation package that checks for a certain previous version of an application, then installs the changed files/directories, is an effectively an updater and is certainly possible with PackageMaker. If you mean something that actually patches files ala diff/patch, then, no, you can't do that easily with PackageMaker (you _could_ with a postflight script, but that's really violating the spirit of install packages) I am using PackageMaker tocreate installers for my application. It seems, however that with PackageMaker it is not possible to create updaters. How can I create an udater to an application installed by the installer created by PackageMaker? This email sent to greg.neagle(a)disneyanimation.com This email sent to site_archiver(a)lists.apple.com

1 0

updaters
by Piotr Rychlik 13 Feb '09

13 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi, Piotr Rychlik _______________________________________________ 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 using PackageMaker tocreate installers for my application. It seems, however that with PackageMaker it is not possible to create updaters. How can I create an udater to an application installed by the installer created by PackageMaker? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer created in 10.4 crashes in 10.5
by Paul Wasmund 10 Feb '09

10 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Paul On Jan 15, 2008, at 9:53 PM, David Nock wrote: Hi, The install.log shows the following: The crash.log shows the following: Date/Time: 2008-01-16 16:09:12.976 +1300 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 8 Does this mean anything to anyone?? Dave _______________________________________________ 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/pwasmund%40orderndev.c… This email sent to pwasmund(a)orderndev.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 same thing is happening to me. I am generating my installer with the PackageMaker 2.1.1 and have the problem installing on recent version of Mac OS 10.5. Does anyone know what is causing this type of crash? I've just been testing our software in Leopard and the first problem is that the installer crashes when it is finishing. Everything of ours seems to been installed correctly. This installer was created with PackageMaker running in 10.4 and I'm installing into a clean install of 10.5 with the 10.5.1 update. Jan 16 16:09:02 imac Installer[149]: Starting installation: Jan 16 16:09:02 imac Installer[149]: Finalizing installation. Jan 16 16:09:12 imac Installer[149]: An exception was thrown from the install queue while running IFEndOfInstallElement. NSInvalidReceivePortException. connection went invalid while waiting for a reply. Process: Installer [149] Path: /System/Library/CoreServices/Installer.app/Contents/ MacOS/Installer Identifier: com.apple.installer Version: 3.0.1 (278) Build Info: Installer-2780000~2 Code Type: X86 (Native) Parent Process: launchd [84] Application Specific Information: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[IFRunnerProxy restoreUIDs]: unrecognized selector sent to instance 0x30b43b50' This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installing command line tools
by Nigel Kersten 09 Feb '09

09 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Sun, Feb 8, 2009 at 7:38 PM, Eli Bach <ebach2(a)gmail.com> wrote: > > On Feb 8, 2009, at 7:18 PM, Brent Burton wrote: > >> OK, this is a huge reason to not use a postinstall-based technique. I >> agree, >> how else can a real uninstaller begin to work if we're hacking the >> process? > > I would say this isn't exactly a great reason, because Apple has had 10 > years of complaints about not having an uninstaller of any kind. From going > to WWDC, I have never heard Apple even hint about ever adding such > functionality (other than, file a bug report and we'll consider it). > > So it's up to individuals to create uninstallers for their own setup, which > can be quite straightforward to create, and doesn't depend on what is listed > in the Package to do it's work. You would need to do this anyway, to clean > up auxiliary files, such as preferences or cache/data files that are created > when your application runs. Greg and I have been having this discussion for a while now, and he has put together some really interesting code to try to automate the uninstallation process for packages. This isn't the biggest reason for me as someone who deals with packages every day and has to mange many many thousands of Macs though, but it is closely related. If developers continue to do hacky things with regard to destinations (and I've seen Apple people suggest this on this list, something I strongly disagree with) then it not only makes such tools well nigh impossible to develop, but it makes auditing and troubleshooting incredibly difficult. To take a simple example... If you want to make packages of Ruby modules that work on 10.4 and 10.5, you usually want the destination to be /usr/lib/ruby/site_ruby/1.8. On 10.4 this is a directory. On 10.5 it is a symlink. We rely heavily upon Ruby for our internal management systems, and there are many Ruby packages out there that install to /usr/lib/rub/site_ruby/1.8, but don't follow symlinks, breaking all existing Ruby modules in the process of wiping out the symlink. Trying to audit which packages are causing these problems is rather difficult when the bom doesn't actually contain the true destination. We have to deal with problems like this every day. Correlating dates in /Library/Receipts or installer logs with incidents is not my idea of a good time. _______________________________________________ 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: Installing command line tools
by Greg Neagle 09 Feb '09

09 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com -Greg On Feb 9, 2009, at 9:47 AM, Brent Burton wrote: On Mon, Feb 9, 2009 at 10:14 AM, Greg Neagle <Greg.Neagle(a)disneyanimation.com> wrote: On Feb 8, 2009, at 7:18 PM, Brent Burton wrote: Hence my "This is reasonable behavior, but is a bit too loose." comment at the end of that paragraph. My point being, the results you get if you do it this way may not be the values you want at install time. _______________________________________________ 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 guess this behavior is totally expected to me because the classic way of creating a package was to create a "fauxroot" directory, place all your files and directories within, make sure they all had the permissions, owners, and groups you wanted, and pass the "fauxroot" directory to packagemaker (or even pax!). packagemaker/pax would just archive the files as-is. Basically, PM will indeed expand a directory when the package is built. The limitation is that for any file that is expanded that was not listed in the .pmdoc, PM will use the filesystem's mode & ownership. What else could it possibly use? Without any information to the contrary, the current mode, owner and group must be assumed to be correct... This email sent to site_archiver(a)lists.apple.com

1 0