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

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

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

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

Но в целом да, ситуация заметно проще, чем в ОС с ПО без исходных кодов.

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

Шindows и есть про хардлинки, там всё один сплошной хардлинк. А ещё можно прикрутить файловые потоки и тогда наверно пихать несколько версий файла в один файл? Или держать в одном файле ссылки на все версии? Хотя подождите.

anonymous
()

AppImage не нравится?

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

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

Ну так это лечится приведением в порядок системы сборки софтины, которая зачем-то хочет, например, старую версию либы А которой нужна старая версия либы B, и одновременно требует новую версию либы В. Это в общем-то само по себе является каким-то дурдомом и бардаком.

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

пересобери

портируй, либо собери старую версию

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

Вообще не понимаю в чём проблема

Ппц XD

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

которая зачем-то хочет, например, старую версию либы А которой нужна старая версия либы B, и одновременно требует новую версию либы В

Даже не так. Допустим, имеем MariaDB и MySQL. Соответственно, какие-то приложения можно собирать с библиотеками одного сервера, а какие-то - другого. И тут ррраз, какая-то ещё библиотека собрана с либами MariaDB и используется для сборки приложения, которое собирается с либами MySQL. А там есть одинаковые имена.

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

Как называются? Хотелось бы посмотреть как это работает.

Потому что примотанным к обычному дистрибутиву flatpak выглядит не оч.

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

есть дистрибутивы, использующие только flatpak?

Да, Endless OS совсем и Fedora Silverblue отчасти.

1) Пакеты так же нуждаются в зависимостях,

Только от рантайма.

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

Не только могу, но для этого ещё и встроенный механизм есть, flatpak create-usb.

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

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

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

И тут ррраз, какая-то ещё библиотека собрана с либами MariaDB и используется для сборки приложения, которое собирается с либами MySQL. А там есть одинаковые имена.

Но зачем так делать? Автор приложения что, вообще не в курсе что за библиотеки он заказал найти системе сборки?

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

для этого ещё и встроенный механизм есть, flatpak create-usb

А без него не получится.

Уж лучше так, чем как у снапа

А у меня ещё лучше - сносишь рантайм, а прога остаётся, няняня.

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

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

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

Да, когда в системе постоянно что-то отваливается - это не жизнь

Я конечно мог бы пособолезновать вам, но неосиляторы должны страдать. :)

ЗЫ: Ну вот почему тупости нету в списке смертных грехов?... Для развития цивилизации это было бы очень полезно.

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

Ну вот почему тупости нету в списке смертных грехов?

Зачем ты так самоубийственно?

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

AS про ситуацию когда софтина требует libA.so.0.2 и libB.so.0.1, но при этом libB.so.0.1 требует libA.so.0.1

Можно, конечно просто сделать libA.so.0.1 линком на libA.so.0.2, если они совместимы, но это как-то не очень правильно лечить косяки автора/мэинтейнера таким образом.

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

Но зачем так делать?

Затем, что у этой третьей библиотеки мантейнер другой, и он своими интересами руководствуется. Да, если вовремя заметить, можно договориться, либо что-то сделать самостоятельно. Но тут ключевой момент - «вовремя заметить».

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

Затем, что у этой третьей библиотеки мантейнер другой, и он своими интересами руководствуется. Да, если вовремя заметить, можно договориться, либо что-то сделать самостоятельно. Но тут ключевой момент - «вовремя заметить».

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

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

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

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

Пакеты так же нуждаются в зависимостях, ты не можешь просто скопировать установленный пакет на другую систему

Прямо как в Винде.

Если пакет использует одну-единственную прогу из рантайма на 500 Мб - он потянет весь рантайм, и удалить его будет нельзя, не поломав работу пакета

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

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

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

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

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

когда в системе постоянно что-то отваливается - это не жизнь

Что у тебя там за система такая, в которой постоянно что-то отваливается? Рач поди какой-нибудь, прости г-споди.

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

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

Fedora Silverblue.

Пакеты так же нуждаются в зависимостях, ты не можешь просто скопировать установленный пакет на другую систему

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

Если пакет использует одну-единственную прогу из рантайма на 500 Мб - он потянет весь рантайм, и удалить его будет нельзя, не поломав работу пакета

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

Хотя проблема жирности рантайма конечно присутствует.

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

возможность использовать хардлинки с каталогами не исключает случая циклических ссылок, когда каталог А ссылается на каталог Б, а тот, в свою очередь, на каталог А

Запретить создание циклических ссылок и всё.

пользователи могут разносить хомяки на разные разделы или даже носители

А не надо так делать. Файлопомойку - пожалуйста.

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

Твой выверт решается с помощью хардлинков для файлов

Нет

Директории можно и скопировать, это не страшно и много места не занимает

Да вот именно что страшно, это всё усложняет в лютой-бешеной степени

Deleted
()

когда же уже хипстеры осилят статическую линковку. во времена когда мегабайта ram хватало всем динамической ещё небыло, и у всех всё работало.

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

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

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

Запретить создание циклических ссылок и всё.

Как? Каждый раз делать проверку? А если цикл состоит из количества элементов > 2? Где гарантии, что 500-й или 1000-й элемент последовательности не является ссылкой на первый?

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

Например, не давать сделать хардлинк на корень.

О-ло-ло.

Root → A → B(=C)
Root → C → D(=A)

Кстати, прикинь на пальцах, сколько будет стоить поиск циклов в графе и как часто нужно будет это делать.

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

В смысле? Я вроде не предлагал разрешить создание хардлинков на каталоги всем и каждому для каких угодно целей.

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

По всей видимости, ты просто не желаешь видеть класс проблем. Что ж, удачи. Возможно, всё получится.

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

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

А его разве кто-то запрещал? Вот создаст человек (или что скорее скрипт) неправильный хардлинк и капец твоему копированию пакетов вручную.

curufinwe ★★★★★
()

Выкрик с дивана

А чем символьные ссылки не устраивают? Допустим, есть общесистемная свалка артефактов по именам и версиям, а каждая прикладная программа имеет в своём уютном домашнем каталожике символьные ссылочки на все, что ей надо.

Пакетный менеджер при установке смотрит: этому тетрису надо libminer-1.0, есть такое? Делаем ссылку. Нет? Ставим и делаем ссылку.

Nervous ★★★★★
()
Ответ на: Выкрик с дивана от Nervous

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

curufinwe ★★★★★
()

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

Блять, малолетний дебил, откуда вы такие берётесь. Убей себя нахуй об стену, и продолжай, сцуко, это делать десятилетиями.

* * *

Код проверки защиты от роботов не совпадает (incorrect-captcha-sol)

Я вас в рот всех здесь вот за это ебал, макском пидарас и шома тоже. Сосите хуец без соли суки.

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

Какой-то ты агрессивный. Тебя хотя бы по ойпи не забанили.

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

anonymous
()

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

Чего только не придумают, лишь бы не юзать NixOS.

stage3 ★★
()

При удалении пакета полностью удаляется его каталог со всеми deps-пакетами. Если они где-то используются - они остаются там. Если больше нигде не используются - удаляются вместе с пакетом. Такая автоматическая сборка мусора без лишних сущностей.

Добро пожаловать в NixOS.

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

Потом что-то ещё было, но тоже не взлетело.

Был еще GoboLinux. Не взлетел, но пока еще жив. Эту типичную линуксовую помойку пытаются прибрать NixOS, flatpak, snap, appimage, но пока к сожалению воз и ныне там.

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