Пакетные менеджеры и системы управления пакетами
-
>> Ну так, в чём загвоздка? ) Я весь внимание. Что там неправильно, конкретно?
Вы придумываете новый слой абстракции вводя понятие системы управления пакетами как отдельной единицы и пытаетесь на этом построить систему. А в действительности всё проще)
Например, dpkg
Представьте, шёл 1993 год... Интернет тогда был больше похож на интранет. Вышел первый релиз Debian, пакеты deb представляли из себя 2 строки(версия и длина первого архива, чтобы знать как их пилить) и два tar архива.
Через год один хороший человек написал dpkg, чтобы работа с этими пакетами была более человекоудобной. Напоминаю, интернет ещё в виде интранета. Поэтому основной способ распространения ПО - дискеты, в последствии cd диски. И dpkg работал только с локальными файлами, другого и не требовалось. В случае наличия сети, пакет скачивался и локально устанавливался.
Однако к 1998 году уже распространение получили dial up модемы. И появилась возможность доступа к репозиториям не только в локальных сетях университетов, но и из разных точек, интранет превращается в интернет. И основным каналом распространения ПО становится сеть! И другой хороший человек написал apt (advanced packaging tool), которая обеспечивала скачивание, отслеживание зависимостей пакетов и их установку, посредством вызова dpkg, т.к. с этой задачей dpkg справляется на отлично! При этом является ли apt frontend'ом dpkg вопрос личной фантазии!)
И к этому времени обертка конфеты deb уже стала подарочной коробкой, хотя внутри также лежит tar-data!
Тоже самое и в Slackware, например. Pkgtool работает с локальными пакетами. А потом появился slackpkg.
Как то так) -
Что касается типов установки, то я бы сказал их два, а не три. 1 и 2 можно объединить, принцип один, обертка у Slack попроще только (точнее, slack'a благодаря Патрику придерживается изначальных принципов построения ос).
А вот Ваш 3 пункт, я бы поставил на первое место. Изначально все пакеты компилировались на хосте, т.к. архитектуры были различны, да и машинное время стоило дорого, его требовалось оптимизировать. Но с появлением Персональных Компьютеров достаточно быстро завоевала рынок архитектура x86. И появился смысл компилировать под неё с усредненными или заранее работоспособными параметрами.
Но всегда есть люди, придерживающиеся взглядов oldschool))) И в linux такой веткой стала Gentoo, многое позаимствовав у BSD в этом плане. От BSD также по сходному пути пошёл Macintosh, ныне macos. Но они пошли ещё дальше и обрезали на уровне железа (с выходом M1 они на самом деле вернулись к своей исходной модели)
Как то так) -
Спасибо за разъяснения. Прям, не пожалели времени. Вижу, раз так стараетесь объяснить, значит есть смысл прислушаться. Хотя, у меня всё равно осталось системное мышление. В частности, на это:
Я бы сказал "конечно, является", хотя и с оговорками. Функции СУП и менеджеров могут пересекаться, это нормально. Ведь пересекаются же (и перемешиваются) под Африкой Индийский океан с Атлантическим, хотя никто не называет их одним океаном, потому что разная солёность, плотность, флора, фауна... Так и тут, принцип разделения поддерживается на фундаментальном уровне, не на практике. Да и названия существуют не просто так. Ведь что-то же отличает Snappy от snapd или Portage от emerge.xKDE:При этом является ли apt frontend'ом dpkg вопрос личной фантазии!)
Но, раз убеждаете, я таки добавлю к табличке оговорку о том, что, мол, не всегда это разделение имеет смысл. Кто знает, может в будущем менеджеры полностью заменят СУП-ы, т. к. будут код логики содержать в себе.
Кстати, верно ли я понял, что:
...Бинарный пакет - это пакет, собранный из бинарников.
...Небинарный пакет - пакет, собранный из исходников. -
>>Ведь что-то же отличает Snappy от snapd или Portage от emerge.
Emerge - это просто cli для Portage
Со snappy сложнее объяснить. Грубо говоря, snapd на мобильной версии ubuntu, откуда это все и пошло, назывался snappy. Потом перенесли на пк и называться стал snapd, а мобильная ветка вообще заглохла. А высвободившееся слово стали использовать в общем смысле для IoT, ядер, облачных решений, использующих snap.
P.S.: на фундаментальном уровне есть Мировой Океан, а разграничения люди придумывают для удобства!) -
А что касается fronfend/backend, то есть принцип разделения ответственности между внутренней реализацией и внешним представлением в программной инженерии, откуда и пошли эти термины. И для apt/dpkg это точно не подходит. Хотя можно натянуть сову на глобус, но это такое себе системное мышление)
-
Полностью согласен! Все дистрибутивы - это мировой океан Линукс.xKDE:P.S.: на фундаментальном уровне есть Мировой Океан
Не надо. Птичку жалко!xKDE:Хотя можно натянуть сову на глобус -
Третья (надеюсь, финальная) версия конспекта. Исправленная и дополненная ))
Ссылка (https://drive.google.com/file/d/1UxX1D4X2QjTdTKAV8tPElsUUdMDr-suQ/view?usp=sharing) -
Админам: обратить внимание. Что-то пропала кнопка "Предпросмотр". И ссылка в сообщении выше у меня ссылкой не стала, хотя добавлял через кнопочку на оснастке.
