Интервью с разработчиком системы Paludis

Gentoo капец?

только вчера переехал на тестовое использования paludis, пока из впечатлений - слишком много букв пишет, необходимые папки создавать сам не может, все нужно ручками ему создавать, равно как и разрешения выставлять; так же ставит зависимостями какие-то пакеты, без которых моя система спокойно жила 2 года

забыл добавить что параметры командной строки там намного запутенней чем у портеджа

>забыл добавить что параметры командной строки там намного запутенней чем у портеджа

Но в целом-то как, юзабельно или пока даже соваться не стоит?

>Но в целом-то как, юзабельно или пока даже соваться не стоит?

Ставьте лучще dpkg.

Как бывший гентушник, завляю, что ты сравнил красное с пушистым.

Посидел я какое-то время на Палудисе, с месяц наверное, да и вернулся обратно... Реальных плюсов не заметил, кроме более жёсткого контроля ебилдов (оно же и минус - когда они не твои), а минусов - масса. Особенно убила постоянная нелюбовь палудиса к версиям, типа "20071217", им лишних пару байт было жалко зарезервировать :)

Использую палудис долгое время, очень доволен. Из самых частоюзаемых плюсов: удобное распределение по оверлеям (с возможностью явно указать с какого оверлея ебилд мержить) и scm ебилды.

А букв он много пишет, да. И без bash-completion его --dl-* иногда затрахивает набирать.

>Из самых частоюзаемых плюсов: удобное распределение по оверлеям (с возможностью явно указать с какого оверлея ебилд мержить)

А я просто тупо подключаю исключительно /usr/local/portage, а всё, что надо из сторонних оверлеев, прописываю туда симлинками :) Получается намного универсальнее и безопаснее.

paludis пробует решить святую задачу - gentoo без python. Идеологически это правильно, лишняя зависимость не нужна, и такая важная системная функция должна выполняется не скриптом, а хорошо спроектированной программой.

Я использую paludis уже около года. Он не только контролирует зависимости при установке пакета, но и и при его удалении, что исключительно важно. Позволяет создавать собственные множества типа world, например security, т.е можно проводить обновления связанные с безопасностью, что может быть немаловажно.

Несравнимо быстрее составляет дерево зависимостей при обновлении world-а

Практически невозможно одновременно обновляться с paludis и emerge, так как они по разному понимают зависимости между пакетами, и если обновишь world по одной программе, потом другая захочет сделать всё по другому, а когда это ей позволишь, то потом уже первая захочет всё вернуть обратно.

в общем программа довольно надёжна и удобна в работе, не считая слишком длинные названия ключей.

Я просто ставлю алиасы на наиболее используемые ключи.

Тоже юзаю уже больше года наверное. реконцильо на порядок быстрее revdep-rebuild, сам палудис у меня тоже работает шустрее нежели emerge. Из killing-feature стоит отметить --with-dependencies и --uninstall-unused, --report. А для оверлеев есть playman (ruby вместо python :) ) и руки.

Ну, если я понимаю правильно, --uninstall-unused — это тоже самое, что и emerge --depclean. Так что это не killing-feature...

А вообще, paldius да, пошустрее, но какой-то он строгий слишком, опции слишком длинные, аналога --ask нету, не понимает файлы /etc/portage (по идеологическим соображениям, насколько я понял), задавать индивидуальные настройки для определённых пакетов я тоже не нашёл как...

> не понимает файлы /etc/portage

USE="portage" emerge -av paludis

>задавать индивидуальные настройки для определённых пакетов я тоже не нашёл как.

Может быть мануал поможет?:)

/etc/paludis/keywords.conf:

dev-util/netbeans ~x86

/etc/paludis/use.conf:

dev-util/netbeans experimental nb j2ee

Красные глаза...
Компиляю-удаляю.
Красные глаза...
О генте одной мечтаю.

Красные глаза, красные глаза :)

>А вообще, paldius да, пошустрее, но какой-то он строгий слишком, опции слишком длинные, аналога --ask нету, не понимает файлы /etc/portage (по идеологическим соображениям, насколько я понял), задавать индивидуальные настройки для определённых пакетов я тоже не нашёл как...

Читайте маны, они рулез :-)

у палудиса есть директория /etc/paludis, аналог /etc/portage. Там есть файлы с похожими именами, функциями, и синтаксисом. В этом смысле автор молодец, не стал делать лишних движений.

А иметь одну директорию на два пакетных менеджера невозможно, и я уже говорил почему. Кроме того, это две разные программы, и естественно их конфиги должны быть в разных местах.

Чем принципально лучше палдиус в сравнении с эмерджем ?

Поскольку после прочетния треда, мысль пришла только одна - кому что нравится, тот то и ставит ... что есть не существенная причина ...

Хотелось бы ответ более понятный, навроде - эмердж то-то и тото не умеет, а палдиус умеет.. и наоборот.. просветите ))

http://paludis.pioto.org/overview/features.html

Лень переводить.

>А иметь одну директорию на два пакетных менеджера невозможно, и я уже говорил почему

угу особенно весело потом переносить USE-флаги между конфигами.

А вообще вещь хорошая, особенно радует работа с оверлеями и наличие сетов. Не радует то что он слишком заморочаный, там где портедж просто работает, в палудисе нужно совершить тыщу напонятных телодвижений. Вот например как подулючить туда getdelta я так и не понял

> paludis пробует решить святую задачу - gentoo без python. Идеологически это правильно

4.2

> такая важная системная функция должна выполняется не скриптом, а хорошо спроектированной программой.

Скрипт не исключает возможность быть "хорошо спроектированной программой".

Пробовал как-то... Впечатления - малосовместимо с портежем и заморочно. И прикольно еслиб сделали client/server'ным. А что без питона, то это конечно хорошо. Но "малавата бует" (с) Вот если его официально на замену портежу- то да. А так вряд ли.

> только вчера переехал на тестовое использования paludis

Переехал с генты на Ubuntu и Debian! Не жалею! Фтопку эти компиляции сутками и бесполезный на анлиме дельтап! Фтопку эти проблемы при обновлениях! Фтопку этот тормознутые эмердж на пистоне! Фтопку недеделанные нерусифицированные системные утилиты и ман рисующий кракозябры. Фтопку revdep-rebuild и трахание с блокирующимися зависимостями! Фтопку постоянные пересборки ядра с жесктим контролем make xconfig, чтобы ничего не отвалилось. Фтопку-фтопку-фтопку это кривое красноглазое поделие в котором вечно что-то сломано, рассинхронизировано или положено на стандарты типа LSB!

>>А иметь одну директорию на два пакетных менеджера невозможно, и я уже говорил почему

>угу особенно весело потом переносить USE-флаги между конфигами.

на сайте программы есть скрипт для миграции...

>Вот например как подулючить туда getdelta я так и не понял

я использую для скачки emerge -uf world, главное не компилировать разными програмными менеджерами.

Когда нибудь и этот вопрос допилят, но пока у них есть другие, более приоритетные вопросы

>> paludis пробует решить святую задачу - gentoo без python. Идеологически это правильно

>4.2

Любая лишняя зависимость в идеале должна быть ликвидированна. Ничего личного...

>> такая важная системная функция должна выполняется не скриптом, а хорошо спроектированной программой.

>Скрипт не исключает возможность быть "хорошо спроектированной программой".

Скрипт может быть достаточно надёжным, но важные вещи лучше делать программой.

>Чем принципально лучше палдиус в сравнении с эмерджем ?

Да вроде я изложил уже основные причины, стараясь подбирать наиболее объективные:

http://www.linux.org.ru/jump-message.jsp?msgid=2349296&cid=2349691

Хммм. А имеется ли какое-нибудь более-менее наукообразное сравнение систем пакетов? В основном интересует документированность, кроссплатформенность и понятность. Просто тут есть нечто типа задачи сделать локальную систему распространения, более-менее автоматизированную, думаю вот что-нибудь из умного использовать, а как-то не нашел.

С вашей стороны было бы наивно предполагать, что я вообще не прочёл документацию... Индивидуальные keywords и use-flags, конечно, можно указывать. Если бы это было не так, то на paldius вообще бы никто не посмотрел. А вот как указать, например, индивидуальные CCFLAGS или FEATURES?

Дело в том, что это аналог, а не полная копия. Две разные директории ещё не страшно, если бы между ними можно было бы мигрировать обычным копированием. А синтаксис файлов всё же отличается, причём я бы сказал, что разница в синтаксисе введена намеренно...

Говорите, что читали документацию?

http://paludis.pioto.org/configuration/bashrc.html

О, ужас. Представляю на что будет похож этот файл при десятке другом условий для разных пакетов. А вообще, я про bashrc знаю. Он и в portage есть.

> Любая лишняя зависимость в идеале должна быть ликвидирован<s>на</s>. Ничего личного...

Несомненно. Но что такое "лишняя"? Давайте не будем использовать libc, а все нужные функции в каждом проекте реализовывать заново -- всё равно ведь вся libc в одном проекте полностью не используется, зачем лишняя зависимиость?

> Скрипт может быть достаточно надёжным, но важные вещи лучше делать программой.

"Какой вкусный ужин, но в важные моменты лучше есть еду."

Код в portage настолько суров, что для его упрощения приходится переписывать аналогичный функционал на cpp.

>Переехал с генты на Ubuntu и Debian! Не жалею! Фтопку эти компиляции сутками и бесполезный на анлиме дельтап! Фтопку эти проблемы при обновлениях! Фтопку этот тормознутые эмердж на пистоне! Фтопку недеделанные нерусифицированные системные утилиты и ман рисующий кракозябры. Фтопку revdep-rebuild и трахание с блокирующимися зависимостями! Фтопку постоянные пересборки ядра с жесктим контролем make xconfig, чтобы ничего не отвалилось. Фтопку-фтопку-фтопку это кривое красноглазое поделие в котором вечно что-то сломано, рассинхронизировано или положено на стандарты типа LSB!

>anonymous (*) (17.12.2007 16:10:12)

Еретик.

2argin ** (*) (17.12.2007 14:22:02):

>>> paludis пробует решить святую задачу - gentoo без python. Идеологически это правильно, лишняя зависимость не нужна, и такая важная системная функция должна выполняется не скриптом, а хорошо спроектированной программой.

Неправильная у Вас какая-то идеология. В топку такую идеологию, где выбрасывается высокоуровневный язык в угоду низкоуровневому только ради того, чтобы избавиться от 'лишней' зависимости.

'скрипт' и 'программа' -- это яблоки и апельсины.

Эк тебя сплющило-то... Не отпустить тебя чудо-трава даже на Убунте и Демьяне :)

Кривые беркановские ебилды уже перестали вгонять его в ступор?

>> Любая лишняя зависимость в идеале должна быть ликвидирован<s>на</s>. Ничего личного...

>Несомненно.

Вот мы друг друга и поняли. Думаю, что при наличии здравого смысла ответ и на вторую часть фразы найдётся без труда.

>Какой вкусный ужин, но в важные моменты лучше есть еду.

:-)

Но лучше ужин отдать врагу.

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

>> paludis пробует решить святую задачу - gentoo без python. Идеологически это правильно, лишняя зависимость не нужна, и такая важная системная функция должна выполняется не скриптом, а хорошо спроектированной программой.

>Неправильная у Вас какая-то идеология. В топку такую идеологию, где выбрасывается высокоуровневный язык в угоду низкоуровневому только ради того, чтобы избавиться от 'лишней' зависимости.

>'скрипт' и 'программа' -- это яблоки и апельсин

Базовая системная функциональность не должна реализовываться скриптами.

> Неправильная у Вас какая-то идеология. В топку такую идеологию, где выбрасывается высокоуровневный язык в угоду низкоуровневому только ради того, чтобы избавиться от 'лишней' зависимости.

Назвать С++ низкоуровневым языком - это 5.

> 'скрипт' и 'программа' -- это яблоки и апельсины.

Это демагогия.

Использую Paludis больше года. Впечатления:

1) Быстро работает. На экспериментальной системе с >1200 пакетов emerge -uDNp world выдает список пакетов через примерно 7 минут. Paludis - через 20 сек.

2) Некоторые проблемы при переходе. Файлы конфигурации - свои. Документированы не очень хорошо, хотя, в-основном, все понятно по примерам на сайте. Может работать с конфигурацией portage, хотя и ругается, что не все фичи поддерживаются. Для этого есть ключ --environment portage или можно просто удалить /etc/paludis.

3) Не удалось прикрутить deltup. В паре случаев очень нужно.

4) Более корректно, чем portage, работает с зависимостями. Удаление не используемых пакетов - намного быстрее и надежнее. Не дает удалять пакет, который кому-то нужен.

В целом, после доводки мог бы вытеснить emerge. На системах с большим кол-вом пакетов и часто обновляемых - просто необходим.

>Базовая системная функциональность не должна реализовываться скриптами.

ой, а инит до сих пор весь на скриптах, бегом переписывать /etc/init.d/* на С или лучше на ассме

> Базовая системная функциональность не должна реализовываться скриптами.

С каких пор portage или любой его аналог стали хоть как-то относится к системе??? Может Вам лучше почитать учебники?

Замечательный сайт по ссылке! Желаю ему долгой и счастливой жизни!

> Базовая системная функциональность не должна реализовываться скриптами. 

Базовая системная функциональность - это ядро.
Монолитные двоичные уродцы это не unix-way; не гибко, не стабильно и глубо.

>Support for repositories containing things other than ebuilds.

>Ability to manage packages even where no ebuild is available.

А portage так умеет?

apt

> Support for repositories containing things other than ebuilds.

Ну, в репозиториях много всякого "хлама" помимо ебилдов. Manifest'ы там всякие... :)

> Ability to manage packages even where no ebuild is available.

Portage сможет его снести или сделать из него бинарный пакет. Если постараться, то можно его пересобрать. Что ещё нужно?

смотри sys-apps/baselayout-2 и sys-apps/initng Да - на С

>1) Быстро работает. На экспериментальной системе с >1200 пакетов emerge -uDNp world выдает список пакетов через примерно 7 минут. Paludis - через 20 сек.

Что-то ты круто...

$ time emerge -puvDN world
...
real 0m28.308s

$ eix -Ic|wc -l
1849

paludis в этих условиях работал секунд по 10..15. Вообще, я ни на одной машине у себя не видел, чтобы он обгонял портеж более чем вдвое.

>смотри sys-apps/baselayout-2 и sys-apps/initng Да - на С

Гы.

$ eix -Ic baselayout
[I] sys-apps/baselayout (2.0.0_rc6@03.12.2007): Filesystem baselayout and init scripts

$ cat /etc/init.d/local
...
#!/sbin/runscript

$ cat /etc/init.d/consolefont
...
#!/sbin/runscript

И где тут Си в /etc/init.d/* ? :)

В baselayout2 не инит-скрипты на Си, а то, что их выполняет.