LINUX.ORG.RU

Человеческое управление пакетами в Linux

 , ,


2

3

Предыстория тут

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

Касательно NixOS: _формально_ в ней есть то, чего мне хочется, но вместе с этим - куча всего на тему «как нам обустроить Линукс», причём сделано это как-то сумрачно, сопряжено с красноглазием, и мне трудно представить NixOS на среднем десктопе или ноуте, так что нужно что-то попроще.

Суть предложения: переделать FHS и немного пропатчить ядро, чтобы умело хардлинки для каталогов.

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

Поэтому корневой каталог будет выглядеть как-то так:

/Alyssa
/Bob
/root

На втором уровне много чего можно разместить, но речь про управление пакетами, так что ограничимся очевидным /pkg:

/Alyssa
  /pkg
/Bob
  /pkg
/root
  /pkg

Каждый пакет устанавливается в отдельный каталог:

/Alyssa
  /pkg
    /firefox:85.0.2
    /firefox-developer-edition:127.0.0.1
    /smplayer:28.6
    /telegram-desktop:4.8.2
/Bob
/root
  /pkg
    /linux-ubuntu:6.3.9600
    /linux-vanilla:6.3.9600
    /systemd:666
    /ubuntu-core:24.04
    /ubuntu-core:25.17

Логика такова:

  • Для каждого пакета разработчики/мантейнеры указывают зависимости (deps) пофайлово (чтобы отвязаться от названий пакетов, которые в каждом дистрибутиве свои).
  • В репозиториях лежат данные, в каком пакете какие файлы содержатся.
  • При установке пакета ПМ скачивает нужные deps-пакеты и устанавливает их в каталог пакета же.
  • Но если такой deps-пакет уже где-то установлен - вместо каталога с новым экземпляром deps-пакета создаётся хардлинк на уже установленный экземпляр (можно менять политики поиска дубликатов - только у root или же у любого пользователя, ради пущей экономии места).
  • Установка deps-пакета ничем не отличается от установки любого пакета. Т.е. всё вышеописанное выполняется рекурсивно вплоть до самого «нижнего» пакета (наверное, это ядро).

То есть:

/Alyssa
  /pkg
    /firefox:85.0.2
      /deps  - тут зависимости фаерфокса
        /ffmpeg:5.8.12
          /deps
            /bzip2:2.4.8  --хардлинк------------
            /lame:3.200                        |
              /deps                            |
                /ncurses:10.20  --хардлинк-----|-----
              /usr                             |    |  
          /usr                                 |    |
        /gtk:4.2  --хардлинк--------------     |    |
      /usr   - файлы самого фаерфокса    |     |    |
/root                                    |     |    |
  /pkg                                   |     |    |
    /ubuntu-core:24.04  - метапакет      |     |    |
      /deps                              |     |    |
        /bzip2:2.4.8  <------------------|------    |
        /gtk:4.2  <-----------------------          |              
        /ncurses:10.20  <----------------------------

Привычное файловое окружение для программ (аля FHS) это некоторый срез файлового дерева, выбирающий пакеты нужных версий. Окружение можно создавать, например, передачей нужных переменных среды. По сути, у пакетов остаётся только одно общее место в деревьях зависимостей - ядро и systemd (уточните, нужно ли добавить сюда libc и прочие подобные штуки, или их тоже можно подхватывать динамически).

Далее:

  • Обновления пакета как такового нет. Всегда идёт установка новой версии параллельно прежним.
  • При установке новой версии пакета, ПМ может переключить зависящие от него пакеты на эту новую версию, если это явно указано мантейнерами.
  • По умолчанию пакет остаётся с текущими версиями deps-пакетов и может так работать сколь угодно долго, пока в ядре что-нибудь не отломают.
  • Чтобы перенести пакет на новую систему, достаточно скопировать его каталог - это вытянет рекурсивно все его зависимости, кроме самых общих (ядро и systemd).
  • При удалении пакета полностью удаляется его каталог со всеми deps-пакетами. Если они где-то используются - они остаются там. Если больше нигде не используются - удаляются вместе с пакетом. Такая автоматическая сборка мусора без лишних сущностей.

В общем, суть такова. На мой взгляд, это хороший баланс между стабильностью, обновляемостью, экономией места и «ленивостью» сопровождения. Мантейнерам больше не придётся бежать в колесе, постоянно починяя отвалы программ из-за того, что A хочет B, а в репах уже B1 во все поля. Особенно это касается программ не из центральных репозиториев, а из всяких AUR и PPA. Ну а юзеры, в свою очередь, могут очень долго пользоваться необновляемыми программами при свежей системе.

Дискасс!

Deleted

Чтобы всё это работало как следует, необходимо не просто «переделать FHS и немного пропатчить ядро», а основательным образом пересмотреть саму концепцию файловой системы, попутно отделив от неё одно из её фундаментальных свойств – иерархичность. Но обо всём по порядку.

Итак, что такое файл? Это именованная область данных, не так ли? А что если полностью отделить «имена» от «данных»? Получится отдельно иерархическая система имён [файлов], и отдельно плоская система хранения неименованных блоков данных. Система имён будет обращаться к системе хранения, чтобы поместить туда блок данных или запросить его оттуда.

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

В таком случае, у хранилища блоков можно будет запрашивать «передай мне блок данных вот с этим хэшем» и «вот блок и его хэш, помести на хранение». Таким образом, в хранилище блоков будут храниться блоки и их хэши, а в системе имён – сами имена, их иерархия, и хэши тех блоков, которые соответствуют этим именам. «Файл» в такой системе имён – это имя и список хэшей блоков данных, которые ему соответствуют. Но и каталог в таком случае – это тоже имя и список блоков данных, которые ему соответствуют! Разница между файлами и каталогами становится несколько менее заметной. Проблема символических и жёстких ссылок уходит сама собой, потому что «ссылками» будут все «файлы», но ссылаться они будут не друг на друга [=логически как бы на ту же самую сущность], а на хэши объектов из хранилища – отдельную, независимую сущность. Ну или как-то так.

И судя по всему, в ядре уже и так в том или ином виде есть многое из описанного. И привести файловую подсистему к такому виду при желании (и умении) будет не так уж и сложно. Наверное.

anonymous
()
Ответ на: комментарий от anonymous

Классная мысль, мне нравится

Deleted
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Воистину, бро. Ты прям NixOS описал. Правда, контентно-адрерсуемое хранилище там пока сделано поверх обычной ФС, но это только начало. Рано или поздно запилим под это дело специализированную контентно-адресуемую ФС, а потом и иерархический слой реализуем поверх неё, а потом и специальное ядро... Снится мировая революция, победа контентной адресации, иоттабайты контента в межпланетной сети IPFS...

anonymous
()

Прочитай про устройство flatpak и в частности ostree, который там используется. Тебе пацаны никогда не расскажут, что там вовсю используются хардлинки, и всё замечательно обходится без хардлитков на каталоги.

anonymous
()
Ответ на: комментарий от anonymous

«Those who don't understand NixOS are condemned to reinvent it, poorly.»

anonymous
()
Ответ на: комментарий от WitcherGeralt

FHS говно, это всем давно понятно

Аргументы?

1) Излишняя иерархия каталогов дублирующих друг друга, пример /bin, /sbin, /usr/local/bin, /usr/share/bin, /opt. Логично отправить все в помойку, как это сделали в NixOS, и создать интуитивно понятный /Applications. /Applications в свою очередь будет делиться на /System где будет находиться базовый системный софт и доступ у нему будет только у суперюзера и соответственно /User, в котором будет находиться пользовательский софт. Таким образом будет разделение на kernel land и user land как во FreeBSD, а не так как сейчас, все намешано в одну кучу.

2) Наркоманские и непонятные названия каталогов, например /opt и /etc, без гугления и чтения документации непонятно зачем нужны и за что отвечают. Как я выше писал, /opt вообще нужно выпилить за ненадобностью, а /etc или переименовать в /Config или еще лучше и логичнее, конфиги софтин поместить в их рабочие каталоги.

3) Каталог суперюзера root почему вынесен в корень? Он хоть и суперюзер, но все таки юзер, а значит место ему в /Users. Да и самого пользователя root логично переименовать в Superuser.

4) Каталог lib выпилить а его содержимое, прочие общие файлы и рантаймы в /Applications. 5) Каталог var см. п. 4 6) Каталог etc см. п. 4

Это основное.

anonymous
()
Ответ на: комментарий от anonymous

/Applications

Слишком длинное слово, да ещё прописные буквы. Не надо так. Чем /apps или /pkg не устраивает?

С остальным, в целом, согласен.

Deleted
()

Вкратце: достала нынешняя концепция с вечным отвалом то одного, то другого из-за зависимостей

а нефиг из стебла в тестинг перелезать.

darkenshvein ★★★★★
()
Ответ на: комментарий от anonymous

Файловая система не то место, где нужна прям 100-процентная интуитивная понятность. Программы же не через файловый менеджер запускают, а через всякие менюшки-иконки.

Deleted
()
Ответ на: комментарий от WitcherGeralt

ты просто ННП

Что именно?

сложилось просто исторически

Будто что-то хорошее. Разная вредная муть типа традиций и верований тоже сложились исторически.

anonymous
()
Ответ на: комментарий от Deleted

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

anonymous
()
Ответ на: комментарий от anonymous

Что именно?

Какие профиты несёт FHS, какая логика за ней стоит.

Разная вредная муть типа традиций

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

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Какие профиты несёт FHS

Какие? На ум приходит только одно: переменные среды коротенькими получаются.

Deleted
()
Ответ на: комментарий от WitcherGeralt

Какие профиты несёт FHS, какая логика за ней стоит.

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

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

Это уже попахивает фанатизмом. Никто не говорит что fhs нужно каждый год менять, но она уже давно нуждается в основательном пересмотре.

anonymous
()
Ответ на: комментарий от WitcherGeralt

Точки монтирования

С ними даже в винде нет проблем.

бекапы

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

порядок в системе

Это щас ты пошутил так? Куча дублирующих друг друга каталогов, бинарники в lib и конфиги в share это порядок в системе? XD

Deleted
()
Ответ на: комментарий от WitcherGeralt

Про порядок я уже выше писал на примере /bin, /sbin и так далее.

А точки монтирования и бэкапы никто не отменял. Просто нужно основательно пересмотреть FHS и привести к человеческому виду.

anonymous
()
Ответ на: комментарий от anonymous

Это уже попахивает фанатизмом

Только когда ты цитируешь не полностью и игнорируешь смысл сказанного.

Может в семидесятых несла профит, а позже в серьезных коммерческих юниксах было переработано

Лул. Ну ты давай подробнее, не стесняйся. Как именно преработали и какой именно выигрыш с этого получили?

Ты аргументируй свою позицию

Аргументировать за пользу стандартов?

WitcherGeralt ★★
()
Ответ на: комментарий от anonymous

Про порядок я уже выше писал на примере /bin, /sbin и так далее

Так там полный порядок, просто ты не догоняешь.

А точки монтирования и бэкапы никто не отменял

Да ладно? Расскажи, как ты будешь, например, вменяемым образом монтировать жирную файловую систему под данные, которая в FHS будет просто смонтирована в /srv, если ты растащишь данные куда попало. С бекапами примерно та же ситуация.

привести к человеческому виду

К домохозяечному виду для неосиляторов.

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Так там полный порядок, просто ты не догоняешь.

Аргумент вида «сам дурак».

К домохозяечному виду для неосиляторов.

Зачем осиливать жрать говно?

anonymous
()
Ответ на: комментарий от anonymous

Аргумент вида «сам дурак»

Каким был твой аргумент, такой получился и контраргумент.

Зачем осиливать жрать говно?

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

WitcherGeralt ★★
()
Ответ на: комментарий от anonymous

У культиста есть аргументы, а у тебя только «не по-человечески».

WitcherGeralt ★★
()

Для каждого пакета разработчики/мантейнеры указывают зависимости (deps) пофайлово

А если имя файла одно и тоже, а содержимое требуется принципиально разное? Какая-нибудь tzdata формат поменяла, а имена и пути остались.

ls-h ★★★★★
()
Ответ на: комментарий от anonymous

NixOS, flatpak, snap, appimage, но пока к сожалению воз и ныне там.

Кроме первого пункта (и, возможно, второго?) все остальные «решают» проблему частично и сбоку: есть основная система на каком-нибудь apt+dpkg, а для левого ПО есть отдельный менеджер пакетов (flatpak, snap, appimage). Вот если использовать один подход для всей системы, то воз поедет.

ls-h ★★★★★
()
Ответ на: комментарий от anonymous

Может в семидесятых несла профит, а позже в серьезных коммерческих юниксах было переработано.

Что именно и где было переработано в лучшую сторону?

ls-h ★★★★★
()
Ответ на: комментарий от meliafaro

Где гарантии, что 500-й или 1000-й элемент последовательности не является ссылкой на первый?

Где на практике встречаются пути из 500 элементов?
В принципе не так уж сложно составлять список идентификаторов inode'ов при обходе пути и проверять на одинаковые. Хотя, да, оверхед. Лучше придумать что-то другое вместо жёстких ссылок на каталоги.

ls-h ★★★★★
()
Ответ на: комментарий от i-rinat

Некоторый каталог в глубине является ссылкой на корень. Обойди рекурсивно всё дерево.

Запоминаем номера inode'ов, не ходим два раза по одному номеру.
Конечно, это дополнительные тормоза.

ls-h ★★★★★
()
Ответ на: комментарий от Deleted

Именно! Хотя это не самоцель, причина несколько глубже.

Можно копировать с опцией «заменять симлинки оригиналами».
Не такая большая проблема.

ls-h ★★★★★
()

Для каждого пакета разработчики/мантейнеры указывают зависимости (deps) пофайлово
При установке пакета ПМ скачивает нужные deps-пакеты и устанавливает их в каталог пакета же.
/bzip2:2.4.8

Т.е. внутри каталога какого-нибудь firefox есть подкаталог bzip2:2.4.8, который состоит не просто из названия пакета, но и из версии?
Как firefox при запуске находит нужный .so файл? просматривает все подкаталоги у себя?

ls-h ★★★★★
()
Ответ на: комментарий от ls-h

Как firefox при запуске находит нужный .so файл?

Так же, как и сейчас - через переменные среды.

Deleted
()
Ответ на: комментарий от ls-h

В принципе не так уж сложно составлять список идентификаторов inode'ов при обходе пути и проверять на одинаковые.

Только в это время надо лочить создание/удаление других каталогов в этой ФС.

пути из 500 элементов?

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

Ещё ломаются классические права доступа, недостаточно будет сменить права на каталог, чтобы закрыть доступ во все его подкаталоги. Непонятно что делать, если каталог стал точкой монтирования, а внуть его ведут эти самые ссылки на каталоги...

mky ★★★★★
()

Дискасс!

Решают же эти проблемы уже! Fedora Silverblue мечтают в 30(если я правильно понял) стать Workstation по умолчанию, хотя и очевидно, что время ещё не наступило, flatpak пока не тянет заменить репозитории пакетов, а набивать пакетами os-tree как-то странно, но факт в том, что скоро тема с пакетами будет прикрыта и всё проблемы закончатся.

papin-aziat ★★★★★
()

У тебя уже ничилавечиские(С)(кажется тв канал из ЕКБ) конструкции на основе хардлинков.

Приложение должно лежать в одном месте, а лучше контейнере (в смысле хранилища) и к нему ОС должна предоставлять доступ всех пользователей.

Но, похоже, всё к этому и идёт. Когда каждой запущенной копии ОС подсовывает свое окружение.

Deleted
()
Ответ на: комментарий от papin-aziat

Пакеты хороши при малом количестве и чёткой цели их создания.
Когда RH был маленьким, а я молодым и наивным, то 650МБ СД диска решали за пакеты всё, что нужно.

Deleted
()
Ответ на: комментарий от Deleted

Пакеты хороши при малом количестве и чёткой цели их создания.

Ну да, именно из них и состоит, как я понял, os-tree и репозиторий для системы, а все юзерские хотелки в flatpak, вот и всё, и нет никаких зависимостей.

papin-aziat ★★★★★
()

и мне трудно представить NixOS на среднем десктопе или ноуте

потому что что? пацаны не поймут? мне вот сложно представить что-то отличное от NixOS на своём десктопе. как вспомню этот пердолинг с дебианом и убунтой, аж передёргивает

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.