On Fri, Jun 02, 2006 at 11:06:37AM +0700, Slava Semushin wrote: > AT> То есть для взвешенного иерархического ранжирования сборочных зависимостей > AT> ничего специально делать не нужно, и наиболее "трудным" моментом в этой задаче > AT> было как раз осознать, что специально ничего делать не нужно. > > Признаться результаты кажутся мне несколько завышенными. Их проблема в > том, что они основываются на BuildRequires, которые прописываются > мэйнтейнерами и следовательно могут врать. В частности есть две То есть мы сталкиваемся с тем, что мэйнтейнеры могут врать. Увы, поэты много врут. Это не новость. > 1) в BuildRequires могут попадать пакеты, которые _вообще_ не нужны > для сборки. Такие случаи есть и их не так уж и мало. С другой стороны, если пакет из BuildRequires не удается установить, тогда соответствующий пакет нельзя собрать. Ви знайете что такое \sup и \inf? В случае с BuildRequires речь идёт о \sup. В случае Requires получаем \inf. То есть нужность для сборки двояка. С одной стороны, пакет нужно как минимум установить. С другой стороны, может статься, установленный пакет должен работать! > 2) в отдельный случай я хотел бы выделить зависимости на виртуальные > пакеты. В частности, раньше иксы были не модульными и для многих > чисто иксовых программ было достаточно прописать xorg-x11-devel (а > ещё раньше XFree86-devel AFAIR). С приходом модульного Xorg7 иксы > разделились на отдельные пакеты, а xorg-x11-devel стал виртуальным > пакетом, который вытягивает за собой не меньше десятка отдельных > пакетов. Ситуация такая, что очень многие мэйнтейнеры то ли из-за > нехватки времени, то ли по ленности своей не стали изменять > BuildRequires, а оставили xorg-x11-devel, т.к. с ним всё равно > пакеты собираются и работают. Соответственно у очень многих > пакетов, как я думаю, в chroot ставятся пакеты которые вытягивает > xorg-x11-devel, но при этом программа их реально не использует. > > Ваши результаты IMHO это лишь подтверждают: > > AT> [at@basalt ~]$ buildlog_uris /raid/beehive/success |tail -33 > AT> 934 libfreetype-devel-2.2.1-alt2 > AT> 938 libXaw-1.0.2-alt1 > AT> 940 libxml2-2.6.23-alt2 > AT> 940 xml-common-0.6.3-alt11 > AT> 974 libXp-1.0.0-alt3 > AT> 985 libXmu-1.0.1-alt1 > AT> 1013 libXinerama-1.0.1-alt3 > AT> 1049 libjpeg-6b-alt7 > AT> 1054 libXcursor-1.1.6-alt1 > AT> 1056 libXrandr-1.1.1-alt1 > AT> 1059 libXfixes-4.0-alt2 > AT> 1071 libX11-devel-1.0.0-alt6 > AT> 1072 libXau-devel-1.0.1-alt1 > AT> 1073 libXdmcp-devel-1.0.1-alt1 > AT> 1075 libXft-2.1.8.2-alt5 > AT> 1078 libXi-1.0.1-alt1 > AT> 1086 libXpm-3.5.5-alt1 > AT> 1092 libXt-1.0.2-alt1 > AT> 1093 libXrender-0.9.1-alt1 > AT> 1139 libssl-0.9.7g-alt3 > AT> 1145 libSM-1.0.1-alt1 > AT> 1149 xorg-x11-proto-devel-7.1.0-alt1 > AT> 1150 libICE-1.0.1-alt1 > AT> 1219 zlib-devel-1.2.3-alt3 > AT> 1230 libXext-1.0.0-alt4 > AT> 1335 libpng3-1.2.8-alt3 > AT> 1349 fontconfig-2.3.2-alt8 > AT> 1399 libfreetype-2.2.1-alt2 > AT> 1463 libexpat-2.0.0-alt3.1 > AT> 1539 libX11-1.0.0-alt6 > AT> 1541 libXdmcp-1.0.1-alt1 > AT> 1619 libstdc++4.1-4.1.1-alt1 > AT> 1660 libXau-1.0.1-alt1 > AT> [at@basalt ~]$ > > БОльшая часть из этих пакетов как раз являются теми частями бывшего > когда-то единым xorg-x11-devel. А то что libXau является более > востребованной чем даже libstdc++ вообще удивительно :) Да. Тем не менее это не отменяеть \sup-семантики BuildRequires. > Я с этим уже давно столкнулся при сборке программы требующей > glib-devel, которая в свою очередь при сборке требовала > xorg-x11-devel. Я даже предлагал убрать эту зависимость, но ldv@ > сказал что пусть так и будет. Поэтому программа (wmclockmon кажется) в > Сизиф так и не попала.