Почему нет действительно унифицированного менеджера пакетов для Linux?


31

Почему нет единого менеджер пакета , который действует как интерфейс между конечным пользователем и подстилающим менеджером пакетов низкого уровня ( apt, yast, pacmanи т.д.)?

Сложно ли это сделать и поэтому не практично, или есть реальное препятствие, делающее невозможным это сделать?


14
Я предполагаю, что мы получим единую теорию поля задолго до того, как получим единого менеджера пакетов ...


2
По той же самой причине мы не хотим ни одного дистрибутива - мне нравится, как это делает мой дистрибутив. Если вы этого не сделаете, то вы можете использовать другой или написать свой собственный. Прежде чем вы это знаете, у вас столько же менеджеров пакетов, сколько и программистов.
new123456

2
Вы не имеете в виду низкоуровневые менеджеры пакетов rpm, dep, source? Те, что вы перечислили, сами по себе.
frogstarr78

Ответы:


35

Прежде всего, есть. Проблема не в том, что нет единого менеджера пакетов, проблема в том, что их десять - серьезно.

Давайте возьмем мой любимый poldek. Это пользовательский интерфейс для управления пакетами, который может работать в нескольких разных дистрибутивах и управлять ими rpmили debпакетами. Poldek не делает то, что делает rpm (он оставляет это для rpm), а просто посылает правильные команды без необходимости разбираться со всем этим беспорядком.

Но на этом проблемы не заканчиваются. У всех разные представления о том, как должен выглядеть пользовательский интерфейс, как он должен функционировать и какие опции он должен предоставлять. Так что другие люди написали свои. На самом деле многие из менеджеров пакетов, которые люди сегодня используют в распространенных дистрибутивах, способны обрабатывать более одного бэкэнда.

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

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

Каждый раз, когда у вас есть инструмент, который пытается сделать больше, чем одна вещь, в конечном итоге он не так хорош в одном из них. Например, poldekотстой при обработке зависимостей пакета deb.


1
Почти то, что я собирался сказать. И, честно говоря, до тех пор, пока вещи прилично взаимодействуют под капотом (скажем, придерживаясь стандартов LSB), я действительно не вижу проблемы.
Шадур

10
++ для «UNIX лучше всего, когда ... каждый инструмент делает одно и делает это хорошо». Иногда я думаю, что слишком много инструментов далеко от этого пути ...
ktf

Поместите ссылку на poldek.pld-linux.org --- может быть полезно изучить что-то, что было последним обновлением в 2005 году.
Сорин

10

Короче говоря: потому что каждый дистрибутив использует свой подход к управлению пакетами. Они просто не совместимы. Стратегия управления, которая работает лучше всего для Ubuntu, не имеет большого смысла в Arch и т. Д. «Универсальный» (независимый от распространения) менеджер пакетов будет просто дополнительным уровнем пользовательского интерфейса, который никогда не будет работать так же хорошо, как отдельный менеджер каждого дистрибутива.

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


Решения по управлению пакетами переносимы на другие системы. Я видел перенос на Debian. Однако название игры состоит в том, чтобы найти то, что работает для пользователя, например. нет смысла делать portage по умолчанию в Ubuntu. Похоже, у нас пока все хорошо.
Silverfire

8

Исторические причины, в основном. Несколько систем управления пакетами были созданы примерно в одно и то же время, особенно .rpm и .deb. У каждого есть свои приверженцы, и каждый достаточно хорош, чтобы ни один менеджер пакетов не имел убедительного преимущества. Дистрибьюторы, конечно же, не увидят смысла в перестройке своей системы для реализации другого менеджера пакетов.

Это также потребовало бы перекомпиляции каждого пакета в системе (10 000 в случае Debian). Это также потребовало бы внедрения гладкой системы миграции, чтобы пользователи системы могли перейти от старого к новому диспетчеру пакетов. Усилия по миграции будут невероятно большими и экспоненциально большими, чтобы протестировать миграцию, так что вы почти наверняка получите много поломок. Это породило бы много разгневанных игроков.

Каждый дистрибутив поддерживает свой собственный набор зависимостей, основанный на том, что было построено для этого выпуска. Универсальный репозиторий пакетов будет слишком сложным для координации между дистрибутивами, поскольку конфликты зависимостей почти наверняка возникнут. Поэтому фактическое преимущество единой системы управления пакетами (универсальные пакеты) будет невозможно реализовать на практике в любом случае.

Наконец, кто может выбрать универсальный стандартный менеджер пакетов? В комиксе XKCD, указанном в комментариях к OP, обобщен обычный режим отказа в этом типе упражнения. Стандартизация такого рода вещей будет очень политической и может привести к тому, что что-то будет непригодным для использования или настолько испорченным, что порождает еще один раунд разборок в отношении стандартов - если стороны вообще могут прийти к соглашению.

Таким образом, в основном все сводится к: слишком политическим, слишком жестким, слишком рискованным и не приносящим никакой пользы, чтобы этим заниматься.


8

Что вы описали,

который действует как интерфейс между конечным пользователем и нижележащим менеджером пакетов

звучит немного как PackageKit мне, то есть ,

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

Редактировать: см. Здесь список поддерживаемых бэкэндов. Edit2: удалено бесполезное замечание.


6

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

Однако, если вы спрашиваете, почему различные операционные системы, использующие ядро ​​Linux, не имеют совместимых менеджеров пакетов, вы также можете спросить, почему в Windows и Mac нет совместимых менеджеров пакетов. Или любые другие две операционные системы.

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

Ответ: Разные штрихи для разных людей.


1
+1 для «Linux» не является операционной системой »
Silverfire
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.