В Арче нет никаких проблем.

ln -T «Arch Linux» «Не было печали - апдейтов накачали»

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

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

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

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

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

Потому что арч не нужен.

А зачем мне обосновывать? Я не ору, что нужно всех под одну гребенку.

Для того, чтобы отличать от сырцов и арчепакетов.

Потому что в tar.xz может лежать порно с твоей мамашей, а может и утилитка какая, да.

В Арче нет никаких проблем.

Ну да, конечно. Там тупой пакетный менеджер. Он не может просто взять и обновить систему, в процессе постоянно пристаёт к пользователю со странными вопросами. То ли дело apt, он сразу перед началом обновления всё анализирует и сразу предупреждает о возможных проблемах, которые пользователь может устранить перед началом обновления. А в процессе обновления встроенный искусственный интеллект разрешает сам все проблемы. Вы только посмотрите на это чудо!

dpkg: предупреждение: подпроцесс старый сценарий pre-removal возвратил код ошибки 2
dpkg: попытка использовать сценарий из нового пакета ...
dpkg: ... похоже всё обошлось.

Там тупой пакетный менеджер.

по всем картинкам «page not found»

по всем картинкам «page not found»

Да не важно что там было (из контекста там всё более менее понятно). Он постоянно задавал всякие вопросы. Отвечаю «да», падает с какой-то ошибкой. Повторяю, но на этот же вопрос отвечаю «нет», падает чуть позже с другой ошибкой. Суть в том что пакетный менеджер мог бы сам всё разруливать без участия пользователя, как это делает apt в дебиянах.

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

RPM точно не нужен, а DEB норм.

Почему не сделают везде bff как в аиксе?

fixed, можешь не благодарить

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

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

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

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

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

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

rpm - стандарт де-юре, deb - стандарт де-факто, а арчепакеты годятся только для арчепомойки.

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

И этот apt регулярно ломается из-за этого. Все форумы завалены сообщениями убунтоидов, о том, что перестали устанавливаться пакеты.

И этот apt регулярно ломается из-за этого.

Нет. С 2007г. у меня всё работает.

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

Новички. У меня в самом начале тоже были какие-то проблемы. Потом мне подсказали волшебный ключ --fix-broken (-f) и проблемы исчезли.

И этот apt регулярно ломается из-за этого.

В стабильной ветке? Нет такого и никогда не было.

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

Так это они загаживают систему всякими левыми кривыми ppa а потом жалуются.

почему не сделают setup.dmg или Appname.app?

Почему не сделают везде tar.xz как в Арче?

Чтобы арчеводы спрашивали.

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

Так это они загаживают систему всякими левыми кривыми ppa а потом жалуются.

Apt от этого не ломается, кстати. А что, собственно у апта может сломаться? Ну видел я пару случаев поломки базы dpkg, но обычно это происходило из-за ручного вмешательства, а не само.

почему не сделают setup.dmg или Appname.app?

В Убунте об этом уже подумывают.

это был вопрос с подвохом

Жаль картинки из того сообщения не загружаются...

ху из кира?

Вроде чучело с юзерпика ТС.

И этот apt регулярно ломается из-за этого. Все форумы завалены сообщениями убунтоидов, о том, что перестали устанавливаться пакеты.

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

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

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

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

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

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

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

https://www.youtube.com/watch?v=GSeEnBMqgYo

Только тебе туда опасно. Там онеме.

чтобы из за таких вопросов, начинался срач

RPM и DEB - так правильнее.

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

Зачем же рисковать :)

А как скрипты сборки в 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 сам? Да и вообще, это гораздо костыльнее и ненадежнее, чем передать параметры/переменные

давай в rar лучше, или в 7z

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

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

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

man DeathNote

Товарищ на аватарке heinrich2 весьма на него похож.

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

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

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

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

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

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

DEB на бумаге двойной тар, а на деле обычно двойной tar.gz, что уже намекает на его расовую порочность.

DEB на бумаге двойной тар

ar != tar

Что только не делают люди

лишь бы не юзать install.msi