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