On Sun, Jan 29, 2006 at 04:46:20PM +0300, Денис Смирнов wrote:
> Таки написал я код для ранжирования пакетов по важности и автоматического
> выявления наиболее требующих внимания участков.
> 
> Проблема в том, что сейчас я подразумеваю одинаковую важность всех пакетов
> изначально, что явно не соответствует действительности.
> 
> Соответственно у меня вопрос -- какие пакеты мы должны считать наиболее
> важными _без учета зависимостей_? То есть, скажем, с этой точки зрения
> glibс не важный пакет -- сам по себе он никому не нужен, а, скажем,
> какой-нибудь bc может быть для кого-то один из самых важных пакетов, так
> как его использует какой-нибудь ОченьВажныйСкрипт.
> 
> Сейчас я могу легко получить список пакетов, требующих внимания, по своему
> списку используемых в работе пакетов.

Я тоже думал над этой задачей.  Что касается сборочных зависимостей, то,
оказывается, существует неожиданное решение: список установленных
пакетов можно извлечь из лога пересборки.  Поскольку логи пересборки
репозитария существуют, остается только сосчитать пакеты, которые встают
в чрут (в логах указаны все пакеты, которые встают в чрут, за вычетом
базовой сборочной среды, т.е. basesystem+rpm-build; последнее
обстоятельство можно рассматривать и как преимущество).

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

buildlog_uris()
{
	find "$@" -type f -print0 |xargs -r0 gzip -cdfq |
		awk '/^Preparing packages for installation/,/^Installing .*[.]src[.]rpm$/ {
			if (/^[[:alnum:]][[:graph:]]*[[:alnum:]]-(alt|ipl)[[:graph:]]*$/ && !/[.]rpm$/)
				print }' |sort |uniq -c |awk '{print $1 "\t" $2 }' |sort -n
}

(Название функции buildlog_uris интуитивно не понятно, потому что эта
функция используется в рамках решения другой задачи.)

[at@basalt ~]$ buildlog_uris /raid/beehive/success |tail -33
934     libfreetype-devel-2.2.1-alt2
938     libXaw-1.0.2-alt1
940     libxml2-2.6.23-alt2
940     xml-common-0.6.3-alt11
974     libXp-1.0.0-alt3
985     libXmu-1.0.1-alt1
1013    libXinerama-1.0.1-alt3
1049    libjpeg-6b-alt7
1054    libXcursor-1.1.6-alt1
1056    libXrandr-1.1.1-alt1
1059    libXfixes-4.0-alt2
1071    libX11-devel-1.0.0-alt6
1072    libXau-devel-1.0.1-alt1
1073    libXdmcp-devel-1.0.1-alt1
1075    libXft-2.1.8.2-alt5
1078    libXi-1.0.1-alt1
1086    libXpm-3.5.5-alt1
1092    libXt-1.0.2-alt1
1093    libXrender-0.9.1-alt1
1139    libssl-0.9.7g-alt3
1145    libSM-1.0.1-alt1
1149    xorg-x11-proto-devel-7.1.0-alt1
1150    libICE-1.0.1-alt1
1219    zlib-devel-1.2.3-alt3
1230    libXext-1.0.0-alt4
1335    libpng3-1.2.8-alt3
1349    fontconfig-2.3.2-alt8
1399    libfreetype-2.2.1-alt2
1463    libexpat-2.0.0-alt3.1
1539    libX11-1.0.0-alt6
1541    libXdmcp-1.0.1-alt1
1619    libstdc++4.1-4.1.1-alt1
1660    libXau-1.0.1-alt1
[at@basalt ~]$ 

Соответственно, если какой-либо пакет из этого списка станет
неустанавливаемым (допустим, вследствие анмета), то пересборка сизифа
станет практический невозможной.  Опять же, за вычетом базовой сборочной
среды.  Но в случае с базовой сборочной средой очевидно, что если она
разломана, то собрать вообще ничего не удастся.

Поскольку логи сборки содержат результаты find-requires, то становится
также возможным произвести взвешенное иерархическое ранжирование
реальных (а не сборочных) зависимостей.  Это несколько сложнее, но не
намного (основная проблема состоит в том, чтоб отмаппить виртуальные
пакеты в реальные).  Поскольку я сейчас хочу выпить пива, я не буду до
конца показывать, как это сделать... Ж)  Суть опять же в том, что
специально делать ничего не нужно.

buildlog_deps()
{
	find "$@" -type f -print0 |xargs -r0 gzip -cdfq |
		awk  -F'[:,] +' '/^Processing files:/ { pkg = $NF }
			/^PreReq:|^Requires([(].+[)])?:|^Provides:|^Obsoletes:/ {
				if (pkg) for(i=2;i<=NF;i++) print pkg "\t" $1 "\t" $i }' |sort -u
}