>> Вплоть до отдельного glibc для разных пакетов?
> А зачем, кстати? В glibc довольно неплохо с обратной бинарной совместимостью, Disclaimer: Растекание мыслью ниже чисто теоретическое -- я на стадии "изучения" вопроса. Сам пока не пользую. Совру недорого.
У них, насколько я ничего не понимаю, нет ничего про совместимость -- запускают бинари *только* с теми зависимостями, с которыми собирали. Правда. для обновлений поштучно для патчей безопасности приделали костылик grafting.
Мучаются, но едят кактус: при обновлении 1 библиотеки "в центре" пересобирают тысячи пакетов (ну, или оттягивают час Ч, как могут).
Вот Debian-ы пакеты (у альтов та же традиционная для бирарщиков механика, я думаю) собирают с зависимостями от библиотек -- или без версий (в конкретном релизе она всё равно практически одна~), или с версиями >N.NN. (*)
На днях будет GuixSD 0.12, они смержили ветку core-updates (=оно, оттягивание пересборки) в master и, видимо, уже какое-то время бинари пересобирают (~с новым ядром билиотек) на билдерах. Релизят они usb и tar образы - по готовности будет анонс.
Конкретно зачем этот фокус с несколькими glibc, которым я анонимов пугаю, не скажу. Разве что они именно настолько упираются в "функциональную" сторону сборки: если одна библиотека не та, то это уже не тот пакет (или derivation, м.б., - пакет + все его зависимости). Может быть, воспроизводимая сборка, доведённая до предела -- до воспроизводимого [библиотечного~] окружения.
Но тут надо заметить, что это фокус касается всего-всего: соберёшь (нет они не дают инструментов для этого -- но _пользователь_ может невозбранно написать (поменять 2 строчки!) свой вариант сборки на scheme и собрать его локально) openssh, например, не с openssl, а с libressl - получится другой бинарь, установленный и работающий в той же системе. То же с новой версией того же openssh. То же с локальной разработкой того же openssh.
Питоновский virtualenv или RH-ский SCL для _всех_ пакетов, сервис/часть дистрибутива и пакадж менеджера. Это показалось мне существенным отличием от "всех source-based д.", на что попенял выше.
--
(*) И обычно прокатывает, а изредка, когда не прокатывает, чинят. Ну, там страшные library transitions -- против пересборки всего в guix. Более того Denian в сборке своих пакетов какой-то хитрый скан фактичеси используемых API, для glibc точно.
Собирая, скажем wget в stratch-е (9.x) с glibc 2.24[-2] на бинарные пакеты ставят 'dep: libc6 (>= 2.17)'. В старичке wheeze (7.x) эта зависимость выглядит даже интереснее (присмотреться - это одна зависимость на архитектуру):
dep: libc0.1 (>= 2.11) [kfreebsd-amd64, kfreebsd-i386]
dep: libc6 (>= 2.11) [not armhf, ia64, kfreebsd-amd64, kfreebsd-i386, s390x]
dep: libc6 (>= 2.13) [s390x]
dep: libc6 (>= 2.13-28) [armhf]
dep: libc6.1 (>= 2.11) [ia64]
https://packages.debian.org/src:wget
https://packages.debian.org/wheezy/wget
https://packages.debian.org/src:glibc
> а ограничение по ядру для системы с одним ядром в любом
> случае "или стрельнуло, или нет" (да и консервативно оно довольно-таки).
