Які типи інсталятора має використовувати комерційне програмне забезпечення для підтримки Linux?

9

Вихідний код не відкритий або вільний, тому компіляція при встановленні не є варіантом. Поки я бачив розробників, які:

надайте файл tar.gz, і користувач повинен розпакувати в потрібному місці.
надайте .tar.gz зі скриптом install.sh для запуску базового інсталятора, можливо, навіть спонукає користувача до параметрів установки.
надавати RPM та / або файли deb, дозволяючи користувачеві продовжувати використовувати нативні засоби управління пакетами, з якими вони знайомі для встановлення / оновлення / видалення.

Хотіли б підтримати найбільшу кількість дистрибутивів Linux, зробити життя користувачів якомога простішим, а також підтримувати якомога менше інфраструктури побудови / упаковки / установки.

Шукаю рекомендації щодо упаковки мого програмного забезпечення.

linux software-installation packaging

— Майк Грей
джерело

19

Я бачу два способи на це подивитися.

Один з них - орієнтація на найпопулярніші Linuxes, надання нативних пакетів для кожного, доставку пакетів у порядку популярності. Кілька років тому це означало надання RPM для Linux Redes типу спочатку, а тоді, коли час дозволяв перебудовувати вихідний RPM для кожного менш популярного ОС на базі RPM. Ось чому, скажімо, RPM Mandriva часто трохи старше, ніж Red Hat або SuSE RPM. Оскільки Ubuntu настільки популярний останні кілька років, ви можете почати з .deb і додавати RPM пізніше.

Інша - спробувати націлити на всі Linuxs одразу, саме це роблять ті, хто надає двійкові тарболи. Мені дуже не подобається цей варіант, як систематичний та кінцевий користувач. Такі тарболи розкидають файли по всій системі, в якій ви їх розпаковуєте, і пізніше немає ніяких варіантів для таких цікавих деталей, як видалення, перевірка пакунків, інтелектуальні оновлення тощо.

Ви можете спробувати змішаний підхід: рідні пакети для найпопулярніших Linux, плюс двійкові тарболи для диваків Linuxes та старих системних адміністраторів, які не люблять менеджерів пакетів з будь-якої причини.

— Воррен Янг
джерело

Це майже такий підхід, який я застосував до цього часу - розпочавши з RPM для Redhat / Fedora / CentOS, тепер надаючи Ubuntu / Debian .deb файли, але ще не вирішив, чи зробити tar.gz все ще буде корисним і потрібним. Здається, це було б добре, щоб користувачі з менш популярними дистрибутивами могли принаймні примусити програмне забезпечення працювати самостійно, а не навіть мати можливість. Дякую.

— Майк Грей

2

Створення портативного двійкового тарболу може бути набагато більшою роботою, ніж ви уявляєте. Лише однією можливою пасткою є те, що g ++ ABI змінювався кілька разів за ці роки, тому вам, можливо, доведеться надсилати бінарні версії будь-яких використовуваних вами бібліотек C ++, а не використовувати версії платформи для досягнення достатньо широкої сумісності. Це одна з причин, що один двійковий RPM не встановлюється і не працює всюди. Це, мабуть, є культурним сприйняттям цього факту з RPM, тоді як тарболи - можливо, тому, що вони стародавній стандарт - повинні працювати всюди.

— Воррен Янг

Я бачив, що мікс-підхід є найкращим: ви можете досягти багатьох людей і зусиль не так вже й багато.

— Гюго

Зробити простий, двійковий тарбол все ще добре. Особливо, якщо цей тарбол зберігає всі файли гри в одному автономному каталозі. Це дозволить деяким користувачам розпакувати та запустити його без встановлення; і це також полегшить життя іншим дистрибутивам (наприклад, Gentoo, Arch тощо), тому що їм буде простіше розпакувати / перепакувати цей тарбол.

— Denilson Sá Maia

4

Що б ви не робили, не забудьте включити "скрипт підтримки", який дозволяє зібрати якомога більше інформації в цільовій системі для усунення помилок. Я гарантую, що ви зіткнетеся з проблемами та налагодженням речей, за якими замовник говорить, а порівняно з реальністю, дуже сильно відрізняються.

— vwduder
джерело

0

Мої переваги - це завжди пакет (rpm | deb тощо). Залежно від характеру програмного забезпечення, можливо, варто націлити пакети на конкретні дистрибутиви (rhel / centos тощо), але ви, ймовірно, ніколи не зможете прокрутити достатню кількість пакетів для всіх.

Встановлення скриптів може бути нормальним, залежно від сценарію. Для мене найважливіше, що стосується непакетного програмного забезпечення, це те, що його легко встановити в обраному вами місці.

— теоретично
джерело

0

Ігри, як правило, використовують інсталятор (раніше Loki Installer, нині MojoSetup), який встановлює гру чисто в префікс і обробляє такі речі, як іконки.

— directhex
джерело