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

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

(Кстати, для тех из вас, кто следит за таинственным, но политически заряженным миром форматов каналов синдикации блогов, вы можете увидеть, что там происходит то же самое. 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.

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

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

Having the same package format wouldn't help anyway. You just can't use the same package in other distributions. You can't often even use it in the different version of the same distribution. And even building the package can have the same problems.

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

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

Я думаю, есть немного синдрома "Не изобретено здесь". Система упаковки 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]