Сохранить бинарник (приложение) в системе

Да.

В NixOS, просто установи и забудь про проблему в принципе, только бекапы нужны и всё.

чрут

Имел дело со snap — собрать обычно довольно просто. Flatpak тоже выглядит несложно, но никогда не собирал. Но у них обычно есть зависимость от базового рантайма. Если хочешь прямо self-contained без дураков, то можно собрать OCI-образ (Docker, podman).

вплоть до libc

А зачем? Она обратно совместима.

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

То есть я хотел узнать, есть «магическая» команда, что её указываешь пакет, а она всё что надо убирает в chroot или ещё куда. И, если такая команда есть, то как она отделит libc от всяких других библиотек, которые не совсем обратно совместимы.

И мне полная «изоляция» (блин, сейчас прибегут и будут писать про изоленту) не нужна, в смыле не нужно отдельное сетевое адресное пространство и т.д. И даже syslog и X11 сокеты оставить бы минимумом телодвижений.

вплоть до libc

А зачем? Она обратно совместима.

Не у гнутых, нет.

https://github.com/landley/toybox/issues/450

То есть я хотел узнать, есть «магическая» команда, что её указываешь пакет, а она всё что надо убирает в chroot или ещё куда.

Ну, технически, всё, что я перечислил, позволяет ничего не собирать, и просто упаковать существующие файлы. Snap может затянуть пакеты из Ubuntu. Инструменты сборки OCI вообще ничего не диктуют, пиши Dockerfile хоть под Gentoo с компиляцией всего при сборке. Есть что-то прям совсем готовое — не знаю.

https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt#Upgrade/compatibility_impact

Всё не так плохо.

есть «магическая» команда, что её указываешь пакет, а она всё что надо убирает в chroot или ещё куда

Звучит как контейнер.

emerge -bk ...

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

Может действительно будущее за Immutable-дистрибутивы, что это такое, и с чем это едят?? Когда есть «неизменяемая база + куча приложений, посредством flatpak (или других контейнеров)».

Тут и Dependency hell остается за бортом, и версию приложения можно ставить любую, не сломав систему. Про неубиваемость даже можно и не упоминать, а уж вопросы «обновил систему, все сломалось и что теперь делать», можно будет забыть. )

Самые известные дистры с подобной фичей - Fedora Silverblue (Gnome), Fedora Kinoite (KDE), Fedora Sericea (Sway).
Назову и NixOS, а то житья не дадут на ЛОРе. :)

AppImage

Не надо chroot и тем более фтатпаки и подобное, лучше создай /usr/local/имя_проги/{bin|lib} и сложи туда всё что ей нужно для работы отличающееся от основной системы, и запускай с LD_LIBRARY_PATH.

libc бекапить незачем.

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

Будь мужиком - стань мейнтейнером этого осиротелого софта. Тебе же надо? )) Ты выбрал генту, знал, куда шел 🤡

Не хочешь возиться с апстримом - оверлей заведи или как там это сейчас называется)

всеми зависимостями, вплоть до libc?

Это плохая идея. Лучше положи те зввисимости, ктторые действительно мешают обновляться рядом с бинарником и указывай путь туда через LD_LIBRARY_PATH

Бинарные пакеты то у меня есть, и комп их собирающий и компы их себе устанавливающие. Меня интересуют готовые скрипты, чтобы все пакеты с зависимостями подтянули, развернули, упаковали во что-то, не знаю, tar или flatpack, скрипт обёртку, выставляющий LD_LIBRARY_PATH сгенерили, если надо...

Контейнер имеет кучу значений, но, вроде, контейнер — это результат работы этой программы, складывающий вместе всё что нужно. То есть чем из ebuild-пакета сделать контейнер?

docker, buildah.

Почему libc — плохая идея?

ктторые действительно мешают обновляться

Но это ручная работа. И ладно, libc, но часто ещё куча библиотек, не совместимых от версии, к версии. ЕМНИП, ffmpeg имел какую-то баго-фичу, но при переходе хромиум 89->90 он крошился при запуске, если не та версия ffmpeg.

Поэтому, как сложить всё по зависимостям, я ещё представляю, но как только минимальный набор, действительно нужных библиотек — нет. И потом, там же ещё симлинки должны быть на библиотки, их же ldconfig создаёт. Ещё это вручную делать...

вплоть до libc

А зачем? Она обратно совместима.

В Linux? Ха-ха!

Бекапь исходники, на каждый билд свой чрут дабы наверняка и делай сборки AppImage всё (в разумных пределах) своё ношу с собой. Это единственный вариант бесконфликтного сохраненния бинарника по моему с единственной зависимостью для работы себя от ядра в виде поддержки fuse. Конечно можно использовать чруты и подобное, но там нужно следить на пробросом устройств и прочего.

Но и с AppImage могут быть свои приколы. Не всегда всё тривиально. Но уж точно проще чем всякие инфраструктуры flatpack/snap и подобного. Последние больше про изоляцию чем про просто прозрачный запуск.

А так, боль. Да. Компилять и самому паковать, сам себе майнтейнер. Патчить часто просто нереально под новое, слишком много работы для простого пользователя, пусть и продвинутого. :(

И как, допустим, /bin/grep упаковать в docker? Чтобы из скриптов спокойно дёргать сколько угодно экземлпяров, чтобы каждый, вызывая isatty() определял, нужно ли раскрашивать вывод, и каждого могла быть своя переменная среды GREP_COLORS.

И как, допустим, /bin/grep упаковать в docker?

Найти базовый образ без grep, написать Dockerfile, который соберёт образ с grep (ну, как он там у вас в Gentoo ставится).

isatty()

not a tty :)

и каждого могла быть своя переменная среды GREP_COLORS

https://ibb.co/njFYD0X

В Linux?

Да.

делай сборки AppImage

Делать сборки чем? И зачем исходники, тогда по логике и ebuild-файлы нужны, чтобы команда ″ebuild configure″ этот исходник по USE-флагам сконфигурила?

Делать сборки чем?

Да хоть шелл-скриптом с cp(1) откуда угодно. Мне кажется, от тебя ускользает, что вообще все перечисленные форматы открыты, и собирать артефакты в них можно любыми, даже самыми дикими, способами.

Делать сборки чем?

• https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages/cc2441518975caca23e9ce2dba6f08a22c678d1e

И зачем исходники

Из репозитория то ты сказал выкидывают софт, собирать то из чего то надо. Ну или делать сборку на той версии ОС где софт ещё есть из готовых бинарей и библиотек.

тогда по логике и ebuild-файлы нужны

Ну тут бать, тебе либо собрать софт что-бы он работал там где он более не работает. Чтобы ПО собрать никакие ebuild не нужны, нужна система сборки поставляетмая с исходниками, зависимости и руки. Всё. Если хочется именно что сделать всё родными средствами включая

чтобы команда ″ebuild configure″ этот исходник по USE-флагам сконфигурила?

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

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

Можешь как в слакваре make && make install указав TARGET_PATH или какие там будут флаги на $(/HOME/.local/)``bin/share/etc и установить софт локально.

Опять же смотря что за софт. Вариантов много, весь вопрос в том насколько будет сложно его хоть как-то собрать. И насколько ты хочешь озабобится интерграцией в систему, локально закинуть в ~/.local, в систему опакетить, или портативную сборку сделать AppImage. Нужно ли патчить сам софт, нужно ли патчить зависимости, как разраливать конфликты и прочее.

Пердолинг в той или иной степени обеспечен. А как быть? У меня десяток софтин просто собраны в chroot и установлены в ~/local/bin Этого софта нет в debian. Как и некотрых зависимостей.

Достаёшь исходники, достаёшь зависимости, а дальше всё в твоих руках, пиши ебилд или просто собирай, опакечивай или через LD_LIBRARY_PATH запускай из своего каталога.

Всё очень сложна :(

Я тему начал про «меньше телодвижений», ″cp″ как-то не очень.

Я хотел прояснить, не ускользает ли от меня готовая тулза, исходно ведь есть работающая система ebuild'ов, зависимостей, Portage Python API... И тут городить bash-скрипт, парсящий вывод equery/qdepend?

Я тему начал про «меньше телодвижений»

Я выше назвал два инструмента, которые позволяют задействовать «работающую систему ebuild’ов, зависимостей, Portage Python API» с минимальными телодвижениями: docker, buildah. Что ещё такого есть, я не знаю. Не нужен сложный запуск OCI-образа как в docker/podman с namespaces и прочим барахлом — найди/напиши запускалку попроще.

У меня ситуация примерно такая. Я изредка делаю ″emerge --sync″, потом устанавливаю новый portage и делаю ″equery l @unavailable″. И становится понятен масштаб бедствия. Часть ebuild'ов из оверлев становятся нерабочими (типа eapi=5 не поддерживаем), часть софта уже нет в основном репозитарии.

Но у меня в этот момент в системе есть всё и рабочее, и зависимости такого софта, в принципе, известны, я же его через emerge ставил. Вот и был вопрос, как минимуом телодвижений программу blabla (бинарники доки и ВСЕ нужные либы) переместить в chroot или отдельный каталог или есть что лучше. Чтобы не выснилось, что после обновления, какую-то либу забыл скопировать

Да ещё в идеале это как-то бы оформить псевдо-ebuild'ом, по которому ничего не собирается, а просто обозначается в какой каталог софт переместился и config-файлы из /etc/.

Если нет ничего готового, значит нет, значит пердолинг...

Это можно сделать примерно так:

0. Выбираешь пакеты, которые ты считаешь достаточно стабильными в плане обратной совместимости - например, ядро, glibc и т.п.
1. Пакуешь их в бинарные пакеты и разворачиваешь в каком-нибудь подходящем каталоге, например, в /mnt/pkgcore
2. Чрутишься в /mnt/pkgcore и собираешь там нужную тебе программу со всеми зависимостями вплоть до ядра, glibc и т.п.
3. Удаляешь в чруте пакеты ядра, glibc и т.п.
4. Выходишь из чрута. В каталоге /mnt/pkgcore у тебя будет срез FHS, который можно потом запаковать в архив-бандл.
5. Создаёшь скрипт запуска программы, который добавит все нужные PATH среза FHS перед системными PATH.

Запускаешь скрипт - он экспортирует PATH, ведущие в срез FHS, и запускает программу. Благодаря этому программа подгрузит все зависимости из среза FHS, а базовые компоненты (ядро, glibc и т.п.), которых в срезе нет - подтянет из системы.

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

Ну, наверное можно попробовать так, раз ПО сейчас в системе есть и работает.

• Через ldd /path/application узнать какие библиотеки нужны

Скопировать их все в каталог свой

• Сделать pidof appneme получив PID пойти в /proc/PID/maps

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

По сути итеративно создать чрут куда понапихать всё что трогает и ото чего зависит ПО. Затем написать скрипт где указать все LD_LIBRARY_PATH и прочие LD_PRLOAD и так далее rpath который будет запускать это ПО из каталога со всем фаршем. Заархивировать

Затем в виртуалке с такой же системой что у тебя, но без этого софта разархивировать и попробовать запустить. С веростностью в 99% что-то не будет хватать, дополнить и так до победного пока не получишь что-то вроде портативной сборки как у firefox

Если из руками созданного архива всё будет собираться и работать на другой системе, то можно обернуть всё в AppImage и получить просто 1 файл который можно просто запускать, а внутри него весь фарш в виде по сути корня системы который прозрачно будет монтироваться в твоей.

Но, всё равно придётся помучится. Как не крути, вот просто взять некую утилиту и сказать её, «вот название программы, а вот каталог, засунь в него всё что нужно вот этой программе» такое вероятно есть, так как по идее всё можно сделать полностью автоматически, но я вот про такое не знаю. Я знаю как это сделать автоматически (ну или на 99% автоматически). Но я такого не делал. Так как есть нюансы например если программа с библиотекой не слинкована, а загружает её сама через dlopen то это узнать можно или через трассировку программы или ещё как, но это уже проблема, и таких мелочей много, а про некоторые я вот даже не в курсе 100%.

Это я к тому что придётся в любом случае поработать ручками, так как даже зависимости все по библиотекам через ldd не узнать. С некоторым софтом, ну не знаю например с cfiles будет всё ну очень просто и приятно, полностью всё автоматически (ну автоматизацию написать надо конечно) и красиво. А вот с чем то другим, комплексным, зависящим от скриптов и конфигов которые вызываются хрен пойми когда и где то в коде вшиты, зависят не только от библиотек, но и от утилит ещё обычных например дёргают питон скрипт, который дёргает /usr/bin/curl всё уже не так однозначно.

Сложно №2 :( Могу только посочувствовать и пожелать удачи и упорства.

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

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

Тут и Dependency hell остается за бортом

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

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

Разработчики дистрибутивов и сейчас не способны составлять сложные системы. Так что все идёт закономерным путём, есть некая отлаженная база, а приложения для продуктивности отданы на откуп кому-то ещё (может быть даже самим разработчикам приложений).

Почему libc — плохая идея?

Потому что при попытке загрузить шаредлибы с хостовой версии будут проблемы. Да даже банально glvnd загружающий драйвер, требующий libc новее.. Обратный случай вполне работает - свежий glibc хорошо держит софт как минимум за последние 20 лет, если не больше.

Но это ручная работа. И ладно, libc, но часто ещё куча библиотек, не совместимых от версии, к версии.

Это никогда не было проблемой. ldd, /proc/<pid>/maps...
valve в своём steam runtime и pressure-vessel даже сделали этот процесс автоматическим - он для каждой библиотеки, которая совместима и в системе новее подсовывает системную версию, тем самым избегая проблем при использовании хостовых библиотек, mesa.

Для какого-нибудь серверного софта, где зависимостей немного часть используют докеры, но в результате получаем контейнер с древними уязвимыми библиотеками, предсказуемыми адресами и каким-нибудь потенциальным buffer overflow, через который вскроре кто-нибудь внутри контейнера какой-нибудь майнер разместит.

Я конечно понимаю, что есть реально проблемные случаи, но в целом можно полагаться на некоторый базовый набор библиотек, вроде libc, zlib, x11, xcb, при этом openssl старый, если он нужен, тащить с собой т.к там abi поломали. Остальное уже брать от приложения. При этом будет и mesa нормально работать

если развернуть пакет виртуалок приложение_на_систему.

Это как? Как эти приложения будут взаимодействовать между собой?

Мне тут про докер написали, что там istty() всегда false, то есть чтобы приложение дало цветной вывод, нужно в обёртке, его заменяющией не только писать <inline>docker run --interactive --rm</inline> но и добавлять опцию приложению, чтобы оно давало цветной вывод всегда. А потом ещё что-нибудь вылезет, допустим, если запускать как coprocess в bash.

Я знаю только статическую линковку, которая на самом деле не совсем статическая в области gethostbyname(), и которая включается не у каждого ebuild'а.

Скопируй ебилд в свой оверлей и не парься. Это самый простой способ.

Простой нерабочий способ. Это надо становится мантейнером ebuild'а, разбираться в eapi, разбираться в какой версии библиотеки поломали совместимость, засовывать старые (нужные этому пакету) версии библиотеки в отдельный слот или как там...

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

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

А никак! Ну, т.е. придётся таскать файлики через самбу и работать через них.

Зато само приложение будет очень надёжным и переосимым.

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

Для какого-нибудь серверного софта, где зависимостей немного часть используют докеры, но в результате получаем контейнер с древними уязвимыми библиотеками, предсказуемыми адресами и каким-нибудь потенциальным buffer overflow, через который вскроре кто-нибудь внутри контейнера какой-нибудь майнер разместит.

Кто-нибудь это кто? Явно автор не на публичном сервере генту держит. Риск чего-то подобного на домашнем компьютере ничтожен. Если кто угодно имеет доступ к нему, то у вас проблемы другого порядка, нежели устаревшие библиотеки в контейнере.

Вот ещё: https://blog.hiler.eu/win32-the-only-stable-abi/.

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

Суть в том, что в glibc поломали ABI. В спецификации ELF формата чётко чёрным по белому написано что DT_HASH обязателен.

Figure 2-7. Dynamic Array Tags
DT_HASH 4 d_ptr mandatory mandatory