Каков предпочтительный способ публикации бинарного приложения для нескольких дистрибутивов Linux? - PullRequest
5 голосов
/ 01 октября 2009

У меня есть приложение Linux с закрытым исходным кодом, которое я хочу распространять. Это приложение использует wxWidgets / GTK, поэтому существует огромный список общих библиотек (более 60), от которых зависит это приложение.

Какой способ публикации приложения и поддержки максимального количества дистрибутивов является предпочтительным?

  • Нужно ли создавать приложение для каждого поддерживаемого дистрибутива и публиковать их отдельно? Недостатком является сложность сборки (chroot и сборка для дистрибутива), и она будет работать только на поддерживаемом дистрибутиве.

  • Это добавить все общие библиотеки в установщик и использовать их с переменной env LD_LIBRARY_PATH (например, VMware)? Недостатком является увеличение размера установщика.

  • Это создание полностью статического приложения? Это, безусловно, невозможно, так как это нарушит некоторые лицензии.

  • Это смесь того или другого варианта? Как большинство коммерческих поставщиков публикуют свое собственное графическое приложение (предпочтительно на основе GTK)?

Ответы [ 3 ]

4 голосов
/ 01 октября 2009

Вы должны взглянуть на Standard Base Linux . Он разработан специально, чтобы помочь людям на вашей должности. Он определяет среду, на которую могут положиться сторонние разработчики приложений - так что есть установленная версия libc и других библиотек, а определенные программы и каталоги живут в известных местах. Все основные дистрибутивы Linux поддерживают LSB.

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

3 голосов
/ 01 октября 2009

В принципе, есть два пути. Вы можете выбрать оба, если хотите.

Первый способ - это обычные игры и такие игры. Создайте подкаталог lib /, используйте LD_LIBARY_PATH и включите в него практически все необходимые вам общие библиотеки. Это гарантирует безболезненное взаимодействие с пользователем, но при этом увеличивает размер установщика и, вероятно, увеличивает объем памяти. Я бы даже не пытался повторно использовать уже существующие библиотеки, поскольку они, как правило, исчезают при обновлении системы.

Второй способ - предоставить дистрибутивные пакеты. Как правило, их не так сложно создать, и они будут хорошо интегрироваться с дистрибутивами, и, кроме того, они будут казаться вашим клиентам более приветливыми. 2 недостатка: вы должны будете делать это для каждого дистрибутива (Debian, Ubuntu, SuSE, redhat, вероятно, хорошее начало), и вам нужно будет поддерживать их: со временем некоторые библиотеки больше не будут доступны в конкретной версии, и, таким образом, пользователь получит проблемы с зависимостями.

2 голосов
/ 01 октября 2009

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

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

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

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

Я имею в виду: сколько стоит часть вашего кода, которая настраивает пользовательский интерфейс? Сколько вы потеряете, когда кто-то украдет это?

...