February 2009 - Installer-dev

Upgrading with a metapackage or distribution in PackageMaker
by Dymyr Winicki 22 Feb '09

22 Feb '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 I can create a metapackage using PackageMaker where the individual packages will upgrade (and not downgrade) the modules they contain, however when I use these packages within the metapackage they just update (upgrade and downgrade) As far as I can see I do not have the downgrade option selected however this is through the flag - I cannot seem to add anything to the components window (and none of the documentation tells you how to do this. I find the whole layout of package maker very intuitive and useful at the package level, however I need to use it at the metapackage level for the upgrade of certain components and I am unable to get this to work. I am using v3.0.2 of packagemaker (however I have tried this on the previous version as well and it didn't work then)

1 0

Re: Nested or Hierarchal Options at Install Time?
by Paul Cook 22 Feb '09

22 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Best Wishes, Paul On Feb 20, 2009, at 4:39 AM, Iceberg-Dev wrote: On Feb 20, 2009, at 4:32 AM, Paul Cook 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.… Thanks very much. That is exactly the question that I was after. This is one of those things where once you have it you go "duh!, why couldn't I get that to work before?" For any future person attempting this for the first time and for whom this is also less than obvious, here's a verbose version of the answer. First add your top level choice by dragging contents into the "Contents" pane of the PackageMaker window. (Or add your top level choice with the "add Contents...", "Add Snapshot Package", "Add Package Reference" or "Add Choice items" from the pull down Project menu or the gear shaped menu icon at the bottom of the "Contents" pane of the PackageMaker window. To make a second level choice, select one of the first level choices in the "Contents" pane of the PackageMaker window. Make sure that you select the choice itself and not a Package within it. Now select the "Add Choice" menu option from either the pull down "Projects" menu at the top of the screen, or from the gear shaped menu at the bottom of "Contents" pane in the PackageMaker window. If you would like this choice to have contents, you may add those contents either by dragging them onto the choice. Hope this helps someone else. And I hope I've properly used the PackageMaker vocabulary in this answer. How do you create a package so that the user experience sees nested or hierarchal options at install time? If you're referring to the "Installation Type" step, this can be done by embedding a choice within a choice (in the left/source list of a PackageMaker document). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Nested or Hierarchal Options at Install Time?
by Iceberg-Dev 20 Feb '09

20 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=8alsMNao7EjeUepz7uG3OO4/efzf3tcNrQdc/9brS9w=; b=ePEiBpLnEUqDjJb9pnFKHSKu/w8TwQqMS/LXhX2Y1ip2I5A7gpAXM/6nv3m65T6kV5 XME6D4hs3uvH+KzVn5GLBNJSbTO6tij8Zm2VSO7mwu47pMrzpYbQTadFkY+mq5bmyG8M GSRrX4EMwOGtGHpiQRTmko3cDfVZGIKo3AD/g= 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=PeQgqasCz5olsIiJjX2UYKp7J5kKwFSCr+Tn9lDjH+VcOZpOrmWVWTmFgGLnPYq1Ar f8LjtchpbvU8Ir4byJbqbH5KbQHWtTiXyjFZitxPd83BIuktxBkojXkyHEo0MdYyzfLh w5DTrj8ugDS3/VoVtpTMDbH2zUzdq7WRmbOKk= On Feb 20, 2009, at 4:32 AM, Paul Cook 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.… How do you create a package so that the user experience sees nested or hierarchal options at install time? If you're referring to the "Installation Type" step, this can be done by embedding a choice within a choice (in the left/source list of a PackageMaker document). This email sent to site_archiver(a)lists.apple.com

1 0

Nested or Hierarchal Options at Install Time?
by Paul Cook 20 Feb '09

20 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thanks in advance for any help, Best Wishes, Paul How do you create a package so that the user experience sees nested or hierarchal options at install time? I want to give the user a couple of main options and if those are selected, I want to enable sub options. But how do I create something where the user sees some nesting or something similar to convey that there is a hierarchal relationship and that these are sub-options? I'm using Apple's PackageMaker 3.0.3 and my targets are all Leopard. I've tried various things, looked over all the menu options, etc. but can't quite figure out how to get any result other than that the user sees a flat list of choices. P.S. I apologize if this is a newbie question. I've made a number packages that work. And with effort, I've figured out quite a bit. But this has me stumped. I've even resorted to reading Apple's documentation--"PackageMaker User Guide" and "Software Delivery Guide" as well as searching the logs of this list. _______________________________________________ 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: updaters
by Greg Neagle 19 Feb '09

19 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com You can read them with lsbom; you can make them with mkbom. man lsbom man mkbom for more info. -Greg On Feb 19, 2009, at 6:51 AM, Glover,David wrote: Just out of interest how do you open / edit .bom files? -----Original Message----- From: installer-dev-bounces+david.glover=prometheanworld.com(a)lists.apple.com [mailto:installer-dev-bounces+david.glover=prometheanworld.com@lists.app le.com] On Behalf Of Iceberg-Dev Sent: 18 February 2009 22:46 To: Greg Neagle Cc: Installer-Dev mailing-list Subject: Re: updaters On Feb 17, 2009, at 6:45 PM, Greg Neagle wrote: As a systems administrator, I expect the changes an installation package makes to be documented in the Archive.bom (for bundle-style receipts), or in the receipts database (for Leopard-style flat packages). I don't expect to have to reverse engineer what a postinstall script installed. What's possible to do is this: - have a .bom file that describes what will get installed. - install nothing from the pax payload - install everything from a postinstall script. It just requires to build a standard package and a package that installs nothing. You then replace the .pax[.gz] payload with the one from the empty package. When you install this package through Installer.app (tested on Tiger): - when you display the list of files from the UI, it lists the files - when you run the installation, it installs nothing and succeeds. _______________________________________________ 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/david.glover%40prom etheanworld.com This email sent to david.glover(a)prometheanworld.com Promethean Ltd and or associated and or subsidiary companies : This e-mail is for the exclusive use of the addressee(s). Unauthorised disclosure, copying or distribution is prohibited. ***************************************************************** This email has been checked by the e-Sweeper Service ***************************************************************** _______________________________________________ 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 pipe lsbom's output to a text file and then edit it, you can use mkbom -i textfile to make a new bom from the edit. Promethean Limited is a company registered in England and Wales with company number 1308938 and VAT number GB 572 2599 18 ______________________________________________ The views expressed in this communication may not necessarily be the views held by Promethean Ltd and or associated and or subsidiary companies. This e-mail message has been swept for the presence of computer viruses. Promethean Ltd and or associated and or subsidiary companies accepts no liability for any loss resulting from this email transmission. Promethean, Promethean House, Lower Philips Road, Blackburn, Lancashire, BB1 5TH, UK. Please update your records accordingly. Thank you! This email sent to site_archiver(a)lists.apple.com

1 0

RE: updaters
by Glover,David 19 Feb '09

19 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcmSGqnCHzCs5khtRA+jC/ZYbhZXBwAhnvgw Thread-topic: updaters Just out of interest how do you open / edit .bom files? -----Original Message----- From: installer-dev-bounces+david.glover=prometheanworld.com(a)lists.apple.com [mailto:installer-dev-bounces+david.glover=prometheanworld.com@lists.app le.com] On Behalf Of Iceberg-Dev Sent: 18 February 2009 22:46 To: Greg Neagle Cc: Installer-Dev mailing-list Subject: Re: updaters On Feb 17, 2009, at 6:45 PM, Greg Neagle wrote: > As a systems administrator, I expect the changes an installation > package makes to be documented in the Archive.bom (for bundle-style > receipts), or in the receipts database (for Leopard-style flat > packages). I don't expect to have to reverse engineer what a > postinstall script installed. What's possible to do is this: - have a .bom file that describes what will get installed. - install nothing from the pax payload - install everything from a postinstall script. It just requires to build a standard package and a package that installs nothing. You then replace the .pax[.gz] payload with the one from the empty package. When you install this package through Installer.app (tested on Tiger): - when you display the list of files from the UI, it lists the files - when you run the installation, it installs nothing and succeeds. _______________________________________________ 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/david.glover%40prom etheanworld.com This email sent to david.glover(a)prometheanworld.com Promethean Limited is a company registered in England and Wales with company number 1308938 and VAT number GB 572 2599 18 ______________________________________________ Promethean Ltd and or associated and or subsidiary companies : The views expressed in this communication may not necessarily be the views held by Promethean Ltd and or associated and or subsidiary companies. This e-mail is for the exclusive use of the addressee(s). Unauthorised disclosure, copying or distribution is prohibited. This e-mail message has been swept for the presence of computer viruses. Promethean Ltd and or associated and or subsidiary companies accepts no liability for any loss resulting from this email transmission. Promethean, Promethean House, Lower Philips Road, Blackburn, Lancashire, BB1 5TH, UK. Please update your records accordingly. Thank you! ***************************************************************** This email has been checked by the e-Sweeper Service ***************************************************************** _______________________________________________ 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: updaters
by Crawford Kyle 19 Feb '09

19 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:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=9v0MlfXiZdx4a2kz4zknzEPMnu8pvdvrM9A9YDtnh7Y=; b=T7LqYi+Qy3xHQpZqKOiqWb1DY174Z9xc3yK6gnzOSL3veSmiz67FprZPYZnKzeCZnT XrXaiSoTjOXB/yUatUVaXgQt79/G133u3ioMJtFgmDiRiqcDI8aUdF9wP8O7jFDaZaeO SM8PpMTHNUJUIhs+2C3I7qtuQQfkDVO3p5paI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=FUT/fW/D3hR4kh2yiSOpeVTCShbpLvRtD8viFoAKtzceUJiXrAs07ZJ4n9sYXqE6bl px7wjd++YbqYJ3eH5WC1UtgQaH/PevATnynM7WlHPA/hxkiAg4jsIkVG/cpjFS2/XFx4 UVsTDUll83YrOYiTVG54OrljDQ+/Z+Ay8e+5k= On Feb 18, 2009, at 5:45 PM, Iceberg-Dev wrote: On Feb 17, 2009, at 6:45 PM, Greg Neagle wrote: What's possible to do is this: - have a .bom file that describes what will get installed. - install nothing from the pax payload - install everything from a postinstall script. - when you display the list of files from the UI, it lists the files Kyle _______________________________________________ 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.… As a systems administrator, I expect the changes an installation package makes to be documented in the Archive.bom (for bundle-style receipts), or in the receipts database (for Leopard-style flat packages). I don't expect to have to reverse engineer what a postinstall script installed. It just requires to build a standard package and a package that installs nothing. You then replace the .pax[.gz] payload with the one from the empty package. When you install this package through Installer.app (tested on Tiger): - when you run the installation, it installs nothing and succeeds. This seems like a good idea. Is there a way Apple could enforce this? For example the installer would warn if the installer wrote files not listed in the bom. There needs to be incentive to do the right thing. The goal here is to keep us sysadmins happy and potentially allow for uninstalls without having to reverse engineer and repackage packages provided from software vendors. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Re: updaters
by Dymyr Winicki 19 Feb '09

19 Feb '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

Re: updaters
by Dodger 19 Feb '09

19 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:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pBwpbNzuVB7nezSeyppBonk4HNWrJH2YjRTZ2h84m7M=; b=WUbn3ee6l048V81N4Z9hwbFgLTnbt8TZTtoieRoElabfHlif/R3dz95FAKjky1sHDc q8S0DtuGhFVfz0uGGtKuMgnW/nck6RxhHlPdcliH9Zdd6aASghA1uX/bFs5irdJELGqd kdS3+vKywUVOp04odRVhFciSZeZSjk6vXLuAE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gATSN8PWqB2BYtJkkMXZMJSXHuuUDYeJT+uYGNFuJWgqTA9O+QOMQLAdX3pcTFazjl JroGhTpWeAR0t5Oc5FC26AnSxSIUKnZQp+Moc9UltZS5cW/OGZ1iEwUCi/EhtTigDht2 b950Em/YMZvcagbziR9a9TUGFUv5frAM7RQ5Y= Yup yup. I'd also like them to fix that preflight/preinstal absolute path problem. Setting a script invisible in the root of the DMG is a hack at best, but it's the only think I can think to do to. 2009/2/18 Karl Kuehn <kuehn.karl(a)gmail.com>: > On Feb 18, 2009, at 3:01 PM, Dodger wrote: > >>> I've been thinking about this. Is there a way Apple could disallow these >>> arbitrary installer scripts and still support the scenarios that seem to >>> require them? Perhaps this warrants a separate thread. >> >> If you mean disallow any external scripts, well, there's a reason >> they're allowed: to allow for things they haven't foreseen. I know my >> problem would be very unlikely to be handled in the packagemaker app, >> for instance (i.e. applying a morph target to an Alias Wavefront Maya >> object file and saving out the results). If Apple foresaw that need, >> they probably *still* wouldn't include the possibility because it >> would be so rare. > > I agree completely that there is no way that Apple could get rid > scripts from installers. I think that the better way of making both the > installer-writers and the system-admins happy would be to have a way for > installer script to tell the installer program that they had touched > specific files so that the installer could then communicate that > appropriately (through .bom's, etc). And vitally important: document that as > an important thing. > > What I would want in the perfect installer program has been in my > mind much recently, and since nobody asked here are a few things that I > would want: > > - Ability to sandbox/chroot the installer scripts so that it only used and > wrote to the target volume > > - The same as above, but for the javascript sections of the installer > > - An explicit mechanism for licensing/registration systems. I am thinking > about something like a plugin system, but with the ability to pass the > licensing/registration information from the command line for command-line > installs. It would also allow for a GUI that would provide the information > to the Plugin the same way. I don't want Apple to mess around with trying to > do this themselves, but rather to provide a consistent interface for > package-developers to do so. > > - Better documentation and examples of how to write all of the javascript > components now allowed (documentation on this is really hard to find) > > - Apple emphasizing to installer writers (both internal and external) that > their installers will not always be used by consumers on a single machine > that they are logged into. (InstaDMG has become the lens I view this > thorough) > > And on the really-out-there field: > > - Redo the conversion to XAR and this time don't just wrap a CPIO inside a > XAR but rather extend XAR to handle all of the cases the CPIO handles. With > some careful work this would allow for tools like Radmind to work directly > with .pkg's rather than replace them. > > -- > Karl Kuehn > larkost(a)softhome.net > > > > _______________________________________________ > 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/el.dodgero%40gmail.com > > This email sent to el.dodgero(a)gmail.com > -- Dodger _______________________________________________ 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: updaters
by Karl Kuehn 18 Feb '09

18 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:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=7RzRWK9t1oFvvNUZSeK41YNHjxeUtNZOxHh/d7nvBVM=; b=dBmIXfXsPhxgBGA36xHN8NpZoexCyBVVHIQTG4f51Hc2XR1ktwbh5QXq2L/W2w/kSG l5eZrRUHp+UpL3wnJ8wzivAaufv0+uydq7jrqxQsrO086x17+wS30DYPGfVXtXOnfx5z kxaM7ZJlYbmpgRswvg8fxpb6XW5pgh7oysqdM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=ZIl5ZBMnevsVJAVfbDOsjy5kNNZADbOLGoj0GUQPUeRDMfUuvo+H/TXTS5BO+L9VBW urQHuijZruIwjBaUXVW+n5atBf+Dpyu9SDYujPo7FSnlCRXmmqwhfb0uFzj8LH0OPWmg Mmcf+/TxYVzU3p7VthHIXoBsPMHyvj97M5+Kw= On Feb 18, 2009, at 3:01 PM, Dodger wrote: If you mean disallow any external scripts, well, there's a reason they're allowed: to allow for things they haven't foreseen. I know my problem would be very unlikely to be handled in the packagemaker app, for instance (i.e. applying a morph target to an Alias Wavefront Maya object file and saving out the results). If Apple foresaw that need, they probably *still* wouldn't include the possibility because it would be so rare. - The same as above, but for the javascript sections of the installer And on the really-out-there field: -- Karl Kuehn larkost(a)softhome.net _______________________________________________ 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 thinking about this. Is there a way Apple could disallow these arbitrary installer scripts and still support the scenarios that seem to require them? Perhaps this warrants a separate thread. I agree completely that there is no way that Apple could get rid scripts from installers. I think that the better way of making both the installer-writers and the system-admins happy would be to have a way for installer script to tell the installer program that they had touched specific files so that the installer could then communicate that appropriately (through .bom's, etc). And vitally important: document that as an important thing. What I would want in the perfect installer program has been in my mind much recently, and since nobody asked here are a few things that I would want: - Ability to sandbox/chroot the installer scripts so that it only used and wrote to the target volume - An explicit mechanism for licensing/registration systems. I am thinking about something like a plugin system, but with the ability to pass the licensing/registration information from the command line for command-line installs. It would also allow for a GUI that would provide the information to the Plugin the same way. I don't want Apple to mess around with trying to do this themselves, but rather to provide a consistent interface for package-developers to do so. - Better documentation and examples of how to write all of the javascript components now allowed (documentation on this is really hard to find) - Apple emphasizing to installer writers (both internal and external) that their installers will not always be used by consumers on a single machine that they are logged into. (InstaDMG has become the lens I view this thorough) - Redo the conversion to XAR and this time don't just wrap a CPIO inside a XAR but rather extend XAR to handle all of the cases the CPIO handles. With some careful work this would allow for tools like Radmind to work directly with .pkg's rather than replace them. This email sent to site_archiver(a)lists.apple.com

1 0