[solved] А как спокойно сделать emerge много-чего?

[user11]

Вот, к примеру, я ставлю систему, в т.ч. kde и прочие большие вещи.
Пусть у меня быстрый интернет или просто есть готовые distfiles.

Задача: выполнить с минимальным участием пользователя:
emerge --sync
emerge -ND world # Обновить старые пакеты (те, что были в комплекте изначально)
emerge куча пакетов
emerge еще куча пакетов
emerge еще куча пакетов

Как я понимаю, сначала надо дождаться завершения --sync (чтобы по два раза не ставить).
Потом, как я подозреваю, надо обновить старые пакеты, чтобы потом из-за их обновления ничего не сломалось (?)
Потом, как показал случайный опыт, попытка одновременной установки пакетов, имеющих общие зависимости, может вылиться в странные результаты (откуда-то берутся blocker-пакеты) - т.е. по крайней мере то, что зависит от kde, надо ставить после успешной установки kde.

По идее, проще всего ставить все это последовательно. На однопроцессорной машине в этом ничего плохого нет.

Однако дело осложняется тем, что что-то может не поставиться.

1. Если дать "emerge очень большая куча пакетов", то очень велика вероятность того, что где-то в середине или раньше установка прервётся на какой-нибудь ошибке - а то, что от этой ошибки не зависит, поставлено не будет. Этого хочется избежать.
2. Если писать "emerge что-то; emerge что-то ещё; emerge что-то там", то потом будет очень сложно узнавать, возникли ли где-то ошибки, и какие именно (ведь make генерирует тонны сообщений).
3. Если запускать все это в нескольких параллельных консолях, то получаем описанные выше проблемы с синхронизацией.

Как действовать? Не хочу чувствовать себя компьютерной приставкой

Попутно смежный вопрос: есть ли средство грубо оценить, сколько времени понадобится на установку чего-либо?
equery size, по-видимому, дает размер только для уже установленных пакетов (это совсем не то, что надо),
emerge -pv дает размер только для того, что еще не скачано.

Хотелось бы хотя бы видеть размер для неустановленных пакетов: для скачанных + нескачанных в сумме. Есть ли готовая утилита или опция?
Конечно, видеть ожидаемое время - это вообще идеально, но об этом я пока только мечтаю

[dmiceman]

по поводу серийной установки, наверное надо делать скриптик типа:

[user11]

здОрово. Мне так нравится

например...

#!/bin/bash
for i in "--sync" "-ND world" "kde licq что-то там еще что от kde зависит" pciutils gentoolkit strace ;
do
emerge $i || echo $i >>failed.log
done

ну просто супер!

[mango123]

[viy]

emerge -epv world

[lashzcore]

есть хороший скриптик update-world
почитать можно на http://www.gentoo.org/news/ru/gwn/20061204-newsletter.xml

[user11]

По поводу "грубо оценить, сколько времени понадобится на установку". А точнее, "на обновление".

Налабал коротенький (80 строк) ламерский ("у меня работает") скриптик на перле, который читает /var/log/emerge.log и засекает, сколько времени имеет тенденцию собираться каждый пакет, а потом суммирует по интересующим.
Теперь, чтобы оценить, сколько оно там ещё будет колупаться со сборкой, я могу сделать:

[_Sir_]

При первоначальной установке обычно стараются побыстрей выйти из chroot и livecd, но это не обязательно, если достаточно памяти. Я к тому, что минимально-работоспособная система может быть получена быстро. (Хотя я еще ни разу не пользовался инсталляторами gentoo, может быть они тоже часть задач решают)

В зависимости от этого, синхронизация с текущим деревом портежей (а не портов! - это термин xBSD) проводится либо в chroot'е, либо после минимальной инсталляции...

Дальше выбирается среда, в которой будете работать. К примеру десктоп-менеджер, что-то из мультимедии, средства разработки (помимо тех, что включены в system) сервера и/или сервисы, свистки и п... пардон, колокольчики) Далее можно прописать эти пакеты в world и воспользоваться (с обработкой ошибок) скриптом update-world, о котором выше уже шла речь. Но этот путь -- заимствован из бинарных дистрибутивов. Выгодное отличие gentoo в том, что можно добавлять необходимые (только!) компоненты на ходу. А вот этого преимущества многие не понимают. Не случайно есть переменная понижения приоритета emerge -- можно спокойно работать, обновление/досборка понадобившегося идет фоном. На самом деле есть несколько долгоиграющих пакетов -- gcc, glibc, gtk+ qt[34] wxGTK, kdelibs, kdepim... Остальное появляется в виде, пригодном для употребления, достаточно быстро. Поэтому: сборка -- это не самоцель. Трудно полностью загрузить современный процессор написанием статейки в форум русскоязычных пользователей Gentoo. А в это время потихоньку все обновлятся...
На самом деле, пока я вчера лазил по своим лит. делам, у меня обновилась система, кроме mplayer'а и realaudio -- качать надо новый плэйер, а пока не хочется.

И вообще, ни ос, ни набор софта на компьютере не являются самоцелью. Поэтому стремно слышать про "много много пакетов"! Их, между прочим, в портеже

[user11]

Да, видимо, у меня просто специфический этап пользования gentoo плюс специфический уровень запросов и ламерства.

_Sir_, спасибо за мнение, действительно очень ценно (как пример классического подхода к классической вещи), но, мне кажется, для меня описанные здесь проблемы актуальны, а решения полезны (и emerge в цикле, и estimate-emerge-time).

Всем спасибо за update-world - хоть ещё ни разу не воспользовался, но скрипт, безусловно, полезный, надо взять на вооружение и попытаться перейти на него с самопального цикла.

[fank]

[_Sir_]

Скриптик назывался porthole написан на python идеологически ошибочно опирается на gtk -- отсюда вечные глюки в работе. Но из всех гуевых приставок к portage единственно правильно сделан. При повторной компиляции время предполагаемой сборки пакет показывает.

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

С другой стороны, захотелось человеку посмотреть на показометр -- он это сделал теми средствами, какими получилось. Результат достигнут, потому что это -- юникс.
_________________
(Sir) * Life is placeholder for Love *