После года разработки состоялся релиз пакетного менеджера RPM 4.18.0. Проект RPM4 развивается компанией Red Hat и используется в таких дистрибутивах, как RHEL (включая производные проекты CentOS, Scientific Linux, AsiaLinux, Red Flag Linux, Oracle Linux), Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS, Tizen и многих других. Ранее независимой командой разработчиков развивался проект RPM5, который непосредственно не связан с RPM4 и в настоящее время заброшен (не обновлялся с 2010 года). Код проекта распространяется под лицензиями GPLv2 и LGPLv2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57809
> Добавлен новый OpenPGP-бэкенд для работы с подписями пакетов, основанный на проекте Sequoia (реализация OpenPGP на языке Rust)И этот поржавел. Праведному сяшечнику скоро компьютер нельзя будет включить, чтобы не зашквариться. /s
Да и незачем будет его включать - все равно собрать трэшовую утилитку на нем не получится, нужно арендовать в амазоне пару сотен инстансов чтобы кое-как собрались все зависимости зависимостей.
Но пока, к счастью, это ненужное-ненужно всего лишь дополнительный бэкэнд который придется еще и отдельно подключать, если так уж хочется собрать rpm с его поддержкой. А иначе опять немодный сишный gpg будет.
К сожалению с растом это очень существенная проблема. Хоть сколько-нибудь легковесного компилятора для него нет...
Вы прям так жалуетесь, будто вас кто-то заставляет собирать весь свой инструментарий на своём компьтере из исходников.
это должен быть персональный ад для растоманов - сборка раста из исходников не на роллинге...
Вообще довольно часто приходится. Каких-то мелких патчей накинуть - обычное дело. Раст довольно сильно мешает тяжёлым компилятором (у плюсов тоже такая проблема).
Си - совсем другое дело.
Такая же проблема плюсов решается ccache, но не в случае rpm.
Решил такую проблему имеенно так. Чяднт?
Специально собирали на локальной машине, а не вон там, где положено.
>> чтобы кое-как собрались все зависимости зависимостейуберите --with-bdeps=true :D
>>проект RPM5, который непосредственно не связан с RPM4 и в настоящее время заброшен (не обновлялся с 2010 года).Ну и зачем его тогда каждый раз упоминать?
Чтоб не думали, наверное, что 4.18 это что-то древнее с поддержкой на уровне секурити баги пофиксим.
Что бы я каждый раз писал, что «разработчики» свеженькой Rosa долго рекламировали его среди пользователей как прогрессивный, а пару лет назад выкинули, поскольку не умеют исправлять тривиальные переполнения стека и вообще кодить.
>> а пару лет назад выкинулиКакие пару лет? С 2010 года заброшен, уже давно пора его забыть.
>>> а пару лет назад выкинули
> Какие пару лет? С 2010 года заброшен, уже давно пора его забыть.Это автор его тогда забросил. Потом местные деятели купили Mandriva Linux. Внедрили RPM5 вместо RPM4, что бы быть впереди планеты всей. Потом произошло разделение на OpenMandriva и Rosa. Первые вынужденно поддерживали RPM5, что-то там доделывали. Вторые слепо патчи копировали. Накопировали переполнение стека при установке пакета и не могли его исправить, это сделал за них я. Платформа 2016 была у них актуальна ещё год назад, там RPM5.
RPM - это формат пакетов. Пакетный менеджер RPM - DNF. Почему RPM называют пакетным менеджером?
rpm -ivh *.rpm
> RPM - это формат пакетов. Пакетный менеджер RPM - DNF.Неверно. Формат пакетов — CPIO + RPM-специфичные доп. заголовки. А пакетный менеджер — RPM. Что касается DNF, то он просто докачивает недостающие RPM из прописанных репозиториев. Формально его тоже можно обозвать пакетным менеджером, но часть своего функционала он просто делегирует RPM.
Да ну? Название расшифруй для начала
https://en.wikipedia.org/wiki/RPM_Package_Manager
> Предложен более понятный макрос "%bcond" для определения условий при сборке.В сусе уже давно, весрии где-то с 12.2
> Fix %_minimize_writes regression (in 4.15.0)Всего 4 года фиксили или около того.
Никогда не пользовался, чем он лучше deb, стоит пробовать?
Зачем пробовать, если вас устраивает ваш deb дистрибутив?Не понимаю людей вообще.
Как и не понимаю как люди пользуются deb-based дистрибутивами - рядом с RPM не валялся по фичам.
> рядом с RPM не валялся по фичамчто за фичи такие?
Можно скопировать spec файлы из Fedora и scamпелировать дистрибутив с ̶н̶е̶с̶к̶у̶ч̶н̶ы̶м̶и̶ ̶о̶б̶о̶я̶м̶и̶ трендовым сетом иконок.
Не понимаю людей, которые пользуются rpm и deb дистрибутивами, когда есть tgz-дистрибутивы.
У вас слишком много ошибок в слове "ebuild" :D.
У вас слишком много ошибок в слове по"ebuild" :D.Исправил, можешь не благодарить.
Создавать rpm пакеты как мне кажется проще чем deb. Всего один spec-файл для пакета написать и всё.
Хотя тут наверное дело привычки...
Лучше ебилды попробуй.
> Лучше ебилды попробуй.Нет столько свободного времени.
Замени свой Эльбрус на Ryzen наконец.
> Замени свой Эльбрус на Ryzen наконец.Свободному времени на зад-тство от этого неоткуда взяться.
>чем он лучше debdnf лучше apt, а нижний слой всё равно сплошной оверинжениринг
Я про формат больше, а не менеджер. Так-то с apt у меня и так нет сложностей, зависимости разруливает, о проблемах предупреждает до того как начнёт обновление.А вообще по возможности предпочитаю AppImage или просто тарбол бандлы.
На формат бинарного пакета всем кроме белок-истеричек начхать. (Хотя возможность одной командой вытащить интересующий файл а не распаковывать бессмысленную матрешку в несколько приемов все же иногда удобна.)Но возможно до тебя когда-нибудь дойдет, что мы тут не все белки-истерички, неистово надр@4ивающие на шва6одку, и кто-то когда-то всерьез предпочитал опенсорс потому что мог его сделать для себя таким как ему удобно.
Вот сборка .deb - это боль, унижение, страдания. Уе...щный формат (три разных формата), мильен загадочных хелперов без документации, еще и норовящих "устареть", куча мусора часть которого не предназначена для людей, зато вторая требует ручного ковыряния - отдельный привет тем кто привык при работе пользоваться vcs, невозможность быстро и просто поправить чужое.
.spec - единственный обычно _мелкий_ файлик, вся сложная деятельность загнана под капот и оттуда не торчит, лазят туда только дистростроители, новый образуется cp старый от первого попавшего под руку пакета и быстрой правкой десятка идущих подряд очевидных строк с именем и версией для начала - тратить время на чтение документации тебе скорее всего не придется. На некоторые сложности напарываешься в сложных местах (типа сборки модуля для язычка с собственной нескучной пакетной системой), но обычно где-то в федорином сайте есть документация и на этот случай. Макро и хелперы сделаны в режиме автопилота а не т-пого робота-водителя - т.е. включаются явно, делают за тебя твою работу, при малейшем несогласии с тем как они это делают - просто отключаются. Хочешь - дергай %configure, не хочешь или просто не дочитал до этого места - запускаешь вручную, никаких "dh-override" когда сперва догадайся, ЧТО override.
>>(Хотя возможность одной командой вытащить интересующий файл а не распаковывать бессмысленную матрешку в несколько приемов все же иногда удобна.)Простите, а пользоваться mc и ходить им унутре пакетов вам совсем убеждения не позволяют?
Это ваше mc как-нибудь скриптуется или мне руками файлы готовить под плейбуки и прочие репаки каждый раз?
Классическая ситуация, ты ставишь зависимости для сборки какого-то куска софта через классический apt-get build-dep имя_пакета, например, php. Классика же, да? А он тебе в ответ:
Required такой-то package but it will not be installed.И дальше мудовые рыдания, а почему? потому что ты из него не можешь выбить причину заминки установки. А причина кроется в том, что у доебана зависимости ставятся через самолётное крыло.
Например, у тебя есть зависимость второго уровня "a | b | c" и зависимость третьего уровня "x | y | z". Известно, что "a" конфликтует с "x и "z", "b" конфликтует с "y" и c конфликтует с "x" и "y". А что делает dpkg/apt-get? Вы думаете, он строит дерево зависимостей, выявляет нужное сочетание пакетов и ставит их? Хрен там плавал.
Вместо того, чтобы обмозговать ситуацию и поставить пакеты "a" и "y", он попытается поставить "a" и "x" и скажет, что он обосрався. И то, это произойдёт тогда, когда ты извернёшься, вынешь build-time зависимости, (обычно достаточно дерева 3, иногда 4-го уровня) и начнёшь играться с разным сочетанием пакетов, ставя их через apt/apt-get. У RPM такой жидкомозговости не наблюдается.И эта всратость в apt-е присутствует уже очень давно, в убунте 20.04 она точно была, равно как и в debian wheezy (который 7). И при сборке dpkg-шек меня это задолбало. А "великолепная" документация по dh-чего-то_там? Причём, бюрократия внутри debian 80+ левела: бох с ним, что надо облизать coc.md, но уже готовую документацию, соответствующую всем облизанным coc.md принимать отказываются. Я не знаю, с кем надо там переспать, кому занести, чтобы была возможность дополнить, а местами просто написать отсутствующую документацию по всем этим сборочным "тайным знаниям".
В то же время собрать rpm-пакет вполне возможно и по пути не надо будет крафтить сборочное окружения руками, подсовывая туда правильные пакеты, правильных версий и в правильном сочетании (в обход списка зависимостей). Даже тот же php (у которого гигантское количество зависимостей) собирается без проблем и потом *работает* ровно так как и должен (в меру набора багов внутри самого php).
Ну это уже проблема не deb/dpkg - это проблема apt и она тоже в головах у тех кто его изначально разрабатывал, что хотя бы примитивный путь вручную прооверрайдить его зависимости зависимостей не то что не предусмотрен, а если даже ты голым dpkg их решишь, при следующем же запуске apt либо все сломается либо он тебе все сломает.Но тут можно долго рассуждать о вкусах - поскольку ни dnf, ни zypper тоже в общем звезд с неба в этой области не хватают.
> Классическая ситуация, ты ставишь зависимости для сборки какого-то куска софта через классический apt-get build-dep имя_пакета, например, php. Классика же, да?Не совсем, что-то компилить самому редко приходится.
Во-вторых, я не делаю build-dep на основной системе, предпочитаю компилить что либо в чруте, чтобы не засирать систему кучей *-dev пакетов (к слову, они и в rpm-based системах есть вроде как).
> И дальше мудовые рыдания, а почему?Не было такого, если /etc/apt/sources.list.d не засран левыми репами, то проблем не бывает. Что убунтушные, что дебияновские репы обычно в нормальном состоянии.
> потому что ты из него не можешь выбить причину заминки установки.
Тут вовсе враньё, apt выдаёт подробную инфу что такой-то пакет не может быть установлен, потому что зависит от такого-то пакета такой-то версии, но его нет в репах или типа того. Но опять же, такая ситуация возникает только если система засрана левыми репозиториями или пакетами не из реп.
> И эта всратость в apt-е присутствует уже очень давно,
Давно это когда? Прост я с 2007г. пользуюсь уже ))
Когда слышу "рпм", вспоминаю вечные ожидания поиска зеркал yum. Это настолько раздражало что на всю жизнь запомнилось.
И кто виноват в том, что ты не способен заменить строчку "mirrorlist" на "baseurl"?