Кто-нибудь действительно использовал PackageMaker для создания установочных пакетов MacOSX? Если да, то я просто использую его неправильно?

Я использую PackageMaker 3.0.4 для создания установочного пакета, включающего файлы .kext и .plugin, которые необходимо установить в системные каталоги. Моя цель - создать .pmdoc

Я просто не могу поверить, что кто-то на самом деле использует его, потому что я обнаружил так много ошибок, что я не знаю, как кому-то удалось заставить его работать на них. Я не верю, что делаю что-то особенно необычное, но почти каждый раз, когда я открываю .pmdoc для редактирования (или даже при его создании из командной строки), PackageMaker произвольно меняет мои настройки. В частности, разрешения, но также и пути.

Это особенно бесит из командной строки, потому что мы используем .pmdoc при сборке установщиков ... поэтому мы получаем сломанный установщик, потому что PackageMaker пошел и испортил различные (важные!) разрешения - это означает, что файлы .kext не могут нагрузка и тому подобное.

На данном этапе лучшим обходным путем, по-видимому, является написание сценария после проверки, который изменит разрешения в командной строке и просто позволит PackageMaker нарушить разрешения, как он хочет. Это не касается других изменений, которые он вносит (иногда даже приводит к повреждению файлов до такой степени, что я больше не могу даже открыть .pmdoc.

Итак... удалось ли кому-нибудь успешно интегрировать PackageMaker в процесс сборки? Или он действительно так фундаментально сломан, как кажется, и все остальные слишком мудры, чтобы даже прикасаться к нему?


osx-leopard packagemaker
person Will Baker    schedule 22.06.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы можете попробовать параметр командной строки [--no-recommend, -m]. Однако вам нужно будет установить правильные разрешения для всех ваших файлов перед упаковкой. ссылка: человек-упаковщик

person Vishal    schedule 18.08.2011
comment
Это разрешения, которые позволяет установить пользовательский интерфейс PackageMaker, или это установка разрешений для физических файлов на диске? Именно в настройках разрешений PackageMaker ведет себя странно (имеется в виду, что разрешения периодически сбрасываются до разных значений при открытии документа PackageMaker). - person Will Baker; 23.08.2011

arrow_upward
1
arrow_downward

У меня похожие проблемы, и я только что наткнулся на интересное наблюдение.

Если быть точным, проблема заключалась в том, что при использовании packagemaker для создания pkg, содержащего kext, разрешения для kext-файлов и папок в pkg иногда создавались с правильными разрешениями (например, rw-r--r--) и иногда нет (например, rw-rw-r--). Я считаю, что это похоже на вашу проблему, но я не использую pmdoc и всегда запускаю packagemaker из командной строки. Однако я верю, что основные проблемы, с которыми мы сталкиваемся, одни и те же.

Мне потребовалось некоторое время, чтобы обнаружить разницу. Если копия kext находится в /System/Library/Extensions и загружается, то pkg создается с файлами kext, имеющими правильные разрешения. Выгрузите и удалите kext из /System/Library/Extensions, и pkg будет создан с неправильными разрешениями. Это безумие!

То, что я делал с моим установщиком, было чем-то похоже на то, что вы предлагаете: у меня есть сценарий после проверки, который правильно устанавливает все разрешения для файлов kext. Однако я наблюдал периодически возникающие ошибки установки. Для некоторых пользователей при запуске установщика главное окно установки сообщит об успешном завершении, но появится отдельное диалоговое окно с сообщением о том, что «Расширение системы не может быть использовано» и что оно «установлено неправильно». После этого драйвер не загружается даже после перезагрузки. Мой послеполетный скрипт работает правильно, так как права доступа к установленному kext верны. Драйвер также можно успешно загрузить вручную с помощью kextload.

Я проследил это до того, что, кажется, есть небольшое окно, в котором установленные разрешения kext неверны. Это время между копированием kext-файлов (с неправильными разрешениями) в нужное место и выполнением моего сценария после проверки.

Итак, в конце концов я наткнулся на это предложение: http://osdir.com/ml/darwin-kernel/2010-03/msg00017.html. Вместо установки kext в /System/Library/Extensions установите его в другое временное место. Затем в сценарии postflight установите разрешения этой временной копии на правильные разрешения kext, а затем переместите их в папку /System/Library/Extensions. Я еще не пробовал, но уверен, что это сработает.

В качестве альтернативы вы можете сделать то, что предлагает Вишал, а это то, что предлагают вам некоторые документы Apple. Однако мне это решение не очень нравится. Это означает, что наша система сборки должна создавать файлы, принадлежащие пользователю root, и, следовательно, всякий раз, когда я вношу изменения и собираю снова, мне нужно будет вводить свой пароль. Ввод паролей при сборке кажется не совсем правильным.

person Steg    schedule 09.11.2011