https://www.opennet.ru/openforum/vsluhforumID3/128486.html После года разработки состоялся релиз пакетного менеджера 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...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57809<br> https://www.opennet.ru/openforum/vsluhforumID3/128486.html#58 Sun, 25 Sep 2022 07:36:38 GMT &gt;&gt;&gt; а пару лет назад выкинули <br>&gt; Какие пару лет? С 2010 года заброшен, уже давно пора его забыть. <br><br>Это автор его тогда забросил. Потом местные деятели купили Mandriva Linux. Внедрили RPM5 вместо RPM4, что бы быть впереди планеты всей. Потом произошло разделение на OpenMandriva и Rosa. Первые вынужденно поддерживали RPM5, что-то там доделывали. Вторые слепо патчи копировали. Накопировали переполнение стека при установке пакета и не могли его исправить, это сделал за них я. Платформа 2016 была у них актуальна ещё год назад, там RPM5.<br> https://www.opennet.ru/openforum/vsluhforumID3/128486.html#57 Sat, 24 Sep 2022 10:18:50 GMT &gt;&gt; а пару лет назад выкинули<br><br>Какие пару лет? С 2010 года заброшен, уже давно пора его забыть. <br> https://www.opennet.ru/openforum/vsluhforumID3/128486.html#56 Fri, 23 Sep 2022 11:59:19 GMT Специально собирали на локальной машине, а не вон там, где положено.<br> https://www.opennet.ru/openforum/vsluhforumID3/128486.html#55 Thu, 22 Sep 2022 22:53:39 GMT Решил такую проблему имеенно так. Чяднт?<br> https://www.opennet.ru/openforum/vsluhforumID3/128486.html#54 Thu, 22 Sep 2022 20:40:17 GMT И кто виноват в том, что ты не способен заменить строчку "mirrorlist" на "baseurl"?<br> https://www.opennet.ru/openforum/vsluhforumID3/128486.html#53 Thu, 22 Sep 2022 19:25:48 GMT &gt; Классическая ситуация, ты ставишь зависимости для сборки какого-то куска софта через классический apt-get build-dep имя_пакета, например, php. Классика же, да?<br><br>Не совсем, что-то компилить самому редко приходится.<br>Во-вторых, я не делаю build-dep на основной системе, предпочитаю компилить что либо в чруте, чтобы не засирать систему кучей *-dev пакетов (к слову, они и в rpm-based системах есть вроде как).<br><br><br>&gt; И дальше мудовые рыдания, а почему?<br><br>Не было такого, если /etc/apt/sources.list.d не засран левыми репами, то проблем не бывает. Что убунтушные, что дебияновские репы обычно в нормальном состоянии.<br><br>&gt; потому что ты из него не можешь выбить причину заминки установки. <br><br>Тут вовсе враньё, apt выдаёт подробную инфу что такой-то пакет не может быть установлен, потому что зависит от такого-то пакета такой-то версии, но его нет в репах или типа того. Но опять же, такая ситуация возникает только если система засрана левыми репозиториями или пакетами не из реп.<br><br>&gt; И эта всратость в apt-е присутствует у https://www.opennet.ru/openforum/vsluhforumID3/128486.html#52 Thu, 22 Sep 2022 14:43:31 GMT Когда слышу "рпм", вспоминаю вечные ожидания поиска зеркал yum. Это настолько раздражало что на всю жизнь запомнилось.<br> https://www.opennet.ru/openforum/vsluhforumID3/128486.html#50 Thu, 22 Sep 2022 08:46:53 GMT Ну это уже проблема не deb/dpkg - это проблема apt и она тоже в головах у тех кто его изначально разрабатывал, что хотя бы примитивный путь вручную прооверрайдить его зависимости зависимостей не то что не предусмотрен, а если даже ты голым dpkg их решишь, при следующем же запуске apt либо все сломается либо он тебе все сломает.<br><br>Но тут можно долго рассуждать о вкусах - поскольку ни dnf, ни zypper тоже в общем звезд с неба в этой области не хватают.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/128486.html#49 Thu, 22 Sep 2022 08:06:05 GMT Классическая ситуация, ты ставишь зависимости для сборки какого-то куска софта через классический apt-get build-dep имя_пакета, например, php. Классика же, да? А он тебе в ответ:<br>Required такой-то package but it will not be installed.<br><br>И дальше мудовые рыдания, а почему? потому что ты из него не можешь выбить причину заминки установки. А причина кроется в том, что у доебана зависимости ставятся через самолётное крыло.<br>Например, у тебя есть зависимость второго уровня "a &#124; b &#124; c" и зависимость третьего уровня "x &#124; y &#124; z". Известно, что "a" конфликтует с "x и "z", "b" конфликтует с "y" и c конфликтует с "x" и "y". А что делает dpkg/apt-get? Вы думаете, он строит дерево зависимостей, выявляет нужное сочетание пакетов и ставит их? Хрен там плавал.<br>Вместо того, чтобы обмозговать ситуацию и поставить пакеты "a" и "y", он попытается поставить "a" и "x" и скажет, что он обосрався. И то, это произойдёт тогда, когда ты извернёшься, вынешь build-time зависимости, (обычно достаточно дерева 3, иног