March 2014 - Installer-dev - lists.apple.com

Re: Minimum operating system requirement in Packages
by Stephane Sudre 29 Mar '14

29 Mar '14

The latest intermediate build (here for 1.1.2) is available at: http://s.sudre.free.fr/files/Packages.pkg Only real limitation with intermediate builds is that the installation package at this URL is not "product signed" (the installed components are "codesigned"). On Fri, Mar 28, 2014 at 5:54 PM, Conor Schutzman <conor(a)mac.com> wrote: > Until Packages is updated, your best solution is (assuming you are building a flat distribution package): > * building the package in Packages > * expanding it with pkgutil > * manually editing the Distribution file > * re-flattening it with pkgutil > * distributing > > If you know your way around sed and such, it's not that hard to script it. > > > On Mar 28, 2014, at 2:56 AM, James Pritchard <james(a)emnetsoftware.com> wrote: > >> I'm creating a new distribution using Packages and would like to set the minimum operating system version to be 10.9. Previously using PackageMaker this was an editable field and easy to set but in Packages it's a drop down list box and the highest version available to me is 10.8. >> >> Does anyone know a way of changing this? I've tried uninstalling Packages and reinstalling in case it populates the field during install time but I still have the same list of OS versions available to me. >> _______________________________________________ >> 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: >> https://lists.apple.com/mailman/options/installer-dev/conor%40mac.com >> >> This email sent to conor(a)mac.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: > https://lists.apple.com/mailman/options/installer-dev/dev.iceberg%40gmail.c… > > This email sent to dev.iceberg(a)gmail.com -- Packaging Resources - http://s.sudre.free.fr/Packaging.html _______________________________________________ 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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Minimum operating system requirement in Packages
by Matthias Schroeder 28 Mar '14

28 Mar '14

On 03/28/2014 05:54 PM, Conor Schutzman wrote: Until Packages is updated, your best solution is (assuming you are building a flat distribution package): • building the package in Packages • expanding it with pkgutil • manually editing the Distribution file • re-flattening it with pkgutil • distributing - make a copy of the pkgproj file - open the pkgproj file with a text-editor - search for 'IC_REQUIREMENT_OS_MINIMUM_VERSION' - change the number in the line below to '100900' - save the file - try to build The only thing that can't be edited that way are the Project Comments. Cheers, Matthias If you know your way around sed and such, it’s not that hard to script it. On Mar 28, 2014, at 2:56 AM, James Pritchard <james(a)emnetsoftware.com> wrote: I'm creating a new distribution using Packages and would like to set the minimum operating system version to be 10.9. Previously using PackageMaker this was an editable field and easy to set but in Packages it's a drop down list box and the highest version available to me is 10.8. Does anyone know a way of changing this? I've tried uninstalling Packages and reinstalling in case it populates the field during install time but I still have the same list of OS versions available to me. _______________________________________________ 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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com That looks like a lot of work. I'm not sure whether the following works, but I would I love how you can modify the pkgproj file and run packages from the command line. For almost all of my cases I run scripts that modify the pkgproj file with sed (including version strings that are all over the pkgproj file), do the packaging, do the signing and have the final packages without any further intervention. If Packages has a check which values for IC_REQUIREMENT_OS_MINIMUM_VERSION are allowed this will not work, but it is worth a try.

1 0

Re: Minimum operating system requirement in Packages
by Conor Schutzman 28 Mar '14

28 Mar '14

Until Packages is updated, your best solution is (assuming you are building a flat distribution package): • building the package in Packages • expanding it with pkgutil • manually editing the Distribution file • re-flattening it with pkgutil • distributing If you know your way around sed and such, it’s not that hard to script it. On Mar 28, 2014, at 2:56 AM, James Pritchard <james(a)emnetsoftware.com> wrote: > I'm creating a new distribution using Packages and would like to set the minimum operating system version to be 10.9. Previously using PackageMaker this was an editable field and easy to set but in Packages it's a drop down list box and the highest version available to me is 10.8. > > Does anyone know a way of changing this? I've tried uninstalling Packages and reinstalling in case it populates the field during install time but I still have the same list of OS versions available to me. > _______________________________________________ > 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: > https://lists.apple.com/mailman/options/installer-dev/conor%40mac.com > > This email sent to conor(a)mac.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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Minimum operating system requirement in Packages
by James Pritchard 28 Mar '14

28 Mar '14

_______________________________________________ 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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com I'm creating a new distribution using Packages and would like to set the minimum operating system version to be 10.9. Previously using PackageMaker this was an editable field and easy to set but in Packages it's a drop down list box and the highest version available to me is 10.8. Does anyone know a way of changing this? I've tried uninstalling Packages and reinstalling in case it populates the field during install time but I still have the same list of OS versions available to me.

1 0

Re: Conditionally destination for package
by Matthias Schroeder 21 Mar '14

21 Mar '14

Hi, On 03/19/2014 12:37 AM, Stephane Sudre wrote: ... Basically the idea here is to avoid a copy or a move from the post install script. if requirementA then install packageA if requirementB then install packageB if requirementC then install packageC Matthias _______________________________________________ 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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com That brings up another question: is there a way that I can avoid this copy or move when I repackage something? My use case is the following: We have Product A, already in form of a package or an Installer app. We want to add Product B (and sometimes product C), also in form of a package. What I currently do is to create a distribution package that has packages A,B and C as payload, and run the command line installer on the delivered payload. For small packages this is no big issue, but for larger packages the re-shuffling of the data costs a lot of time. Is there a more economic way to tell Packages

1 0

Re: Conditionally destination for package
by Matthias Schroeder 21 Mar '14

21 Mar '14

Hi Bill, On 03/19/2014 07:27 PM, Bill Coderre wrote: In these days of security risks, let me point out that Installer provides an environment variable called INSTALLER_TEMP which points to a secure folder that is created by Installer at the very start of installation, and deleted at the very end. Please use it instead of /tmp whenever possible! Why? Let’s suppose that I am a 14 year old who knows that my school is going to install a certain package, and that package writes to /tmp/cookie. So I create a symbolic link from that to, say, a web filtering program. Now when the install happens, the web filter gets deleted. YAY. Matthias _______________________________________________ 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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com Thanks a lot for pointing this out! I was already wondering how I could create such a folder and pass the info about it to the various parts of the package. Are there already any files or directories inside INSTALLER_TEMP used by the installer itself, so that my scripts should avoid touching them? The "Software Delivery Legacy Guide" is not very detailed in that respect. And that is probably one of the less dangerous abuses (except for the legal department).

1 0

Re: Conditionally destination for package
by Bill Coderre 19 Mar '14

19 Mar '14

In these days of security risks, let me point out that Installer provides an environment variable called INSTALLER_TEMP which points to a secure folder that is created by Installer at the very start of installation, and deleted at the very end. Please use it instead of /tmp whenever possible! Why? Let’s suppose that I am a 14 year old who knows that my school is going to install a certain package, and that package writes to /tmp/cookie. So I create a symbolic link from that to, say, a web filtering program. Now when the install happens, the web filter gets deleted. YAY. On Mar 19, 2014, at 2:45 AM, Stephane Sudre <dev.iceberg(a)gmail.com> wrote: > On Wed, Mar 19, 2014 at 6:33 AM, Edward Spiegel <lists(a)edwardspiegel.org> wrote: >> Hi, >> >> Thanks for the ideas. I am not sure that I quite understand. >> >> A couple of questions: >> >> what is an invisible package? > > It's a standard package inside the distribution but the corresponding > choice is hidden (in the Installation Type pane if you allow the user > to see the available choices). > >> Is the cookie being created with javascript or is there a way to create it >> with a shell script? > > By cookie, I just mean a file (with a value or not) that you can > create with touch(1). > >> Is this a correct paraphrase of this technique: >> >> ) the installer will be set up to always install the supporting files into >> location A >> ) location A will either be a real location or a symbolic link to the actual >> destination (either location B or C) if A does not really exist >> ) the cookie is used to tell the installer whether a symbolic link was used, >> in which case it will be deleted at the end > > That's the first possible alternative. > >> Would this technique work: >> ) use the script to create a symbolic link in /tmp to whichever A,B or C is >> found to exist >> ) install into /tmp/symboliclink? > > That's the second possible alternative. > _______________________________________________ > 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: > https://lists.apple.com/mailman/options/installer-dev/bc%40apple.com > > This email sent to bc(a)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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Conditionally destination for package
by Stephane Sudre 19 Mar '14

19 Mar '14

On Wed, Mar 19, 2014 at 6:33 AM, Edward Spiegel <lists(a)edwardspiegel.org> wrote: > Hi, > > Thanks for the ideas. I am not sure that I quite understand. > > A couple of questions: > > what is an invisible package? It's a standard package inside the distribution but the corresponding choice is hidden (in the Installation Type pane if you allow the user to see the available choices). > Is the cookie being created with javascript or is there a way to create it > with a shell script? By cookie, I just mean a file (with a value or not) that you can create with touch(1). > Is this a correct paraphrase of this technique: > > ) the installer will be set up to always install the supporting files into > location A > ) location A will either be a real location or a symbolic link to the actual > destination (either location B or C) if A does not really exist > ) the cookie is used to tell the installer whether a symbolic link was used, > in which case it will be deleted at the end That's the first possible alternative. > Would this technique work: > ) use the script to create a symbolic link in /tmp to whichever A,B or C is > found to exist > ) install into /tmp/symboliclink? That's the second possible alternative. _______________________________________________ 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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Conditionally destination for package
by Edward Spiegel 19 Mar '14

19 Mar '14

_______________________________________________ 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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Conditionally destination for package
by Stephane Sudre 18 Mar '14

18 Mar '14

Another possible solution (if we assume that the application is in one package and the supporting files in another one): - Always install the supporting files to A and be sure to follow symbolic links. - Add 2 invisible packages with empty payloads. This would like this: --+-- distribution --+-- Application Package | +-- Invisible Package P1 | +-- Supporting Files Package | +-- Invisible Package P2 P1 would have a pre or post installation script whose sole purpose in life is to check for the existence of folder A: - if A exists, it just exit. - if B exists: it creates a symbolic link to B at location A, set a cookie in /tmp and exit. - if C exists: it creates a symbolic link to C at location A, set a cookie in /tmp and exit. - if none of these case, it exits with 1. P2 would check for the presence of the cookie and remove the appropriate symbolic link. ------------ Another way to do it is to use only 1 invisible package P1 and have the supporting package always install to a fixed location in /tmp (such as /tmp/mypackageidentifier). P1 would check which folder is to be the final target and then create a symbolic link from /tmp/mypackageidentifier to the appropriate folder. ------------ Basically the idea here is to avoid a copy or a move from the post install script. On Tue, Mar 18, 2014 at 7:16 PM, Matthias Schroeder <Matthias.Schroder(a)cern.ch> wrote: > Hi Edward, > > On 03/18/2014 06:05 PM, Edward Spiegel wrote: >> >> Hi, >> >> One of the installers that I have to build installs an app plus a folder >> of supporting files. >> >> There are 3 possible destinations for the folder of supporting files and >> it is easy for me to detect the correct destination by checking for the >> location of a couple of folders in well-defined places. Since the >> payload is pretty large (a few hundred megabytes of audio files), I'd >> like to have only a single instance of the payload in the installer and >> to be able to have the installer put it in the right place. >> >> What I want to do is test for the presence of target folder A and if it >> is there deliver the payload there and go on to potential targets B and >> C if A is not present. >> >> Any suggestions about the best way to accomplish this? > > > If you don't have any user-selectable options you can just put your payload > somewhere in /tmp, and check in a post-install script whether A, B or C > exist. Then you do a command line install of the package in /tmp into A, B > or C in that same post-install script. > > But this does not work if the user is supposed to select or deselect part of > the payload. > > Maybe somebody has a nicer solution that allows true interaction with the > user. > > Hope this helps, > > Matthias > >> >> Best, >> >> Edward >> >> >> _______________________________________________ >> 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: >> >> https://lists.apple.com/mailman/options/installer-dev/matthias.schroder%40c… >> >> This email sent to matthias.schroder(a)cern.ch >> > > _______________________________________________ > 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: > https://lists.apple.com/mailman/options/installer-dev/dev.iceberg%40gmail.c… > > This email sent to dev.iceberg(a)gmail.com -- Packaging Resources - http://s.sudre.free.fr/Packaging.html _______________________________________________ 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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0