Упаковка проприетарного программного обеспечения для Linux

Общие проблемы

Ваш способ упаковки ваших материалов (с зависимыми библиотеками) в / opt - это то, как упаковывается проприетарное (и даже с открытым исходным кодом) программное обеспечение. Это рекомендованная практика Linux Foundation (см. мой ответ на другой вопрос для ссылок).

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

Обратите внимание, что нет необходимости включать в ваш пакет некоторые действительно низкоуровневые библиотеки (такие как glibc, Xorg). Их лучше доверить настройку системным поставщикам, и вы можете просто предположить, что они существуют. Более того, существует Стандартная база Linux , в которой описаны наиболее важные библиотеки; эти библиотеки существуют почти везде, и им можно доверять.

Отметьте также, что если вы компилируете в новой системе, скорее всего, пользователи старых систем не смогут ее использовать, в то время как обратное неверно. Итак, для достижения лучшей совместимости может быть полезно скомпилировать пакет для системы, которая на два года старше, чем сегодня.

Я только что обрисовал в общих чертах, но считаю, что веб-сайт Linux Developers Network содержит дополнительную информацию об упаковке и переносимости.

Упаковка

Судя по тому, что я видел в проектах распространения с открытым исходным кодом, ваш сценарий делает это так же, как поставщики дистрибутивов упаковывают программное обеспечение.Их сценарии автоматически исправляют исходные коды, имитируют установку программного обеспечения и упаковывают полученные папки в файлы DEB и RPM.

Tar.gz, или конечно, тоже может работать, но создание, например, RPM недостаточно сложно, чтобы вы упустили такую ​​возможность, чтобы сделать жизнь ваших пользователей намного проще.

Отвечая на ваши вопросы,

• Да, вам нужно дважды жестко запрограммировать зависимости.

  Дело в том, что когда вы жестко закрепляете их в CMake, вы указываете их в других терминах, чем когда вы указываете их в сценарии упаковки. CMake относится к разделяемым библиотекам и файлам заголовков , а сценарий упаковки относится к пакетам .

  Между именами пакетов и общими библиотеками и заголовками нет взаимно-однозначной связи между распределениями. Это зависит от дистрибутива. Поэтому его следует указывать дважды.

  Но пакет может быть легко перепакован поставщиками дистрибутивов, особенно если вы стремитесь упаковать в него все зависимые библиотеки (так что будет меньше внешних зависимостей для переноса). Кроме того, скоро появится инструмент, который может переносить пакеты из одного дистрибутива в другой (я обновлю свой ответ, когда он будет выпущен).

• Да, вам нужно указать вашу версию дважды.

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

Анализ зависимостей

Для анализа зависимостей вашего программного обеспечения вы можете использовать наш бесплатный инструмент с открытым исходным кодом Linux Application Checker . Он сообщит список библиотек, от которых он зависит, покажет дистрибутивы, с которыми совместимо ваше программное обеспечение, и поможет вашему приложению быть более переносимым между дистрибутивами. Оказывается, иногда большей совместимости между дистрибутивами можно добиться с помощью небольших усилий, и вам не нужно ограничивать себя поддержкой лишь нескольких выбранных дистрибутивов.