问题描述
|
我正在使用PackageMaker 3.0.4制作一个包含需要安装到系统目录的.kext和.plugin文件的安装软件包。我的目标是创建一个.pmdoc
我简直不敢相信有人在使用它，因为我遇到了很多错误，以至于我不知道有人如何设法使它为他们所用。我不相信自己在做任何特别的事情，但是几乎每次我打开.pmdoc进行编辑（甚至从命令行构建它时），PackageMaker都会随意更改我的设置。特别是权限，还有路径。
从命令行特别令人生气，因为我们在构建安装程序时使用了.pmdoc。因此，由于PackageMaker离开并弄乱了各种（重要的！）权限（意味着.kext文件），导致安装程序损坏了。无法加载等。
在此阶段，最好的解决方法似乎是编写一个postflight脚本，该脚本将修改命令行上的权限，并只留下PackageMaker来破坏其所需的权限。这不能解决它所做的其他更改（有时甚至导致文件损坏到我什至无法打开.pmdoc的程度。
那么...实际上有人成功地将PackageMaker集成为他们的构建过程的一部分吗？还是真的从根本上破坏了它，而其他所有人都太聪明了，甚至不能去碰它？
解决方法
您可以尝试命令行选项[--no-recommend，-m]。但是，在打包之前，必须对所有文件设置正确的权限。
参考：男子包装
, 我遇到类似的问题，偶然发现了一个有趣的发现。
具体来说，问题是当使用packagemaker创建包含kext的pkg时，有时会使用正确的权限（例如rw-r--r--）创建pkg中kext文件和文件夹的权限，并且有时不是（例如rw-rw-r--）。我相信这与您的问题类似，但是我不使用pmdoc并始终从命令行运行packagemaker。但是，我确实相信，我们所面临的基本问题是相同的。
我花了一段时间才发现差异。如果kext的副本位于/ System / Library / Extensions中并已加载，则将使用具有正确权限的kext文件创建pkg。从/ System / Library / Extensions卸载并删除kext，并且使用错误的权限创建了pkg。疯了吧！
我对安装程序所做的工作与您建议的类似-我有一个postflight脚本，可以正确设置kext文件的所有权限。我一直看到间歇性安装错误发生。对于某些用户，在运行安装程序时，主安装窗口将报告成功，但将显示一个单独的对话框，指出“无法使用系统扩展名”和“未正确安装”。即使重新启动后，驱动程序也无法加载。我的postflight脚本正常运行，因为已安装的kext的权限正确。也可以使用kextload手动成功加载驱动程序。
我追溯到的地方似乎是一个很小的窗口，其中安装的kext权限不正确。这是将kext文件（具有错误权限）复制到正确位置到执行我的postflight脚本之间的时间。
因此，我最终偶然发现了这个建议：http://osdir.com/ml/darwin-kernel/2010-03/msg00017.html。无需将kext安装到/ System / Library / Extensions，而是将其安装到其他临时位置。然后，在postflight脚本中，将此临时副本的权限设置为正确的kext权限，然后将其移动到/ System / Library / Extensions文件夹中。我还没有尝试过，但是可以肯定。
或者，您可以执行Vishal建议的操作，这是某些Apple文档建议您执行的操作。但是，我不太喜欢这种解决方案。这意味着我们的构建系统必须创建由root拥有的文件，因此，每当我进行更改并再次构建时，都需要输入密码。构建时输入密码似乎不太正确。