Какие зависимости можно не включать в самодостаточный пакет?

Те, которые не нужны

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

включая libc и иксовые библиотеки

Всё так плохо?

Ну ты же замахнуться на 10 лет хочешь.

Разве в glibc могут что-то поломать за это время? Да и иксы тоже никто не переписывает.

Почему бы прсто не собрать статический бинарник?

Оглянись на десять лет назад, если бы тогда собирал AppImage, ты бы, наверняка, компилял всё под x86, а сегодня это работало бы примерно нигде (в убунте точно. либу перемещали). Нельзя загадывать так далеко и надеяться, что ничего не изменится. Тем более, если ты расчитываешь на множество дистрибутивов.

Тут кто-то активно собирает ( mandala?) портативные версии софтин, но не помню кто, его бы спросить. На гитхабе в вики рекомендации довольно поверхностные и по ним складывается ощущение, что никто и не предполагает срок годности AppImage более лет трёх.

включая libc и иксовые библиотеки

Всё так плохо?

Я тут с питоном пакую. А им видите ли...

Предлагаю поискать что-то стоящее здесь, пораспаковывать, посмотреть что включено. Я бы сам сделал и отписал, но сейчас не у компа и не скоро буду.

Пакет Appimage не самодостаточен в принципе - он выполняется в том окружении, которое есть на хосте. За самодостаточностью к flatpak или snap.

чтобы приложение работало, допустим, 10 лет?

Оглянись:

Qt3 -> Qt4 -> Qt5
Gtk2 -> Gtk3
X11 -> Wayland

И? Статикой вкорячить и всё.

Для 10 лет нужны все зависимости. Только ядерный ABI остается обратно совместимым.

Теоретически, можно и просто flatpak бандл собрать, но с учетом того, что скорее всего придется использовать deprecated рантайм в будущем.

Другой вариант, собрать контейнер на ubuntu 18.04, у нее 10 лет поддержки как раз.

С линем это невозможно. Только сорцы.

Собирай один статический бинарник вообще без зависимостей. Никаких динамических загрузок, линкуй сразу всё.

Разве в glibc могут что-то поломать за это время?

memcpy может в другую сторону начать копировать. Снова.

То, что AppImage выполняется в окружении хоста ещё не значит что он это что-то обязательное и правильное. AppImage сделан так, чтобы он просто работал в типовых окружениях, которым вполне может любой дистрибутив выступать. В контейнере, например. Для сравнения, AppImage + LTS дистр в качестве рантайма даст больше самодостаточности, чем flatpak бандл + специфический рантайм флатпака.

Разве в glibc могут что-то поломать за это время?

Нет. Просто заменят libc6 на libc7 и т.д.

даст больше самодостаточности, чем flatpak бандл + специфический рантайм флатпака

Это как понимать? flatpak бандл + рантайм запускаются в своём пространстве имён, и от хоста используют только ядро. Чтобы добиться того же с AppImage, придётся туда запихать целый дистрибутив, начиная c libc и xorg.

С другой стороны, 8086, праздновавший 40-летний юбилей в прошлом году, до сих пор совместим с современными процессорами.

Целые дистры уже есть в виде OCI рантаймов для того же докера. Так что ничего никуда пихать не нужно, просто пишется простенький Dockerfile, который будет собирать контейнтер с AppImage на базе желаемого дистра.

Какое отношение это имеет к самодостаточности полученной сборки? Или запускать её тоже предлагаешь в контейнере?

Такое, что AppImage более самодостаточен и переносим, чем flatpak бандлы. Тут только разница в том, что flatpak изкоробки умеет докачивать необходимый рантайм и запускать с ним, а тут потребуется в ручную. Но никто не запретит тем же bubblewrap'ом запускать.

Для appimage «рантаймом» является ОС хоста. То, что какие-то библиотеки можно запихнуть в бандл, этого не меняет - они всё равно зависят от библиотек хоста.

Один я тут тупо не догоняю, как ты собрался через 10 лет запускать иксовое приложение, когда не будет иксов?

Для АppImage рантаймом является то окружение, в котором он запускаетя. Это может быть ОС хоста, или независимый от хоста рантайм в отдельном неймспейсе. Это вообще фича линукса - запустить бинарь в с желаемым рантаймом, независимо от того, что там в /. Это не какая-то уникальная фича флатпака, флатпак только дает удобную обертку, не более.

XWayland кто запретит использовать?

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

Кстати, ладно бы бинарники либ за это время менялись. Так ведь и конфиги в $HOME за это время перехреначивали. Так что гипотетический статический бинарник с гуём сделанный 10 лет назад сейчас в лучшем случае бы выглядел как-то сильно дефолтно, а в худшем - ломал бы конфиги при первом удобном случае (?)

А как подход AppImage/flatpack/snap решает вопрос совместимости GUI-TK`шных конфигов в $HOME?

вопрос совместимости GUI-TK`шных конфигов

Не в курсах. Автора темы спроси.

Один я тут тупо

->zvezdochiot (07.01.2019 18:38:12)

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

То есть ты на полном серьёзе сравниваешь встроенную в дизайн функциональность

Да, я сравниваю. Флатпак сильно сырой, в нем постоянно что-то меняется, так что рано даже говорить о какой-то «встроенной в дизайн функциональности». Тем более оно ломает привычную для приложения иерархию ФС, и требует пересборки или даже переработки приложений под флатпаковские костыли. Зайди на flathub и удивись. Там половина софта, если не больше, это пересборка бинарных DEB и AppImage. Так что да, сейчас оно больше используется не как самостоятельный инструмент, а как прослойка для запуска тех же AppImage.

и как помогут иксовые либы запуску проги в гуи с другой версией иксов?

Flatpak, к примеру держит конфиги отдельно, так что без разницы, что там поменялось.

Нужную версию иксов в виде Xwayland можно запустить в отдельном неймспейсе, так что наружу будет торчать всё только как Wayland клиент.

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

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

...но гарантированно корректно будет работать только на тех, под которое собран. В этом и суть «самодостаточности», которой appimage не обладает.

Зайди на flathub

Трусь там уже почти год.

Там половина софта, если не больше, это пересборка бинарных DEB и AppImage

Перепаковываются DEB проприетарных приложений, которые в другом формате не поставляются. Все свободные собираются из исходников, за исключением особо жирных и проблемных программ на electron'е.

оно больше используется ... как прослойка для запуска тех же AppImage

Это такая чушь, даже возражать не буду.

за исключением особо жирных и проблемных программ на electron'е.

Со сборкой AppImage у приложений на электроне проблем нет.

т.е. там пользовательские темы не поддерживаются?

Это особенность конкретно flathub'а, а не flatpak'а вообще. NPM приколочен к сети, а на flathub'е сеть при сборке запрещена во благо воспроизводимости.

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