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

Зачем это? Чем тебя flatpak не устроил?

Там все твои проблемы уже решены, причем более рационально и это уже де-факто стандарт. Зачем велосипед изобретаешь?

curufinwe ★★★★★ ()

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

Нечто подобное когда-то очень-очень давно я видел в Qtopia Linux (дистрибутив для мобилок).

Там тоже попытались привести в порядок всю эту UNIX-Way’ную помойку с /usr/bin, /bin/, /sbin, /usr/local/share/, /usr/local/bin и прочий махровый неадекват родом из 70-ых. Потом что-то ещё было, но тоже не взлетело.

Так что как ни крути, NixOS сегодня это наиболее user-friendly попытка избавиться от Linux’ового проклятия в виде Dependency Hell.

EXL ★★★★★ ()

Не в Linux, а в ОСях на Linux. Никто ничего делать не будет, потому что почти все пакетные менеджеры «популярных» дистров устаканились навсегда ещё в конце 90х, а новые дистры с новыми молодежными пакетными менеджерами – «маргинальные», и их массово использовать не будут.

abbcto ()

FHS говно, это всем давно понятно. Жалко sta.li не взлетел. Из условно живых есть gobolinux, но в том то и дело что условно.

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

NixOS сегодня это наиболее user-friendly попытка избавиться от Linux’ового проклятия в виде Dependency Hell

Проблема в том, что это user-friendly очень non-friendly

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

Linux’ового проклятия в виде Dependency Hell

ты имеешь в виду вендового? В божественном линуксе с этим отродясь проблем не было. А вот WinSxS на 100500+ гигов регулярно встречается (в этом месте передаём привет NixOS).

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

Никто ничего делать не будет

Я сам начинал пилить такой ПМ, ещё когда на gentoo сидел, но упёрся в неумение ядра создавать хардлинки на каталоги. Пилил, кстати, на баше))

Сейчас бы попробовал для Арча на Питоне запилить, но опять же, ядро...

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

А нефиг ставить всякое проприетарное говно. Не нравится как собрал дядя - пересобери со своими либами, да и всё, делов-то.

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

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

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

Ну вот ядрописателям это не нужно

Ядрописателей много, это не какой-то Государственный Комимитет им. Линуса. Одним не нужно, другим нужно.

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

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

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

На первое время пойдёт. Главное увидеть как это всё будет работать. Потом можно хоть на rust переписывать.

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

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

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

Не, я почитаю и отпишусь, но лично мне и текущие реалии нравятся.

P.S. Я тебя сразу спрошу — ты понимаешь, в чем сложность хардлинков на каталоги?

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)

Если юзеры могут пакеты, значит у них есть все права на /pkg. А если там хардлинки, то alice может поиметь bob-а записью туда кейлоггера и прочего. /дискасс

То, что ты хочешь, называется virtualbox/jail/kvm/etc, где каждый сам себе хозяин, но не может потрогать хост-систему. Платишь местом на диске и памятью, которую сейчас можно купить 16гб на сэкономленный завтрак в приличном ресторане. Для экономии места можно юзать какую-нибудь специфичную CoW фс. А вообще пакеты и версии для юзера это головняк, дай им /Applications, .app bundles и AppStore.

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

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

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

Это не фанатизм. Просто кто-то смог освоить инструмент, а кому-то всю жизнь придётся мышевозить между 2 кнопок и полагаться на других.

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

питоновый портаж работает быстрее и эффективней плюсового полютиса

Хромой обогнал одноногого

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

А нефиг ставить всякое проприетарное говно. Не нравится как собрал дядя - пересобери со своими либами, да и всё, делов-то.

Причём тут вообще проприетарный софт?

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

Этот пердолинг самым непосредственным образом относится к Dependency Hell в Linux.

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

Зато это делает его МОЩНЫМ и ЭФФЕКТИВНЫМ. Да, именно так. А понятия о красоте у каждого свои.

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

Если юзеры могут пакеты, значит у них есть все права на /pkg. А если там хардлинки, то alice может поиметь bob-а записью туда кейлоггера и прочего

Да. Поэтому по умолчанию предлагаю тянуть deps только от root, он как бы доверенное лицо. Но так будет повышенный расход места на диске. Пусть каждый сам выбирает, что ему важнее - безопасность или экономия места. Для домашних машин, думаю, можно расшаривать pkg между пользователями.

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

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

Добавь в свою копилку антипримеров ещё и pacman, которые работает быстрее всего что ты перечислил.

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)

куча всего на тему «как нам обустроить Линукс», причём сделано это как-то сумрачно

Можно же просто поставить Nix в убунту.

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

Веток ядра - хренова туча, ядро ничем не отличается в этом плане от любого другого проекта, накладывай сколько угодно патчей и обзывай пакет linux-abbcto-edition

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

Это не ненужно, а дыра в логике фс и всех программ по работе с ней. Их нет for a reason. Погуглили бы ради приличия.

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

Если какой-то дистр будет поддерживать такую ветку то это может сработать.

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

Возможно ты хочешь не виртуал-оверкилл даже, а просто набор sh скриптов по установке (но не удалению/замене) пакетов через apt-get, добавление их в sudoers ALL и какую-то уи-морду к ним. Ну и квоты реализовать, чтобы не ставили все подряд. Никакие рут права не нужны в этом случае, как и кастомный пм.

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

Какая-то шиза говнодистра. В нормальных вся эта шляпа с bundled либами и всем остальным падает в opt. У тебя именно что легаси параша там лежит, могли бы уж сразу кидать в /parawa не стесняясь.

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

Зачем тебе хардлинки на каталоги? Чем не устраивают симлинки?

Прочитай весь пост, станет понятно.

GoboLinux пробовал?

Парни начали вроде как в верном направлении, но остановились после пары шагов.

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

Flatpak это то же, что и любой другой ПМ, только пакеты крупнее.

Ерунду не неси. Почитай про flatpak сначала. Все твои проблемы там решены.

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

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

Ну либо портируй, либо собери старую версию библиотеки - делов-то.

Вообще не понимаю в чём проблема. В линуксе вообще нет и не было никаких проблем с совместным проживанием хоть вообще всех версий какой-либо либы одновременно, если это зачем-то нужно. Даже в телефоне у меня прекрасно живут одновременно аж 3 версии libcrypto/libssl от 0.9.8 до 1.1.0h без малейших проблем.

Этот пердолинг самым непосредственным образом относится к Dependency Hell в Linux.

Нет никакого пердолинга. Нет никакого Dependency Hell в Linux. В некоторых дистрах - да, есть Dependency Hell _пакетов_. Но это лишь проблемы конкретных дистров, которые, впрочем, достаточно легко решаются даже в случае какого-нибудь упоротого в смысле зависимостей дебиана.

Stanson ★★★★★ ()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от curufinwe

Ок, почитал. Сразу вопрос: есть дистрибутивы, использующие только flatpak?

Ещё из недостатков:

1) Пакеты так же нуждаются в зависимостях, ты не можешь просто скопировать установленный пакет на другую систему
2) Если пакет использует одну-единственную прогу из рантайма на 500 Мб - он потянет весь рантайм, и удалить его будет нельзя, не поломав работу пакета

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