Как сделать AppImage на Debian?

А почему именно AppImage? Чем не устраивает Docker?

Не знаком с тим, сейчас посмотрю что это

Чем не устраивает Docker?

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

Если лень велосипедить самому, то есть готовый distrobox на базе движка докера. Пакет легко ставится из sid на любой релиз Debian/Devuan, потому что зависимостей от новья в нём почти нет:

https://packages.debian.org/sid/distrobox

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

Можно сделать это на старых версиях Debian?

Скорее не можно, а нужно. Собирай AppImage в том окружении где работает нужная тебе программа, а не в том окружении где она неработает. И всё

Хорошо, а как его тогда сделать? Я уже страдаю этим делом 2 недели и ничего не нашел. Скачал кучу не нужной ерунды. Есть какой-то рускоязычный мануал по этому делу?

Тем чтобы не превращать систему в помойку на ровном месте.

Контейнеры это помойка? По сравнению с чем? Даже AppImage захламляет систему менее предсказуемо и управляемо.

Ты ещё предложи ему отдельную виртуалку развернуть или LXC поднять для одного приложения.

Так Docker как раз предназначен для одиночных приложений, и собрать что-то для докера намного проще, чем для других контейнеров, потому что как минимум есть очень подробная дока в отличие от AppImage. Сравни популярность Docker и популярность AppImage. Мало того, AppImage привязан к версии libc системы, на которой запускаешь его, а Docker и chroot не привязаны - огромный профит для любителей ретро приложений.

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

Доктора нынче встречаются и такие, что легко могут похоронить относительно здорового человека. :(

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

Хороший совет, а есть готовые примеры подобной сборки AppImage с доками?

Можно и без, просто сконвертировав deb пакет и всё

https://docs.appimage.org/packaging-guide/converting-binary-packages/pkg2appimage.html

Хочу сделать AppImage программы Sunbird, т.к. его нельзя установить на более новую версию (Devuan 3.1.1), на которой я сижу

Devuan 3.1.1 сам уже устарел давно. А почему нельзя установить то? Может всё проще и установить таки можно?

докер - помойка, смирись

Почему? Обоснуй, или как обычно, твоя пустая болтовня?

Можно и без, просто сконвертировав deb пакет и всё

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

т.ч. вероятно графическим

Mesa можно таскать с собой и без appimage и docker, так и с ними. А нерабочим драйверам на хвостовой системе докер не поможет, как и appimage.

Все таки докер для гуйни это оверкилл.

Все таки докер для гуйни это оверкилл.

Почему? Ведь X смотрелка может быть за пределами контейнера, даже в другой оси на другом хосте, например, OpenBSD Xenocara.

Однажды (ещё 3 года назад) даже запускал 3D игрушку в Docker контейнере, работает прекрасно, вывод шёл через unix сокет X11 (через –volume) на внешний хост с поддержкой аппаратного ускорения.

Если лень велосипедить самому, то есть готовый distrobox на базе движка докера. Пакет легко ставится из sid на любой релиз Debian/Devuan, потому что зависимостей от новья в нём почти нет:

Кстати IMHO было бы очень полезно любителям Астры, потому что там древность, а distrobox позолит им запускать почти любое новьё в Docker контейнерах.

Mesa

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

Ведь X смотрелка может быть за пределами контейнера, даже в другой оси на другом хосте, например, OpenBSD Xenocara.

А 3д как? Я конечно знаю как opengl кинуть на другой хост, но vulkan уже нет.

вывод шёл через unix сокет X11

Тут модный вяленый на пороге, а ты про старье которое просто работает.

И последнее, нет кнопки «сделать удобно» без развлечения с консолью.

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

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

у нвидии её библиотеки заменяются на кастомные

Еще один пункт против использования невидии.

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

«Нужны, надо» для кого? Для внедрятелей закладок в эти либы? Как интересно, LOL

И какая тут связь с захламлением? Наоборот, на хосте, где работает докер, может вообще не быть графических либ и даже X сервера, потому что X находится вообще на другом хосте, прикольно да?

и надо использовать их а не притащеные с собой.

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

appimage это архив. Как он должен помочь с запуском/незапуском программы на том или ином дистре?

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

программы Sunbird, т.к. его нельзя установить на более новую версию (Devuan 3.1.1)

Речь о Mozilla Sunbird?

В настоящее время разработка Mozilla Sunbird свёрнута, последняя общедоступная версия — 1.0 beta 1. (2010)

Пишут, что тот же функционал у дополнения Lightning к почтовой программе Thunderbird.

Это если раззработчик их туда положил, но разработчика об этом конечно же не оповестили

Appimage, это, по задумке, самодостаточное приложение, которое должно содержать в себе все необходимое (либы, и что там еще), для запуска на любом дистре.

Но это в теории. На практике же, запуск *.Appimage чаще на что-то ругается. )

в себе все необходимое (либы

https://github.com/AppImageCommunity/pkg2appimage/blob/master/excludelist

Но это в теории. На практике же, запуск *.Appimage чаще на что-то ругается. )

Вот именно.

не работает, потому что нужно установить fuze, без него Appimage не работает

Все таки докер для гуйни это оверкилл.

Кстати по поводу минимизации образов докера:

https://github.com/intoli/exodus/issues/21

https://github.com/efrecon/exodus

с помощью Exodus.

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

IMHO идеальный вариант для сборки примерно такой:

• Для Linux приложений: сначала минимизируем Exodus-ом, потом кладём в образ Docker (для запуска на любых дистрибутивах) или в AppImage (для запуска на похожих дистрибутивах по крайне мере по году выпуска - версии libc).

• Для Windows приложений: сначала оборачиваем Энигмой - по сути более навороченный аналог AppImage, потом добавляем Wine и кладём в образ Docker.

Докер нужно демона держать (podman удобней конечно, но у него несовместимостей много), для серверного софта еще ок, но для десктопа, где нужно просто кликнуть, и оно запустилось, это перебор.

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

Для легких CLI утилиток возможно (и то не факт с учётом преимуществ предсказуемой вездеходности контейнеров), а для тяжёлых приложений тем более, потому что докер на их фоне как песчинка. :)

И да, непринципиально Docker, Podman или ещё что-то, я в целом про идеологию OCI контейнеров.

AppImage

должны на любой машине заводится

Вас обманули. Никому они ничего не должны. AppImage ничего вообще не гарантирует.

самодостаточное

Вас тоже обманули. Он фундаментально ничем от SFX архива не отличается.

Запустится ли программа которая находится внутри архива – одна Селестия знает.

Идеология докера == «мы клали на безопасность нашего кривого приложения»

Если советуют приложение ставить через докер, значит что-то там нечисто.

Раньше советовали самодостаточные приложения собирать с помощью gcc -static, а сейчас со слезами как в аниме и щенячьей радостью как перед сёгуном советуют криводокер.

самодостаточное

Вас тоже обманули.

Во всяком случае, они задумывались «самодостаточными». Аннотация, перед основным текстом на appimage.org:

Приложения Linux, которые работают где угодно

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

В том-то и дело, что appimage.org говорит просто неправду.

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

Идеология докера == «мы клали на безопасность нашего кривого приложения»

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

Если советуют приложение ставить через докер, значит что-то там нечисто.

Приложение без докера будет безопаснее аналогичного такого же в докере?

Но это в теории. На практике же, запуск *.Appimage чаще на что-то ругается. )

Поэтому для надёжности даже AppImage можно предоставить как отдельно, так и засунутый в докер с доп. зависимостями, чтобы уж точно запустился :)

Приложение без докера скорее всего юзер запустит от своей учётной записи, а докер с большой вероятностью может дать ему бекдор к руту, если только юзер перед запуском очень внимательно не изучит конфиг контейнера (если он вообще разбирается в этой лапше). И даже если изучит - дыра может оказаться в самом помойко-докере а не в конфиге контейнера для него.

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

если только юзер перед запуском очень внимательно не изучит конфиг контейнера (если он вообще разбирается в этой лапше).

Разработчик сам не может предусмотреть готовый конфиг?

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

Кроме докера других движков для OCI контейнеров не бывает?

Разработчик сам не может предусмотреть готовый конфиг?

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

Кроме докера других движков для OCI контейнеров не бывает?

Вот с другими может и норм будет. А докер - помойка.

Вот с другими может и норм будет. А докер - помойка.

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

И да, непринципиально Docker, Podman или ещё что-то, я в целом про идеологию OCI контейнеров.

Под помойкой обычно понимается бардак? Он есть в докере?

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

Почему не может? А «god mode» проца?

(хотя конечно лазить по файлам юзера она сможет тоже).

Даже в случае ограничений через LSM + Firejail?

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

А наслушавшись сказок про изоляцию виртуалками и отдельными даже якобы «air gap» хостами? Как ты проверишь, что твой «air gap» действительно gap и нет дополнительных каналов?

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

Хватит прыгать с темы на тему и нести бред.

Бред ты несёшь, что обычный процесс уж точно не сможет повысить свои привилегии.

Речь была про сравнение запуска полученного откуда-то из инета собранного докер-контейнера

Ты топик стартера читал вообще? Он сам собрался собирать свою сборку, а не откуда-то из инита.

с запуском такой же просто проги на компе где докера вообще нет.

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

Второе - в целом безопаснее в плане незаметного получения этой штукой рут прав на компе.

В случае конкретно докера определённой версии возможно, но зачем ты зациклился именно на нём? Топик стартер про безопасность вообще спрашивал что-нибудь или ему пока важно просто сделать максимально совместимым с пользовательскими рабочими местами?

Он же щас является плагином в thunderbird. Или надо именно ту архивную версию погонять?

Собрать его так же, как и на всём остальном.

Программа нужна LinuxDeploy.

Надо поднять в chroot самую старую систему, которую этот AppImage будет поддерживать.

Под рутом

mkdir Sunbird-build
debootstrap --arch=amd64 oldstable Sunbird-build
cp linuxdeploy.AppImage Sunbird-build/root
systemd-nspawn --bind=/dev/fuse -D Sunbird-build
/root/linuxdeploy.AppImage --help

Дальше надо поставить программу, как это можно было делать в старом дистре. Затем что-то типа

mkdir /AppDir
mkdir /AppDir/bin
cp -a /bin/sunbird /AppDir/bin
/root/linuxdeploy.AppImage --appdir /AppDir -d path/to/file.desktop -i path/to/icon.png
# положить еще что нужно программе, но что не положилось автоматически
/root/linuxdeploy.AppImage --appdir /AppDir --output appimage