[devel] Python 2.6: task #16528

[Alexey Tourbin]

On Thu, Nov 26, 2009 at 12:02:45PM +0300, Alexey Tourbin wrote:
> On Wed, Nov 25, 2009 at 02:12:13PM +0700, REAL wrote:
> > Поскольку сборка более 600 пакетов - дело 
> > очень долгое (на сборку не самых 
> > монстроидальных 200 пакетов 
> > потребовалось около 12 часов), возможно, я 
> > попытаюсь в этой задаче всё собирать до 
> > упора, таким образом, надеюсь, именно она 
> > и станет рабочей, из которой в сизиф 
> > пролезет python 2.6.
> > 
> > Чтобы дело пошло быстрее (сбои ещё будут, 
> > т.к. там не все пакеты), большая просьба 
> > пакеты из задачи пока не обновлять, чтобы 
> > потом не пришлось начинать сборку заново.
> > 
> > http://git.altlinux.org/tasks/16528/task/log.2
> 
> У нас очень долго выполняется фаза "no need to rebuild", в среднем
> не менее минуты на пакет.  Всё это конечно не планировалось что людишки
> будут заливать пакеты целыми сотнями.  Но есть то что есть -- мы так
> никуда не уедем.

> Я попробовал запрофилировать почему столько много времени уходит чтобы
> просто понять что пакет не надо пересобирать от прошлого запуска; там
> короче говоря причины разные, то есть одного узкого места нету.

Главный фактор почему медленно работала проверка "no need to rebuild" --
это сама схема проверки: собирается src.rpm пакет и в чрут
устанавливаются все пакеты BuildReqires.  Если содержимое чрута после
этого совпадает, то пакет можно не пересобирать.

Эта схема теперь модифицирована следующим образом: когда имеется src.rpm
пакет от предыдущего запуска, можно замкнуть его список BuildRequires и
получить список пакетов, которые будут установлены.  То есть можно
узнать содержимое чрута без фактической установки пакетов.

Есть ещё два фактора, которые заметно влияют на скорость проверки "no
need to rebuild".

1) hsh --init на репозитарии с полным списком файлов.
Научно установлено, что 'hsh --init' на обычно репозитарии занимает 13
секунд, а на репозитарии с полным списком файлов -- 20 секунд.

2) После сборки каждого очередного пакета хешеру нужно перегенерировать
локальный репозитарий; в том числе прочитать все пакеты и вычислить их
md5 суммы (потому что md5-кеш пакетов на нодах скорее всего не работает).

Я думаю что в хешере можно вообще не генерировать репозитарий и целиком
отказаться от genbasedir, а вместо этого в sources.list использовать
метод доступа "rpm-dir" вместо "rpm" (repo).  Тогда при изменении
каталога rpm-dir apt будет считывать информацию прямо из хедеров
пакетов, которые там лежат.  А это лушче, перечитывать пакеты полностью
(для вычисления md5-сумм).

> Поэтому я сделал превентивный хак для girar-builder'а:
> http://git.altlinux.org/people/at/packages/girar-builder.git?a=commitdiff;h=586f99e1
> Он немного ослабляет требования базовой модели, но не очень сильно.
> Тестовая пересборка пакетов, если мы до неё доживём, будет идти по
> такой же схеме.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20091127/c3002481/attachment-0001.bin>