Было много хороших ответов (включая мой :)) здесь . Хотя это больше касается бинарной совместимости (о которой вам нужно беспокоиться).
Для установщика я бы порекомендовал autopackage (мы успешно выпустили несколько версий нашего программного обеспечения с ним), они уже выполнили часть "installer.sh" и многое другое (например, интеграция с рабочим столом).
Вы должны быть осторожны и тестировать свои сценарии обновления и прочее, в зависимости от того, насколько сложна ваша структура пакета, но в целом она довольно аккуратна. Я исправил несколько ошибок с обработкой зависимостей в 1.2.6, так что все должно быть в порядке.
ОБНОВЛЕНИЕ : исходный вопрос был удален, поэтому отправляя полный ответ здесь, игнорируйте все ссылки на autopackage, который был объединен в Listaller , не уверен, что соответствующие части сохранились.
Для стандартных библиотек (таких как crypto ++, pthreads и т. Д.), Которые, вероятно, будут доступны в дистрибутиве, создайте динамическую связь и попросите пользователей получить их из своего репозитория дистрибутивов. Или ссылку статически, если это возможно.
Для странных библиотек, версию которых вы должны контролировать (например, если вы хотите развернуть приложение Qt4 на территории вражеских гномов), скомпилируйте их самостоятельно и установите в закрытое место, о котором знает только ваше приложение.
Никогда не устанавливайте private libs в стандартные места, если вы не уверены, что не мешаете пакетным системам всех поддерживаемых вами дистрибутивов. (и что они тоже не могут вам мешать).
Используйте rpath вместо LD_LIBRARY_PATH и установите его правильно для всех двоичных файлов и всех библиотек, которые ссылаются друг на друга. Вы можете установить rpath в вашем двоичном файле на «$ ORIGIN; $ ORIGIN /../ lib; / opt / my / private / libs» и заставить линкер искать эти места перед любыми стандартными путями. (я думаю, что для работы нужно установить флаг компоновщика). Убедитесь, что на ваших библиотеках также установлен rpath: например, QtGui нужен QtCore, и если пользователь установит стандартный пакет с другой версией, вы абсолютно не хотите, чтобы он был загружен (exe -> ../lib/QtGui.so ( 4.4.3) -> /usr/local/lib/QtCore.so (4.4.2) - верный способ умереть рано).
Если вы компилируете с любым rpath, вы можете позже изменить его с помощью chrpath, что позволит настроить местоположение установки как часть пост-обработки или сценария установки.
Поддерживать бинарную совместимость. GLIB_C довольно статичен для ваших пользователей, поэтому вам следует ссылаться на достаточно старую версию. 2.3 - безопасная ставка. Вы можете использовать APBuild - оболочку gcc, которая поддерживает версию GLIB_C и выполняет несколько других приемов двоичной совместимости, поэтому вам не нужно компилировать все свои приложения в действительно старом дистрибутиве.
Если вы ссылаетесь на что-либо статически, его, как правило, тоже нужно перестраивать с помощью APBuild, в противном случае оно обязательно будет перетаскивать более новые символы GLIB_C. Все .so, которые вы устанавливаете в частном порядке, естественно, должны быть собраны вместе с ним. Иногда вам приходится исправлять сторонние библиотеки, чтобы использовать более старые символы. (Мне пришлось исправлять ruby, чтобы вернуть реальные разрешения вместо эффективных, поскольку в более старых GLIB_C таких функций нет. До сих пор не уверен, что я что-то сломал:)).
Для интеграции со средами рабочего стола (ассоциации файлов, mime-типы, значки, пункты меню «Пуск» и т. Д.) Используйте xdg-utils. Но будьте осторожны, как и все в Linux, им не нравятся пробелы в именах файлов :). Обязательно проверяйте эти вещи в каждом целевом дистрибутиве - реализации xdg пронизаны ошибками и причудами.
Для фактической установки вы можете либо предоставить множество собственных пакетов (rpm, deb и некоторые другие), либо развернуть свой собственный установщик, либо найти установщик, который работает на всех дистрибутивах в обход собственных менеджеров пакетов. Для этого мы успешно использовали Autopackage (те же люди, которые сделали APbuild).