Во-первых, я нашел похожий вопросКак создать портативное приложение для Linux?но на самом деле это не отвечает на мои вопросы, это больше о том, как скомпилировать, чтобы сделать приложение переносимым, что я уже умею делать (по крайней мере, я думаю, что умею), а не о развертывании, как я объясню ниже.
Вот моя ситуация. Нас наняли, чтобы решить определенную проблему для клиента, поэтому мы будем разрабатывать приложение с закрытым исходным кодом, которое мы собираемся продать ему. Однако нам не дали никаких подробностей о том, где оно должно работать, я имею в виду дистрибутив, версию ядра или что-то еще. Задача довольно проста и не зависит от каких-либо низкоуровневых драйверов или чего-либо, что могло бы усложнить переносимость. Однако мы зависим от пары сторонних библиотек, ниже приведена простая схема зависимостей:
app --+-- libA
| +-- lib1
+-- libB --+-- lib2
+-- lib3
Где libA,B и lib1,2,3 — все это проекты с открытым исходным кодом с подходящими лицензиями (LGPL, ASL и BSD). После компиляции общие зависимости нашей программы становятся libA, libB, lib1, lib2, lib3 и набор системных библиотек, таких как libc, libm, libz, libstdc++, libpthread и т. д. Все динамически связано.
Теперь, поскольку у нас нет целевого дистрибутива, мы хотим сохранить его независимым от любой системы упаковки, такой как .deb или тому подобное. Прямые зависимости (libA и libB) не очень распространены, поэтому очевидным выбором является поставка их вместе с нашим приложением. lib1,2,3 на самом деле более распространены (т. е. один из них — libpng), хотя все еще не уверен, что они будут установлены в целевой системе. Мы решили включить все 5 из них в окончательный пакет программного обеспечения.
Что делать с системными библиотеками, мы понятия не имеем. Как нам с этим справиться? Просто предположить, что у них будут правильные библиотеки, и молиться о лучшем? В таком случае, что произойдет через год или два, когда одна из этих библиотек изменится и наше приложение перестанет работать?
Должны ли мы распространять их все (libstdc++, glibc и т. д.) вместе с нашим программным обеспечением? Это кажется неправильным, и я думаю, что это может противоречить условиям лицензирования в них. Я знаю, что в прошлом я использовал некоторые программы, которые фактически содержали собственную копию [по крайней мере] некоторых из этих библиотек, это привлекло мое внимание, потому что это была более старая версия, чем та, что была в моей системе, и их замена заставила все перестать работать (о чем я узнал случайно).
Как это обычно решается?
решение1
Строго правильный подход к переносимым исполняемым бинарным файлам в Linux — это работать противСтандартная база LinuxИ егоподробные характеристики. LSB разработан для обеспечения двоичной совместимости между совместимыми дистрибутивами путем указания конкретных версий библиотек (или совместимости с этими версиями). LSB (или, по крайней мере, предыдущая версия) была формализована какИСО/МЭК 23360. Если вы создадите свою программу для компоновки только с библиотеками LSB (и теми, которые она сама поставляет), она будет переносима между всеми этими системами.
LSB определяет формат RPM для пакетов, поэтому вам нужно создать только один (строго). Тарбола тоже будет достаточно, если вы откажетесь от интеграции с менеджером пакетов.
Что касается некоторых Ваших конкретных пунктов:
Неужели мы просто предполагаем, что у них будут нужные библиотеки, и молимся о лучшем?
Достаточно простая программа, совместимая с LSB, скорее всего, будет работать на многих системах «как есть», так что вы можете это сделать.
В дополнение к этому, несколько дистрибутивов пытаются обеспечить соответствие LSB, включая RHEL и SUSE. Некоторые другие предлагают это через специальный пакет, который тянет соответствующие зависимости. Например, Debian имеетпакетlsbкоторый тянет lsb-coreи несколько других, которые в свою очередь тянут соответствующие зависимости. Возможно, что целевым системам может потребоваться установить такой пакет для запуска вашего программного обеспечения.
LSB менее популярен, чем когда-то, и формальная совместимость ослабла для многих систем, но на практике его можно переносить в довольно широком диапазоне. Даже некоторые системы, которые стремятся к соответствию, пропускают некоторые из более неясных моментов, но для общих целей это часто не имеет значения (и те же программы могут работать на системах, которыенепопытка соответствовать LSB).
В таком случае, что произойдет через год или два, когда одна из этих библиотек изменится и наше приложение перестанет работать?
Когда ваше приложение перестанет работать, ваше приложение перестанет работать. Это вопрос бизнес-процесса.
Должны ли мы распространять их все (libstdc++, glibc и т. д.) вместе с нашим программным обеспечением?
Вероятно, нет. Для libc, в частности, могут быть проблемы совместимости во время выполнения при использовании нескольких версий одновременно в системе. Однако существуют другие реализации libc, которые могут быть более практичными для объединения.
Хотя большинство библиотек можно успешно объединить, вендорские библиотеки — это проблема обслуживания и безопасности в целом, поэтому я бы не советовал делать этого везде, где этого можно избежать. Если в библиотеке обнаружена ошибка или уязвимость безопасности, ее обновление в одном месте в системе, которое будет устранено дистрибутивом, проще и надежнее, чем отслеживать каждую копию (и получать от вас заменяющие пакеты!).
В качестве более практичного шага, возможно, спросите своего клиента, где он хочет, чтобы это было запущено. Вы можете быть слишком восторженными.
решение2
На практике вам нужно будет сделатьнесколькобинарные пакеты (например, .debдля Debian и Ubuntu, .rpmдля Fedora) для наиболее распространенных дистрибутивов Linux (и версий). Очевидно, вам нужно будет сделать разные пакеты для Fedora и Ubuntu, и вам может понадобиться сделать другой пакет для Debian Jessie и Ubuntu 16.04. Однако,иногдапакет для Ubuntu может быть установлен на какой-то (конкретный) Debian и наоборот.
Однако нам не предоставили никакой конкретной информации о том, где его можно будет запустить, я имею в виду дистрибутив, версию ядра или что-то еще.
Вам необходимо обсудить это с вашим клиентом.
В таком случае, что произойдет через год или два, когда одна из этих библиотек изменится и наше приложение перестанет работать?
Вам придется создавать и выпускать новые версии ваших бинарных пакетов, и на это вам придется потратить усилия (и деньги).
Вы можете захотеть связать (если это технически и юридически возможно) некоторые библиотеки статически (помните, что лицензия LGPL рекомендует связывать динамически, или же иметь возможность повторно связывать статически на клиентской машине). Например, libstdc++гораздо более чувствителен к версиям, чем , libcпоэтому вы можете связывать статически libstdc++и динамически libc. В реальности YMMV.
Обратите внимание, что наличиенесколькоВерсии данной системной библиотеки могут работать или не работать на практике. Некоторые библиотеки используют системные ресурсы определенным образом, поэтому детали имеют большое значение.
P.S. Возможно, вам стоит обсудить это с вашим клиентом и предложить сделать бесплатное ПО (с открытым исходным кодом). Некоторые клиенты могут предпочесть это.