Paludis quiet

man bash
/alias

Ну, я привык к чрезмерной говорливости палудиса, тем более это (show-descriptions) - вполне полезная фича. Чтобы каждый раз эти опции не писать - добавь в ~/.bashrc

export CAVE_RESOLVE_CMDLINE_PARAMS="--show-option-descriptions none --show-descriptions none"

Ты точно подметил - все это приходится «нащупывать», документация годится только как reference.

Почитай ман, возможно там как в portage есть переменные для make.conf а-ля EMERGE_DEFAULT_OPTS="--quiet-build=y"

А через «хуки» какие-нибудь - никак не получится сделать его более тихим? Ещё заметил одну странность палудиса. Пробовал ставить его на свежем stage3-hardened+nomultilib. При «cave resolve -cx world» - палудис хочет обновить gcc с флагом fortran. emerge -DuN world - этот флаг не включает. Посмотрел в профилях - fortran должен быть для hardened выключен. В конфиге палудиса и портежа профиль одинаковый. Интересно, много ли таких несоотвествий на более жирной системе?

Хуки это немного не то, они наоборот вызывают дополнительные команды для заданных фаз. Насчет portage ничего не могу сказать, gentoo не использую. У меня в системе (exherbo) gcc[fortran] нужен для numpy, scipy, octave, OpenBLAS и R. Разве paludis не говорит (кстати, вот тебе и «излишняя информативность»), для чего именно нужен этот флаг?

Насколько я помню до одного времени paludis и portage шли нога в ногу а дальше вся работа paludis ушла в exherbo а в gentoo оно осталось вообще непонятно для чего. К тому-же по всем заявлениям тех кто юзал paludis никакого профита относительно обычного portage нет а вот геморроя от него побольше будет.

Т.е. посыл такой либо полностью уходи на exherbo либо не морочь голову.

Увидел, что перевели из тестовой ветки в stable в дереве, потому и решил попробовать http://packages.gentoo.org/package/sys-apps/paludis. Тут разработчики похвалились, что paludis проходит у них какие-то тесты https://bugs.gentoo.org/show_bug.cgi?id=520874.

Увидел, что перевели из тестовой ветки в stable в дереве, потому и решил попробовать

Ну перевели и замечательно. Дело не в этом paludis/cave сейчас в exherbo. И именно в exherbo раскрываются все его прелести, если они в нём вообще есть.

Вот что выдаёт cave: http://paste.org.ru/?i5hic6. Кейворды выставлены «amd64 ~amd64». Профиль как то иначе читается? И как палудисом делается «emerge -e world» (пересборка всех пакетов в системе)?

Вот здесь такая же проблема. Попробуй явно указать в use.conf

sys-devel/gcc -fortran

Пересборка мира делается через cave resolve -e world (согласно «man cave-resolve», "-e" это алиас для "-kt -Sa -sa -B").

Вот мои алиасы для пересборки:

export CAVE_RESUME="/var/tmp/paludis/resume"
export CAVE_RESUME_FILE_OPT="--resume-file $CAVE_RESUME"

alias cr='sudo cave resolve'
alias crz="cr ${CAVE_RESUME_FILE_OPT}"
alias cz="sudo cave resume ${CAVE_RESUME_FILE_OPT} -R -r"
alias czz='cz +r'
alias crw='crz world -Ci'
alias crwc='crw -c'
alias crwe='crw -e'
alias czw='cz world -Ci'
alias czzw='czz world -Ci'

поправка: в алиасах czw и czzw указывать world не нужно, cave resume запоминает какие пакеты надо было обновить.

Между прочим, «cave resume» - очень полезная команда. С ее помощью можно ликвидировать главный недостаток «cave resolve» - неинтерактивность (нету аналога emerge --ask). Можно делать так:

# запускаем солвер без '-x'
cave resolve world -c --resume-file /tmp/cave-resume
# анализируем выхлоп, если все хорошо, запускаем
sudo cave resume --resume-file /tmp/cave-resume
# солвер использует сохраненное состояние

Спасибо. В таком виде этот ПМ кажется более удобным. Но так ли часто приходится что-то чинить? Попробовал сравнить time от «emerge -epv world» и «cave resolve -e world» и cave каждый раз отрабатывает раза в 3 медленнее (хотя пакетов в системе минимальное количество - 187). Слышал, что в «cave» есть какое-то грамотное разрешение круговой зависмости, и поэтому многие удивляются тому, что работает он медленнее, чем emerge. Можно ли как то на это повлиять? Что-нибудь типа --resolve-dangerous-kote-vopasnoste. С поиском пакетов разобрался - он таки работает быстро при «cave show».

Лично мне cave не кажется медленным, возможно привык уже (все равно в exherbo выбирать не из чего). По моим наблюдениям, долгое время работы солвера обьясняется «корректностью» построения графа зависимостей (не забываем, что автор - учёный, занимающийся алгоритмами на графах). При разрешении блокировок солвер иногда начинает строить граф заново (обозначая в выхлопе все restarts).

часто приходится что-то чинить

Пакетный менеджер, поддерживающий PMS, не должен ломаться, ломаются некорректные ebuild'ы. У нас exheres'ы никогда не ломаются, любой пользователь достаточно компетентен чтобы пофиксить мелкие косяки и отправить патчик.