April 2013 - Installer-dev - lists.apple.com

Re: productbuild(1) distribution definition
by Greg Neagle 26 Apr '13

26 Apr '13

I have no information on how productbuild creates its packages. I can only point to actual existing packages and their Distribution files. I suspect that productbuild does not support the full range of what is possible to do in a package or a Distribution file, but rather, implements a generally useful subset. So I guess I have no useful information for you. Sorry! -Greg On Apr 26, 2013, at 6:34 AM, Dave Barker-Plummer <dbp(a)stanford.edu> wrote: > I am not sure why I should be able to infer the required layout of the files on disk from the layout of the files in the resulting package. The whole point of productbuild is to collect together files on disk and then put them in the right place within the package. What I am asking is how to specify the original location of the files. > > If I interpret your suggestion correctly, you're saying that if I create a Resources directory on the package search path, and place a file "readme" in that directory, then I can reference the file as Resources/readme (or possibly readme) in the distribution,xml file. Regrettably, neither of these work. The resulting package does not contain the readme file. > > -- Dave > > On Apr 25, 2013, at 7:27 PM, Greg Neagle <greg.neagle(a)disneyanimation.com> wrote: > >> Oh -- you mean relative file references inside the XML distribution file. I misunderstood your original question. >> >> You can peek inside an Apple package for clues. >> >> For example, I expand the iPhoto 9.4.3 update pkg: >> >> % pkgutil --expand /Volumes/iPhoto\ 9.4.3/iPhoto9.4.3Update.pkg iPhoto_update >> % cd iPhoto_update/ >> gneagle@foo:iPhoto_update % ls >> Distribution Resources iPhoto9.4.3ContentUpdate.pkg iPhoto9.4.3Update.pkg >> >> There are two pkgs in the same directory as the Distribution file. The corresponding bits in the Distribution file: >> >> <pkg-ref id="iPhotoUpdate" auth="Root" active="LogicalAnd3(my.target.mountpoint)">#iPhoto9.4.3Update.pkg</pkg-ref> >> <pkg-ref id="iPhotoContentUpdate" auth="Root" active="LogicalAnd3(my.target.mountpoint)">#iPhoto9.4.3ContentUpdate.pkg</pkg-ref> >> >> Those are relative paths. I've seen distribution-style packages refer to component pkgs _outside_ of the distribution pkg; this is typically on DVD media or on a disk image, and looks something like this: >> >> <pkg-ref id="foo" auth="Root">../Packages/foo.pkg</pkg-ref> >> >> This probably doesn't really help you, though. What is it you are trying to accomplish? For self-contained flat packages (especially if they are signed) you just want to use the default behavior described in the document you linked to: >> >> "Content >> Required. A URL specifying the location of the installation package to which this element refers. Typically, you specify a simple filename and productbuild adjusts the URL as needed when the product archive is created." >> >> -Greg >> >> >> On Apr 25, 2013, at 5:13 PM, Dave Barker-Plummer <dbp(a)stanford.edu> wrote: >> >>> I should probably have mentioned the places that do not work: >>> >>> - the working directory when productbuild is run >>> - the directory containing the distribution file >>> - the directories on the package-path >>> >>> -- Dave >>> >>> On Apr 25, 2013, at 3:17 PM, Greg Neagle <Greg.Neagle(a)disneyanimation.com> wrote: >>> >>>> Most UNIX tools interpret relative paths as relative to the current working directory. >>>> >>>> I'd be surprised if productbuild doesn't do the same. If it doesn't, it's a bug and should be reported. >>>> >>>> A big exception is /usr/bin/defaults, which does not "do" relative paths. But that is because `default` really operates on preference domains, and not files. >>>> >>>> -Greg >>>> >>>> On Apr 25, 2013, at 3:09 PM, Dave Barker-Plummer <dbp(a)stanford.edu> wrote: >>>> >>>>> The productbuild(1) command line tool for building installers allows one to specify files to be included in the installer (readme, license and the like) within the distribution.xml file. >>>>> >>>>> I can get this to work by specifying an absolute path name for these keys, but all my attempts to use a relative path name have been unsuccessful. Has anyone been able to use a relative path here, and to work out how the path is interpreted (relative to what)? >>>>> >>>>> -- Dave >>>>> >>>>> Documentation for the xml format here: >>>>> https://developer.apple.com/library/mac/#documentation/DeveloperTools/Refer… >>>>> _______________________________________________ >>>>> 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/greg.neagle%40disneya… >>>>> >>>>> This email sent to greg.neagle(a)disneyanimation.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: productbuild(1) distribution definition
by Dave Barker-Plummer 26 Apr '13

26 Apr '13

I am not sure why I should be able to infer the required layout of the files on disk from the layout of the files in the resulting package. The whole point of productbuild is to collect together files on disk and then put them in the right place within the package. What I am asking is how to specify the original location of the files. If I interpret your suggestion correctly, you're saying that if I create a Resources directory on the package search path, and place a file "readme" in that directory, then I can reference the file as Resources/readme (or possibly readme) in the distribution,xml file. Regrettably, neither of these work. The resulting package does not contain the readme file. -- Dave On Apr 25, 2013, at 7:27 PM, Greg Neagle <greg.neagle(a)disneyanimation.com> wrote: > Oh -- you mean relative file references inside the XML distribution file. I misunderstood your original question. > > You can peek inside an Apple package for clues. > > For example, I expand the iPhoto 9.4.3 update pkg: > > % pkgutil --expand /Volumes/iPhoto\ 9.4.3/iPhoto9.4.3Update.pkg iPhoto_update > % cd iPhoto_update/ > gneagle@foo:iPhoto_update % ls > Distribution Resources iPhoto9.4.3ContentUpdate.pkg iPhoto9.4.3Update.pkg > > There are two pkgs in the same directory as the Distribution file. The corresponding bits in the Distribution file: > > <pkg-ref id="iPhotoUpdate" auth="Root" active="LogicalAnd3(my.target.mountpoint)">#iPhoto9.4.3Update.pkg</pkg-ref> > <pkg-ref id="iPhotoContentUpdate" auth="Root" active="LogicalAnd3(my.target.mountpoint)">#iPhoto9.4.3ContentUpdate.pkg</pkg-ref> > > Those are relative paths. I've seen distribution-style packages refer to component pkgs _outside_ of the distribution pkg; this is typically on DVD media or on a disk image, and looks something like this: > > <pkg-ref id="foo" auth="Root">../Packages/foo.pkg</pkg-ref> > > This probably doesn't really help you, though. What is it you are trying to accomplish? For self-contained flat packages (especially if they are signed) you just want to use the default behavior described in the document you linked to: > > "Content > Required. A URL specifying the location of the installation package to which this element refers. Typically, you specify a simple filename and productbuild adjusts the URL as needed when the product archive is created." > > -Greg > > > On Apr 25, 2013, at 5:13 PM, Dave Barker-Plummer <dbp(a)stanford.edu> wrote: > >> I should probably have mentioned the places that do not work: >> >> - the working directory when productbuild is run >> - the directory containing the distribution file >> - the directories on the package-path >> >> -- Dave >> >> On Apr 25, 2013, at 3:17 PM, Greg Neagle <Greg.Neagle(a)disneyanimation.com> wrote: >> >>> Most UNIX tools interpret relative paths as relative to the current working directory. >>> >>> I'd be surprised if productbuild doesn't do the same. If it doesn't, it's a bug and should be reported. >>> >>> A big exception is /usr/bin/defaults, which does not "do" relative paths. But that is because `default` really operates on preference domains, and not files. >>> >>> -Greg >>> >>> On Apr 25, 2013, at 3:09 PM, Dave Barker-Plummer <dbp(a)stanford.edu> wrote: >>> >>>> The productbuild(1) command line tool for building installers allows one to specify files to be included in the installer (readme, license and the like) within the distribution.xml file. >>>> >>>> I can get this to work by specifying an absolute path name for these keys, but all my attempts to use a relative path name have been unsuccessful. Has anyone been able to use a relative path here, and to work out how the path is interpreted (relative to what)? >>>> >>>> -- Dave >>>> >>>> Documentation for the xml format here: >>>> https://developer.apple.com/library/mac/#documentation/DeveloperTools/Refer… >>>> _______________________________________________ >>>> 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/greg.neagle%40disneya… >>>> >>>> This email sent to greg.neagle(a)disneyanimation.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: Distribution of library via Mac App Store
by Greg Neagle 26 Apr '13

26 Apr '13

_______________________________________________ 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: Distribution of library via Mac App Store
by Joe Mele 26 Apr '13

26 Apr '13

_______________________________________________ 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

Distribution of library via Mac App Store
by Natalia Antonova 26 Apr '13

26 Apr '13

_______________________________________________ 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: productbuild(1) distribution definition
by Greg Neagle 26 Apr '13

26 Apr '13

Oh -- you mean relative file references inside the XML distribution file. I misunderstood your original question. You can peek inside an Apple package for clues. For example, I expand the iPhoto 9.4.3 update pkg: % pkgutil --expand /Volumes/iPhoto\ 9.4.3/iPhoto9.4.3Update.pkg iPhoto_update % cd iPhoto_update/ gneagle@foo:iPhoto_update % ls Distribution Resources iPhoto9.4.3ContentUpdate.pkg iPhoto9.4.3Update.pkg There are two pkgs in the same directory as the Distribution file. The corresponding bits in the Distribution file: <pkg-ref id="iPhotoUpdate" auth="Root" active="LogicalAnd3(my.target.mountpoint)">#iPhoto9.4.3Update.pkg</pkg-ref> <pkg-ref id="iPhotoContentUpdate" auth="Root" active="LogicalAnd3(my.target.mountpoint)">#iPhoto9.4.3ContentUpdate.pkg</pkg-ref> Those are relative paths. I've seen distribution-style packages refer to component pkgs _outside_ of the distribution pkg; this is typically on DVD media or on a disk image, and looks something like this: <pkg-ref id="foo" auth="Root">../Packages/foo.pkg</pkg-ref> This probably doesn't really help you, though. What is it you are trying to accomplish? For self-contained flat packages (especially if they are signed) you just want to use the default behavior described in the document you linked to: "Content Required. A URL specifying the location of the installation package to which this element refers. Typically, you specify a simple filename and productbuild adjusts the URL as needed when the product archive is created." -Greg On Apr 25, 2013, at 5:13 PM, Dave Barker-Plummer <dbp(a)stanford.edu> wrote: > I should probably have mentioned the places that do not work: > > - the working directory when productbuild is run > - the directory containing the distribution file > - the directories on the package-path > > -- Dave > > On Apr 25, 2013, at 3:17 PM, Greg Neagle <Greg.Neagle(a)disneyanimation.com> wrote: > >> Most UNIX tools interpret relative paths as relative to the current working directory. >> >> I'd be surprised if productbuild doesn't do the same. If it doesn't, it's a bug and should be reported. >> >> A big exception is /usr/bin/defaults, which does not "do" relative paths. But that is because `default` really operates on preference domains, and not files. >> >> -Greg >> >> On Apr 25, 2013, at 3:09 PM, Dave Barker-Plummer <dbp(a)stanford.edu> wrote: >> >>> The productbuild(1) command line tool for building installers allows one to specify files to be included in the installer (readme, license and the like) within the distribution.xml file. >>> >>> I can get this to work by specifying an absolute path name for these keys, but all my attempts to use a relative path name have been unsuccessful. Has anyone been able to use a relative path here, and to work out how the path is interpreted (relative to what)? >>> >>> -- Dave >>> >>> Documentation for the xml format here: >>> https://developer.apple.com/library/mac/#documentation/DeveloperTools/Refer… >>> _______________________________________________ >>> 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/greg.neagle%40disneya… >>> >>> This email sent to greg.neagle(a)disneyanimation.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: productbuild(1) distribution definition
by Dave Barker-Plummer 26 Apr '13

26 Apr '13

I should probably have mentioned the places that do not work: - the working directory when productbuild is run - the directory containing the distribution file - the directories on the package-path -- Dave On Apr 25, 2013, at 3:17 PM, Greg Neagle <Greg.Neagle(a)disneyanimation.com> wrote: > Most UNIX tools interpret relative paths as relative to the current working directory. > > I'd be surprised if productbuild doesn't do the same. If it doesn't, it's a bug and should be reported. > > A big exception is /usr/bin/defaults, which does not "do" relative paths. But that is because `default` really operates on preference domains, and not files. > > -Greg > > On Apr 25, 2013, at 3:09 PM, Dave Barker-Plummer <dbp(a)stanford.edu> wrote: > >> The productbuild(1) command line tool for building installers allows one to specify files to be included in the installer (readme, license and the like) within the distribution.xml file. >> >> I can get this to work by specifying an absolute path name for these keys, but all my attempts to use a relative path name have been unsuccessful. Has anyone been able to use a relative path here, and to work out how the path is interpreted (relative to what)? >> >> -- Dave >> >> Documentation for the xml format here: >> https://developer.apple.com/library/mac/#documentation/DeveloperTools/Refer… >> _______________________________________________ >> 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/greg.neagle%40disneya… >> >> This email sent to greg.neagle(a)disneyanimation.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: productbuild(1) distribution definition
by Greg Neagle 25 Apr '13

25 Apr '13

Most UNIX tools interpret relative paths as relative to the current working directory. I'd be surprised if productbuild doesn't do the same. If it doesn't, it's a bug and should be reported. A big exception is /usr/bin/defaults, which does not "do" relative paths. But that is because `default` really operates on preference domains, and not files. -Greg On Apr 25, 2013, at 3:09 PM, Dave Barker-Plummer <dbp(a)stanford.edu> wrote: > The productbuild(1) command line tool for building installers allows one to specify files to be included in the installer (readme, license and the like) within the distribution.xml file. > > I can get this to work by specifying an absolute path name for these keys, but all my attempts to use a relative path name have been unsuccessful. Has anyone been able to use a relative path here, and to work out how the path is interpreted (relative to what)? > > -- Dave > > Documentation for the xml format here: > https://developer.apple.com/library/mac/#documentation/DeveloperTools/Refer… > _______________________________________________ > 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/greg.neagle%40disneya… > > This email sent to greg.neagle(a)disneyanimation.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

productbuild(1) distribution definition
by Dave Barker-Plummer 25 Apr '13

25 Apr '13

The productbuild(1) command line tool for building installers allows one to specify files to be included in the installer (readme, license and the like) within the distribution.xml file. I can get this to work by specifying an absolute path name for these keys, but all my attempts to use a relative path name have been unsuccessful. Has anyone been able to use a relative path here, and to work out how the path is interpreted (relative to what)? -- Dave Documentation for the xml format here: https://developer.apple.com/library/mac/#documentation/DeveloperTools/Refer… _______________________________________________ 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: Does a flat package allow a relocatable installation?
by Jim Dodd 25 Apr '13

25 Apr '13

Thank you both for your help. A special "thank you" to Stephane for his excellent Packages application and his many posts in this list. While Packages may have this one missing feature, I find it MUCH easier to use than trying to figure out how pkgbuild and productbuild work and miles (or kilometers) ahead of the old PackageMaker application. I will attempt to add the customLocation attribute by hand for now (through a script, really) and see if that gives us the flexibility of loading our application into different places. This is mostly used for creating subfolders in Applications so that multiple versions of our product can be available. Regards, Jim Dodd Onset Computer Corporation ----- Original Message ----- > From: Andrew Keller <andrew(a)kellerfarm.com> > To: Apple Installer list <installer-dev(a)lists.apple.com> > Cc: > Sent: Thursday, April 25, 2013 8:14 AM > Subject: Re: Does a flat package allow a relocatable installation? > > On Apr 25, 2013, at 5:06 AM, Stephane Sudre wrote: >> On Thu, Apr 25, 2013 at 1:03 AM, Andrew Keller > <andrew(a)kellerfarm.com> wrote: >>> On Apr 24, 2013, at 1:13 PM, Jim Dodd wrote: >>> >>>> We have finally switched from using PackageMaker and creating a > bundled package installer to using Stephane Sudre's Package program to > create a flat package installer. I have chosen Relocatable in the Settings for > the package but when we get to the list of volumes, I can only choose the > volume. Previously, with bundled package installers created with PackageMaker, I > could select the volume and a Choose Folder button would appear to allow us to > change where our application is installed (from the /Applications default). >>>> >>>> Is there something else I must select in Packages or is choosing a > different folder on a volume no longer allowed with a flat package installer? >>> >>> I do not have experience with Packages (we create our installer > manually), however I do know modern flat packages can install onto other > volumes, and you can activate the "relocate" feature, which allows > files (bundles, technically) to be installed during an upgrade install to follow > to where a user may have previously moved them. So, you could install an app, > move the app manually, and when you reinstall, the new copy would overwrite the > copy you moved, rather than putting the new one in the original location. >>> >>> I have not seen any documentation for the ability to install apps to a > specific folder, although I may have just missed it. >> >> The relocation feature of the original post refers to the ability to >> install the entire payload in a specific folder. > > Yes, of course. I attempted to imply that, but looking at my words again, I see > the confusion... Thanks keeping it clear. > >> By default, the payload of a package can be installed on any volume at >> the relative default location described in the PackageInfo file (the >> install-location key). it's usually / (but it can be set to >> /Applications). >> >> With flat packages and distributions, you can only restrict the >> installation to the startup volume when the package is integrated into >> a distribution (I personally find this limitative but that's how it >> is). >> >> Then you have the relocatable option in the PackageInfo file of a raw >> package which indicates that the entire payload can be installed at a >> relative custom location on the selected target volume. >> >> This works fine for flat package. But with distribution packages, this >> won't let you see the popup menu on the right of the choice/package in >> the "Installation Type" pane. For that, it requires to set the >> customLocation attribute of the corresponding choice. And it's not >> supported by Packages at this time. >> >> And finally, with distributions, you have the ability define the >> domains where the entire payload can be installed. > > Well, hey - look at that. That's awesome. > > Thanks, > Andrew Keller > > > > _______________________________________________ > 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/bcbuilderboy%40yahoo.… > > This email sent to bcbuilderboy(a)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: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0