Зачем нужны deb и rpm?

В Linux должен быть единый стандарт пакетов.

Уже есть, RPM называется. См. Linux Standards Base.

Уже есть, RPM называется. См. Linux Standards Base.

Насквозь заскриптованный формат в стандартах — это даже не смешно. Его туда банально протолкнули.

Формат со скриптами стандартным быть не может.

заскриптованный формат

Что такое «заскриптованный формат»? Разверни мысль, пожалуйста.

Там написано, что должа быть поддержка rpm, например как в debian — ч-з alien, для обеспечения совместимости. Формат пакетов не регламентируется.

Формат пакетов не регламентируется.

This specification does not require the implementation to use RPM as the package manager; it only specifies the format of the package file.

Я что-то не так понимаю? К тому же, ТС ничего не говорил про _формат_ пакетов.

Я что-то не так понимаю?

Да

Applications shall either ... or supply an installer which is LSB conforming (for example, calls LSB commands and utilities).

К тому же, ТС ничего не говорил

Но кого это останавливает?

Что такое «заскриптованный формат»? Разверни мысль, пожалуйста.

В rpm для всех собранных файлов явно пишется, куда их класть или как удалять, а если для какого-то файла не прописано — тот же OBS пакет не пропустит. Процесс перечисления файлов пытаются облегчить костылями вроде масок и макросов, вместо того чтобы просто выкинуть нафиг из spec файла это ненужно.

Также rpm сам вызывает систему сборки, параметризуя её какими-то захардкоженными ключиками. А вообще-то это кроссплатформенная система сборки должна вызывать rpm, чтобы создать пакет (будь то пакет с бинарниками, удобный проприетарщине или в личных сборках, либо srpm, для мейнстрима).

В итоге rpm, deb, pkgbuild и уж тем более ebuild представляют собой скрипты, которые к тому же гоняются на интерпретаторе, средой выполнения в котором является вся система (в лучшем случае в пределах chroot). Такое скриптонелепие совершенно не поддаётся автоматической обработке, автоматическому обновлению на новые версии rpm/dpkg/pacman и постепенному улучшению (даже для добавления переводов к описаниям пакетов каких только костылей не выдумывали, и везде они свои, а чужие не работают).

Поэтому заскриптованный формат стандартом быть не может — он уже при рождении становится легаси и улучшению не подлежит. Только декларативное описание свойств пакетов и минимум производной инфомации вроде списка действий для каждого файла.

В rpm для всех собранных файлов явно пишется, куда их класть или как удалять, а если для какого-то файла не прописано — тот же OBS пакет не пропустит.

А вдргу апстрим внезапно изменит make install и положит файлы туда, куда политика дистрибутива класть не разрешает? Без явного списка файлов никто не заметит

Также rpm сам вызывает систему сборки, параметризуя её какими-то захардкоженными ключиками

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

Во-вторых, а как тогда должны собирать src.rpm? Вариант «src.rpm не нужны» не катит, так как этот формат 1) гарантриует целостность исходников и позволяет распространять их вместе с набором патчей; 2) позволяет мне собрать незнакомую софтину из исходников, не заморачиваясь, как использовать ее систему сборки и как получить из нее rpm; 3) позволяет пересобирать целые репозитории в автоматическом режиме с нужными ключами компилятора

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

А вдруг апстрим внезапно изменит make install и положит файлы туда, куда политика дистрибутива класть не разрешает? Без явного списка файлов никто не заметит

Автоматика заметила бы.

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

Было бы чем гордиться, система сборки сама по себе параметризуется.

Во-вторых, а как тогда должны собирать src.rpm?

А как скрипты сборки в rpm помогают в этом, если сборка всё равно ведётся силами системы сборки?

А как скрипты сборки в rpm помогают в этом, если сборка всё равно ведётся силами системы сборки?

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

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

Ага, и перестанет работать yum provides */%{filename}

Также rpm сам вызывает систему сборки, параметризуя её какими-то захардкоженными ключиками. А вообще-то это кроссплатформенная система сборки должна вызывать rpm, чтобы создать пакет (будь то пакет с бинарниками, удобный проприетарщине или в личных сборках, либо srpm, для мейнстрима).

Ничего не понял. Собираю пакеты обычным rpmbuild'ом или mock'ом (в chroot'е). Сама утилита rpm при этом не используется. С другой стороны, при обработке пакетов или их базы yum'ом или rpm'ом rpmbuild вообще не требуется.

В итоге rpm, deb, pkgbuild и уж тем более ebuild представляют собой скрипты, которые к тому же гоняются на интерпретаторе, средой выполнения в котором является вся система (в лучшем случае в пределах chroot). Такое скриптонелепие совершенно не поддаётся автоматической обработке, автоматическому обновлению на новые версии rpm/dpkg/pacman и постепенному улучшению (даже для добавления переводов к описаниям пакетов каких только костылей не выдумывали, и везде они свои, а чужие не работают).

Просто нелепица какая-то.

Поэтому заскриптованный формат стандартом быть не может — он уже при рождении становится легаси и улучшению не подлежит. Только декларативное описание свойств пакетов и минимум производной инфомации вроде списка действий для каждого файла.

Мусье вообще имел дело с опакечиванием?

Мусье вообще имел дело с опакечиванием?

Мусье имел дело не только с опакечиванием, но и с пакетированием для андроида и айфона, где пакет собирается в один клик. И если в андроиде ещё есть отдельно стоящая метаинформация, то в айфонах нету.

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

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

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

Мусье имел дело не только с опакечиванием

Тогда зачем глупости пишете про утилиты сборки rpm'ок?

Во-первых все системы сборки ловят переменные окружения CXX, CXXFLAGS

Бугага. Могут не ловить, могут насильно переопределять своими, могут ловить, но что-то другое.

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

Система сборки у каждого пакета своя, неповторимая, и набор флагов у каждого пакета, естественно, разный. А у srpm интерфейс гарантирован: запускаешь rpmbuild -bb => получаешь пакет с рекомендованным мейнтейнером набором опций (и сборочных зависимостей заодно)

Бугага. Могут не ловить, могут насильно переопределять своими, могут ловить, но что-то другое.

А теперь посмотрите на пакеты и узрите, что они используют именно CXX и CXXFLAGS как средства кастомизации, но не всегда. Так что они просто наследуют описанные проблемы и добавляют свои.

Система сборки у каждого пакета своя, неповторимая, и набор флагов у каждого пакета, естественно, разный. А у srpm интерфейс гарантирован: запускаешь rpmbuild -bb => получаешь пакет с рекомендованным мейнтейнером набором опций (и сборочных зависимостей заодно)

Рекомендованный набор опций патчем реализуется. Или вы не сторонник KISS?

а как тогда предоставить --with-x --without-y для тех, кто хочет собрать srpm сам? Да и вообще, это гораздо костыльнее и ненадежнее, чем передать параметры/переменные

То есть всё что есть у сторонников скриптов сборки внутри пакетов — это мнение, что такой подход надёжнее.

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

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

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

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

а как тогда предоставить --with-x --without-y для тех, кто хочет собрать srpm сам? Да и вообще, это гораздо костыльнее и ненадежнее, чем передать параметры/переменные

Вторая фраза, очевидно, ничего не говорит о единообразии сборки. Да и я уже говорил: достаточно вызвать систему сборки с флагами, не зависящими от пакета (или вообще без флагов). Систем сборки лишь несколько, что там упорядочивать?