Portage + deb пакеты

А нафига? zlib собирается за 5-10 секунд, втрое больше уходит на работу самого тормоза-portage.

У меня была другая идея, в rpm-spec так-же как и в ebuild обычно бывают параметры сборки, и вообще эти вещи весьма близки. Идея была средствами портков генерить rpm-spec(с учетом USE) и по нему компилить rpm. Устанавливать уже rpm.

Наверное это возможно и для deb, но с ним я мало знаком.

Что-то вроде нескольких backend для портков.

А где тормоза то? Цифры в студию!

Наверно и с rpm можно - прикрутить portage на шляпу.

Мне интересно обратное. Просто генту девелоперы давно говорили о поддержке бинарников, а они то есть в виде deb/rpm пакетов. Просто надо чтоб USE флаги поддерживались каким то образом. Можно например прописать что если какие-то стандартные USE то ставится бинарь. Иначе как обычно.

>А где тормоза то? Цифры в студию!

Я ни чего такого не говорил.

Я говорил скорее о gentoo, как-раз поддержка бинарников, поддержка зависимостей при удалении, поддержка зависимостей от use флагов.

> А где тормоза то? Цифры в студию!

Есть известная проблема у портажей: при запуске команды emerge происходит чтение кучи мелких файлов с диска, из-за этого возникают неслабые тормоза. Дело тут не в питоне, как многие любят говорить, а в неэффективности современных файловых систем.

# time ebuild /usr/portage/sys-libs/zlib/zlib-1.2.3.ebuild clean unpack compile install

real 0m12.121s
user 0m9.420s
sys 0m2.595s

# time emerge zlib

real 1m15.083s
user 0m12.719s
sys 0m4.581s

# time emerge zlib

real 0m13.725s
user 0m10.616s
sys 0m2.743s

При первом запуске emerge zlib на работу портажа ушло около минуты. При повторном запуске всё нужное было в кэшэ => скорость работы резко возросла.

> Можно например прописать что если какие-то стандартные USE то ставится бинарь.

А как быть с бинарной (не)совместимостью? :) У всех ведь разные версии gcc и разные версии библиотек. Грабель имхо необерёшься.

Версии библиотек и так в зависимостях, а с gcc не особо страшно. Как-то ведь бинарные дистры живут =)

В бинарных дистрах версия gcc и основных библиотек не меняется в течении жизни релиза. И для каждого релиза приходится поддерживать свой репозиторий пакетов. Юзеры gentoo не это вряд ли согласятся. =)

Не, на Fedora 5.9 без проблем ставятся rpm от Fedora 4, можно и от чего еще, но там обычно нужно с --no-deps, так-ка зависимости все именуют как хотят =)

Разные репы держат не из-за этого.

>Дело тут не в питоне, как многие любят говорить, а в неэффективности >современных файловых систем

А откуда такой вывод?
возможно дело в неэффективности алгоритма,
и нужные файлы нужно хранить в какой-нибудь встроенной БД?

> А откуда такой вывод?

Ну так при повторном запуске все тормоза пропадают как по волшебству. Значит, дело в ФС, другого объяснения я не вижу. Встроенная БД, наверное, помогла бы.

> Ну так при повторном запуске все тормоза пропадают как по волшебству

это называется кэш :)

> это называется кэш :)

А я разве с этим спорил, друг? :P

это проблема emerge, а не ФС.

нет единого кэша со списком пакетом, как в apt.

>Ну так при повторном запуске все тормоза пропадают как по волшебству. Значит, >дело в ФС, другого объяснения я не вижу.

Я не утверждаю, что в данный момент не работа с ФС узкое место emerge,

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

В портажах есть свой кеш: /var/cache/edb. То есть emerge -p gnome первый раз займет кучу времини на Calculating dependencies, а второй раз все будет почти мгновенно:

# rm -rf /var/cache/edb/*
# reboot
# time emerge -p gnome

real 2m30.274s
user 1m37.642s
sys 0m32.994s


# reboot
# time emerge -p gnome

real 0m9.232s
user 0m1.908s
sys 0m0.244s


# rm -rf /var/cache/edb/*
# reboot
# time emerge -p gnome

real 2m27.973s
user 1m35.954s
sys 0m33.446s

Так что фс и кеш кернела тут особо непричем. Кешируются зависимости и т.д. Фс у меня кстати reiser. Спроведливости ради /usr/portage у меня на nfs на сервере. Кто нить проверте на xfs и ext3 пожалуйста для полноты так сказать.

>В портажах есть свой кеш: /var/cache/edb. То есть emerge -p gnome первый раз >займет кучу времини на Calculating dependencies, а второй раз все будет почти >мгновенно:

Так речь о том чтобы в первый раз пару секунд работать, а не 2 минуты.
Это просто ужасно долго 2 минуты, это же не научные вычисления,
за сколько apt или yum в данном случае отработают?

Дык "первый раз" это при установке системы. К тому же это как раз вычесления: посчитать последние версии и их зависимости. Хотя я думаю есть способы ускорить процесс.

>Дык "первый раз" это при установке системы

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

>К тому же это как раз вычесления: посчитать последние версии и их зависимости.

обсчитать граф (сколько зависимостей у гноме, скажем 500) это теперь "вычисляния" называется на современных машинах?

>нет, это происходит каждый раз при первом запуске emerge на только что загруженной машине.

Читай мой пост еще раз (лучше два): после второй перезагрузки emerge -p gnome занял 9 секунд. КЕШ КЕРНЕЛА ТУТ НЕ ПРИЧЕМ!

>обсчитать граф (сколько зависимостей у гноме, скажем 500) это теперь "вычисляния" называется на современных машинах?

Ну скажем это поиск по своеобразной базе данных. Сначала данные надо считать в память (быстро), потом разобратся с зависимостями (операция по доступу к данным в памяти - не сильно быстро), потом разбор версий - чисто математическая задача (if (2.9 > current_version)..... - медленно).

>после второй перезагрузки emerge -p gnome занял 9 секунд.

и что твои данные истина в последней инстанции?
$time emerge -pv xfce4
...
real 0m2.032s
user 0m0.840s
sys 0m0.092s

$reboot
$time emerge -pv xfce4
real 0m31.458s
user 0m0.824s
sys 0m0.264s

в 15 раз дольше после перезагрузки.

>Ну скажем это поиск по своеобразной базе данных.

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

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

>и что твои данные истина в последней инстанции?

Нет конечно, но сравни с тем что ты получишь если удалишь /var/cache/edb/*. Как сам видишь у меня была прибавка в 16.67 раз.

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

Не знаю, может я терпеливее :))

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

Да но если делать как в Debian то теряются USE Flags, а это очень не интересно. Как я уже сказал: наверняка можно и быстрее, но я и так доволен. Если бы был недоволен - перешел бы на что-то другое.

>Нет конечно, но сравни с тем что ты получишь если удалишь /var/cache/edb/*. Как >сам видишь у меня была прибавка в 16.67 раз.

30 секунд еще на 16, нет спасибо.

Создать кеш:
emerge --metadata
Запускать один раз после каждого обновления портажа.

>Запускать один раз после каждого обновления портажа.

он и так создается.

>Запускать один раз после каждого обновления портажа.

а смысл,

--metadata
Causes portage to process all the metacache files _as is normally done on the tail end
of an rsync update using emerge --sync. _

т.е. это и так происходит после каждого emerge --sync, зачем пересоздавать кэш повторно.