October 2009 - Installer-dev

Re: Fed up with PackageMaker, any advice?
by Iceberg-Dev 09 Oct '09

09 Oct '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=DZwhkX+doF+YZQxKPDlipvk6l4jBZJiOR2rldiPagzc=; b=X2t+DJrlndRZVxzjRkkjVyzCDf9bnXslI5cR5pIemmzp8NXGDOEkdMUBPNl+yRM0T6 vSJQH+gkyzzQgEZe5sh/3VghTZ/YH5zMboKQbltfdJ74FmHfA/6ykDyUBJ6hPjDMjCeT PuNGLJj+gdPt84OlyVs2i+doLQKEoDbS6zyMg= 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=rE6WqJNQ0hZ8hYCrP98d82ktBWAdviHp0vQV2PtOttlkejYO+6ejFeg3xfb9lf5Lgq EKADT1nILYeWMnaxv7cgZiO3oGhV2kvpr2h7M3QcqRZEDiJft4s0D7GpOTMgcnN9Jv5U WjoQpX68B2cZqdsqFpK14PHmABbLUqMuXUPQ0= On Oct 9, 2009, at 12:45 AM, Sidney San Martín wrote: _______________________________________________ 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 have been poking around inside installer packages for years. They always looked simple and straightforward: *Check scripts run, plugins run, pre* scripts run, files are copied and permissions are set, then post* scripts run. Simple. So I thought it would be painless to put together an installer package for a product of my own. The process turning out to be surprisingly headachy. Can any of you give some advice on taming this beast? Here's what I want to do: 1. Run a plugin to collect some setup information from the user (it's built) 2. Copy some files to a company-specific folder in Application Support 3. Copy a launchd.plist to /Library/LaunchDaemons 4. If running on >=10.5, copy a launchd.plist to /Library/LaunchAgents 5. Run a postflight script to do initialization (including launching a helper executable to add a global login item if running on <10.5) I also want to be able to build the installer from an XCode project (which will depend on its components' products) so I can build the product in full, in debug or release config, with one click and spit out an installer package (or, eventually, a disk image with a package inside it). Right now, I'm not at all close to that goal. I started out thinking that a simple package with a root of / containing the desired hierarchy was the most straightforward design, but saw a stern warning against that in the docs. It looks like the only option is a package containing subpackages (four of 'em) for each component, with appropriate roots. Apple does not follow this recommendation so just don't follow it if you don't want to. Just don't overwrite permissions and you will be fine. Yet, considering 4., I would recommend using 2 packages. one for the common components and another for the ones that need to be install only when specific requirements are met. I have no idea where to put my pre/postflight scripts, though. Apparently they can only be set for the subpackages, and there's a note in the docs stating "In Mac OS X v10.5 clients, the only install operations available are preinstall and postinstall." What the heck does that mean? What about preflight, postflight, preupgrade, and postupgrade? If only preinstall and postinstall are available, does that mean they'll be run every time? Either way, I don't NEED any of those advanced options, just a postflight guaranteed to run at the very end. PackageMaker itself seems to be able to create pre and postflight scripts (Actions tab), but there's no way to specify my own. If the OS target is 10.5, postinstall and preinstall are the same as postflight and preflight. This email sent to site_archiver(a)lists.apple.com

1 0

metapackage component conditionally set required
by Andy Mroczkowski 09 Oct '09

09 Oct '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi all, I have a metapackage that has two sub-components. These components install resources for a particular architecture (Intel or PPC). I can conditionally select or de-select the sub-components with requirements scripts, but I'd like to automatically make the appropriate component Required and disable the other component. For example, if I'm installing on an Intel macine, the Intel sub-component would be Required, while the PPC component would be disabled. Can this be accomplished? Thanks, Andy _______________________________________________ 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: Fed up with PackageMaker, any advice?
by Kevin Brock 09 Oct '09

09 Oct '09

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

Conditionally build different versions of a package?
by marc hoffman 09 Oct '09

09 Oct '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi. is this possible? thanx, marc _______________________________________________ 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've been staring at this problem for a while now and don't see an obvious solution, i'm hoping that someone can help out. as part of my (automated/scripted) build process, i would like to build two versions of my installer package, each of which would conditionally exclude/include a certain subset of components. more specifically, i'm installing a framework product, and would like to (obviously) exclude the source code and release level binaries from the trial version, and instead ship a differently-compiled trial binary of the framework. as my installer is deploying quite a few items that will be shared between trial and non-trial versions, i'd really love to avoid aintaining two separate copies of the .pmdoc, and be able to build both versions of the installer from one set of files. This email sent to site_archiver(a)lists.apple.com

1 0

Fed up with PackageMaker, any advice?
by Sidney San Martín 08 Oct '09

08 Oct '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com I have been poking around inside installer packages for years. They always looked simple and straightforward: *Check scripts run, plugins run, pre* scripts run, files are copied and permissions are set, then post* scripts run. Simple. So I thought it would be painless to put together an installer package for a product of my own. The process turning out to be surprisingly headachy. Can any of you give some advice on taming this beast? Here's what I want to do: 1. Run a plugin to collect some setup information from the user (it's built) 2. Copy some files to a company-specific folder in Application Support 3. Copy a launchd.plist to /Library/LaunchDaemons 4. If running on >=10.5, copy a launchd.plist to /Library/LaunchAgents 5. Run a postflight script to do initialization (including launching a helper executable to add a global login item if running on <10.5) I also want to be able to build the installer from an XCode project (which will depend on its components' products) so I can build the product in full, in debug or release config, with one click and spit out an installer package (or, eventually, a disk image with a package inside it). Right now, I'm not at all close to that goal. I started out thinking that a simple package with a root of / containing the desired hierarchy was the most straightforward design, but saw a stern warning against that in the docs. It looks like the only option is a package containing subpackages (four of 'em) for each component, with appropriate roots. I have no idea where to put my pre/postflight scripts, though. Apparently they can only be set for the subpackages, and there's a note in the docs stating "In Mac OS X v10.5 clients, the only install operations available are preinstall and postinstall." What the heck does that mean? What about preflight, postflight, preupgrade, and postupgrade? If only preinstall and postinstall are available, does that mean they'll be run every time? Either way, I don't NEED any of those advanced options, just a postflight guaranteed to run at the very end. PackageMaker itself seems to be able to create pre and postflight scripts (Actions tab), but there's no way to specify my own. PackageMaker is specifying everything with absolute paths (great, since this project may be moving around) and when I try to add a couple of binaries to the package's Resources folder through Raw Editing Mode, it includes them non-executable. I have also had PackageMaker try to munge my project a couple of times, including resetting all the permissions to defaults and spontaneously requiring logout on all my components. I'm fed up, and I'm also scared of the big mess of XML files that currently defines the installer. I would much What would ya'll suggest as far as implementing this (or any) package in the simplest and most useful (read: easy to modify, easy to script, less likely to spontaneously break) way? _______________________________________________ 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 ownership issues
by Jakub Bednar 08 Oct '09

08 Oct '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Oct 6, 2009, at 11:25 PM, Iceberg-Dev wrote: On Oct 6, 2009, at 12:24 PM, Jakub Bednar wrote: On Oct 5, 2009, at 9:56 PM, Iceberg-Dev wrote: On Oct 5, 2009, at 11:04 AM, Jakub Bednar wrote: On Oct 2, 2009, at 5:14 PM, Greg Neagle wrote: user/group info for filesystem items is _always_ stored as numeric values. When you create your user, specify the UID at that time as well. Well ok, You are probably right in 99% of the cases. But I'm installing a transparent proxy that needs a unique UID in the system to take advantage of UID matching in firewall rules. Never mind, there are workarounds. I was just wondering why it is not supported. Thanks a lot, Jakub P.S. There is a bunch of Linux/FreeBSD software that is creating new user accounts in the system for their purposes. It is just a normal way of doing things on Linux/FreeBSD. There is also no problem to create an invisible user without home directory and password with the dscl utility, so why not support it in Installers? It is supported since you can do it in a package with a script. It's just that it would not be a good idea for the Installer to create a new user account just because there is a file in the package payload whose owner does not exist on the target system. The way I need to go now to make pkgutil --repair work correctly is: _______________________________________________ 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.… [...] Apparently we do not understand each other. I know I can create the user in a preinstall script and I don't want installer to create him for me. What I want is to allow package maker, to store file ownership also by user name. With this the receipt files after installation will hold correct user/group specification of the newly created user by my preinstall script. pkgutil --repair will than work correctly repairing rights to the user my script has created on the system (and not to the UID/GID of that user on the system where the installation package was created, as it is now) If the package has the user specified by his name and the installer doesn't find the specified user in the target system when unpacking the files (after preinstall script), it should return an error and not unpack the files. 1. Create the user in preinstall script and install the files 2. Execute pkgutill --export-plist to get the current receipt plist with wrong UID/GID specifications 3. Do some seding to fix the UID/GID to match those of my newly created user in step 1 4. Execute pkgutil --import-plist to store this fixed plist back in receipts This is not really simple way how to have correct receipts stored in the system. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Problems creating "complex" installation
by Rob Keniger 08 Oct '09

08 Oct '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 08/10/2009, at 11:24 AM, Rob Keniger wrote: > I need to create an installer that can do the following: > > - install my app in /Applications > - install a bunch of plug-ins for other applications in various locations I'm following up on my own post... After many frustrating hours I've given up on PackageMaker 3.0 and Flat Packages. I have to say that dealing with the Installation system is BY FAR the worst experience I've had in five years doing Mac development. Compared to the Cocoa documentation, the Software Delivery and PackageMaker documentation is just a joke. I did figure out how to integrate installer plug-ins by manually inserting the correct files using the Flat Package Editor, but why is it this difficult? I found the Raw mode of PackageMaker but I was still unable to get my custom scripts installed in the correct locations and called successfully. It just should not be this hard. Anyway, here is what I plan to do with my problem. I've switched to Iceberg as unlike PackageMaker it's well-designed and well-documented. Iceberg lets me easily add InstallationCheck scripts to a package, so I can run my custom Launch Services command line script and skip the package if the required application is not installed. To install in the ~/Library/Application Support/Coda/Plug-ins/ folder, I let the installer install my plug-in to /Users/Shared and then use a postinstall script to move the file to the correct location. I did eventually find a note in the Software Distribution docs suggesting this. Does this sound like the right approach? I plan on filing bugs against the documentation, as well as a feature request to add a Launch Services check for existing applications, and one for allowing installation in the User's home folder. -- Rob Keniger _______________________________________________ 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

Problems creating "complex" installation
by Rob Keniger 08 Oct '09

08 Oct '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi all, It's been a few years since I used PackageMaker to build an installer and so PackageMaker 3 is new to me. I'm having problems. I need to create an installer that can do the following: - install my app in /Applications - install a bunch of plug-ins for other applications in various locations The problem I have is that each plug-in needs to be installed if and only if the application it supports is present. For example, I have a plug-in for Panic's Coda application that needs to be stored here: ~/Library/Application Support/Coda/Plug-ins/ So, in order to install it, I need to detect whether Coda is installed. From what I can tell, the installer's JavaScript support is only able to query running applications. So, I wrote a command line tool that uses Launch Services to check whether Coda exists, using a call like this: LSFindApplicationForInfo(kLSUnknownCreator, CFSTR("com.panic.Coda"), NULL, NULL, &appURLRef); The tool works fine and returns 0 if Coda exists and 1 if it doesn't, however basing the plug-in installation on "Result of Script" in PackageMaker does not seem to work, and in fact the installer doesn't include the command-line tool in the package, it just references the original file on my machine, so it can't work. The appallingly terse documentation for PackageMaker does not even mention the "result of script" step so I have no idea how this is supposed to work. I also can't see how to install to the user's Application Support folder. If I enter the installation path as "~/Library/Application Support/Coda/Plug-ins/" then I get a folder called "~" at the root of the installation volume. Not helpful. Is there a way to install in the user's domain? I am having trouble finding it. I thought that perhaps I could use Installer plug-ins to handle all of this, and I managed to find the example code and the headers that appear to be the only documentation for this. However, PackageMaker 3 seems to have no idea that installer plug-ins exist and since it no longer creates a bundle there seems to be no way to use them. I have downloaded Iceberg which appears at least to be sensibly designed and possibly flexible enough to do what I want but I must admit I am flailing at this point. Can anyone help me with any of the issues I'm having? Many thanks, -- Rob Keniger _______________________________________________ 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 allow for optional install?
by Iceberg-Dev 07 Oct '09

07 Oct '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=lRzVtmLGhAor0gzZcHeIaB1kGGuV5pyrXR1YfwD0158=; b=a+CPq0MOfczOP1rtxBrUjT9BXcXwvp+JECjXX5Buleg9kiMhQ5c9j2+MXrDoDoIdKS zrX7v0MRQzmvj7lzgrzz37dRsODQLaa7vD2g1c7fVedvSvuZu29sqjKYEQ/EY2FtOoSD 1vVSDJBBuVgqzEIH5DLOIOF0sm/UktJ8aSqS0= 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=il5r9fNWX0MnK6/pHkvbOTDPHmPkNcmdplQ1IScvkLdnWibSVWQWVMhRzUmwlvYyWR qK9/tIvhA8I2WHYQjY2/5knZij5FpbjNKEkH1LV9BIHBihTIG+LSnTnHSMPHPl32L747 0eH+Vo1/meuvNSvpjx/dMnxfL5sEoVFhTyLIY= On Oct 7, 2009, at 12:39 AM, Brant Sears wrote: _______________________________________________ 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 know how to do that - but I didn't know you could do it for things that weren't part of your package. This point is critical: At the time I make this installer I won't know what the custom install items are. I'm discovering these on the CD at the time the installer runs. If you don't know the list of all the potential packages and their locations when you create the distribution script, you would need to look at the solution suggested by Bill C. Just in case, it's easier to dynamically create a metapackage bundle than a distribution script. This email sent to site_archiver(a)lists.apple.com

1 0

Re: PackageMaker allow for optional install?
by Bill Coderre 06 Oct '09

06 Oct '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Oct 6, 2009, at 3:39 PM, Brant Sears wrote: > I know how to do that - but I didn't know you could do it for things that weren't part of your package. > > This point is critical: At the time I make this installer I won't know what the custom install items are. I'm discovering these on the CD at the time the installer runs. Tweaking a running installer is completely unsupported. You might be able to create a small program that scans the CD for packages, and creates an installer package on the fly, then opens the package with Installer.app. Apple has no such functionality to accomplish this, so you're on your own. This is not a trivial program to write, but could be done in under a week. Note that if you scan and create a "distribution" file, it could easily end up installing stuff that you should not install. For apps this might not be a big deal, but if you install an old kext on a new OS, it could cause crashes, so think carefully about what you are doing. So you probably should not create disks that include installers that install any extensions. If you scan and create a "bundle" installer, there would be a bunch of different issues to work out -- each individual package might be able to veto the installation of the entire collection. _______________________________________________ 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