2

I'm using PackageMaker 3.0.4 to make an install package that includes .kext and .plugin files that need to be installed to system directories. My goal is to create a .pmdoc

I just can't believe that anybody is actually using it because I have hit so many bugs that I don't know how anybody has managed to get it working for them. I don't believe I'm doing anything particularly unusual, but almost every time I open a .pmdoc to edit (or even when building it from the commandline) PackageMaker will arbitrarily change my settings. Particularly permissions, but also paths.

It is particularly infuriating from the commandline because we're using the .pmdoc when building the installers... so we end up with a broken installer because PackageMaker has gone and messed up the various (important!) permissions - meaning .kext files cannot load and the like.

At this stage the best workaround seems to be writing a postflight script that will modify the permissions on the commandline, and just leave PackageMaker to break the permissions however it wants to. This doesn't address the other changes it makes (sometimes even causing the files to be corrupt to the point I can't even open the .pmdoc anymore.

So... has anybody actually managed to successfully integrate PackageMaker as part of their build process? Or is it really as fundamentally broken as it seems and everyone else is too wise to even touch it?

Will Baker
  • 2,747
  • 4
  • 20
  • 17

2 Answers2

1

You could try commandline option [--no-recommend, -m]. However, you will have to set correct permissions on all your files before packaging. ref: man packagemaker

Vishal
  • 636
  • 5
  • 8
  • Is that the permissions that the PackageMaker UI allows you to set, or is that setting the permissions of the physical files on disk? It is in the permissions setting that PackageMaker seems to behaving strangely (meaning that permissions are periodically reset to different values when opening a PackageMaker document). – Will Baker Aug 23 '11 at 09:59
1

I am having similar issues and have just stumbled across an interesting observation.

To be specific, the problem was that when using packagemaker to create a pkg containing a kext, the permissions of the kext files and folders in the pkg were sometime being created with the correct permissions (e.g. rw-r--r--) and sometimes not (e.g. rw-rw-r--). I believe this is similar to your problem, but I don't use a pmdoc and always run packagemaker from the command line. I do believe, though, that the underlying issues we are experiencing is the same.

It took me a while to discover the difference. If a copy of the kext resides in /System/Library/Extensions and is loaded, then the pkg is created with the kext files having the correct permissions. Unload and delete the kext from /System/Library/Extensions and the pkg is created with the wrong permissions. This is insane!

What I was doing with my installer was something similar to what you suggest - I have a postflight script that sets all the permissions correctly on the kext files. I have been seeing intermittent installation errors occurring though. For some users, when running the installer, the main installation window will report success but a separate dialog will appear stating that the "System extension cannot be used" and that it was "installed improperly". The driver then fails to load, even after a reboot. My postflight script is working correctly since the permissions of the installed kext are correct. The driver can also be successfully loaded manually using kextload.

What I traced this back to is that there seems to be a small window where the installed kext permissions are incorrect. This is the time between when the kext files (with the wrong permissions) are copied into the correct location and when my postflight script is executed.

So, I eventually stumbled across this suggestion: http://osdir.com/ml/darwin-kernel/2010-03/msg00017.html. Instead of installing the kext to /System/Library/Extensions, install it to some other temporary location. Then, in the postflight script, set the permissions of this temporary copy to the correct kext permissions and then move that into the /System/Library/Extensions folder. I've yet to try it out but am sure it will work.

Alternatively, you could do what Vishal suggests which is what some of the Apple docs suggest you do. However, I don't really like that solution. It means our build system has to create files that are owned by root and, consequently, whenever I make changes and build again, it would require me to enter my password. Entering passwords when building doesn't really seem right.

Steg
  • 10,000
  • 3
  • 24
  • 17