Каков наилучший способ распространения бинарного приложения для Linux?

Ответ 1

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

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

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

Ответ 2

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

Для установщика я бы порекомендовал autopackage (мы успешно выпустили несколько версий нашего программного обеспечения с ним), они уже выполнили часть "installer.sh" и многое другое (например, интеграция с рабочим столом).

Вы должны быть осторожны и тестировать свои сценарии обновления и прочее, в зависимости от того, насколько сложна ваша структура пакета, но в целом она довольно аккуратна. Я исправил несколько ошибок с обработкой зависимостей в 1.2.6, так что все должно быть в порядке.

ОБНОВЛЕНИЕ: исходный вопрос был удален, поэтому отправляя полный ответ здесь, игнорируйте все ссылки на автопакет, который был объединен с Listaller, не будучи уверенным, сохранились ли соответствующие части.

Для стандартных библиотек (таких как crypto++, pthreads и т.д.), Которые, вероятно, будут доступны в дистрибутиве, создайте динамическую ссылку и попросите пользователей получить их из своего дистрибутива дистрибутива. Или ссылку статически, если это возможно.

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

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

Используйте 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).

Ответ 3

Вы можете попробовать InstallBuilder. Это кроссплатформенность (работает на Windows, Linux, Mac OS X, Solaris и практически на любой другой платформе Unix). Он используется Intel, Motorola, GitHub, MySQL, Nokia/Trolltech и многие другие компании, чтобы вы были в хорошей компании:) Кроме того, для двоичных установщиков, он также может создавать кросс-distro RPM и DEB-пакеты.

InstallBuilder является коммерческим, но мы предлагаем бесплатные лицензии для программ с открытым исходным кодом и очень значительные скидки для mISV или сольных разработчиков, просто напишите нам.

Ответ 4

Нет лучшего способа (универсально). tar.gz исполняемые файлы, которые должны работать.

Ответ 5

Я расскажу вам дополнительную возможность, хотя я не знаю ее статуса: установщик Loki. Loki была компанией, занимающейся переносом видеоигр для Linux. Он спустился в 2002 году, но установщик доступен.

InstallShield также доступен для Linux. Подумайте о статусе.

Хотя многие люди предлагают вам пойти с tar.gz, пожалуйста, не делайте этого. Я предполагаю, что вы хотите обеспечить приятный опыт для процедуры установки для ваших пользователей. Tar.gz - один из самых низких, низких, низких вариантов использования, который вы можете сделать. Он работает повсюду, потому что он ничего не делает, как вы знаете.

Ребята из freedesktop.org и LSB вполне поняли, куда их класть. Для этого вам нужна дружественная программа. У Autopackage imho есть цифры (я люблю это), но, несмотря на свой возраст, я не видел ни одной программы, распространяемой как автопакет.

Оцените это внимательно, но не пропустите шанс стать частью импульса в пользу этого, просто потому, что он не популярен. Если он работает для вас, и он работает для ваших пользователей, все остальное не имеет значения.

Ответ 6

Создайте архив .tar.bz2 с двоичным кодом, а затем опубликуйте для него фид, например:

<?xml version="1.0" ?>
<interface uri="http://mysite/myprog.xml"
           xmlns="http://zero-install.sourceforge.net/2004/injector/interface">
  <name>MyProgram</name>
  <summary>what it does</summary>
  <description>A longer description goes here.</description>

  <implementation main='bin/myprog'
                  id="sha1new=THEDIGEST"
                  version='1.0'>
    <archive href='http://mysite/myprogram-1.0.tar.bz2'
             size='10000'/>
  </implementation>
</interface>

Подпишите его с помощью GPG-ключа. Вы можете использовать инструменты 0install.net, чтобы вычислить дайджест и добавить подпись GPG для вас в правильном формате.

Затем разместите его на своем веб-сайте по адресу в атрибуте uri. Любой пользователь в большинстве дистрибутивов Linux (например, Ubuntu, Fedora, Debian, Gentoo, ArchLinux и т.д.) Может установить и запустить вашу программу с помощью:

0launch http://mysite/myprog.xml

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

Также посмотрите на некоторые существующие каналы для вдохновения.

Ответ 7

Возможно установить RPM на Debian и APT на RHEL.

Если вы собираетесь статически связывать эту программу или динамически связываться только с библиотеками, которые вы будете распространять в пакете, то не имеет большого значения, как вы ее распространяете. Самый простой способ - tar.gz, и это сработает.

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

Ответ 8

Я также изучил это на работе, и мне пришлось бы согласиться, что на самом деле это не лучший способ. Если ваше приложение распространяется как источник, я бы пошел с методами make/configure, упакованными в tar.gz. Это кажется довольно универсальным в мире Linux.

Хороший способ получить представление о том, что делать, - это посмотреть на более крупную организацию и посмотреть, как они распространяют свои двоичные файлы.