Господи, какое ж это щастье, когда менеджер пакетов не на питоне!

🥳

Там это не только из-за «питона».

Полагаю, речь про более сложную логику расчёта зависимостей с учётом USE-флагов и т.п. Полагаю также, что говнопитон (как и любая говнодинамическая типизация) к расчётам не приспособлена в принципе, и будучи переписанной на C/C++, эта логика отрабатывала бы тоже мгновенно, и юзер вместо одного мгновения не заметил бы два.

Боюсь даже представить бурность твоей реакции при встрече с менеджером, который менеджит.

При чем здесь питон ?

Если ты такой умный в ЯП, то тебе задача:

На каком языке быстрей выполнится sleep(1000); - на C++ или на Python ?

часами зависимости считает? слабо верится

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

Уже переписывали (Paludis). Насколько я знаю, он не был значительно быстрее в разрешении зависимостей.

Кстати, +1

Минут 40

Уже переписывали (Paludis). Насколько я знаю, он не был значительно быстрее в разрешении зависимостей.

Значит, базу надо также бинарную.

А как pacman решает опциональные зависимости?
Там это как настраивается?

Полагаю, речь про более сложную логику расчёта зависимостей с учётом USE-флагов и т.п.

и т.п.

eix на c++, а emerge да, говно

eix по ощущениям довольно шустро работает.

поиск пакета-владельца файла

Вместо equery можно использовать qfile (https://wiki.gentoo.org/wiki/Q_applets).

Но вообще, да, portage - это боль.

eix на c++

Собственно да, его я зря сюда до кучи приплёл. Вывод пакетов по подстроке имени, или там eix --installed-from-overlay – всё это быстро; а больше никак его не юзал.

Интересно, пакетные менеджеры Gentoo за вычетом времени компиляции медленнее DNF из Fedora/CentOS/RHEL? Самый тормозной на моей памяти это именно DNF, который тоже склеен Python’ом. А самый быстрый на моей памяти действительно pacman из Arch Linux. Быстрее него только pkgman в Haiku, но там пакеты по другому работают, через монтирование.

Там дело не только в питоне. Там всю архитектуру менять надо.

Если руки из задницы, из любого языка можно сделать bash.

А как их надо решать?

А yum на чем?

А как pacman решает опциональные зависимости?

По умолчанию они не ставятся. Но есть костыль.

Кстати, забавно, как раз вчера пытался Gentoo поставить. В итоге всё сделал, всё настроил (начал с чисто консольного профиля, чтобы легче было)… и забыл установить sudo! А теперь оно не хочет, выбивает непонятные ошибки.

Когда сделают быстрый поиск?

Медленнее конечно.

А самый быстрый на моей памяти действительно pacman из Arch Linux.

ЕМНИП, самый быстрый — апк.

Ну если готовые пакеты - то решение очевидное - там есть рекомендованные пакеты в информации самого пакета.
Насчёт менеджеров собирающих из исходников понятия не имею как в арче это решается.

Какие? Просто от рута зайдите и установите.

По дефолту опциональные пакеты — опциональны.

Я sudo вообще не использую (ну т.е. использую на горячих клавишах в openbox, чтобы всякие браузеры с мессенжерами в отдельных юзерах запускались, но руками – никогда); тупо su -. Т.к. один хрен редко какая maintenance операция бывает одиночная, обычно надо несколько действий подряд делать, и писать перед каждым sudo – нафиг.

На Python видимо. Он ещё медленнее DNF, но он уже в прошлом. DNF его идейный наследник. Тормоза унаследовал тоже.

Рекомендации вручную ставить.

Сам pacman только информирует о них.

Хотя наверняка это доделано в куче оберток для него.

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

Питон.

https://github.com/rpm-software-management/yum

В кого а прошлом. А у кого в суровом настоящем.

Но тормозов особо не замечал. Может потому, что на сервере в принципе пакетов мало.

Это опции зависимостей пакета, а не сборки.

Sudo нужен для скриптов. У тебя скрипт один раз полез в рут через sudo, ты пароль ввел, и следующие 10 минут он тебя не спрашивает.

У меня так автоматизированно пакеты пересобираются, например.

Ну если есть программа, поддерживающая Qt и GTK. У тебя стоит обе библиотеки. Как pacman выбирает способ сборки?

И в принципе опция аналогичная emerge --with-bdeps реализуется предельно тупо, но в pacman -hS не видать. И пох: лично я никогда не понимал, нафига она нужна, и никогда не использовал. Особенно если этих опциональных зависимостей – вагон и маленькая тележка, а тебе если и нужно из них чего, то 1-2.

Арч не source-based.

Понятия опциональной зависимости времени компиляции в нем нет.

Предполагается, что если собирает билд-сервер, он собирает полный фарш.

А если пользователь, то пользователь вручную pkgbuild отредактировать может.

Никак. https://github.com/archlinux/svntogit-community/blob/packages/zathura/trunk/P...

тогда не совсем ясно сравнение pacman с emerge

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

Гента головного мозга, похоже =)

Это к ТСу)

Ну понятно, к кому же ещё. =)

Можно два пакета с разной сборкой сделать. Типа yoba-qt, yoba-gtk.

Ну если есть программа, поддерживающая Qt и GTK. У тебя стоит обе библиотеки.

Если оба варианта востребованы, то арчевский билд-сервер будет собирать два разных пакета. У некоторых приложений я такое видел.

Обычно так и делают.

Человек только узнал, что зависимости могут вычисляется того, как вы успеете сделать кофе, дайте ему по радоваться. :)

то есть смысл в том, что pkgbuild проще устроен, чем ebuild? в общем.

Да. Он простой как палка. Этим и хорош, ибо во что превратился apt мне больно смотреть. Почему оно такое жирное и встратое!?

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

У меня реально мгновенно, не успеваю заметить как панели mc моргают. В виртуалке на голой системе (без иксов).