Назад | Перейти на главную страницу

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

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

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

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

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

(курсив мой)

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

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

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

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

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

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

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

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

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

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

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

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

Думаю, есть немного "синдрома не изобретенного здесь". Система пакетов 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). По умолчанию только владелец домена может создавать пакеты в этом пространстве имен.

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

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