Какими «самодостаточными» форматами пакетов вы пользуетесь?

deb/rpm - пользуюсь.

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

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

Нет там никаких костылей. Используется PipeWire как мультимедиа-фреймворк, в который композитор «кладёт» кадры.

Костыль.

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

Я тоже пытаюсь объяснить людям, что вяленд - говно. Но некоторые люди увы слабоумные и всё равно зачем-то его продвигают.

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

Прикинь, не может, а так и происходит.

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

Но единой реализации Wayland-сервера мы так и не увидим, следовательно DE будут монолитными и несовместимыми. Все компоненты DE будут прибиты гвоздями к серверу этого же DE, а всё чего нет будет реализовываться через Pipewire/DBus костыли.

Из Flatpak стоят Steam и Bottles. Всё.

Дисклеймер: Wayland не использую.

Суть: Прежде чем пытаться доказать что что-то там является говном неплохо было бы разобраться в теме и изучить терминологию. Начните с:

Wayland-сервера

DE

костыль

Это не спецификация. Эта утилита даже не является основой для создания AppImage, это просто пример как ещё можно собирать.

Я повторюсь, они просто изобрели SFX (с пометкой на то что он просто монтируется через fuse). А безграмотные люди почему-то приравнивают его к Flatpak.

Три с половиной программы в Flatpack. Несколько штук самописными скриптами. Куча игр в Steam, парочка в portproton. Всё остальное из исходников, часть из собственного оверлея.

Посматриваю на Gentoo: читаю Gentoo Handbook, смотрю видео, планирую потренироваться с установкой в виртуалке.

Ну да - в генте с тееграмом проблем нет. Вот собрал себе 4.8.4 5 минут назад. Без всяких богомерзких флэтпаков.

Я повторюсь, они просто изобрели SFX

А это что-то плохое? (Более-менее стандартный вариант SFX для десктопных линуксов, заводящийся на любом мейнстримовом дистрибутиве и даже на многих НЕмейнстримовых.)

Потому, что опенсорс!

Но есть люди, для которых «собрал себе» — это шок и ужас. И их интересы тоже надо учитывать, если мы хотим, например, чтобы ни одна тварь не посмела выпустить видеокарту или МФУ без линукс-драйвера.

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

в генте с тееграмом проблем нет. Вот собрал себе

В Ubuntu на моей памяти софт тоже благополучно собирался. Репозитории огромные, есть практически любая библиотека. Напрягает, в общем-то, только линия партии.

Все это есть на флатхабе.

Короче поставил, и оказалось, не совсем

NOTE: This wrapper is not verified by, affiliated with, or supported by JetBrains s.r.o.

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

А в том, что your average Linux programmer Joe не знает как собирать кроссдистрибутивные пакеты. Или делает вид что знает, но на самом деле нет. Как автор AppImage например. (Да, я этого чувака не очень сильно люблю)

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

Более менее решает эту проблему Flatpak, кроме того когда устаревшее и забытое приложение зависит на Freedesktop SDK столетней давности, с соответствующим количеством дыр.

Ну да, не спецификация, рекомендация.

Но на основе AppImage можно сделать подобную Флатпаку систему, но без той долбанутости. Или не на AppImage. Тут важнее не формат, а соглашение о том, что собирать с программой, а что требовать от ОС.

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

deb/rpm

Опять получается опрос не о предпочтениях лоровцев, о том в каком формате собрали пакеты авторы софта.

Обычный архив вряд ли можно считать форматом пакетов. Перепаковывать его в deb/rpm непонятная затея, этот пакет не будет привязан к репозитарию и не будет автоматически обновляться. Проще распаковать, кинуть симлинк в $PATH. Ну а обновляться руками, раз в полгода-год вполне допустимо открыть релизную страницу в браузере, или если это возможно (как на гитхабе), написать скрипт, проверяющий наличие новой версии.

Дело в том, что DEB и RPM тоже могут быть самодостаточными, если в них уже вкомпилены все нужные зависимости.

Вообще если быть дотошным, то очень мало тулкитов так позволяют делать. Почти везде есть сишечка, а там и glibc, со всеми вытекающими.

Так распространяются некоторые проприетарные программы для Linux, например, Яндекс.Браузер

~/Downloads/data 
❯ ldd opt/yandex/browser-beta/yandex_browser | wc -l
33

~/Downloads/data took 2s 
❯ find . -iname "*.so" | wc -l
5

Flatpak, конечно. Изредка юзаю Аппимаге, если быстренько нужно новую версию посмотреть, а засорять систему нет желания. Снап прибит к магазину Убунты, вот пусть они и мучают своё поделие. Остальное - старческий кал, место которому в музее копрофилии.

Не пользуюсь флетпаками и не собираюсь. 99% процентов софта есть в репозитории, 0.9% из AUR, а для оставшихся 0.1% можно и самому PKGBUILD сделать и выложить на AUR.

МФУ без линукс-драйвера.

А сталкиваться приходилось? Вроде бы этим сильно грешит Canon, есть ещё кто?

Ну в моем случае deb, потом архив.
Есть что-то в appimage. И конечно приходится страдать, snap.
В canonical по каким-то неведомым соображениям canonical-livepatch запихали в snap.
Теперь на сервере есть snap :)

В отличие от snap, не создаёт в домашнем каталоге одноимённый каталог

Всё же, создаёт $HOME/.var

Всякое проприетарное ПО, к которому доверия нет от слова «совсем» (Anydesk, Skype, Discord…), изолировано от системы в песочнице, которую можно легко и просто огородить ещё сильнее (или, наоборот, разрешить ходить куда-нибудь) через Flatseal.

В другом виде есть и в Snap, огородить ещё сильнее можно через отключение интерфейсов.

Всё же, создаёт $HOME/.var

Он скрытый. Был бы ~/.snap, претензий бы не было.

А не скрытый ~/snap потому, что разработчики вместо сложного технического решения в виде порталов, как сделали в flatpak, решили просто складывать экземпляр домашнего каталога для конкретной программы в видимый каталог в хомяке: сохранил документ – ищи его в ~/snap/program. Т.е. предполагалось, что в этот каталог пользователь будет заходить, поэтому он и не скрытый.

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

В другом виде есть и в Snap, огородить ещё сильнее можно через отключение интерфейсов.

Я больше в сравнении с обычными пакетами и всякими AppImage это писал, но да, snap тоже изолирован.

Но есть ли в нём возможность рулить ограничениями из простого и удобного графического интерфейса? Скажем, я могу просто запустить Flatseal и дать доступ только на чтение к какому-то конкретному каталогу.

проиграет процент-два

Однако.

Я вижу. И радуюсь. Но боюсь,, десант ретхата активизируется и будет дальше насаждать. А аппимэдж никто не насаждает.

Было бы круто, если бы программы могли таскать с собой еще и libc, но меня бы устроило и если бы они ее требовали как зависимость. Пусть даже версии такой-то или новее. Пусть даже с оговоркой, что мейнтейнеры могут ее изгадить. Это ведь уже во много раз лучше, чем эти десятки зависимостей. Собираешь прогу:

У тебя libpango слишком старая
У тебя libcurl слишком новая
У тебя libmodplug слишком старая, а если обновишь, то отвалятся вот эти 4 проги
...

но меня бы устроило и если бы они ее требовали как зависимость

Так проблема как раз в том что бинарный софт привязывается к glibc той системы, где собирали и если она старее, то не загрузится

и если она старее, то не загрузится

У пользователя в системе старее, чем у того, кто собирал?

Да, обычно так и есть,спасибо пользователям с древнобианом

Я и говорю, я бы смирился с невозможностью запустить современную прогу на Ubuntu 10.04.

mittorn пишет:

А когда мне надо собрать какой-то архив, чтобы он работал везде я его и собираю на ubuntu 12.04

Намного хуже, когда приложение требует libcurl3 и с libcurl4 не работает.

там не проблема уровня ubuntu 10.04 в 2023 году, там проблема уровня свежий debian vs свежий арч

Так надо собирать на несвежем Дебиане, и на свежем чём угодно будет тоже работать. Или нет?

Либо собирать специальным тулчейном в котором уже более-менее поддерживаемая версия glibc. Но ни того ни того не делают, потом начинают делать флетпаки, которые увеличивают оверхед памяти. Мне недавно жаловался один знакомый, что ему 16гб памяти стимдека не хватает ни на что в десктопном режиме. Неудивительно.