Общие вопросы
Ваш способ упаковать свои вещи (с зависимыми библиотеками) в /opt - это то, как упаковывается проприетарное (и даже с открытым исходным кодом) программное обеспечение. Рекомендуемая практика Linux Foundation (см. мой ответ на другой вопрос для ссылок).
Внешние библиотеки могут быть скомпилированы с нуля и встроены в ваш процесс сборки как отдельный шаг (особенно если вы их изменили), или извлечены из пакетов некоторых дистрибутивов. Второй подход проще, но первый обеспечивает большую гибкость.
Обратите внимание, что нет необходимости включать некоторые действительно низкоуровневые библиотеки (такие как glibc, Xorg) в ваш пакет. Их лучше оставить системным вендорам для настройки, и вы можете просто предположить, что они существуют. Более того, существует Стандартная база Linux , которая документирует наиболее важные библиотеки; эти библиотеки существуют почти везде, и им можно доверять.
Обратите внимание, что если вы компилируете в более новой системе, пользователи более старых систем, скорее всего, не смогут ее использовать, в то время как обратное неверно. Поэтому для достижения лучшей совместимости может быть полезно скомпилировать пакет в системе, которая на два года старше, чем сегодня.
Я только что рассказал о некоторых общих вещах, но я считаю, что Веб-сайт Linux Developers Network содержит больше информации об упаковке и переносимости.
Упаковка
Судя по тому, что я видел в проектах распространения с открытым исходным кодом, ваш скрипт выполняет те же действия, что и поставщики дистрибутивов, упаковывающие программное обеспечение. Их сценарии автоматически исправляют источники, имитируют установку программного обеспечения и упаковывают полученные папки в DEB и RPM.
Tar.gz, или, конечно, также может работать, но, например, создание RPM не достаточно сложно, чтобы упустить такую возможность, чтобы сделать жизнь ваших пользователей намного проще.
Отвечая на ваши вопросы,
Да, вам придется дважды жестко кодировать зависимости.
Дело в том, что когда вы жестко их кодируете в CMake, вы указываете их другими терминами, чем когда вы указываете их в скрипте упаковки. CMake ссылается на общие библиотеки и заголовочные файлы , а пакетный скрипт ссылается на пакетов .
Между именами пакетов и общими библиотеками и заголовками нет взаимного распределения. Это зависит от распределения. Поэтому его следует указывать дважды.
Но пакет может быть легко переупакован поставщиками дистрибутивов, особенно если вы попытаетесь упаковать в него все зависимые библиотеки (поэтому будет меньше внешних зависимостей для порта). Также скоро появится инструмент, который может портировать пакеты из одного дистрибутива в другой (я обновлю свой ответ, когда он будет выпущен).
Да, вы должны указать свою версию дважды.
Но дело в том, что вы можете организовать процесс упаковки таким образом, чтобы версии пакетов и программного обеспечения никогда не выходили из синхронизации . Просто сделайте так, чтобы скрипт упаковки извлекал из вашего хранилища (или загружал с вашего веб-сайта) ту же версию, которую сценарий будет писать в спецификации пакета.
Анализ зависимостей
Для анализа зависимостей вашего программного обеспечения вы можете использовать наш бесплатный Linux Application Checker инструмент с открытым исходным кодом. Он сообщит список библиотек, от которых он зависит, покажет дистрибутивы, с которыми совместимо ваше программное обеспечение, и поможет вашему приложению быть более переносимым между дистрибутивами. Оказывается, что иногда можно добиться большей совместимости между дистрибутивами без особых усилий, и вам не нужно ограничиваться поддержкой только нескольких выбранных дистрибутивов.