Продолжайте наблюдения.

Я за тар.* файл, в котором будет сама программа и список зависимостей.

Наиболее изящный формат пакетов это setup.exe. Два клика и всё.

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

три перезагрузки, три «вы уверены?», …

Какой же тарбол будет огромным?

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

а если кроме этого добавить еще и необходимость выполнять какие-либо pre/post-install скрипты, которые тоже в этом гипотетическом тарболе болтаются - тарбол деб-у в качестве формата пакетов громко сливает

Да начнется холивар.

После слаковских пакетов остальные выглядят как-то неочень.

патрик до сих пор симлинки скриптами создает?

У Патрика все нормально.

надо построить дерево зависимостей всего репозитория пакетов

What a coincidence, мне не надо. А если кому-то и надо, тогда, да прийдётся подождать.

Я не интересовался, как у него все? Я задал вопрос про симлинки, особенно к либам, которые, раньше по крайней мере, делались через doinst.sh

Ты сформулировал вопрос провокационно :)

а нахрена тебе тогда зависимости в тарболе вообще? держи все в зо^Wголове

ага, и вообще троль

но да, это был не вопрос, а промах

Какой глупый вопрос.

Очевидный flatpack. Никаких зависимостей с тарболами — ещё более гениально в своей простоте.

когда нет ни ответа, ни обоснования - да, приходится мандячить философский кисляк

чрезмерно жирно. я сейчас про флатпак, как таковой, а не про коммент

Лишь бы не прикладуха

Главное, чтобы прикладные приложения были самодостаточными(типа appimage), а не вот этим вот. И их можно было запустить через много лет без пердолинга с зависимостям как в винде(на самом деле нет), ибо секьюрность не всегда нужна, если с интернетом работать не надо. А мейнтейнеры занимались полезными вещами системного уровня, а не онанизмом с «пакетами» браузеров и плееров. Но, к сожалению, программистов мало, а мейнтейнеров и девопсов, профессионально занимающихся переусложнением простых вещей, становится все больше(flatpak и snap это их творчество).

deb – это рак. Я одно время мейнтейнил несколько пакетов для убанты. Нiколи знову!

Ответа и обоснования чего?

Вот в арче пакеты тар.зст (ЕМНИП, таки зст теперь), дистрибутив не развалился, пакман остался быстрым.

вибачай, друже, але ти попутав. рак - це убунта, а не деб

ты видел и измерял скорость рач на тарболах vs рач на дебах?

ну, идеала вообще не существует. к нему просто надо стремиться

Я про формат пакетов, который у них одинаковый. И геморрой был во многом из-за него и из-за инструментария для сборки этих пакетов. Так что рак – это таки деб.

У вас есть арч на дебах?

Рак — екосистема дебиана.

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

а у вас?

Нет, он более чем ненужен.

в таком случае прекращайте использовать относительное понятие «быстрота» без соответствующих сравнений

Вот я так и представляю: сидит игзперд на ЛОРе и сразу знает, где и почему у меня были проблемы с мейнтейнерством пакетов.

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

пакман остался быстрым

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

но я говорю о формате пакетов, а не о пакетных менеджерах. чувствуешь разницу? и чтобы утверждать, что «tчегототам» быстрее, надо таки сравнить с не «tчегототам» на том же самом пм-е. иначе - кому и кобыла невеста (мне и так быстро/нормально). это приемлемо, но не имеет отношения к сути поста

А разложить эти зависимости по фс - тоже сам? Или там всё от корня должно быть?

А разложить эти зависимости по фс - тоже сам

Пакетный менеджер скачает и установит зависимости.

Когда я нырял(в защитном костюме, конечно) в системы управления пакетами, то становилось понятным, что они производные от задач. Debian - метадистрибутив, подходящий для кучи задач, кроме десктопа, где он так себе(хотя я лет 7-8 использовал). А arch очень примитивно устроен, ванильный софт без патчей хорош для прикладухи, не для кастомных задач и многолетней поддержки стабильных версий ПО, поддержка архитектур слабая. Я бы на него и не взглянул, если бы не AUR. Проблемы дебиана совсем не в формате пакетов и ПМ, копирование с арча ничего не даст. Собственно, чувак по твоей ссылке, нырявший без костюма и глубоко, об этом тоже пишет

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

самая здравая мысль. вот только конченые пользователи зачастую не отличают apt от dpkg, rpm от yum или dnf и т.д. зато потрепаться охота. но топик, в принципе, для этого и создавался

Там нет xml, незачёт.

а за отстутсвие джейсона вообще стрелять

да

почтим уважением мудрых дедов, придумавших нам формат deb

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

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

Не знаю, чем тебя RPM не устраивает, это просто пожатое cpio.

Вот если бы у дебов ещё была вменяемая структура в репозитории… И описание сборки в одном файле…

А так, на мой взгляд, наиболее изящный формат пакетов - это Nix. Это просто космос. Пакета как такового нет, есть только инструкция для сборки из исходников на функциональном языке Nix. Потому с одной стороны NixOS - это source-based дистрибутив. Но в то же время, у них есть кеш готовых артефактов, из которого тянутся готовые сборки со стандартной конфигурацией из их гита. Но если ты переопределишь какой-либо из параметров пакета (например, с чем он будет собираться, с чем не будет) - он соберётся из исходников прямо у тебя на машине. Если переопределить самые базовые параметры, например - стандартные флаги компиляции, можно пересобрать мир.

Это самый лучший компромисс между source-based и binary дистрибутивами.

rpm не устраивает тем, что из rpm без самого rpm метаинформацию хрен вытянешь. Да и для доступа к содержимому приходится с dd изгаляться

Что-то ты пытаешься через одно место сделать. Вот если честно, ни разу не приходилось вытягивать метаинформацию из RPM. Особенно - в отсутствии RPM. ¯_(ツ)_/¯

Да ещё и раcковыривать без rpm2cpio.

guix

Какая-то перепись неосиливших guix.

На формат пакетов вообще наплевать, никто его руками не собирает и не разбирает. Пусть там хоть сжатый xz’м xml в котором в base64 закодировано содержимое файлов, а метаданные хранятся в json запихнутом в атрибут корневого элемента.

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

s/никто/мало кто/

так что плевать не всегда получается