[devel] Критерий значимости пакета (Was: статистика)

[Alexey Rusakov <ktirf@altlinux.org>]

Я позволю себе заговорить независимо чуток на другую тему, которая,
благодаря at@, получила продолжение.

On Sat, 25 Aug 2007 01:23:57 +0400
Alexey Tourbin wrote:

> Займемся теперь вопросом, сколько же сизифовских пакетов придётся
> тестировать пересборкой на каждый входящий src.rpm пакет.  У меня
> есть полная таблица, кусочек которой приведен выше.  Введу новое
> обозначение для полей таблицы:
> 	<test-src-rpm-basename> <incoming-rpm-basename>
> Это означает, что собравшийся в incoming'е пакет <incoming-rpm-basename>,
> оказывается, встает в чрут для сборки <test-src-rpm-basename>.  Значит,
> вследствие прохождения <incoming-rpm-basename> нужно протестировать
> пересборкой <test-src-rpm-basename>.
> 
> Я дополнил эту таблицу ещё одним полем:
> 	<test-src-rpm-basename> <incoming-rpm-basename> <incoming-src-rpm-basename>
> 
> Последнее поле означает, какой src.rpm пакет собрался в incoming'е.
> Это нужно для того, чтобы учитывать, что из одного src.rpm пакета
> при сборке в среднем получается больше одного установочного пакета,
> которые будут вставать в чрут.  Это не должно искажать статистики.
> 
> Я выложил эту таблицу сюда (952K):
> ftp://ftp.altlinux.org/pub/people/at/rebuild-map.bz2
> 
[...]
> Я теперь сделаю совсем уж интуитивно понятную таблицу
> 	<incoming-src-rpm-basename> <rebuild-number-src-rpm>
> 
> $ uniq -c -f1 .ss |awk '{print$3"\t"$1}' |sort -k2,2n >.sz
> $ head -2 .sz
> GraphicsMagick-1.1.8-alt1.src.rpm       1
> MySQL41-4.1.21-alt5.1.src.rpm   1
> $ tail .sz   
> libSM-1.0.3-alt1.src.rpm        1952
> libICE-1.0.4-alt1.src.rpm       1962
> fontconfig-2.4.2-alt3.src.rpm   2120
> libXext-1.0.3-alt1.src.rpm      2196
> libfreetype-2.3.5-alt2.src.rpm  2203
> gcc4.1-4.1.1-alt11.src.rpm      2365
> libXau-1.0.3-alt1.src.rpm       2388
> libXdmcp-1.0.2-alt1.0.src.rpm   2389
> libX11-1.1.3-alt3.src.rpm       2392
> expat-2.0.1-alt0.1.src.rpm      2646
> $
> 
> Видим, что GraphicsMagick на входе потребует пересборки всего одного
> src.rpm пакета (кстати, это koffice), а expat на входе потребует
> пересобрать уже 2646 src.rpm пакетов.  Всего сейчас в репозитарии 6687
> src.rpm пакетов (с точки зрения этой статистики).
> 
> ЗДЕСЬ НЕ УЧИТЫВАЮТСЯ ИЗМЕНЕНИЯ В basesystem + rpm-build.
> Любой пакет, который попадает в basesystem + rpm-build, потребует,
> по идее, полной пересборки сизифа, и этот случай я сейчас специально
> отсёк.  Никакой другой пакет, однако, не может зацепить для пересборки
> даже и половину сизифа.
В своё время, ещё в конце прошлого года, обсуждалась тема критерия
заморозки Сизифа. Я и mithraen@ более-менее независимо толкнули идею о
том, что замораживать Сизиф можно с разной "глубиной", основываясь на том,
какие пакеты насколько "значимы" для репозитория. В первом приближении
в качестве критерия значимости предлагалось учитывать количество
зависимостей от этого пакета. В частности, говорилось следующее:

On Tue, 2 Jan 2007 15:54:24 +0300
Денис Смирнов wrote:

> On Sun, Dec 31, 2006 at 07:37:45PM +0300, Alexey Rusakov wrote:
> 
> AR> А возможно определить формальную величину "значимости" пакета через 
> AR> количество зависящих от него пакетов? Неоднозначные зависимости можно 
> AR> учитывать либо через коэффициент < 1, либо учитывать все возможноые 
> AR> варианты. Если мы сможем определить такую величину, то дальше можно 
> AR> устанавливать этапы, замораживая пакеты со "значимостью" больше, чем 
> AR> некоторая очередная величина. Подход, конечно, наивный, но в качестве 
> AR> первого приближения почему бы и нет.
> 
> Когда-то я ровно это и предлагал. Вопрос лишь в том как правильно
> отрабатывать нечеткие зависимости (с >= %version, например)?
> 
> Так как эта задача не требует абсолютно точного результата, то можно все
> нечеткие зависимости представлять себе как самые что ни на есть четкие.
> Тогда можно получить вполне осмысленный результат за разумное время.

Так вот, по-моему, приведённый at@ метод, в качестве побочного эффекта,
даёт такой критерий, причём в более удачной формулировке, чем высказанная раньше.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team