LINUX.ORG.RU

Вышел Paludis 1.0

 , ,


0

3

Состоялся релиз Paludis 1.0, менеджера пакетов для Gentoo и производных дистрибутивов, написанного на С++. Состоит из основной библиотеки и ряда консольных клиентов.

  • Paludis — менеджер программных пакетов, применяется в ОС Exherbo и, в качестве альтернативы portage, на Gentoo. В активном развитии с января 2006 года.
  • Изначально Paludis представлял собой инструмент для разрешения проблем с зависимостями и использовался в дополнение к системе portage в Gentoo GNU/Linux. Однако позже, не в последнюю очередь ввиду разногласий между разработчиком и комитетом Gentoo, превратился в самостоятельную систему управления пакетами. В качестве причин фигурируют: бюрократия Gentoo, ошибки в дизайне, неполноценность/избыточность и запутанность исходных кодов emerge, личный эгоизм некоторых участников комитета Gentoo, страх перед изменениями.
  • После долгой разработки, начиная с версии Paludis 0.60.0 клиент paludis и все поставляемые с ним утилиты были заменены на значительно более понятный клиент cave. Сave можно кратко охарактеризовать как: «Клиент доступа ко всем возможностям системы paludis, схожий по дизайну с aptitude, а синтаксисом с git». Система по-прежнему носит название «Paludis», но клиент paludis и все утилиты были убраны.

Почему бы не исправить portage?
Код portage слишком сломан, чтобы его можно было исправить. Это огромное месиво спагетти-образного процедурного кода без какого-либо дизайна. Он повсеместно и везде опирается на нестандартные уловки, поэтому любое изменение способно вызвать огромные нарушения работоспособности в, казалось бы, никак не связанных областях. Он практически целиком недокументирован, внутренние переменные нелепы и часто уже не отражают реалии, которые код выполняет в настоящее время.
— Ciaran McCreesh

>>> Подробности

★★★★★

Проверено: Pinkbyte ()
Последнее исправление: Silent (всего исправлений: 3)

Ответ на: комментарий от Kindly_Cat

1967 год не в счет, ООП тогда не вылез за рамки одного проекта, только с приходом С++ выродился монстр ООП. Польза в какой-то степени была от ООП, но только одна - чтобы уже снова не возвращаться к нему в будущем :)

Deleted
()
Ответ на: комментарий от Kindly_Cat

Ты из себя мудреца в генту-то не строй.

anonymous
()
Ответ на: комментарий от Deleted

Еще что-то говорили про издержки ООП и компилятора с C++ vs С.

Издержки только при использовании exceptions, которые можно минимизировать в релизе.

ООП - частный случай императивного программирования.

Не будем начинать спор по этому поводу, вы ведь обламываетесь с С++ а не я.

A-234 ★★★★★
()
Ответ на: комментарий от A-234

ведь обламываетесь с С++ а не я.

Странное умозаключение.

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

Настоящее и будущее за декларативным программированием и частным его случаем ФП для меня это тоже очевидно.

Deleted
()
Ответ на: комментарий от Kindly_Cat

Ты на протяжении всего треда делаешь какие-то маркетоидные туманные намёки на «разные стратегии разрешения зависимостей» и «тысячи проверок, выполняемых paludis'ом»

для этого достаточно просто прочитать руководство - делается командой man cave-resolve.

С чего ты взял, что мне интересно троллить ?

argin ★★★★★
()
Ответ на: комментарий от argin

man cave-resolve

Предлагаешь мне спецом для этого поставить paludis?

С чего ты взял, что мне интересно троллить ?

Приводить аргументы в обсуждении - это у тебя «троллить»? Ок, всё ясно.

Kindly_Cat
()
Ответ на: комментарий от Kindly_Cat

маркетоидные туманные намёки на «разные стратегии разрешения зависимостей»

git.exherbo.org/paludis/paludis.git/tree/paludis/solver

Как очевидно, разрешение дерева - самая толстая часть, которая не только предлагает линейный набор дерева, но и разные компоненты связности, сброс циклов (рестарты).

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

sanaris
()
Ответ на: комментарий от sf

На диске или в памяти?

На диске, строить при обновлении дерева.

В одном файле обновлять метаданные неудобно. В текущей схеме вообще ничего не нужно синхронизировать.

Очень удобно - десериализовали в память - обновили что надо - сеиализовали обратно. Объемы там копеечные.

Какую операцию Вы этим собираетесь ускорить? eix-update на моей машине работает 2 секунды (строит такой бинарный кэш).

Вы это указали как один из этапов разреления зависимостей. Если у вас получается всё прочесть за 2 секунды при этом - можно и не делать, конечно.

Что будете делать при изменении формата *DEPENDs? (новый EAPI) eix выпускает новую версию и перестраивает кэш.

Ну вот ровно то же и буду делать. Я этот бинарь именно как кэш и имею в виду.

Нормальная. Маски приводят к изменению построения плана разрешения зависистей. Знаете что делает опция --backtrack= в emerge?

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

crazy_alex
()
Ответ на: комментарий от crazy_alex

> Что будете делать при изменении формата *DEPENDs? (новый EAPI) eix выпускает новую версию и перестраивает кэш.

Ну вот ровно то же и буду делать. Я этот бинарь именно как кэш и имею в виду.

ok, это улучшит ввод/вывод на фрагментированном дереве. Если решение eix устраивает, то http://en.gentoo-wiki.com/wiki/Portage_SQLite_Cache + pypy будет уже близким к желаемому.

> В одном файле обновлять метаданные неудобно. В текущей схеме вообще ничего не нужно синхронизировать.

Очень удобно - десериализовали в память - обновили что надо - сеиализовали обратно. Объемы там копеечные.

Это избавит только от чтения метаданных пакетов. От stat() на файлы используемых метаданных и *.ebuild не избавит.

Что интересно, (не таким эффективным, но того же порядка) кэшем может являться код файловой системы. Если хранить /usr/portage (и /var/db/pkg/) в маленьком loop device (скажем, порядка 1GB), то можно ускорить работу не только чтения метаданных, но и чтения/обновления ебилдов при emerge --sync. Циферки: http://hackie.blog.tut.by/2012/11/17/turbo-boost-emerge-sync-and-cvs-up-on-ge...

> Нормальная. Маски приводят к изменению построения плана разрешения зависистей. Знаете что делает опция --backtrack= в emerge?

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

Вся работа portage и paludis состоит из одних «копеечных операций»:

python -m cProfile /usr/bin/emerge -pvuDN @world | sort -k4 -n -r

perf record cave resolve world
perf report

Ничего не надо вычитать. Граф обсекается по мере обхода. Зачем обходить 2 раза, если можно один? Зачем фильтровать то, до чего никогда не доберемся? (маски неустановленных пакетов).

При невозможности резолва юзеру бы неплохо объяснить по каким причинам все варианты отвалились.

Ну и, маски и блокировки пристутствуют в самих выбранных пакетах:

util-linux-2.22.2.ebuild:
RDEPEND="!sys-process/schedutils
        !sys-apps/setarch
        !<sys-apps/sysvinit-2.88-r4
        !sys-block/eject
        !<sys-libs/e2fsprogs-libs-1.41.8
        !<sys-fs/e2fsprogs-1.41.8

sf ★★★
()
Ответ на: комментарий от Kindly_Cat

Приводить аргументы в обсуждении - это у тебя «троллить»? Ок, всё ясно.

всё зависит от самих вопросов - в твоём случае не было интереса к вопросу, был только троллинг.

Предлагаешь мне спецом для этого поставить paludis?

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

argin ★★★★★
()
Ответ на: комментарий от argin

в твоём случае не было интереса к вопросу, был только троллинг

Никакого троллинга не было. Я весь тред пытался вытянуть из тебя инфу, но ты встал в бугуртову позу.

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

То есть беседы ты избегаешь. Ну и ладно. Всё понятно.

Kindly_Cat
()
Ответ на: комментарий от Kindly_Cat

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

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

argin ★★★★★
()
Последнее исправление: argin (всего исправлений: 1)
Ответ на: комментарий от sf

а зачем нам куча stat, если обновление метаданных всё равно делается соотвествующей командой, которая и должна обновлять кэш? тут кэш - даже, пожалуй, неправильное определение. Надо говорить об исходниках дерева, лдя которого при получении создаётся компилированная версия. И на исходники только emerge --sync layman -s и что-то, чем заменится ebuild digest смотреть должны.

И, судя по тому, что просто на поиск нужного пакету уходит секунд 5 (допустим, я даю emerge sys-apps/man-pages, и примерно через столько появляется «Calculating dependencies...») - то ли индексы кривые и ебилд так должго ищется, то ли оно действительно столько времени вычитывает свои данные. Это на sqlite cache как раз.

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

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

crazy_alex
()
Ответ на: комментарий от naryl

Собирал в последнее время PostgreSQL+PostGIS и OpenLDAP+BerkeleyDB - времени на первое конечно много угрохал, но сказать, что ради таких специфических потребностей нужно прямо аж спецдистрибутив ставить - это всё равно, что утверждать об исключительной пользе забивания гвоздей микроскопом.

DRVTiny ★★★★★
()
Ответ на: комментарий от crazy_alex

а зачем нам куча stat, если обновление метаданных всё равно делается соотвествующей командой, которая и должна обновлять кэш?

Ебилды руками патчить никто не запрещает, а даже поощряет. У меня $PORTDIR на cvs дерево gentoo-x86 указывает. Так проверять ебилд перед коммитом проще.

И, судя по тому, что просто на поиск нужного пакету уходит секунд 5 (допустим, я даю emerge sys-apps/man-pages, и примерно через столько появляется «Calculating dependencies...»)

Оверлеи включены? Если CPU=100% и в top висит ebuild.sh, то помогает генерация метаданных для всех оверлеев:

В /etc/eix-sync.conf можно такую фигню добавить:

*
@egencache --jobs="$(($(nproc) + 1))" --repo=overlay-name-1 --update
...
@egencache --jobs="$(($(nproc) + 1))" --repo=overlay-name-N --update

Если тормозит на вводе/выводе, то можно пробовать sqlite кэш (или маленький loop), пока CPU на 100% не начнет загружаться :].

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

Такая спека называется PMS: http://dev.gentoo.org/~ulm/pms/head/pms.html

Ее всю можно не реализовывать, а только добавить функциональность от EAPI=1 до EAPI=3, чтобы не париться со всякими REQUIRED_USE, SUBSLOTs и прочей модной фигнёй.

sf ★★★
()
Последнее исправление: sf (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.