On Wed, Aug 30, 2006 at 08:10:50PM +0400, Dmitry V. Levin wrote: > > (Алгоритм оптимизации BuildRequires обсуждался вчера в частной > > переписке. Правда, спросонья я потерял к нему интерес. Если это > > интересно кому-то ещё, тогда можно перенести обсуждение сюда.) > > Думаю, что лучше перенести сюда - вдруг среди нас есть специалист/практик > по теории графов? Тогда повторю вопрос. 145 "$PACKAGEOF" -f "$WORKDIR/files" >"$WORKDIR/packages" 146 sort -u -o "$WORKDIR/packages" "$WORKDIR/packages" 147 148 cat "$WORKDIR/packages" | 149 xargs -r rpmquery --qf '[%{REQUIRENAME}\n]' -- | 150 sort -u >"$WORKDIR/reqs" 151 152 cat "$WORKDIR/packages" | 153 xargs -r rpmquery --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- | 154 sort -k2,2 -k1,1 -u >"$WORKDIR/provs" 155 156 comm -23 "$WORKDIR/packages" "$WORKDIR/reqs" >"$WORKDIR/package-reqs" 157 158 join -1 1 -2 2 -o 1.1 "$WORKDIR/reqs" "$WORKDIR/provs" | 159 sort -u >"$WORKDIR/reqs_provs" 160 comm -23 "$WORKDIR/package-reqs" "$WORKDIR/reqs_provs" \ 161 >"$WORKDIR/package-reqs-provs" Вопрос про join в строке 158. Допустим, что мы оптимизирем список из двух пакетов: sh и glibc-core (без списка ignore). Список reqs в упрощенном виде выглядит так: reqs <ВиртуальнаяЗависимость> libc.so.6 Список provs в упрощенном виде выглядит так: provs <ВиртуальнаяЗависимость, ИмяПакета> libc.so.6 glibc-core /bin/sh sh Цель оптимизации предположительно состоит в том, чтобы исключить glibc-core, потому что его "вытягивает" sh. join в строке 158 делает нечто отличное: ты соединяешь reqs<ВиртуальнаяЗависимость> на provs<ИмяПакета>, а на выходе хочешь получить provs<ВиртуальнаяЗависимость>. Это выглядит подозрительно, потому что происходит соединение по полям разных типов. Затем с помощью comm в строке 160 ты вычитаешь из списка пакетов package-reqs список полученных таким образом provs<ВиртуальнаяЗависимость>. Это опять же выглядит подозрительно -- вычитание множеств с разным типом элементов. Какой в этом смысл?