Сравнение пакетных менеджеров

Да, ручные зависимости почему-то зачастую делают на имена пакетов. Это плохие, кривые зависимости. Но это вина мейнтейнеров, а не вина формата rpm.

Почти согласен. Зачем в RPM позволяют делать такие зависимости?

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

Именно что использую

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 OPR/72.0.3815.400

Манжара с кедами на макбуке. На десктопе дуалбут, да.

Тебя под дулом пистолета заставляют ставить флатпаки?

Я говорю про будущее. Уже сейчас ряд ПО кроме как через флатпак/снап не поставишь, особенно проприетарщину (привет, вайбер!). Я понимаю, что разработчикам так проще, но лично меня этот подход не устраивает.

Потому что rpmbuild не может понять, какие ручные зависимости хорошие, а какие плохие. Они же ручные, т.е. полностью на совести мейнтейнера.

Не думаю, что пакетные менеджеры вымрут. Флатпак и не позиционируется как замена апту или днф. Но для распространения пользовательских приложений с ГУИ он подходит очень хорошо. Это же был сущий кошмар, когда в репах лежал софт двухгодичной давности, ещё и с васянопатчами от дофига умных мейнтейнеров.

Попробовал магею. Поскольку увиденное меня шокировало (до этого не трогал этот дистр), не могу не заметить:

• Я думал, что у федоры самый безумный инсталлятор, но магея их переплюнула. Начиная с кривого и убогого внешнего вида (как будто оно на баш скриптах с zenity сделано) и заканчивая банально организацией процесса - тебя бомбят кучей ненужных вопросов на протяжении всего процесса установки (ну вот что ЭТО за хрень?). Это в 2020 когда даже васянские сборки типа манжары выглядят солидно и устанавливаются в три клика. Камон...
• Бетка8 у них полностью сломана - банальный dnf update после установки не работает (что-то с зеркалами). Даже fedora rawhide так не поломан
• Это наверное единственный оставшийся дистрибутив который не перешел на отключенный рут и sudo из коробки

Результат Вручную разгребать зависимости и пробовать зафорсить установку не буду.

А вот что говорит OpenSUSE. Если зафорсить установку, то будет работать, т.к. аналогичная библиотека установлена.

Ну и в тему о PackageKit

Широкое значение не включает десктопные решения?

В обоих случаях зависимости на названия пакетов, а не на наличие каких-то so-файлов или других capabilities. То есть проблема в маинтейнерах и в использовании ими Debian-like зависимостей.

alien -r скорее всего

Ленивые маинтейнеры - тоже вариант.

но магея их переплюнула

Магея это как бы наследник мандривы и инсталлятор они взяли мандривовский, который не сильно и поменяли за эти годы. Мандрива умерла в 2011 году, и в последние пару лет до этого им было уже не до пиления инсталлятора. В нулевые же такие инсталяторы были нормой. А в целом, с оценкой магеи согласен

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

Судил по первому сообщению. Но, конечно, может не совпадать.

Ну а в виндовсе его нет. :)

7 на двух CD шёл. На одном, собственно, инсталлятор, на втором - .srpm

Может, и на двух. Я тебе точно не смогу сказать. Да и диски эти я благополучно года два назад выкинул.

Нет необходимости собирать RPM-ки самому, чтобы назвать использующего alien -r ленивым.

Это скорее про роллинг-релиз, а не про pacman

Да нет, про него. Вкупе с политикой Arch.

В том же Debian в имени пакета с библиотекой обязательно присутствует версия ABI, поэтому:

1. Не получится обновить библиотеку на новую мажорную версию и случайно сломать при этом другие пакеты. Скажем, обновление libreadline7 → libreadline8 будет просто несовместимо с зависимостями пакетов от libreadline7. Да, apt в данном случае даст по рукам и не даст совершить операцию (или же удалит зависящие от устаревшей версии пакеты), а pacman обновит без вопросов, что создаст впечатление, что apt «ломается от любого неосторожного движения» — до тех пор пока не обнаружится, что обновлять-то пакет совсем не стоило, и полсистемы сломалось нафиг.

2. Можно установить несколько версий библиотеки одновременно. Скажем, возвращаясь к той же libreadline:

aleksej@lenovo:~$ apt search '^libreadline[[:digit:]]+$'
Сортировка… Готово
Полнотекстовый поиск… Готово
libreadline5/stable,testing,now 5.2+dfsg-3+b13 amd64 [установлен, автоматически]
  Библиотеки GNU readline и history, выполняемые библиотеки

libreadline7/stable,now 7.0-5 amd64 [установлен, автоматически]
  Библиотеки GNU readline и history, выполняемые библиотеки

libreadline8/testing 8.1-1 amd64
  GNU readline and history libraries, run-time libraries

aleksej@lenovo:~$ 

Количество пакетов в основном репе Арча сопоставимо с количеством пакетов Деба, а значит, РЕАЛЬНЫХ проектов в Арче опакечено сильно больше.

Ещё раз спрошу: сколько пакетов в основном репозитории Arch?

ты еще и читаешь плохо Сравнение пакетных менеджеров (комментарий)

Это ты читаешь плохо или не знаешь что делает alien -r.

Раз гражданин стесняется, я скажу. 3272 пакета. Против 28927 пакетов с исходным кодом на момент релиза Debian Buster (из которых и нарезаются те самые мелкие пакеты пакеты, про которые он и говорил, от чего репозитории и распухают до 60000+ пакетов).

Угу. Я просто зашёл сюда, и там во всех разделах, включая Community, KDE-Unstable, Testing и проч. — 11523 пакета. В buster же вы уже привели, а в bullseye в одном только main 30955 пакетов с исходным кодом, а в sid вообще 32723.

Потому я и поинтересовался, где же остальные 20+ тысяч пакетов в основном репозитории Arch, если там, как товарищ утверждает, их больше, чем в Debian.

Я же говорил, то санитары были. Увели его.