У меня 2000 пакетов и portage проверяет зависимости перед установкой каждого пакета около 5 минут

Проблема известная, решения как такового нет. Можно ускорить запихивая portage в squashfs, кеш в sqlite, но всё это полумеры.

И ещё появляются (перед вопросом об установке) куча сообщений QA Notice: 'grep' called in global scope: категория/ебилд-версия

Это - на багзиллу, пинать мэйнтэйнеров

сквош не даёт никакого профита
абсолютно
ибо на фоне считалок время на чтение файлов просто теряется
а вот скулы рулят

QA Notice: 'grep' called in global scope: категория/ебилд-версия

просто разрабы дегенераты - эти сообщения нужны только разрабам
хотя эта херь реально работает криво донельзя - оно ругается даже на те ебилды в которых ни грепа ни седа нет и в помине
потому я сделал так

[ megabaks@desktop ] ~ $ cat /var/portage/patches/sys-apps/portage/shit.patch 
--- orig/portage-2.1.11.30/bin/ebuild.sh	2012-10-18 10:39:51.000000000 +0400
+++ fixed/portage-2.1.11.30/bin/ebuild.sh	2012-10-21 06:20:24.000000000 +0400
@@ -438,6 +438,7 @@
 	QA_INTERCEPTORS="autoconf automake aclocal libtoolize"
 fi
 # level the QA interceptors if we're in depend
+unset QA_INTERCEPTORS
 if [[ -n ${QA_INTERCEPTORS} ]] ; then
 	for BIN in ${QA_INTERCEPTORS}; do
 		BIN_PATH=$(type -Pf ${BIN})
[ megabaks@desktop ] ~ $

[ root@desktop ] megabaks # time emerge -p hostapd

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

Calculating dependencies... done!
[ebuild  N     ] net-wireless/wireless-regdb-20130213 
[ebuild  N     ] dev-libs/libnl-3.2.21  USE="-doc -static-libs -utils" 
[ebuild  N     ] dev-python/m2crypto-0.21.1-r1  USE="-doc -examples" PYTHON_TARGETS="python2_7 -python2_5 -python2_6" 
[ebuild  N     ] net-wireless/crda-1.1.3 
[ebuild  N     ] net-wireless/hostapd-2.0  USE="crda ssl wps -debug -ipv6 -logwatch -madwifi" 

real	0m5.343s
user	0m5.247s
sys	0m0.092s
[ root@desktop ] megabaks #

у тебя явно что-то не так

И ещё появляются (перед вопросом об установке) куча сообщений QA Notice: 'grep' called in global scope: категория/ебилд-версия

https://www.google.com/search?q='QA Notice: 'grep' called in global scope:'&a...

portage проверяет зависимости перед установкой каждого пакета около 5 минут

он (portage) медленный (читай «написан плохо»). это давно известно.

на лоре гдето был тред, где пользователи меряются. Там оказалось две группы «пользователей»: тормозит и очень тормозит (как у тебя). Как всегда причина не установлена.

у меня тоже «очень тормозит»

Ждем в треде init_6 и его возгласы о том что squash&aufs все заруливают

ps: python здень не причем

это не на багзиллу надо - это к психиатру надо отправлять дебилов из рядов генту-разрабов
Вс. окт. 21 06:24:11 MSK 2012
это дата создания патча
это когда уже лопнуло моё терпение

он сольёт - сквош для лохов - он ничего не решает

возможно, я не тестил его. но вот кеш в sqlite тоже не помогает. как минимум мне. думаю что и ТСу тоже

Какая у тебя версия портейджа?

Внезапно из 5 минут (указывал свои флаги, потом пробовал твой - без разницы) стало 25 секунд. И 10 на основном компе. Как так? Он создаёт кеши, что ли?

Я не понял про sqlite. Там хранятся ебилды или графы зависимостей? Т.е. это поможет только при проблемах с дисковой подсистемой (коих у меня нет) или в любом случае (влияет именно в расчет зависимостей, а не на чтение)?

всегда распоследняя из ~
сейчас
sys-apps/portage-2.1.11.59
app-portage/gentoopm-0.2.8

А железо то нормальное? А у то тут есть всякие, которые генту на нетбуках юзают на атоме (без distcc и прочих хитрых хаков) и ноют, что портаж и компиляция очень-очень тормозит.

внезапно, да, портаж создаёт кэш рассчитанных зависимостей
лежит в /var/cache/edb/dep

А app-portage/gentoopm тебе на кой хер?

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

ибо есть лайф-пакеты
а для их нормального обновления нужен smart-live-rebuild
таки дела

думаю дело не в железе. ноут на core2duo (t5600) 6летней давности

если у тебя они рулят - я за тебя рад. у меня они не рулят

жду результатов с и без

Ждем в треде init_6 и его возгласы о том что squash&aufs все заруливают

ZuBB

• во первых {смотри/ищи/делай сам} тесты на чтение всяких фс включая squash
• во вторых в шустром палудисе который на шустрых сях а не на этих их «педонах» все на поверку оказывается ВНЕЗАПНО тоже не так шоколадно как должно быть по идее
• и наконец в третьих - если действительно есть проблема то решать нужно начинать вон оттуда «Please clone it, play with it, make it better, and let's turn this into the next version of Portage» © Daniel Robbins - portage-classic

У меня 2000 пакетов

0_0 Что у тебя такого стоит? KDE + Libreoffice + Opera + Mozilla + apache + php + subversion + mplayer + torrent + всего по мелочи = ~1000 пакетов. Ты явно обленился USE-флаги ковырять.

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

Только не говори что ты смотришь по какому-то KDE'шному виджету. top/htop что показывает?

Все-таки вангую, что проблема именно в дисковой системе. В последнее время на ноутах ставят мега-тормознутые HDD. Сравни выхлопы hdparm -t на обоих своих компах (только повтори команду раза 3, так в манах рекомендуют). Еще посмотри SMART на предмет ошибок. Убедись что hdparm -M выдает 254. (Невключенный DMA уже стал историей, а от NCQ я что-то профита не замечал).

Либо памяти мало. Что показывает free после такого просчета? Сколько занято swap'а?

Пока так.

Ах да… Багзилла у генты вон там Gentoo's Bugzilla а сами баги оформлять как то так Gentoo Bug Reporting Guide

И успехов!

вообще-то портаж реально сжирает только 1 ядро

да не волнуйся ты так. все хорошо.

во первых {смотри/ищи/делай сам} тесты на чтение всяких фс включая squash

возможно когда-нибуть

во вторых в шустром палудисе который на шустрых сях а не на этих их «педонах» все на поверку оказывается ВНЕЗАПНО тоже не так шоколадно как должно быть по идее

1. палудисом никогда не игрался. 2. на форуме это я видел несколько раз. оспаривать не собираюсь

и наконец в третьих - если действительно есть проблема то решать нужно начинать вон оттуда «Please clone it, play with it, make it better, and let's turn this into the next version of Portage» © Daniel Robbins - portage-classic

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

и да, если у тебя squash&aufs все заруливает - то я действительно рад за тебя. просто IMHO ты очень навязчиво об этом на каждом углу говориш

Ах да… Багзилла у генты вон там Gentoo's Bugzilla а сами баги оформлять как то так Gentoo Bug Reporting Guide

Чего так грубо? Я тебя вообще не кастовал, про багзиллу я знаю, регулярно пользуюсь. Я не могу там оформить такой баг, т.к. совершенно не понятно, к чему именно именно я придираюсь (ну что я напишу? что тормозный портаж у меня СЛИШКОМ тормозный?), и абсолютно понятно, что ничего делать они не будут. Из этого треда я понял только то, что у меня проблемы не критичные, и что нужно попробовать скулайт, а на палудис рано пока переходить.

и да, если у тебя squash&aufs все заруливает - то я действительно рад за тебя

Все дело в том что у меня по сравнению с ТС гораздо большее время занимает сам процесс сборки нежели расчет каких то там зависимостей.

И да я несказанно рад за всех обладателей железа из списка top500 у кого вдруг возникла такая проблема… А так же моя радость распространяется и на всех тех у кого сама сборка pypy/openoffice/libreoffice занимает меньшее время чем расчет их зависимостей.

И да - это печально! Давайте что то делать!

скорее всего завтра.

Я знаю. Но не 5 минут же. У него 486DX2 или все-таки уже DX4?

Я не могу там оформить такой баг, т.к. совершенно не понятно, к чему именно именно я придираюсь (ну что я напишу? что тормозный портаж у меня СЛИШКОМ тормозный?), и абсолютно понятно, что ничего делать они не будут.

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

http://i.imgur.com/UZxTcp0.jpg

кто-то считает что это нормально?

ps: ноут припомнен выше

хм...у меня опять 5 сек http://ompldr.org/vaHhuaw

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

И вообще, пора призвать Торвальдса с факом животворящим.

англицкий есть. что писать?

Пусть лучше он и дальше ядро ведет. там о него будет пользы больше.

а генту-разрабы/шники должны сами поумнеть. иначе ихнему дистро быстро придет песец

тут уже была дискуссия https://bugs.gentoo.org/show_bug.cgi?id=431484

Some of the performance difference for Portage is related to that fact that it's possible to modify ebuilds at any time, and Portage is expected to detect these changes automatically and account for them. The makes access to the available package database somewhat less efficient than it would be for something like Debian APT.

дискуссия

:)

надеюсь финальный ответ ты читал

I think the existing repository layout and database/cache formats are pretty optimal for development-oriented scenarios. If you we support both development-oriented and consumer-oriented scenarios simultaneously, then conflicting goals will lead to sacrifices that negatively impact both kinds of users. So, I think it would be optimal to introduce an entirely separate repository layout and database/cache format for the consumer-oriented scenario. This has been discussed previously as a proposed GSOC project:

http://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Repository_of_se...

мое мнение такое: нужно представить работающую альтернативу. а дальше народ сам выберет. благо в генту свобода выбора пока? еще есть

Ну есть же pkgcore и paludis. Иногда даже работающее. Только народ не спешит бросать portage.

Сделай emerge --sync ; layman -S . После этого замерь время ещё раз. Судя по всему я понял (по постам в багзилле по ссылке выше), в чём проблема.

вангую: в него будет все ок

и еще раз вангую: layman (и наличие/отсутствие оверлеев) здесь ни причем

Иногда даже работающее

ключевой момент

real 0m5.302s
и в чём же дело?
в emerge --metadata?

в 42ухнаверно сейчас будет шокируюшая правда о генту

правда?
ну хз - попробовать
FEATURES=«metadata-transfer»
для синка
и после синка
emerge --metadata
это пожалуй единственное «странное» что я делаю в этом плане

да ничего не будет. у тебя же ничего не изменилось. было 5сек и осталось 5сек.

но у меня на автомате это используется...
не, проверил - это точно не влияет

Хер. У меня не удается повторить опыт. Однако, я точно могу сказать, что время без кэша метаданных (например, после emerge --sync без emerge --metadata) в 2 раза больше времени с ним.