Упаковка проприетарного ПО для Linux

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

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

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

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

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

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

Упаковка

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

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

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

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

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

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

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

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

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

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

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

Хорошо подумайте (или спросите в отделе разработки продуктов), какие дистрибутивы/архитектуры вам нужно поддерживать.

Убедитесь, что они полностью понимают последствия тестирования.

Я ожидаю, что вы составите очень короткий список поддерживаемых дистрибутивов и архитектур.

Это действительно зависит от того, какие клиенты платят за поддержку Linux. Большинство людей используют Redhat Enterprise (на серверах) или Centos (что неотличимо с технической точки зрения).

Если вам нужно поддерживать только Redhat, вам нужно поддерживать только RPM, работа хорошая.