[Xquartz-dev] Re: X11.pkg

[Merle Reinhart]

Jeremy,

I know with the Tiger PackageMaker, I always made sure they were  
correct in my tree, then I didn't have do diddle with them internally  
in the tool.  For those packages, I also set the 'overwrite directory  
permissions', but only after make doubly sure that I actually had all  
there perms/owners correct in my tree from the root down.

I just threw together a quick package from a directory where the  
ownerships of the files were 501/501.  I then change the ownerships  
via the 'Content' tab and the 'Apply Recommendations' tab to root/ 
wheel and the BOM came out interestingly.  The top directory of the  
tree was 0/0 as expected, but the group of all the contained files was  
admin (80).  So, it looks like you may have to change all the files  
independently (in my test case, they all came out correctly (0/0)).

However, when I set the owners on the files and did not try and set  
them in the too, they came out wrong (should have been 0/0 everywhere,  
but were 0/80 instead).  So, there might be some bugs in PackageMaker  
that have to be worked around (or we just haven't figured out where  
the critical switches are yet).

When I set all the owners on the files individually via the  
PackageMaker tool, then the BOM comes out as expected.

 From these simple tests, it looks like one may have to set the owners/ 
perms via the Tool for each file individually (which can be a really  
pain for packages that have hundreds of files) to get things to come  
out correctly.

Other than that, I'm not sure what to suggest.  I'll start putting  
together Leopard packages for some of my stuff and see if I can find  
any revelations.

Merle





On Dec 2, 2007, at 2:23 PM, Jeremy Huddleston wrote:

> On Dec 2, 2007, at 07:42, Merle Reinhart wrote:
>
>> Jeremy,
>>
>> I'm still seeing some incorrect ownerships on the updated files.
>
> I have no idea why this is happening... see below.
>
>> A philosophical question:  Since it appears that only some of the  
>> files
>> are changing compared to the standard Leopard X11, do we want to  
>> include
>> only those that have changed, or an entire complete/self-contained  
>> X11
>> install?  I don't think I have a preference either way.
>
> We're just including changed and missing files.
>
>> Here a non-philosophical question:  Will this work to overwrite the  
>> X11
>> install for those that down-revved to Tiger's X11?  Or should the  
>> install
>> detect that and deal with it in a pre-install script?
>
> I setup an install requirement that checks for /usr/X11/bin/ 
> Xquartz.  So in theory, it should fail if they uninstalled or never  
> installed Leopard's X11.
>
>> You can change these in a couple of ways:
>> 1) do a chown on the files you are including in the package
>
> Yeah, that's what I did
>
>> 2) In the 'Contents' pane when the included folders are highlighted,
>>    set the individual ownerships of the files that are wrong.
>>    (I don't think you have to set the 'Overwrite Directory  
>> Permissions'
>>     for this to be effective).
>
> They are all root:wheel.  I'll change the ones that should be  
> root:admin to root:admin, but I show them all as root:wheel
>
>> You can double-check things are right after you've built the  
>> package with
>> the following command:
>>  lsbom `pkgutil --bom <package_file>`
>
> I see the 501/20 there.  Why the heck is it doing that?  Is this a  
> PackageMaker.app bug?  I even deleted the target and readded it to  
> make sure it got the new ownerships.
>
>> Finally, it looks to me like the postinstall script is firing.   
>> Running DeRez
>> on the final /usr/X11/bin/Xquartz file shows the resource fork is  
>> there.
>>
>> As a side note, Rez only gets installed if the Xcode Developer  
>> Tools are installed.
>> If they're not installed, then I would expect Installer to throw an  
>> error when
>> running the postinstall script.  This might be the cause of the  
>> error that that
>> one person saw.  Should we look for the Developer Tools in the  
>> Install Check and
>> abort with a good error message if they are not present before  
>> installing?
>> Another way around that would be for you to include the resource  
>> fork in Xquartz
>> prior to building the package.  As long as the 'Discard Resource  
>> Forks' is not
>> checked in the Package Flags, that should work.
>
> Ok, I'll try that then.
>
> Thanks for your help,
> Jeremy
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2425 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20071202/1714041e/smime.bin