Re: productbuild(1) distribution definition
Re: productbuild(1) distribution definition
- Subject: Re: productbuild(1) distribution definition
- From: Dave Barker-Plummer <email@hidden>
- Date: Fri, 26 Apr 2013 06:34:38 -0700
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 <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 <email@hidden> 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/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Installer-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden