Чому розробники Linux не можуть створити універсальний формат упаковки?

Вибір формату двійкового пакету постачальника визначається формою Закону Мерфі: усі дистрибутиви, якими ви не користуєтесь, мають пакунки. (Корралярі: не існує дистрибутива, який би задовольняв залежності розподілу вашого програмного забезпечення).

Це питання політики чи щось глибше, що ми не бачили появи формату пакетів "побудувати один раз, біжи куди завгодно"?

Здається, цитувати Джоела Спольського на цьому:

(До речі, для тих із вас, хто дотримується затаємничого, але політично зарядженого світу форматів каналів синдикації блогу, ви можете бачити те саме, що відбувається там. RSS роздроблений на кілька різних версій, неточних специфікацій та багатьох політичних боїв, і спроба очистити все, створивши ще один формат під назвою Atom, призвів до декількох різних версій RSS плюс одна версія Atom, неточних специфікацій та безлічі політичних боїв. Коли ви намагаєтесь об'єднати дві протилежні сили, створивши третю альтернативу, у вас лише три протилежні сили. Ви нічого не об'єднали і нічого не виправили.)

(наголос додано)

У вас є (принаймні) дві системи упаковки для Linux. Це насправді гарна річ. Єдина система просто створить третю систему.

Причин для цього багато, і трохи історії - для того, щоб поставити речі в перспективу.

Пам'ятайте, що коли ми говоримо про "Linux", то, що ми зазвичай маємо на увазі, є одним із багатьох різних дистрибутивів Linux . "Linux" - це фактично ядро ​​операційної системи.

Початкова мета Linux полягала у створенні системи на базі Unix, яка працюватиме на ПК (спочатку 386). Першим кроком було створення самого ядра. Поки Лінус Торвальдс працював над ядром, Річард Сталлман працював над власною системою Free Unix, в рамках проекту GNU (GNU's Not Unix) . Щоб скоротити довгу історію, вони дещо зблизилися, оскільки GNU мав пов'язані з ними утиліти (інструменти для компіляції / бібліотеки / збирання, оболонки, текстові редактори тощо), але не було ядра для його запуску, а Linux мав ядро, але не утиліти для бігайте поверх нього, щоб зробити його корисним для мас.

Ця конвергенція стала офіційно відома як GNU / Linux. Ви побачите, що багато дистрибутивів все ще називають себе дистрибутивами GNU / Linux.

Через вільний та відкритий характер GNU / Linux кожен бажаючий міг підібрати його та створити пакетну систему відповідно до своїх специфічних смаків. Результатом було те, що для створення цих систем було використано багато різних потоків різних методів конфігурації, що спричинило побічний ефект від створення майже такої кількості різних систем управління пакетами, щоб вони вміщувались у кожну.

У кожної різної повної системи були свої сильні послідовники, які трималися з ними протягом багатьох років, в результаті чого ми маємо сьогодні: кілька широко використовуваних, глибоко вкорінених і стабільних систем управління пакетами, таких як RPM , APT / dpkg та Gentoo's Portage .

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

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

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

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

Якщо всі залежності були б однаковими, це не був би інший розподіл або інша версія одного і того ж розподілу.

Я думаю, що "Синдром не придуманий тут". Система упаковки Debian передує RedHat, і все ж вона багато в чому перевершує, але RedHat ніколи не побачить перемикання. Натомість ви бачите багато людей, які використовують "apt-rpm", який намагається надати вам деякі переваги apt з rpm-файлами.

Просто зайдіть .deb :-)

Існувало кілька орієнтовних форматів, як встановлення нуля та автопакет . На жаль, ніхто не здобув жодної тяги.

Я думаю, що клетус, Уейн і Іні відповіли на це досить добре. Я хотів би додати, що це дійсно, це не велика справа. Я працюю в змішаному середовищі, де у нас є Gentoo (portage), SUSE (rpm / zypper) та OpenBSD (пакети та порти). Встановити пакети на будь-який з них не складно, і мені не дуже важливо, який формат вони використовують.

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

Ну, завжди є статично складені двійкові файли в кулях дьогтю .... ;-)

Немає визначення стандартного бінарного інтерфейсу для "Linux", оскільки це лише ядро. Шанси, що вашому стеку програмного забезпечення потрібно буде поєднувати більше, ніж просто ваше ядро, що представляє особливу проблему підтримки стандартного ABI між сотнями розрізнених дерев.

Що стосується хороших інструментів упаковки, то я віддаю перевагу Debian GNU / Linux, оскільки це відмінний бінарний формат упаковки. Він обслуговував 90% моїх потреб у стандартних інструментах та програмах. Решта 10% створюється з джерела завдяки включенню невільних компонентів або баггі-залежних бібліотечних залежностей. Коли ці програми потрібно розгорнути, я будую власні бінарні файли для виробничих кластерів.

Щоб отримати вбудований раз, запустіть будь-який формат пакета, не змушуючи всіх використовувати один і той же дистрибутив, вам потрібно пару важливих функцій:

• Унікальне глобальне найменування пакунків, щоб двоє людей / дистрибуторів не могли самостійно створювати різні пакети з однаковою назвою.

• Можливість паралельної установки різних версій бібліотек, коли пакети мають суперечливі вимоги. Розподіл може вирішити, яку версію кожної бібліотеки використовувати, і змусити всі пакети використовувати цю версію. Система, яка працює в різних дистрибутивах, повинна бути більш гнучкою.

Zero Install надає обидві ці функції:

• Назви - це URI (наприклад, http://rox.sourceforge.net/2005/interfaces/ROX-Filer ). Лише власник домену за замовчуванням може створювати пакети в цій області імен.

• Кожна версія кожного пакета знаходиться у власному каталозі. Кожна програма бачить лише ті бібліотеки, які їй потрібні, з версіями, з якими вона сумісна.

Наприклад, програма редагування залежить від Python <3, як це:

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>
  </runner>
</command>

Дивіться також: http://www.osnews.com/story/16956/Decentralised-Installation-Systems

[Примітка: я розробник 0встановлення]