LINUX.ORG.RU

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

 , ,


0

2

Хочу сделать AppImage программы Sunbird, т.к. его нельзя установить на более новую версию (Devuan 3.1.1), на которой я сижу. Ищу разные программы для компеляции. Загружаю, а они не работают. (скачивал appimagetool, appimage.builder, pkg2appimage, pyuploadtool). Это всё было AppImage, т.е. должны на любой машине заводится (я сделал их исполняемыми, но они всё равно не заводились). Что делать? Если ли какие-то другие программы для компеляции? Возможно вообще сделать AppImage самостоятельно? Можно сделать это на старых версиях Debian?

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

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

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

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

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

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

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

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

anonymous
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sanyo1234
()

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

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

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

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

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

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

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

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

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

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

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

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

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

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от sanyo1234

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)

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

Речь о Mozilla Sunbird?

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

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

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

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

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

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 2)
Ответ на: комментарий от einhander

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

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

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

https://github.com/efrecon/exodus

с помощью Exodus.

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

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

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

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

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от sanyo1234

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sanyo1234
()

Он же щас является плагином в 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
Подробнее

damix9 ★★★
()