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

один фиг упираться в производительность файловой системы

В каком месте?

Для поиска зависимостей используют обход графа в ширину, что при небольшом количестве прямых зависимостей даёт практически линейную трудаёмкость. А если учитывать не такое уж и большое количество пакетов/портейжей/прочего, то это дело всего нескольких долей секунды. Задача разбора описательной информации занимает намного меньше времени её считывания из файла (даже если она лежит в БД). Так что основная проблема - это где и как хранится описательная информация и как быстро к ней можно получить доступ.

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

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

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

Вы утверждаете, что инновационных идей реализуемых на С++ в природе уже не осталось? На мой взгляд это слишком сильное утверждение :)))

A-234 ★★★★★
()

Код portage слишком сломан

«слишком сломан», лол.

спагетти-образного

зачем же тут дефис...

без какого-либо дизайна

очень по-русски написано, гм.

повсеместно и везде

ха-ха. масло масляное.

опирается на нестандартные уловки

опираться на уловки? интересное выражение.

огромные нарушения

очередное <<русское>> выражение, хи-хи.

никак не связанных областях

забыли «между собой».

внутренние переменные нелепы

что-что?

переменные ...не отражают реалии, которые код выполняет в настоящее время.

как переменные могут что-то отражать? как реалии могут быть «выполнены»?

в общем, за перевод — даже не 2, а кол.

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

Опять же прибавка времени копирования из ФС в рамдиск, опять тот же вид, только сзади. Только при каждом запуске будет запускаться то, что не всем нужно, и отжирать из памяти то, что можно не отжирать, ценой какого-то мифического «ускорения», которого может и не случиться. Не знаешь наверняка ведь маунт-структуру конкретной машины.

Ускорить можно только алгоритмически, абсолютно верно.

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

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

Из всех языков императивного программирования только Си без плюсов заслуживает восхищения, т.к. наиболее близок к аппаратуре компьютеров и поэтому полагаю, что Си переживет любые плюсы и go.

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

Так ничего и не поменялось с 2007 года :)

Лично меня portage всем устраивает, кроме синтаксиса и императивных языков для сценариев ebuild.

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

Зачем он выполняет работы на порядок больше? что это дает в результате? можно на конкретном примере пояснить?

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

там, где портаж ставит один пакет, палудис ставит 10! Что тут не понятного....

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

Потому что не нужно ничего там писать, всё есть в man emerge.

Ну и как продвигается отвязка пакетов от портажа, а также кто кроме председателей колхоза генту, предлагает альтернативные пакетодеревья.

Только лейман не предлагать. Пройденный проектом кде-свн этап, см. историю.

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

Очередное наступление на ООП, то нападки давайте заменим gcc на clang, то теперь а не заменить ли нам portage на изделие написанное на RIP-языке C++.

К чему бы это, написали бы новость, и без подколок в адрес portage must RIP. Это как раз RIP already С++ особенно 11й и надеюсь последний 11й его вздох ?

Шизофазия или просто наркоман?

А ещё ruby в интересах, как такое может быть - там же сплошное ненавистное ооп.

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

Последний баг портажа, который я отрепортил - зачем-то внутри портажа был пакетоспецифичный код. Это типичный результат работы совета председателей колхоза, т.н. Советы Генты, которым «лишь бы у соседа сдохло, зато мне хорошо». Сломанный интерфейс - это еще цветочки. Политика «закроем глаза вместо бага» - вот это жесть.

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

Ну и как продвигается отвязка пакетов от портажа

Что за «отвязка пакетов от портажа» и зачем она нужна?

кто кроме председателей колхоза генту, предлагает альтернативные пакетодеревья

Только лейман не предлагать

Деццкий сад.

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

Интересно, у тебя с русским языком плохо или с головой? А то я нихрена в твоей писанине понять не могу.

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

Зачем он выполняет работы на порядок больше? что это дает в результате? можно на конкретном примере пояснить?

Цель, чтобы можно было над голым стейджем или новой системой, с понятной конфигурацией, сделать «cave resolve world -ex» и отправиться делать дело. Понятная конфигурация - т.е. уже отлаженная. С неотлаженной придётся втыкать везде.

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

А ещё ruby в интересах, как такое может быть - там же сплошное ненавистное ооп.

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

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

не рекомендую начинать новые проекты на Си++ или других ООП языках

Я ошибался, это не контузия. Это фимоз.

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

Какие все злые стали на этом форуме, нужно больше сотрудничества, а не жестких слов. Цель то одна - сделать ПО лучше надежнее и проще. Может здесь менеджеры команд по распилу бюджетов тролят ? :)

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

Накопал.

Revision 1.2 - (view) (download) (annotate) - [select for diffs] Sun Jul 5 17:36:38 2009 UTC (3 years, 7 months ago) by vapier Branch: MAIN Changes since 1.1: +8 -8 lines Diff to previous 1.1 Switch from gen_usr_ldscript to the root_libdir that the package supports #276465 by Yury Vorobyov. (Portage version: 2.2_rc33/cvs/Linux x86_64)

Честно, не помню оно ли это. Но поскольку я ничего особого не майнтейню, то наверно оно.

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

Между двумя моими компами, изменения только в строке видеодрайвера. В идеале так и должно быть, меняется только то, что действительно изменилось. Кроме флагов(опций) это еще список таргет-пакетов, маски, кое-какая мелочь вроде того, что репки пакетов - тоже пакеты по сути.

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

> > один фиг упираться в производительность файловой системы

> В каком месте?

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

Быстро оно у вас :]

Как насчет для начала:

  • попарсить /etc/make.conf
  • /etc/portage/*
  • /usr/portage/profile/* (каталог размером 16MB, но юзается не весь)
  • убедиться, что /usr/portage/metadata/ соответствует ебилдам (stat storm), которые собираемся мержить
  • получить граф, затронутый обновлением используя DEPEND, RDEPEND, PDEPEND, package.mask (54KB), license_group и т.д.
  • убедиться, что нет ни одного нового возникшего блока (в полученном подграфе блоки не содержатся - их отдельно надо вычитать)

Можно позырить, чем он реально занимается:

python -m cProfile /usr/bin/emerge -pv <чего-надо>

Циферки (python3.2, не очень дохлая amd64 машина):

$ time emerge -pv sys-apps/gawk

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-apps/gawk-4.0.1::gentoo [4.0.1::__unknown__] USE="nls readline" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

real    0m14.568s
user    0m14.431s
sys     0m0.117s

# pypy для смеху:
$ time pypy-c2.0 /usr/bin/emerge -pv sys-apps/gawk

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-apps/gawk-4.0.1::gentoo [4.0.1::__unknown__] USE="nls readline" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

real    0m11.534s
user    0m11.341s
sys     0m0.174s

# без зависимостей
$ time emerge -pvO sys-apps/gawk

These are the packages that would be merged, in order:

[ebuild   R    ] sys-apps/gawk-4.0.1::gentoo [4.0.1::__unknown__] USE="nls readline" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

real    0m1.204s
user    0m1.144s
sys     0m0.056s

Больше секунды даже на стадии без обработки зависимостей. Графы получаются большими почти сразу. Особенно для несчастных python-овских пакетов с такими метаданными:

DEFINED_PHASES=compile configure install prepare test
DEPEND=dev-python/setuptools[python_targets_python2_5(-)?,python_targets_python2_6(-)?,python_targets_python2_7(-)?,python_targ
ets_python3_1(-)?,python_targets_python3_2(-)?,python_targets_python3_3(-)?,python_targets_pypy1_9(-)?,python_targets_pypy2_0(-
)?,-python_single_target_python2_5(-),-python_single_target_python2_6(-),-python_single_target_python2_7(-),-python_single_targ
et_python3_1(-),-python_single_target_python3_2(-),-python_single_target_python3_3(-),-python_single_target_pypy1_9(-),-python_
single_target_pypy2_0(-)] python_targets_python2_5? ( dev-lang/python:2.5 ) python_targets_python2_6? ( dev-lang/python:2.6 ) p
ython_targets_python2_7? ( dev-lang/python:2.7 ) python_targets_python3_1? ( dev-lang/python:3.1 ) python_targets_python3_2? ( 
dev-lang/python:3.2 ) python_targets_python3_3? ( dev-lang/python:3.3 ) python_targets_pypy1_9? ( dev-python/pypy:1.9 ) python_
targets_pypy2_0? ( dev-python/pypy:2.0 ) dev-python/python-exec[python_targets_python2_5(-)?,python_targets_python2_6(-)?,pytho
n_targets_python2_7(-)?,python_targets_python3_1(-)?,python_targets_python3_2(-)?,python_targets_python3_3(-)?,python_targets_p
ypy1_9(-)?,python_targets_pypy2_0(-)?,-python_single_target_python2_5(-),-python_single_target_python2_6(-),-python_single_targ
et_python2_7(-),-python_single_target_python3_1(-),-python_single_target_python3_2(-),-python_single_target_python3_3(-),-pytho
n_single_target_pypy1_9(-),-python_single_target_pypy2_0(-)]
DESCRIPTION=The new features in unittest for Python 2.7 backported to Python 2.4+
EAPI=5
HOMEPAGE=http://pypi.python.org/pypi/unittest2 http://pypi.python.org/pypi/unittest2py3k http://code.google.com/p/unittest-ext/

IUSE=python_targets_python2_5 python_targets_python2_6 python_targets_python2_7 python_targets_python3_1 python_targets_python3
_2 python_targets_python3_3 python_targets_pypy1_9 python_targets_pypy2_0
KEYWORDS=~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~amd64-linux ~ia64-linux ~x86-linux ~ppc-
macos ~x64-macos ~x86-macos
LICENSE=BSD
RDEPEND=dev-python/setuptools[python_targets_python2_5(-)?,python_targets_python2_6(-)?,python_targets_python2_7(-)?,python_tar
gets_python3_1(-)?,python_targets_python3_2(-)?,python_targets_python3_3(-)?,python_targets_pypy1_9(-)?,python_targets_pypy2_0(
-)?,-python_single_target_python2_5(-),-python_single_target_python2_6(-),-python_single_target_python2_7(-),-python_single_tar
get_python3_1(-),-python_single_target_python3_2(-),-python_single_target_python3_3(-),-python_single_target_pypy1_9(-),-python
_single_target_pypy2_0(-)] python_targets_python2_5? ( dev-lang/python:2.5 ) python_targets_python2_6? ( dev-lang/python:2.6 ) 
python_targets_python2_7? ( dev-lang/python:2.7 ) python_targets_python3_1? ( dev-lang/python:3.1 ) python_targets_python3_2? (
 dev-lang/python:3.2 ) python_targets_python3_3? ( dev-lang/python:3.3 ) python_targets_pypy1_9? ( dev-python/pypy:1.9 ) python
_targets_pypy2_0? ( dev-python/pypy:2.0 ) dev-python/python-exec[python_targets_python2_5(-)?,python_targets_python2_6(-)?,pyth
on_targets_python2_7(-)?,python_targets_python3_1(-)?,python_targets_python3_2(-)?,python_targets_python3_3(-)?,python_targets_
pypy1_9(-)?,python_targets_pypy2_0(-)?,-python_single_target_python2_5(-),-python_single_target_python2_6(-),-python_single_tar
get_python2_7(-),-python_single_target_python3_1(-),-python_single_target_python3_2(-),-python_single_target_python3_3(-),-pyth
on_single_target_pypy1_9(-),-python_single_target_pypy2_0(-)]

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

Кого это - вас? Несчастных копрофилов, у которых даже нормального пакетного менеджера нет?

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

Когда моя старая система умерла, я просто скопировал с неё make.conf и /etc/portage в новую (распакованный stage3), собрал ядро, ввёл две команды: emerge -e @installed (чтобы пересобрать уже имеющиеся в stage3 пакеты) && emerge kdebase-meta, и ушёл по своим делам. По возвращении мне оставалось доставить остальные нужные пакеты. Впрочем, если бы я на старой системе озаботился созданием сета, включающего всё нужное мне ПО, можно было бы обойтись и без доустановки остальных пакетов.

Между двумя моими компами, изменения только в строке видеодрайвера

И что? Меняешь строку VIDEO_CARDS в make.conf и делаешь emerge -uDN @world. Портеж пересоберёт только те пакеты, которые затрагивает изменение этой строки.

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

Парсинг /etc/make.conf и /etc/portage - это доли секунды. А дальше - кривая организация данных. Те же метаданные бинарно-компилированными в одном файле кто держать мешает, как и *DEPEND? При аккуратной организации там для всего дерева в памяти это займёт мегабайт 10.

От фильтровать по маскам/лицензиям - охренеть какая сложная задача, угу.

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

Да, C проще плюсов. Другое дело, что в С приходится городить огород из указателей на функции, понимая что фактически это виртуальные методы которые в С отсутствуют в явном виде. А уж от использования такой замечательной штуки как exception придется отказаться сразу. С++ только похож на С, и это создает иллюзию того, что подходы к проектированию используемые в С подойдут и для плюсов, что конечно не верно. В этом случае пишите изначально на С, иначе кроме разочарований в С++ ничего не получите.

A-234 ★★★★★
()

Список файлов

вот смотрю я на список файлов:
http://bpaste.net/show/75205/

и думаю - для того, чтобы изучить paludis - достаточно прочитать man cave?

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

Как же авторы проекта nginx обходятся без плюсов ? Или они глупее нас с Вами ?

http://nginx.org/ru/ https://github.com/nginx/nginx

Или им не надо в их задачах обрабатывать исключения и ошибки ?

PS. Разочарование в ООП и в C++ и во всех языках подобных С++ я давно получил, но оно не мешает мне доводить до кондиции то, что накодили программеры в области финансовых систем. Смотрю с оптимизмом за развитием функционального программирования идущего на смену умершему императивному.

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

То, что в *bsd в ports .Makefile то в gentoo <name>.ebuild

Заметно отличается синтаксисом, и главный плюс после bsd (я freebsd долго пользовался), что для изменения условий сборки не нужно отвечать на диалоговые вопросы как во freebsd.

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

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

Смотрю с оптимизмом за развитием функционального программирования идущего на смену умершему императивному.


Теперь понятна причина вашего разочарования, С++ это не императивное а объектно-ориентированное программирование. Императивное это С. Еще раз, на С++ можно писать как на С, но виноват будет в итоге кодер а не язык.

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

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

по идее больший просчёт зависимостей должен давать более чистую систему/с меньшим количеством конфликтов

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

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

Или это не брать в расчет ?

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

Поправьте меня если я ошибаюсь.

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

что тебе ясно ? хочешь знать подробности - см исходники

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

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

А дальше - кривая организация данных. Те же метаданные бинарно-компилированными в одном файле кто держать мешает, как и *DEPEND?

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

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

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

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

От фильтровать по маскам/лицензиям - охренеть какая сложная задача, угу.

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

sf ★★★
()

Paludis
Exherbo
Cave

Кто все эти люди? Ненужно.

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

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

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

А я что писал ? Читать умеете ?

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

Недостатки ООП ничем не отличаются от недостатков программирования на чистом Си, те же имеются, да еще новые прибавились всего лишь. Поэтому для меня ООП в плане недостатков частный случай чистого императивного программирования, а объекты просто лишние абстракции - в целом ООП неудачная попытка обойти недостатки чистого чистого Си, вместо того чтобы тратить силы на правильное направление - ФП. Два старых треда ложных есть в выч. технике это x86 и ООП, их пора захоронить и взяться за то, что эффективнее ARM и ФП.

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

для меня ООП в плане недостатков частный случай чистого императивного программирования, а объекты просто лишние абстракции

Тяжёлый случай, да.

в целом ООП неудачная попытка обойти недостатки чистого чистого Си

ООП появилось когда С даже в планах не было, лол.

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

вместо того чтобы тратить силы на правильное направление - ФП. Два старых треда ложных есть в выч. технике это x86 и ООП, их пора захоронить и взяться за то, что эффективнее ARM и ФП

Весело, наверное, жить напару с шизой, да?

Kindly_Cat
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.