Почему разработчики Linux не могут создать универсальный формат упаковки?

Выбор формата двоичного пакета от поставщика, по-видимому, определяется формой закона Мерфи: все дистрибутивы, которые вы не используете, имеют пакеты. (Corralary: не существует дистрибутива, который бы удовлетворял зависимостям дистрибуции вашего программного стека).

Является ли это вопросом политики или чем-то более глубоким, что мы не видели появления формата пакета «собери один раз, беги куда угодно»?

Кажется уместным процитировать Джоэла Спольски на этом:

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

(выделение добавлено)

У вас есть (как минимум) две системы упаковки для Linux. Это на самом деле хорошая вещь. Одна система просто создаст третью систему.

Есть много причин для этого, и немного истории для того, чтобы представить вещи в перспективе.

Помните, что когда мы говорим о «Linux», то, на что мы обычно ссылаемся, это один из множества различных дистрибутивов Linux . «Linux» - это просто ядро ​​операционной системы.

Первоначальная цель Linux состояла в том, чтобы создать систему на основе Unix, которая работала бы на ПК (первоначально 386). Первым шагом было создание самого ядра. Пока Линус Торвальдс работал над ядром, Ричард Столлман работал над своей собственной системой Free Unix в рамках проекта GNU (Not Unix) GNU . Короче говоря, два сходятся, потому что GNU имеет связанные утилиты (C-компилятор / библиотека / инструменты сборки, оболочка, текстовые редакторы и т. Д.), Но не имеет ядра для его запуска, а у Linux есть ядро, но нет утилит для бегите сверху этого, чтобы сделать это полезным для масс.

Эта конвергенция стала официально известна как GNU / Linux. Вы увидите, что многие дистрибутивы по-прежнему называют себя дистрибутивами GNU / Linux.

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

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

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

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

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

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

Если бы все зависимости были одинаковыми, это не был бы другой дистрибутив или другая версия того же самого дистрибутива.

Я думаю, есть немного синдрома «Не изобретено здесь». Система упаковки Debian предшествует RedHat, но во многих отношениях она превосходит другие, но вы никогда не увидите переключения RedHat. Вместо этого вы видите много людей, использующих «apt-rpm», который пытается дать вам некоторые преимущества apt с файлами rpm.

Просто зайдите на .deb :-)

Было несколько предварительных форматов, таких как нулевая установка и автоматическая упаковка . К сожалению, никто не получил никакой тяги.

Я думаю, Клетус, Уэйн и Ини ответили на это довольно хорошо. Я бы хотел добавить это на самом деле, это не так уж важно. Я работаю в смешанной среде, где у нас есть Gentoo (portage), SUSE (rpm / zypper) и OpenBSD (пакеты и порты). Установить пакеты на любой из них несложно, и мне все равно, какой формат они используют.

С точки зрения программного обеспечения для упаковки это тоже не сложно. Будь то Gentoo, дистрибутив на основе RPM или дистрибутив на основе deb, он на самом деле сводится к тому, чтобы иметь рецепты для сборки программного обеспечения и добавления метаданных. Если система сборки того, что вы пытаетесь упаковать, не является полностью безумной, обычно для создания пакета требуется чуть больше, чем написание прославленного сценария оболочки.

Ну, всегда есть статически скомпилированные двоичные файлы в tar шарах .... ;-)

Не существует определения стандартного двоичного интерфейса для «Linux», так как это просто ядро. Скорее всего, ваш программный стек должен будет взаимодействовать не только с вашим ядром, что создает особую проблему поддержания стандартного ABI между сотнями разрозненных исходных деревьев.

Что касается хороших инструментов упаковки, я предпочитаю Debian GNU / Linux, потому что это отличный формат двоичной упаковки. Он удовлетворяет 90% моих потребностей в стандартных инструментах и ​​приложениях. Оставшиеся 10% собраны из исходного кода из-за включения несвободных компонентов или глючных зависимостей общей библиотеки. Когда эти приложения необходимо развернуть, я создаю собственные двоичные файлы для производственных кластеров.

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

• Глобально уникальное именование пакетов, так что два человека / дистрибутива не могут независимо создавать разные пакеты с одинаковыми именами.

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

Нулевая установка обеспечивает обе эти функции:

• Имена являются URI (например, http://rox.sourceforge.net/2005/interfaces/ROX-Filer ). Только владелец домена может создавать пакеты в этом пространстве имен по умолчанию.

• Каждая версия каждого пакета идет в своем собственном каталоге. Каждое приложение видит только те библиотеки, в которых оно нуждается, с версиями, с которыми оно совместимо.

Например, приложение Edit зависит от 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

[Примечание: я разработчик 0install]