Arch + Gobo = ?

0

1

Поскольку Gobo потихоньку загибается, а Arch и Gobo идеологически близки друг к другу как системы типа сделай-сам, возникла идея скрестить ужа с ежом и получить следующий пакетный менеджер.

* Пакеты «устанавливаются» (фактически, просто распаковываются) каждый в свой подкаталог: /programs/имяпакета-версияпакета/

* Используются арчевские пакеты. Перекомпиляция не обязательна. Т.е., фактически, это только Arch с иным пакетным менеджером, а не новый дистрибутив.

* Реальная установка производится отображением файлов пакета в корневое пространство. Примерно так:
/var и /etc — сюда копируются файлы из /programs/имяпакета-версияпакета/{var,etc} (при апдейте изменённых файлов принцип тот же, что и в арче — ворнинг в консоль, что надо смерджить файлы)
/usr, /lib и т.п. — сюда кидаются симлинки на соответствующие файлы из /programs/имяпакета-версияпакета/

* Таких корневых пространств может быть любое количество. Пространства можно наследовать («пространство A = пространство B + еще 10 таких-то пакетов»), импортировать часть одного пространства в другое («отобразить в пространство C из пространства A файлы пакета blabla-1.0 по маске /usr/bin/*»). При этом, ссылки на бинарники из другого пространства ведут на утилиту, которая делает chroot в нужное пространство и exec соответствующего бинарника.
Этим решаем проблему библиотечного ада, зоопарка версий, да и в целом задачу удобного управления системами, запускающимися в чруте.

* Разумеется, предусмотреть правила биндинга в пространства имён прочих файлов: одному надо дать доступ к /media, другому — нет; одному один /home, другому — другой и т.п.

* Скрипты сборки пакетов модифицировать, чтобы пакет всегда компилировался в минимально необходимом пространстве имён на основе его списка build-зависимостей.

Еще плюшки, которые можно реализовать в процессе:

* Предусмотреть возможность глобально переопределять имена пакетов и задавать правила поиска в репозиториях. Что-то типа такого:
blabla-1.2: bazbaz-1.2 # Пакет bazbaz-1.2 пакетный менеджер будет считать пакетом blabla-1.2
barbar-*: myextra/barbar-* # Пакеты barbar всех версий пакетный менеджер всегда будет искать в репозитории myextra.

* Предусмотреть набор хуков-фильтров, отрабатывающих в момент распаковки пакета в /programs/ (или во время проставления симлинков? не уверен) и позволяющих откусывать лишнее из содержимого пакета. Например: система без info (это и так выкусывается сборочными скриптами арча, но представим, что нет); система без любых манов, кроме англоязычных; система совсем без манов; система вообще без лишнего мусора в /usr/share, такого как README, INSTALL и прочая документация.

* Предосмотреть возможность собранное корневое пространство имён сконвертировать в систему без пакетного менеджера.

Итого: экономия дискового пространства, удобно разруливать несовместимости пакетов, удобно держать на одном разделе несколько разных конфигураций ОС, удобно создавать изолированные чруты для отдельных программ. При этом сохраняются все преимущества Arch-а, включая и изкоробочную работу всего массива ПО для него — нет необходимости велосипедить свой аналог PKGBUILD-ов, как это было сделано в Gobo.

Собственно, вопросы:

1. Может быть, всё уже есть, а я изобретаю велосипед?

2. Насколько будет востребован такой механизм менеджмента пакетов?

3. Если я начну это пилить потихоньку, найдутся среди ЛОР юзеров Ъ, которые будут это принимать участие в разработке, тестировать и т.п.?

В общем, стоит браться или нет?

Ссылка

←	[kernel] Работа с страницами памяти.

[python][str] Перенос строк в коде

→

>/programs/
дальше не читал

anonymous_sapiens ★★★★★
(28.02.11 05:43:12 MSK)

Ссылка

Что этот спам делает в Development?

Led ★★★☆☆
(28.02.11 06:08:26 MSK)

Ссылка

>1. Может быть, всё уже есть, а я изобретаю велосипед?
Есть, но сам же говоришь: потихоньку загибается.

2. Насколько будет востребован такой механизм менеджмента пакетов?

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

3. Если я начну это пилить потихоньку, найдутся среди ЛОР юзеров Ъ, которые будут это принимать участие в разработке, тестировать и т.п.?

Вряд ли. Здесь и GoboLinux'ом не очень многие пользуются.

А вообще Gobo еще не совсем умер. Recipes доступны вполне свежие. Какая-то активность в блоге разработчиков и в рассылках. Даже релиз 015 все еще готовится. Я надеюсь, что вдруг оно еще и не умрет?

proud_anon ★★★★★
(28.02.11 06:38:58 MSK)

>Реальная установка производится отображением файлов пакета в корневое пространство.

Я у себя на Убунте так делаю. Имею несколько деревьев, скажем, /usr/local/myprogs1, /usr/local/myprogs2 и т.п., где стоит свой, отдельный GCC, свои отдельные библиотеки и туда приделан свой отдельный PATH, LD_LIBRARY_PATH и т.п. Но у меня там все ПО зависит либо от другого ПО в том же дереве, либо от того, что поставлено в систему из стандартных дистрибутивов. Организовывать зависимости между «деревьями» не пробовал.

Реальная установка производится отображением файлов пакета в корневое пространство

В Gobo это используется, как вы, наверное, знаете, в качестве запасного механизма, на случай, если нормальная установка не пройдет, и реализовано через патч в ядре. Это ведь все то же самое, что в FHS, только через костыли. Почему бы сразу не сделать несколько «деревьев» и не держать там отдельный набор библиотек в каждом? Нет, не для каждой программы отдельно, а умещая как можно больше программ в одно дерево, но при необходимости переходя к другому. Экономить место? Можно получить геморроя больше, чем будет сэкономлено места.

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

В общем, стоит браться или нет?

Не стоит. Выпей водки, плюнь и не берись.

(чтобы у тебя были шансы на успех, этот совет нужно проигнорировать)

proud_anon ★★★★★
(28.02.11 06:48:00 MSK)

Ответ на: комментарий от proud_anon 28.02.11 06:48:00 MSK

>из стандартных дистрибутивов
s/дистрибутивов/репозиториев/

proud_anon ★★★★★
(28.02.11 06:48:43 MSK)

Ссылка

Ответ на: комментарий от proud_anon 28.02.11 06:38:58 MSK

> Далеко не все программы способны работать в нестандартной файловой системе даже с перекомпиляцией. На них в Gobo свои патчи накладывали. А без перекомпиляции вообще совсем мало программ, которые будут легко переносить перемещение в файловой системе.

Фишка именно в том, что для программ пути ФС будут стандартными. Или вы имеете ввиду, что некоторые программы заглючат, если вместо реальных файлов по родным путям будут лежать симлинки на файлы? Ну можно, в принципе, хитро извернуться через биндинг точек монтирования, union-ы и/или hard-линки, хотя это становится сильно похоже на костыли.

В Gobo это используется, как вы, наверное, знаете, в качестве запасного механизма, на случай, если нормальная установка не пройдет, и реализовано через патч в ядре. Это ведь все то же самое, что в FHS, только через костыли.

В Gobo программы собираются с нестандартными путями инсталляции в дебрях /System. Для тех программ, которые такого насилия не переживают, лежат симлинки вида /usr/bin -> /System/Links/Executables. Я этот подход считаю ошибочным. Получается ведь та же самая FHS, только с перекореженными во имя няшности /Длинными/Названиями/Каталогов.

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

Т.е. есть каталог, который служит корнем чрута, в нём подкаталог programs забинден на реальный каталог, хранящий пакеты, в других подкаталогах лежат симлинки вида /bin/bash -> /programs/bash-x.y.z/bin/bash. При чруте в такой каталог, мы оказываемся в обычном FHS-ом корне, все программы счастливы.

реализовано через патч в ядре

Патч в ядре там вообще не про то. Разработчику Gobo было не по нраву видеть зоопарк каталогов в корне, вот он и сделал скрытие части имён в листинге каталога: имена /bin, /lib и т.п. в корне есть, и к ним можно обратиться, но при получении содержимого /, они не перечисляются. Можно наложить этот патч на ядро любого дистрибутива, с тем же результатом. Т.е. это чисто свистелка, не влияющая на работу системы.

~~geekless~~ ★★
(28.02.11 07:19:09 MSK) автор топика