* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 16:10 ` [devel] оптимизация сборочных зависимостей Dmitry V. Levin
@ 2006-08-30 16:28 ` Alexey Tourbin
2006-08-30 16:43 ` Dmitry V. Levin
2006-08-30 19:07 ` Alexey Tourbin
` (2 subsequent siblings)
3 siblings, 1 reply; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-30 16:28 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]
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<ВиртуальнаяЗависимость>. Это опять же
выглядит подозрительно -- вычитание множеств с разным типом элементов.
Какой в этом смысл?
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 16:28 ` Alexey Tourbin
@ 2006-08-30 16:43 ` Dmitry V. Levin
2006-08-30 18:30 ` Alexey Tourbin
2006-08-30 20:12 ` Sergey Vlasov
0 siblings, 2 replies; 72+ messages in thread
From: Dmitry V. Levin @ 2006-08-30 16:43 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]
On Wed, Aug 30, 2006 at 08:28:49PM +0400, Alexey Tourbin wrote:
> 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"
packages - это список имён пакетов, которые использовались для сборки
посредством files.
> 148 cat "$WORKDIR/packages" |
> 149 xargs -r rpmquery --qf '[%{REQUIRENAME}\n]' -- |
> 150 sort -u >"$WORKDIR/reqs"
reqs - это все requires пакетов packages.
> 152 cat "$WORKDIR/packages" |
> 153 xargs -r rpmquery --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- |
> 154 sort -k2,2 -k1,1 -u >"$WORKDIR/provs"
provs - это всё provides пакетов packages в виде пар
"ProvideName PackageName".
> 156 comm -23 "$WORKDIR/packages" "$WORKDIR/reqs" >"$WORKDIR/package-reqs"
package-reqs - это пакеты packages за вычетом тех, имена которых совпали с
requires пакетов packages. В частности, эта операция выкидывает простые
циклы целиком.
> 158 join -1 1 -2 2 -o 1.1 "$WORKDIR/reqs" "$WORKDIR/provs" |
> 159 sort -u >"$WORKDIR/reqs_provs"
reqs_provs - это те requires пакетов packages, которые есть среди provides
пакетов packages.
> 160 comm -23 "$WORKDIR/package-reqs" "$WORKDIR/reqs_provs" \
> 161 >"$WORKDIR/package-reqs-provs"
package-reqs-provs - это пакеты package-reqs за вычетом тех, имена которых
совпали с requires, перечисленными в reqs_provs. В частности, эта
операция выкидывает все циклы полностью.
[...]
> join в строке 158 делает нечто отличное: ты соединяешь
> reqs<ВиртуальнаяЗависимость> на provs<ИмяПакета>, а на выходе хочешь
> получить provs<ВиртуальнаяЗависимость>. Это выглядит подозрительно,
> потому что происходит соединение по полям разных типов.
Почему разных? Имя пакета - это частный случай виртуальной provides.
[...]
> Какой в этом смысл?
Минимизация мощности множества зависимостей. Алгоритм нечестный в том
смысле, что он выкидывает циклы.
Поскольку исходное множество конечно, всегда есть алгоритм полного
перебора всех подмножеств данного множества, из которых выбирается любое
удовлетворяющее критерию отбора. Очевидно, что этот алгоритм непрактичен.
Полагаю, что существует алгоритм приемлемой вычислительной сложности, но
мне он не известен.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 16:43 ` Dmitry V. Levin
@ 2006-08-30 18:30 ` Alexey Tourbin
2006-08-30 20:12 ` Sergey Vlasov
1 sibling, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-30 18:30 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 4567 bytes --]
On Wed, Aug 30, 2006 at 08:43:52PM +0400, Dmitry V. Levin wrote:
> > Тогда повторю вопрос.
> >
> > 145 "$PACKAGEOF" -f "$WORKDIR/files" >"$WORKDIR/packages"
> > 146 sort -u -o "$WORKDIR/packages" "$WORKDIR/packages"
>
> packages - это список имён пакетов, которые использовались для сборки
> посредством files.
>
> > 148 cat "$WORKDIR/packages" |
> > 149 xargs -r rpmquery --qf '[%{REQUIRENAME}\n]' -- |
> > 150 sort -u >"$WORKDIR/reqs"
>
> reqs - это все requires пакетов packages.
>
> > 152 cat "$WORKDIR/packages" |
> > 153 xargs -r rpmquery --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- |
> > 154 sort -k2,2 -k1,1 -u >"$WORKDIR/provs"
>
> provs - это всё provides пакетов packages в виде пар
> "ProvideName PackageName".
>
> > 156 comm -23 "$WORKDIR/packages" "$WORKDIR/reqs" >"$WORKDIR/package-reqs"
>
> package-reqs - это пакеты packages за вычетом тех, имена которых совпали с
> requires пакетов packages. В частности, эта операция выкидывает простые
> циклы целиком.
>
> > 158 join -1 1 -2 2 -o 1.1 "$WORKDIR/reqs" "$WORKDIR/provs" |
> > 159 sort -u >"$WORKDIR/reqs_provs"
>
> reqs_provs - это те requires пакетов packages, которые есть среди provides
> пакетов packages.
Здесь было бы логичнее соединять по первому полю provs и на выходе
получать второе поле provs. Тогда reqs_provs -- это те из пакетов
packages, в которые удается разрешить какие-либо зависимости пакетов
packages. При этом более осмысленной становится следующая операция.
> > 160 comm -23 "$WORKDIR/package-reqs" "$WORKDIR/reqs_provs" \
> > 161 >"$WORKDIR/package-reqs-provs"
>
> package-reqs-provs - это пакеты package-reqs за вычетом тех, имена которых
> совпали с requires, перечисленными в reqs_provs. В частности, эта
> операция выкидывает все циклы полностью.
Из списка пакетов packages-reqs логичнее вычитать не виртуальные
зависимости по первой колонке provs, а названия пакетов по второй
колонке provs. Тогда package-reqs-provs -- это пакеты package-reqs
за вычетом тех, которые предоставляют какие-либо зависимости для пакетов
packages.
Разве так не логичнее? Это либо очевидная ошибка, либо осторожный
в каком-то смысле алгоритм (в каком именно я пока не понимаю).
> > join в строке 158 делает нечто отличное: ты соединяешь
> > reqs<ВиртуальнаяЗависимость> на provs<ИмяПакета>, а на выходе хочешь
> > получить provs<ВиртуальнаяЗависимость>. Это выглядит подозрительно,
> > потому что происходит соединение по полям разных типов.
>
> Почему разных? Имя пакета - это частный случай виртуальной provides.
Однако в requires и provides находятся преимущественно виртуальные
зависимости (сгенерированные автоматически и не соответствующие
названиям реальных пакетов). Поэтому алгоритм в текущем виде не сможет
оптимизировать зависимость через soname (что я попытался
продемонстрировать на примере glibc-core и sh).
Мне кажется, что этот алгоритм работает только в случае, когда
в requires содержится имя (невиртуального) пакета. При этом
используется тот факт, что provides любого пакета содержит сам себя по
имени. Рассмотрим оптимизацию списка {glib2-devel,libgtk+2-devel}.
Релевантная часть reqs у libgtk+2-devel выглядит так:
reqs<Зависимость>
glib2-devel -- проставлено вручную
libglib-2.0.so.0 -- сгенерировано автоматически
Релевантная часть provs у glib2-devel выглядит так:
provs<Зависимость,ИмяПакета>
glib2-devel glib2-devel -- любой пакет предоставляет сам себя
Тогда мы соединяем reqs<Зависимость>(glib2-devel) \Join
provs<ИмяПакета>(glib2-devel) = provs<Зависимость>(glib2-devel).
В дальнейшем glib2-devel подлежит вычитанию из списка package-reqs,
и вычитание действительно происходит.
Это наводит на мысль, что алгоритм в текущем виде оптимизирует только
такие пакеты, у которых в requires одного пакета явно прописано имя
другого пакета. Тогда возможно соединение фактически по имени пакета
с последующим вычитанием опять же по имени пакета, за счет совпадения
двух полей в provs. Но в таком случае вовсе не обязательно было
использовать %{PROVIDENAME}! Можно было просто соединять зависимости
пакетов на сами пакеты.
> > Какой в этом смысл?
> Минимизация мощности множества зависимостей.
Это общее место. :)
> Алгоритм нечестный в том
> смысле, что он выкидывает циклы.
Циклы выкидывать нельзя ни в коем случае. Это ведь оптимизация, а
некорректная оптимизация зачастую хуже отсутствия оптимизации вообще.
Think of gcc.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 16:43 ` Dmitry V. Levin
2006-08-30 18:30 ` Alexey Tourbin
@ 2006-08-30 20:12 ` Sergey Vlasov
2006-08-30 21:01 ` Alexey Tourbin
1 sibling, 1 reply; 72+ messages in thread
From: Sergey Vlasov @ 2006-08-30 20:12 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]
On Wed, Aug 30, 2006 at 08:43:52PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 30, 2006 at 08:28:49PM +0400, Alexey Tourbin wrote:
> > 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"
>
> packages - это список имён пакетов, которые использовались для сборки
> посредством files.
>
> > 148 cat "$WORKDIR/packages" |
> > 149 xargs -r rpmquery --qf '[%{REQUIRENAME}\n]' -- |
> > 150 sort -u >"$WORKDIR/reqs"
>
> reqs - это все requires пакетов packages.
Вот здесь вместо этого можно построить список пар вида
"PackageName RequireName".
> > 152 cat "$WORKDIR/packages" |
> > 153 xargs -r rpmquery --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- |
> > 154 sort -k2,2 -k1,1 -u >"$WORKDIR/provs"
>
> provs - это всё provides пакетов packages в виде пар
> "ProvideName PackageName".
Далее join по reqs.RequireName == provs.ProvideName даст список пар
"PackageName -> RequiredPackageName" (назовём его deps) - зависимости
между пакетами.
(На самом деле это тоже не совсем правильно - возможна ситуация, когда
один и тот же виртуальный пакет провайдится несколькими пакетами,
попавшими в список используемых; в этом случае наличие в BuildRequires
пакетов, требующих такую зависимость, не гарантирует установки всех
нужных пакетов. Чтобы не получить в таком случае неверный результат,
список provs надо предварительно почистить - все ProvideName,
встречающиеся более одного раза, нужно удалить. Хотя и это не
поможет, если аналогичные provides есть ещё в пакетах, не попавших в
список packages; более того, такие пакеты могут существовать в
репозитории, но не быть установлены в системе, где выполняется
buildreq... Получается, что наиболее правильный способ - использовать
список provs от всего репозитория, а не только от packages.)
Далее, имея граф зависимостей между пакетами, необходимо каким-то
образом определить минимальный набор вершин, пути, исходящие из
которых, покрывают все вершины графа. При отсутствии циклов эта
задача решается очень просто - достаточно найти вершины, в которые не
входит ни одно ребро (пакеты, которые не зависят от других пакетов).
Если же в графе есть циклы, каждый цикл нужно схлопнуть в одну
вершину, затем, когда в графе не останется циклов, определить нужный
набор вершин; если в этот набор попали вершины, полученные из циклов,
для них можно выбрать любой пакет, входивший в цикл.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 20:12 ` Sergey Vlasov
@ 2006-08-30 21:01 ` Alexey Tourbin
2006-08-30 22:48 ` Alexey Tourbin
0 siblings, 1 reply; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-30 21:01 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]
On Thu, Aug 31, 2006 at 12:12:07AM +0400, Sergey Vlasov wrote:
> > > 148 cat "$WORKDIR/packages" |
> > > 149 xargs -r rpmquery --qf '[%{REQUIRENAME}\n]' -- |
> > > 150 sort -u >"$WORKDIR/reqs"
> >
> > reqs - это все requires пакетов packages.
>
> Вот здесь вместо этого можно построить список пар вида
> "PackageName RequireName".
>
> > > 152 cat "$WORKDIR/packages" |
> > > 153 xargs -r rpmquery --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- |
> > > 154 sort -k2,2 -k1,1 -u >"$WORKDIR/provs"
> >
> > provs - это всё provides пакетов packages в виде пар
> > "ProvideName PackageName".
>
> Далее join по reqs.RequireName == provs.ProvideName даст список пар
> "PackageName -> RequiredPackageName" (назовём его deps) - зависимости
> между пакетами.
Этот список deps -- кандидат на топологическую сортировку -- tsort(1).
Правда, tsort не умеет *молча* разрывать циклы. Но этой особенностью
tsort в общем-то можно пренебречь.
Я вчера много думал, как всё это можно сделать, а сегодня спросонья, как
уже писал, потерял интерес... :)
> (На самом деле это тоже не совсем правильно - возможна ситуация, когда
> один и тот же виртуальный пакет провайдится несколькими пакетами,
> попавшими в список используемых; в этом случае наличие в BuildRequires
> пакетов, требующих такую зависимость, не гарантирует установки всех
> нужных пакетов. Чтобы не получить в таком случае неверный результат,
> список provs надо предварительно почистить - все ProvideName,
> встречающиеся более одного раза, нужно удалить. Хотя и это не
> поможет, если аналогичные provides есть ещё в пакетах, не попавших в
> список packages; более того, такие пакеты могут существовать в
> репозитории, но не быть установлены в системе, где выполняется
> buildreq... Получается, что наиболее правильный способ - использовать
> список provs от всего репозитория, а не только от packages.)
rpm -q --whatprovides $dep |sort -u |wc -w
> Далее, имея граф зависимостей между пакетами, необходимо каким-то
> образом определить минимальный набор вершин, пути, исходящие из
> которых, покрывают все вершины графа. При отсутствии циклов эта
> задача решается очень просто - достаточно найти вершины, в которые не
> входит ни одно ребро (пакеты, которые не зависят от других пакетов).
> Если же в графе есть циклы, каждый цикл нужно схлопнуть в одну
> вершину, затем, когда в графе не останется циклов, определить нужный
> набор вершин; если в этот набор попали вершины, полученные из циклов,
> для них можно выбрать любой пакет, входивший в цикл.
Топологическая сортировка, кажется, решает эту проблему.
Пусть есть список пакетов, отсортированный топологически: пакеты в
начале списка требуют пакеты, которые находятся ближе к концу списка.
Тогда можно применить что-то вроде решета Эратосфена, которое
используется для просева простых чисел. Берем элемент списка и
вычеркиваем все *последующие* элементы, которые к нему сводятся.
Но не просто вычеркиваем, а как бы зануляем, чтобы уже вычеркнутые
элементы сохранились для последующих вычеркиваний. Тогда на выходе
должен остаться список пакетов, которые не сводятся друг ко другу.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 21:01 ` Alexey Tourbin
@ 2006-08-30 22:48 ` Alexey Tourbin
2006-08-30 23:19 ` Alexey Tourbin
2006-08-30 23:45 ` [devel] оптимизация сборочных зависимостей Dmitry V. Levin
0 siblings, 2 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-30 22:48 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]
On Thu, Aug 31, 2006 at 01:01:06AM +0400, Alexey Tourbin wrote:
> > Далее, имея граф зависимостей между пакетами, необходимо каким-то
> > образом определить минимальный набор вершин, пути, исходящие из
> > которых, покрывают все вершины графа. При отсутствии циклов эта
> > задача решается очень просто - достаточно найти вершины, в которые не
> > входит ни одно ребро (пакеты, которые не зависят от других пакетов).
> > Если же в графе есть циклы, каждый цикл нужно схлопнуть в одну
> > вершину, затем, когда в графе не останется циклов, определить нужный
> > набор вершин; если в этот набор попали вершины, полученные из циклов,
> > для них можно выбрать любой пакет, входивший в цикл.
>
> Топологическая сортировка, кажется, решает эту проблему.
> Пусть есть список пакетов, отсортированный топологически: пакеты в
> начале списка требуют пакеты, которые находятся ближе к концу списка.
>
> Тогда можно применить что-то вроде решета Эратосфена, которое
> используется для просева простых чисел. Берем элемент списка и
> вычеркиваем все *последующие* элементы, которые к нему сводятся.
> Но не просто вычеркиваем, а как бы зануляем, чтобы уже вычеркнутые
> элементы сохранились для последующих вычеркиваний. Тогда на выходе
> должен остаться список пакетов, которые не сводятся друг ко другу.
Вот скрипт, который использует топологическую сортировку + вычеркивание
как в решете Эратосфена.
$ cat ./optimize_package_list
#!/bin/sh -ef
. tmpdir.sh
cd $TMPDIR
rpm -q --qf '[%{REQUIRENAME}\t%{NAME}\n]' -- "$@" >qR
rpm -q --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- "$@" >qP
awk '{print$2,$1}' qR |sort -u -k2,2 -k1,1 -o qR
awk '{print$2,$1}' qP |sort -u -k2,2 -k1,1 -o qP
#head -v qR qP
join -j 2 -o '1.1 2.1' qR qP |sort -u >p2p
tsort p2p >tsorted || [ -s tsorted ]
#head -v p2p tsorted
set -- `cat tsorted`
for i in `seq 1 $(($#-1))`; do
eval master="\$$i"
for j in `seq $((i+1)) $#`; do
eval slave="\$$j"
if grep -qs -Fx "$master $slave" p2p; then
#echo master=$master slave=$slave >&2
echo "$slave"
fi
done
done >extrareq
sort -o extrareq -u extrareq
awk '{print$1}' qR |sort -u >req
#head -v req extrareq
comm -23 req extrareq |xargs -r echo
$
У меня пока нет уверенности, что он до конца правильно работает,
однако "основные проблемы" в нём как будто не проявляются.
$ ./optimize_package_list glibc-core sh
sh
$ ./optimize_package_list perl-base
perl-base
$ ./optimize_package_list perl-DateTime-TimeZone perl-DateTime
tsort: p2p: input contains a loop:
tsort: perl-DateTime
tsort: perl-DateTime-TimeZone
perl-DateTime
$
Очень прошу указать мне ситуацию, в которой скрипт лажается.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 22:48 ` Alexey Tourbin
@ 2006-08-30 23:19 ` Alexey Tourbin
2006-08-31 0:17 ` Денис Смирнов
2006-08-31 4:05 ` Alexey Tourbin
2006-08-30 23:45 ` [devel] оптимизация сборочных зависимостей Dmitry V. Levin
1 sibling, 2 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-30 23:19 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
On Thu, Aug 31, 2006 at 02:48:51AM +0400, Alexey Tourbin wrote:
> $ cat ./optimize_package_list
> #!/bin/sh -ef
> . tmpdir.sh
> cd $TMPDIR
> rpm -q --qf '[%{REQUIRENAME}\t%{NAME}\n]' -- "$@" >qR
> rpm -q --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- "$@" >qP
> awk '{print$2,$1}' qR |sort -u -k2,2 -k1,1 -o qR
> awk '{print$2,$1}' qP |sort -u -k2,2 -k1,1 -o qP
> #head -v qR qP
> join -j 2 -o '1.1 2.1' qR qP |sort -u >p2p
> tsort p2p >tsorted || [ -s tsorted ]
> #head -v p2p tsorted
> set -- `cat tsorted`
> for i in `seq 1 $(($#-1))`; do
> eval master="\$$i"
К сожалению для i>9 эта конструкция не работает.
Т.е. i=$10 воспринимается шеллом как i=${1}0 и т.д.
То есть скрипт может лажаться при числе аргументов 10 и более.
Весь этот вложенный цикл нужно переписать на awk или на перле. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 23:19 ` Alexey Tourbin
@ 2006-08-31 0:17 ` Денис Смирнов
2006-08-31 4:05 ` Alexey Tourbin
1 sibling, 0 replies; 72+ messages in thread
From: Денис Смирнов @ 2006-08-31 0:17 UTC (permalink / raw)
To: ALT Devel discussion list
On Thu, Aug 31, 2006 at 03:19:37AM +0400, Алексей Турбин wrote:
>> eval master="\$$i"
AT> К сожалению для i>9 эта конструкция не работает.
AT> Т.е. i=$10 воспринимается шеллом как i=${1}0 и т.д.
AT> То есть скрипт может лажаться при числе аргументов 10 и более.
AT> Весь этот вложенный цикл нужно переписать на awk или на перле. :)
eval master="\${$i}"
?
--
С уважением, Денис
http://freesource.info
----------------------------------------------------------------------------
> Пинайте Юру, в incoming/ все лежит.
Только не сильно, щас исправлюсь.
-- aris in sisyphus@
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 23:19 ` Alexey Tourbin
2006-08-31 0:17 ` Денис Смирнов
@ 2006-08-31 4:05 ` Alexey Tourbin
2006-09-05 13:10 ` [devel] оптимизация сборочных зависимостей (buildreq) Ildar Mulyukov
1 sibling, 1 reply; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-31 4:05 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]
On Thu, Aug 31, 2006 at 03:19:37AM +0400, Alexey Tourbin wrote:
> On Thu, Aug 31, 2006 at 02:48:51AM +0400, Alexey Tourbin wrote:
> > $ cat ./optimize_package_list
> > #!/bin/sh -ef
> > . tmpdir.sh
> > cd $TMPDIR
> > rpm -q --qf '[%{REQUIRENAME}\t%{NAME}\n]' -- "$@" >qR
> > rpm -q --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- "$@" >qP
> > awk '{print$2,$1}' qR |sort -u -k2,2 -k1,1 -o qR
> > awk '{print$2,$1}' qP |sort -u -k2,2 -k1,1 -o qP
> > #head -v qR qP
> > join -j 2 -o '1.1 2.1' qR qP |sort -u >p2p
> > tsort p2p >tsorted || [ -s tsorted ]
> > #head -v p2p tsorted
> > set -- `cat tsorted`
> > for i in `seq 1 $(($#-1))`; do
> > eval master="\$$i"
>
> К сожалению для i>9 эта конструкция не работает.
> Т.е. i=$10 воспринимается шеллом как i=${1}0 и т.д.
> То есть скрипт может лажаться при числе аргументов 10 и более.
> Весь этот вложенный цикл нужно переписать на awk или на перле. :)
--- optimize_package_list- 2006-08-30 23:31:38 +0000
+++ optimize_package_list 2006-08-31 04:00:46 +0000
@@ -9,17 +9,25 @@ awk '{print$2,$1}' qP |sort -u -k2,2 -k1
join -j 2 -o '1.1 2.1' qR qP |sort -u >p2p
tsort p2p >tsorted || [ -s tsorted ]
#head -v p2p tsorted
-set -- `cat tsorted`
-for i in `seq 1 $(($#-1))`; do
- eval master="\$$i"
- for j in `seq $((i+1)) $#`; do
- eval slave="\$$j"
- if grep -qs -Fx "$master $slave" p2p; then
- #echo master=$master slave=$slave >&2
- echo "$slave"
- fi
- done
-done >extrareq
+awk -f - p2p >extrareq <<'EOF'
+BEGIN { # process tsorted
+ while (getline <"tsorted")
+ tsorted[++N] = $1
+}
+{ # process p2p
+ p2p[$1,$2] = 1
+}
+END { # output unneeded reqs
+ for (i = 1; i < N; i++) {
+ master = tsorted[i]
+ for (j = i+1; j <= N; j++) {
+ slave = tsorted[j]
+ if (p2p[master,slave])
+ print slave
+ }
+ }
+}
+EOF
sort -o extrareq -u extrareq
awk '{print$1}' qR |sort -u >req
#head -v req extrareq
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей (buildreq)
2006-08-31 4:05 ` Alexey Tourbin
@ 2006-09-05 13:10 ` Ildar Mulyukov
2006-09-05 13:48 ` Alexey Tourbin
2006-09-05 18:15 ` Michael Shigorin
0 siblings, 2 replies; 72+ messages in thread
From: Ildar Mulyukov @ 2006-09-05 13:10 UTC (permalink / raw)
To: devel
Дорогой Алексей Турбин,
сегодня Ваше творение доехало до репозитария и было мной опробовано.
Результат радует.
Что бросилось в глаза:
1. новый buildreq не убивает старые записи BuildRequires
2. даёт хороший лаконичный список сборочных зависимостей.
Однако:
3. В упор не видит BuildPreReq
4. После объединения множеств BuildRequires и BuildPreReq, получается
опять избыточное множество пакетов.
Если есть желание довести скрипт до совершенства (а вдруг оно ещё
осталось после бессонных ночей, проведённых с ним?), я представляю это
таким образом:
1. Ввести пакеты из BuildPreReq
2. "Прорешетить" их в первую очередь
3. Дальше работать с оставшимися пакетами.
Также было бы разумно старые BuildRequires хотя и не удалять, но
закомментировать (чтобы показать, что они замещаются новыми).
С уважением, Ильдар.
--
Ildar Mulyukov,
free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей (buildreq)
2006-09-05 13:10 ` [devel] оптимизация сборочных зависимостей (buildreq) Ildar Mulyukov
@ 2006-09-05 13:48 ` Alexey Tourbin
2006-09-05 14:57 ` Ildar Mulyukov
2006-09-05 18:15 ` Michael Shigorin
1 sibling, 1 reply; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-05 13:48 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
On Tue, Sep 05, 2006 at 07:10:15PM +0600, Ildar Mulyukov wrote:
> Дорогой Алексей Турбин,
> сегодня Ваше творение доехало до репозитария и было мной опробовано.
> Результат радует.
Творение не мое. Я только предложил алогоритм оптимизации списка.
> Что бросилось в глаза:
> 1. новый buildreq не убивает старые записи BuildRequires
Он убивает только свои собственные записи BuildreQuires.
Запустите повторно и убедитесь.
> 2. даёт хороший лаконичный список сборочных зависимостей.
> Однако:
> 3. В упор не видит BuildPreReq
> 4. После объединения множеств BuildRequires и BuildPreReq, получается
> опять избыточное множество пакетов.
Насколько я знаю, такой логики никогда не было предусмотрено.
Сомнительно, что она нужна.
> Если есть желание довести скрипт до совершенства (а вдруг оно ещё
> осталось после бессонных ночей, проведённых с ним?), я представляю это
> таким образом:
> 1. Ввести пакеты из BuildPreReq
> 2. "Прорешетить" их в первую очередь
> 3. Дальше работать с оставшимися пакетами.
>
> Также было бы разумно старые BuildRequires хотя и не удалять, но
> закомментировать (чтобы показать, что они замещаются новыми).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей (buildreq)
2006-09-05 13:48 ` Alexey Tourbin
@ 2006-09-05 14:57 ` Ildar Mulyukov
0 siblings, 0 replies; 72+ messages in thread
From: Ildar Mulyukov @ 2006-09-05 14:57 UTC (permalink / raw)
To: devel
On 05.09.2006 19:48:45, Alexey Tourbin wrote:
> On Tue, Sep 05, 2006 at 07:10:15PM +0600, Ildar Mulyukov wrote:
> > 1. новый buildreq не убивает старые записи BuildRequires
> Он убивает только свои собственные записи BuildreQuires.
> Запустите повторно и убедитесь.
Да, точно
> > 2. даёт хороший лаконичный список сборочных зависимостей.
> > Однако:
> > 3. В упор не видит BuildPreReq
> > 4. После объединения множеств BuildRequires и BuildPreReq,
> > получается опять избыточное множество пакетов.
>
> Насколько я знаю, такой логики никогда не было предусмотрено.
> Сомнительно, что она нужна.
Я вижу, что не предусмотрена. Нужна ли? Могут быть различные мнения. Но
я не настаиваю.
С уважением, Ильдар
--
Ildar Mulyukov,
free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей (buildreq)
2006-09-05 13:10 ` [devel] оптимизация сборочных зависимостей (buildreq) Ildar Mulyukov
2006-09-05 13:48 ` Alexey Tourbin
@ 2006-09-05 18:15 ` Michael Shigorin
2006-09-05 19:08 ` Alexey Tourbin
1 sibling, 1 reply; 72+ messages in thread
From: Michael Shigorin @ 2006-09-05 18:15 UTC (permalink / raw)
To: devel
On Tue, Sep 05, 2006 at 07:10:15PM +0600, Ildar Mulyukov wrote:
> 3. В упор не видит BuildPreReq
Думаю, это повод гробить в BPR то, что замечено в BR после
прогона br.
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей (buildreq)
2006-09-05 18:15 ` Michael Shigorin
@ 2006-09-05 19:08 ` Alexey Tourbin
2006-09-05 19:15 ` Michael Shigorin
0 siblings, 1 reply; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-05 19:08 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 398 bytes --]
On Tue, Sep 05, 2006 at 09:15:09PM +0300, Michael Shigorin wrote:
> On Tue, Sep 05, 2006 at 07:10:15PM +0600, Ildar Mulyukov wrote:
> > 3. В упор не видит BuildPreReq
>
> Думаю, это повод гробить в BPR то, что замечено в BR после
> прогона br.
В BPR вручную лучше вообще ничего не ставить, кроме специальных случаев,
когда нужно указать версию пакета и т.п.
Так же, как и в Requires.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей (buildreq)
2006-09-05 19:08 ` Alexey Tourbin
@ 2006-09-05 19:15 ` Michael Shigorin
2006-09-06 4:06 ` Ildar Mulyukov
0 siblings, 1 reply; 72+ messages in thread
From: Michael Shigorin @ 2006-09-05 19:15 UTC (permalink / raw)
To: devel
On Tue, Sep 05, 2006 at 11:08:03PM +0400, Alexey Tourbin wrote:
> > > 3. В упор не видит BuildPreReq
> > Думаю, это повод гробить в BPR то, что замечено в BR после
> > прогона br.
> В BPR вручную лучше вообще ничего не ставить, кроме специальных
> случаев, когда нужно указать версию пакета и т.п.
> Так же, как и в Requires.
Так и я о чём. Лучше не трогать скриптами то, что делалось
руками.
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей (buildreq)
2006-09-05 19:15 ` Michael Shigorin
@ 2006-09-06 4:06 ` Ildar Mulyukov
0 siblings, 0 replies; 72+ messages in thread
From: Ildar Mulyukov @ 2006-09-06 4:06 UTC (permalink / raw)
To: devel
On 06.09.2006 01:15:49, Michael Shigorin wrote:
> On Tue, Sep 05, 2006 at 11:08:03PM +0400, Alexey Tourbin wrote:
> > > > 3. В упор не видит BuildPreReq
> > > Думаю, это повод гробить в BPR то, что замечено в BR после
> > > прогона br.
> > В BPR вручную лучше вообще ничего не ставить, кроме специальных
> > случаев, когда нужно указать версию пакета и т.п.
> > Так же, как и в Requires.
>
> Так и я о чём. Лучше не трогать скриптами то, что делалось
> руками.
Я и не предлагал это трогать. Я предлагал это учитывать при вычислении
минимального множества br.
Ильдар
--
Ildar Mulyukov,
free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 22:48 ` Alexey Tourbin
2006-08-30 23:19 ` Alexey Tourbin
@ 2006-08-30 23:45 ` Dmitry V. Levin
2006-08-31 0:27 ` Alexey Tourbin
1 sibling, 1 reply; 72+ messages in thread
From: Dmitry V. Levin @ 2006-08-30 23:45 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]
On Thu, Aug 31, 2006 at 02:48:51AM +0400, Alexey Tourbin wrote:
[...]
> Вот скрипт, который использует топологическую сортировку + вычеркивание
> как в решете Эратосфена.
Боюсь, что для читающей публики нужны комментарии.
> $ cat ./optimize_package_list
> #!/bin/sh -ef
> . tmpdir.sh
> cd $TMPDIR
> rpm -q --qf '[%{REQUIRENAME}\t%{NAME}\n]' -- "$@" >qR
> rpm -q --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- "$@" >qP
> awk '{print$2,$1}' qR |sort -u -k2,2 -k1,1 -o qR
> awk '{print$2,$1}' qP |sort -u -k2,2 -k1,1 -o qP
Зачем так сложно? Понятно что итератор (REQUIRENAME/PROVIDENAME) должен
быть первым, но зачем переставлять?
sort -u -k1,1 -k2,2 -o qR qR
sort -u -k1,1 -k2,2 -o qP qP
> #head -v qR qP
> join -j 2 -o '1.1 2.1' qR qP |sort -u >p2p
соответственно
join -j 1 -o '1.2 2.2' qR qP |sort -u >p2p
и т.д.
Таким образом, p2p состоит из пар имён пакетов вида
(зависящий,удовлетворяющий)
> tsort p2p >tsorted || [ -s tsorted ]
Может ли быть, чтобы tsort разорвал циклы не самым оптимальным образом?
Может, но это не важно ввиду последующего.
> #head -v p2p tsorted
> set -- `cat tsorted`
> for i in `seq 1 $(($#-1))`; do
> eval master="\$$i"
> for j in `seq $((i+1)) $#`; do
> eval slave="\$$j"
> if grep -qs -Fx "$master $slave" p2p; then
> #echo master=$master slave=$slave >&2
> echo "$slave"
> fi
> done
> done >extrareq
Не нравится мне эти eval'ы...
Я бы всё же не стал называть зависящий пакет master, а удовлетворяющий
зависимость slave. Скорее наоборот. :)
Итак, в extrareq попадают (все?) имена пакетов, которые удовлетворяют
хотя бы один зависящий.
> sort -o extrareq -u extrareq
> awk '{print$1}' qR |sort -u >req
req - это имена всех пакетов, у которых есть зависимости.
Поскольку любой пакет имеет какие-нибудь зависимости, хотя бы на
rpmlib(...), это список совпадает с исходным списком.
И всё же я бы сделал этот же самый список на основе qP, воспользовавшись
другим свойством пакетов: всякий пакет предоставляет одноимённый provides.
Или ещё переносимее: rpmquery --qf '%{NAME}\n' -- "$@" >names
> #head -v req extrareq
> comm -23 req extrareq |xargs -r echo
> $
Наконец, из списка имён всех пакетов удаляются имена тех, от которых
зависит хотя бы один.
> У меня пока нет уверенности, что он до конца правильно работает,
> однако "основные проблемы" в нём как будто не проявляются.
Выглядит правильно.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 23:45 ` [devel] оптимизация сборочных зависимостей Dmitry V. Levin
@ 2006-08-31 0:27 ` Alexey Tourbin
2006-08-31 0:59 ` Alexey Tourbin
2006-09-02 16:34 ` Michael Shigorin
0 siblings, 2 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-31 0:27 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 3570 bytes --]
On Thu, Aug 31, 2006 at 03:45:50AM +0400, Dmitry V. Levin wrote:
> > Вот скрипт, который использует топологическую сортировку + вычеркивание
> > как в решете Эратосфена.
[...]
> > rpm -q --qf '[%{REQUIRENAME}\t%{NAME}\n]' -- "$@" >qR
> > rpm -q --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- "$@" >qP
> > awk '{print$2,$1}' qR |sort -u -k2,2 -k1,1 -o qR
> > awk '{print$2,$1}' qP |sort -u -k2,2 -k1,1 -o qP
>
> Зачем так сложно? Понятно что итератор (REQUIRENAME/PROVIDENAME) должен
> быть первым, но зачем переставлять?
Я не претендую на то, что именно этот скрипт лучше всего выражает идею
"топологическая сортировка + вычеркивание как в решете Эратосфена".
Сейчас просто хочется проверить, продуктивна идея или нет.
Что до перестановки, то таковы мои ментальные особенности как
программиста. Бинарное отношение мыслится как глагол ("требует" и
"предоставляет"), что фиксирует соответствующий порядок атрибутов
("пакет" "требует" "зависимость" и "пакет" "предоставляет" "зависимость").
Но в реляционной алгебре, действительно, постулируется неупорядоченность
атрибутов (как и неупорядоченность кортежей). С другой стороны, в
реляционной алгебре у каждого атрибута есть имя и тип, а стандартные
средства UNIX под это не заточены.
(Я с тобой немного обсуждал на конференции, как реализовать реляционную
алгебру на шелле. Идея в том, что первая строка должна содержать имена
(и, возможно, типы) атрибутов). Тогда сортировка кортежей реализуется
так: read -r header; echo "$header"; exec sort "$@". И т.п. Есть
www.rdb.rpm -- ссылка на статью была в докладе -- и свободная реализация
nosql, но мне не нравится, как там сделано.)
> > tsort p2p >tsorted || [ -s tsorted ]
>
> Может ли быть, чтобы tsort разорвал циклы не самым оптимальным образом?
> Может, но это не важно ввиду последующего.
Насколько я понял, tsort разрывает цикл в лексикографическом порядке.
> > #head -v p2p tsorted
> > set -- `cat tsorted`
> > for i in `seq 1 $(($#-1))`; do
> > eval master="\$$i"
> > for j in `seq $((i+1)) $#`; do
> > eval slave="\$$j"
> > if grep -qs -Fx "$master $slave" p2p; then
> > #echo master=$master slave=$slave >&2
> > echo "$slave"
> > fi
> > done
> > done >extrareq
>
> Не нравится мне эти eval'ы...
Мне тоже не нравится. Шелл прекрасно приспособлен к метафоре
"преобразование потока данных", когда для каждой строчки в потоке
выполняется какое-либо действие. В таких случаях на шелле писать
даже удобнее, чем на перле. Но вложенные циклы -- чисто императивная
фишка, которая плохо вписывается в "преобразование потока" -- на шелле
это писать плохо. Может на awk этот цикл надо написать.
Кстати, проверка включения grep'ом тоже не очень-то эффективна.
Допустим, что в списке n=100 пакетов. Тогда придется выполнить
99+98+...+1 т.е. порядка n^2/2 грепов. Кажется, это "классическая"
задача -- найти сумму чисел от 1 до 100. Нужно складывать 0+100 потом
1+99 потом 2+98 и т.д., получится 100*50+50=5050.
> Я бы всё же не стал называть зависящий пакет master, а удовлетворяющий
> зависимость slave. Скорее наоборот. :)
Ну, это дело вкуса, и, на самом деле, метафоры. Я вообразил себе, что
некий Господин держит при себе вниз по списку некоторое количество Рабов.
Причем Господин сам может являться Рабом какого-нибудь более крутого
Господина -- того, что выше по списку. Менеджер среднего звена.
Социальная иерархия. :)
> Выглядит правильно.
Хорошо.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-31 0:27 ` Alexey Tourbin
@ 2006-08-31 0:59 ` Alexey Tourbin
2006-09-02 16:34 ` Michael Shigorin
1 sibling, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-31 0:59 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
On Thu, Aug 31, 2006 at 04:27:05AM +0400, Alexey Tourbin wrote:
> Что до перестановки, то таковы мои ментальные особенности как
> программиста. Бинарное отношение мыслится как глагол ("требует" и
> "предоставляет"), что фиксирует соответствующий порядок атрибутов
> ("пакет" "требует" "зависимость" и "пакет" "предоставляет" "зависимость").
Это по-грамотному называется субъект-предикат-объект.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-31 0:27 ` Alexey Tourbin
2006-08-31 0:59 ` Alexey Tourbin
@ 2006-09-02 16:34 ` Michael Shigorin
2006-09-03 2:12 ` Alexey Tourbin
1 sibling, 1 reply; 72+ messages in thread
From: Michael Shigorin @ 2006-09-02 16:34 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 366 bytes --]
On Thu, Aug 31, 2006 at 04:27:05AM +0400, Alexey Tourbin wrote:
> > Я бы всё же не стал называть зависящий пакет master, а
> > удовлетворяющий зависимость slave. Скорее наоборот. :)
> Ну, это дело вкуса, и, на самом деле, метафоры.
requirer / provider? :)
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-09-02 16:34 ` Michael Shigorin
@ 2006-09-03 2:12 ` Alexey Tourbin
0 siblings, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-03 2:12 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
On Sat, Sep 02, 2006 at 07:34:33PM +0300, Michael Shigorin wrote:
> On Thu, Aug 31, 2006 at 04:27:05AM +0400, Alexey Tourbin wrote:
> > > Я бы всё же не стал называть зависящий пакет master, а
> > > удовлетворяющий зависимость slave. Скорее наоборот. :)
> > Ну, это дело вкуса, и, на самом деле, метафоры.
>
> requirer / provider? :)
Jehovah Jireh, my provider. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 16:10 ` [devel] оптимизация сборочных зависимостей Dmitry V. Levin
2006-08-30 16:28 ` Alexey Tourbin
@ 2006-08-30 19:07 ` Alexey Tourbin
2006-08-30 20:29 ` Alexey Tourbin
2006-09-03 4:36 ` Alexey Tourbin
3 siblings, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-30 19:07 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]
On Wed, Aug 30, 2006 at 08:10:50PM +0400, Dmitry V. Levin wrote:
> > (Алгоритм оптимизации BuildRequires обсуждался вчера в частной
> > переписке. Правда, спросонья я потерял к нему интерес. Если это
> > интересно кому-то ещё, тогда можно перенести обсуждение сюда.)
>
> Думаю, что лучше перенести сюда - вдруг среди нас есть специалист/практик
> по теории графов?
Вот математическая постановка задачи. Дан список (множество) пакетов P.
Найти минимальное подмножество P_0, при котором множество P является
подмножеством транзитивного замыкания P_0:
P_0\subset P
P\subset [P_0]
\forall P_n P\subset [P_n] \Rightarrow |P_n|\geq|P_0|
Здесь [P] -- транзитивное замыкание множества, |P| -- мощность множества.
Подмножества не обязательно собственные.
Говорить о транзитивном замыкании множества не совсем корректно.
Речь идет о транзитивном замыкании пакетов по отношению "зависеть".
Например, если дан пакет A, и при этом известно, что пакет A требует
пакет B, тогда B входит в [A]. Если же пакет B зависит от пакета C,
тогда C снова входит в [A] и т.д.
Последнее условие выражает ту мысль, что подмножество P_0 должно быть
в некотором смысле минимальным. А именно, все другие подмножества с
транзитивным замыканием [P] или больше обладают не меньшей мощностью.
Решение этой задачи в лоб означает перебор всех подмножеств P_n и
построение для каждого из них транзитивного замыкания. Среди
подмножеств, у которых транзитивное замыкание не меньше [P] (а
фактически совпадает с [P]), нужно выбрать наименьшее по числу
элементов.
Однако известно, что перебор подмножеств -- это чрезвычайно трудоемкая
задача.
Кто ничего не понял, транзитивное замыкание -- это, грубо говоря, список
пакетов в чруте, который hasher/apt разворачивает по строчке
BuildRequires. Т.е. список пакетов в чруте -- это транзитивное
замыкание [BuildRequires]. Оптимизация списка BuildRequires тогда
состоит в том, чтобы при удалении некоторых элементов из этого списка
содержимое чрута в конечном счете не менялось. Остается только выбрать
наилучшую их всех возможных оптимизаций, при которой список
BuildRequires становится минимальным.
Кстати, можно изменить условие задачи:
-P_0\subset P
+P_0\subset [P]
Я реализовал это в buildreq2 и получил интересные результаты.
В buildreq2 решена задача построения транзитивного замыкания,
но не до конца не решена задача оптимизации.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 16:10 ` [devel] оптимизация сборочных зависимостей Dmitry V. Levin
2006-08-30 16:28 ` Alexey Tourbin
2006-08-30 19:07 ` Alexey Tourbin
@ 2006-08-30 20:29 ` Alexey Tourbin
2006-08-30 20:57 ` Damir Shayhutdinov
2006-09-03 4:36 ` Alexey Tourbin
3 siblings, 1 reply; 72+ messages in thread
From: Alexey Tourbin @ 2006-08-30 20:29 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 3248 bytes --]
On Wed, Aug 30, 2006 at 08:10:50PM +0400, Dmitry V. Levin wrote:
> > (Алгоритм оптимизации BuildRequires обсуждался вчера в частной
> > переписке. Правда, спросонья я потерял к нему интерес. Если это
> > интересно кому-то ещё, тогда можно перенести обсуждение сюда.)
>
> Думаю, что лучше перенести сюда - вдруг среди нас есть специалист/практик
> по теории графов?
Вот примитивный алгоритм, который однако же работает некорректно,
поскольку полностью исключает из списка циклы.
Дан список пакетов P. Составим два отношения req<name,dep> и
prov<name,dep> (которые соответствуют rpm -q --requires и
rpm -q --provides). Соединим req и prov по полю dep и сделаем
проекцию на prov<name>. Получим список пакетов, которые
требуются какими-либо пакетами из исходного списка P.
Следовательно, эти пакеты можно удалить.
Пример. Дано: glibc-core, sh.
req:
sh libc.so.6
...
prov:
glibc-core libc.so.6
...
Соединение:
sh -> libc.so.6 -> glibc-core
Проекция:
glibc-core
Следовательно, казалось бы, пакет glibc-core можно удалить.
Но это работает корректно не во всех случаях.
(Далее я поясняю на примерах, когда и почему это не работает.)
1) Рассмотрим пакет perl-base. Одной из его особенностей является то,
что он почему то требует сам себя -- Requires: perl-base. Получается
соединение perl-base -> perl-base -> perl-base и пакет совершенно
автоматически удаляется из списка.
Вот сам скрипт, с которым можно поиграться.
$ cat ./optimize_package_list
#!/bin/sh -ef
. tmpdir.sh
cd $TMPDIR
rpm -q --qf '[%{REQUIRENAME}\t%{NAME}\n]' -- "$@" >qR
rpm -q --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- "$@" >qP
awk '{print$2,$1}' qR |sort -u -k2,2 -k1,1 -o qR
awk '{print$2,$1}' qP |sort -u -k2,2 -k1,1 -o qP
#head -v qR qP
join -j 2 -o 2.1 qR qP |sort -u >extrareq
awk '{print$1}' qR |sort -u >req
#head -v req extrareq
comm -23 req extrareq |xargs -r echo
$ ./optimize_package_list perl-base
$
(tmpdir.sh есть в пакете qa-robot)
2) Далее, рассмотрим пакеты perl-DateTime и perl-DateTime-TimeZone.
Эти пакеты зависят друг от друга, получается следующее соединение:
perl-DateTime -> perl(DateTime/TimeZone.pm) -> perl-DateTime-TimeZone
perl-DateTime-TimeZone -> perl(DateTime.pm) -> perl-DateTime
Опять получается, что все требуемые зависимости опять же предоставляются
самими этими пакетами, поэтому уже сразу два пакет, которые образуют
цикл, совершенно автоматически исключаются из списка.
$ ./optimize_package_list perl-DateTime perl-DateTime-TimeZone
$
Ясно, что 1) является частным случаем 2). Это можно представить себе
как простую и сложную рекурсию. При простой рекурсии фунция f вызывает
сама себя. При сложной рекурсии функция f1 вызывает f2, которая в свою
очередь опять вызывает f1.
3) A requires B, B requires C, ..., X requires Y, Y requires A.
Короче, должно быть уже ясно, что при наличии циклических зависимостей
удаляется *весь цикл*, т.е. вследствие некорректной оптимизации теряется
потенциально много пакетов.
Далее, я знаю, как обнаруживать циклы. Нужно сделать соединение ещё раз
само на себя и проверить, не совпадают ли начальный и конечный элементы.
Не понтяно правда, что потом делать с обнаруженными таким образом циклами.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 20:29 ` Alexey Tourbin
@ 2006-08-30 20:57 ` Damir Shayhutdinov
2006-08-30 21:17 ` Dmitry V. Levin
0 siblings, 1 reply; 72+ messages in thread
From: Damir Shayhutdinov @ 2006-08-30 20:57 UTC (permalink / raw)
To: ALT Devel discussion list
> Далее, я знаю, как обнаруживать циклы. Нужно сделать соединение ещё раз
> само на себя и проверить, не совпадают ли начальный и конечный элементы.
> Не понтяно правда, что потом делать с обнаруженными таким образом циклами.
Заменять на любой пакет из цикла - то есть, как говорил Сергей,
схлопывать циклы в одну вершину.
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 20:57 ` Damir Shayhutdinov
@ 2006-08-30 21:17 ` Dmitry V. Levin
2006-08-31 12:29 ` Sergey Vlasov
2006-09-05 14:28 ` Alexey Tourbin
0 siblings, 2 replies; 72+ messages in thread
From: Dmitry V. Levin @ 2006-08-30 21:17 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
On Thu, Aug 31, 2006 at 12:57:49AM +0400, Damir Shayhutdinov wrote:
> > Далее, я знаю, как обнаруживать циклы. Нужно сделать соединение ещё раз
> > само на себя и проверить, не совпадают ли начальный и конечный элементы.
> > Не понтяно правда, что потом делать с обнаруженными таким образом циклами.
> Заменять на любой пакет из цикла - то есть, как говорил Сергей,
> схлопывать циклы в одну вершину.
На любой пакет из цикла нельзя по двум причинам:
1. некоторые вершины есть виртуальные пакеты, их оставлять нехорошо;
2. некоторые вершины могут принадлежать нескольким цепочкам, таким
вершинам следует отдавать приоритет.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 21:17 ` Dmitry V. Levin
@ 2006-08-31 12:29 ` Sergey Vlasov
2006-09-05 14:28 ` Alexey Tourbin
1 sibling, 0 replies; 72+ messages in thread
From: Sergey Vlasov @ 2006-08-31 12:29 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]
On Thu, Aug 31, 2006 at 01:17:07AM +0400, Dmitry V. Levin wrote:
> On Thu, Aug 31, 2006 at 12:57:49AM +0400, Damir Shayhutdinov wrote:
> > > Далее, я знаю, как обнаруживать циклы. Нужно сделать соединение ещё раз
> > > само на себя и проверить, не совпадают ли начальный и конечный элементы.
> > > Не понтяно правда, что потом делать с обнаруженными таким образом циклами.
> > Заменять на любой пакет из цикла - то есть, как говорил Сергей,
> > схлопывать циклы в одну вершину.
>
> На любой пакет из цикла нельзя по двум причинам:
> 1. некоторые вершины есть виртуальные пакеты, их оставлять нехорошо;
Вроде бы на этом этапе виртуальных пакетов уже нет (по крайней мере, в
моём варианте они убирались раньше).
> 2. некоторые вершины могут принадлежать нескольким цепочкам, таким
> вершинам следует отдавать приоритет.
Если имелись в виду циклы, содержащие общие вершины - в этом случае в
одну вершину будут объединяться все вершины всех таких циклов, и с
точки зрения выбора минимального количества вершин никакой разницы
между такими объединёнными вершинами не будет.
Возможно, информацию о пакетах, образующих циклы, стоит выдавать в
spec в качестве комментария, чтобы потом можно было вручную заменить
автоматически выбранный пакет другим.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 21:17 ` Dmitry V. Levin
2006-08-31 12:29 ` Sergey Vlasov
@ 2006-09-05 14:28 ` Alexey Tourbin
1 sibling, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-05 14:28 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 7295 bytes --]
On Thu, Aug 31, 2006 at 01:17:07AM +0400, Dmitry V. Levin wrote:
> On Thu, Aug 31, 2006 at 12:57:49AM +0400, Damir Shayhutdinov wrote:
> > > Далее, я знаю, как обнаруживать циклы. Нужно сделать соединение ещё раз
> > > само на себя и проверить, не совпадают ли начальный и конечный элементы.
> > > Не понтяно правда, что потом делать с обнаруженными таким образом циклами.
> > Заменять на любой пакет из цикла - то есть, как говорил Сергей,
> > схлопывать циклы в одну вершину.
>
> На любой пакет из цикла нельзя по двум причинам:
> 1. некоторые вершины есть виртуальные пакеты, их оставлять нехорошо;
Это решается соединением requires на provides.
Здесь есть более тонкая проблема, о которой написал vsu. Если нечто
предоставляется двумя разными пакетами из списка, тогда теряется
уверенность, что можно сразу два эти пакета выкинуть. Ибо впоследствии
в сборочном чруте может оказаться только один из них.
Правда, я пока не успел столкнуться с этой проблемой. Её можно решить
грубо, учитывая каждый provides только один раз, то есть типа вот так:
--- /usr/bin/packagereq- 2006-09-05 07:11:28 +0000
+++ /usr/bin/packagereq 2006-09-05 14:07:27 +0000
@@ -154,7 +154,7 @@ sort -k1,1 -k2,2 -u -o "$WORKDIR"/Rn "$W
# make list of provides
cat "$WORKDIR"/n |
xargs -r rpmquery --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- >"$WORKDIR"/Pn
-sort -k1,1 -k2,2 -u -o "$WORKDIR"/Pn "$WORKDIR"/Pn
+sort -k1,1 -u -o "$WORKDIR"/Pn "$WORKDIR"/Pn
# make list of package pairs where first depends on second
join -j 1 -o '1.2 2.2' "$WORKDIR"/Rn "$WORKDIR"/Pn |
sort -u >"$WORKDIR"/nn
(Но можно и не решать.:)
> 2. некоторые вершины могут принадлежать нескольким цепочкам, таким
> вершинам следует отдавать приоритет.
А вот с этой проблемой я уже столкнулся, причем дважды в одном пакете.
Проблема состоит в том, что из-за произвольного (относительно предметной
области) разрыва циклов в tsort список пакетов получается неоптимальным
(т.е. в результате в нём присутствуют лишние элементы).
Это пакет perl-XML-Feed.
packagereq: building requires list: tsort: -: input contains a loop:
tsort: perl-XML-SAX
tsort: perl-XML-LibXML
tsort: -: input contains a loop:
tsort: perl-HTML-Parser
tsort: perl-libwww
tsort: -: input contains a loop:
tsort: perl-DateTime-TimeZone
tsort: perl-DateTime
Вот список nn:
bzip2 bzlib
bzip2 glibc-core
bzlib glibc-core
coreutils glibc-core
coreutils sh
findutils glibc-core
findutils sh
glibc-core setup
glibc-gconv-modules glibc-core
glibc-locales glibc-core
glibc-locales sh
glibc-nss glibc-core
libbeecrypt glibc-core
libdb4.4 glibc-core
libelf glibc-core
libexpat glibc-core
libexpat sh
libpopt glibc-core
librpm bzlib
librpm glibc-core
librpm libbeecrypt
librpm libdb4.4
librpm libelf
librpm libpopt
librpm zlib
librpmbuild glibc-core
librpmbuild librpm
libxml2 glibc-core
libxml2 zlib
make glibc-core
make sh
perl-Compress-Zlib glibc-core
perl-Compress-Zlib perl-base
perl-Compress-Zlib zlib
perl-DateTime glibc-core
perl-DateTime perl-DateTime-Locale
perl-DateTime perl-DateTime-TimeZone
perl-DateTime perl-Params-Validate
perl-DateTime perl-base
perl-DateTime-Format-Mail perl-DateTime
perl-DateTime-Format-Mail perl-Params-Validate
perl-DateTime-Format-W3CDTF perl-DateTime
perl-DateTime-Locale perl-Params-Validate
perl-DateTime-Locale perl-base
perl-DateTime-TimeZone perl-DateTime
perl-DateTime-TimeZone perl-Params-Validate
perl-DateTime-TimeZone perl-base
perl-Encode glibc-core
perl-Encode perl-base
perl-ExtUtils-AutoInstall perl-base
perl-ExtUtils-AutoInstall perl-devel
perl-Feed-Find perl-Class-ErrorHandler
perl-Feed-Find perl-HTML-Parser
perl-Feed-Find perl-URI
perl-Feed-Find perl-base
perl-Feed-Find perl-libwww
perl-HTML-Parser glibc-core
perl-HTML-Parser perl-HTML-Tagset
perl-HTML-Parser perl-URI
perl-HTML-Parser perl-base
perl-HTML-Parser perl-libwww
perl-Module-Install perl-YAML
perl-Module-Install perl-base
perl-Module-Install perl-devel
perl-Params-Validate glibc-core
perl-Params-Validate perl-base
perl-URI perl-base
perl-URI-Fetch perl-Class-ErrorHandler
perl-URI-Fetch perl-URI
perl-URI-Fetch perl-base
perl-URI-Fetch perl-libwww
perl-XML-Atom perl-Class-Data-Inheritable
perl-XML-Atom perl-DateTime
perl-XML-Atom perl-Encode
perl-XML-Atom perl-HTML-Parser
perl-XML-Atom perl-XML-LibXML
perl-XML-Atom perl-base
perl-XML-Atom perl-libwww
perl-XML-LibXML glibc-core
perl-XML-LibXML libxml2
perl-XML-LibXML perl-XML-SAX
perl-XML-LibXML perl-base
perl-XML-Parser glibc-core
perl-XML-Parser libexpat
perl-XML-Parser perl-URI
perl-XML-Parser perl-base
perl-XML-Parser perl-libwww
perl-XML-RSS perl-XML-Parser
perl-XML-SAX perl-XML-LibXML
perl-XML-SAX perl-base
perl-YAML perl-base
perl-YAML perl-devel
perl-base glibc-core
perl-base perl-base
perl-devel glibc-core
perl-devel perl-base
perl-libwww perl-Compress-Zlib
perl-libwww perl-HTML-Parser
perl-libwww perl-URI
perl-libwww perl-base
rpm coreutils
rpm glibc-core
rpm libpopt
rpm librpm
rpm librpmbuild
rpm sh
rpm-build bzip2
rpm-build coreutils
rpm-build findutils
rpm-build glibc-core
rpm-build libpopt
rpm-build librpm
rpm-build librpmbuild
rpm-build make
rpm-build perl-base
rpm-build rpm
rpm-build sed
rpm-build sh
rpm-build tar
sed glibc-core
sed sh
sh glibc-core
tar glibc-core
tar sh
zlib glibc-core
Вывод tsort такой:
glibc-gconv-modules
glibc-locales
glibc-nss
perl-DateTime-Format-Mail
perl-DateTime-Format-W3CDTF
perl-ExtUtils-AutoInstall
perl-Feed-Find
perl-Module-Install
perl-URI-Fetch
perl-XML-Atom
perl-XML-RSS
rpm-build
perl-YAML
perl-Class-ErrorHandler
perl-Encode
perl-Class-Data-Inheritable
perl-XML-Parser
tar
sed
rpm
make
findutils
bzip2
perl-devel
libexpat
librpmbuild
coreutils
librpm
sh
libpopt
libelf
libdb4.4
libbeecrypt
bzlib
perl-XML-SAX
perl-XML-LibXML
libxml2
perl-HTML-Parser
perl-libwww
perl-HTML-Tagset
perl-URI
perl-Compress-Zlib
zlib
perl-DateTime-TimeZone
perl-DateTime
perl-DateTime-Locale
perl-Params-Validate
perl-base
glibc-core
setup
Список после оптимизации такой:
perl-DateTime-Format-Mail perl-DateTime-Format-W3CDTF perl-DateTime-TimeZone perl-ExtUtils-AutoInstall perl-Feed-Find perl-Module-Install perl-URI-Fetch perl-XML-Atom perl-XML-RSS perl-XML-SAX
Здесь два раза повторяется похожая ситуация:
1) Пакеты perl-DateTime-Format-Mail и perl-DateTime-Format-W3CDTF
требуют пакет perl-DateTime, а perl-DateTime и perl-DateTime-TimeZone
образуют цикл. Из-за того, что perl-DateTime-TimeZone оказался выше по
списку, чем perl-DateTime, не происходит вычеркивание цикла целиком:
пакет perl-DateTime-TimeZone остается в списке.
То есть могло бы получиться, что perl-DateTime-Format-Mail вычеркнул
perl-DateTime, а perl-DateTime вычеркнул perl-DateTime-TimeZone, и тогда
цикл вычеркивается полностью. Но этого не получилось.
2) perl-XML-Atom требует perl-XML-LibXML, а perl-XML-LibXML и
perl-XML-SAX образуют цикл. Цикл опять не вычеркнут полностью -- в
списке остался perl-XML-SAX -- потому что perl-XML-SAX оказался выше по
списку, чем perl-XML-LibXML.
Теперь можно подумать, каким образом сформулировать требование к tsort
в части более "топологичного" разрыва циклов.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-08-30 16:10 ` [devel] оптимизация сборочных зависимостей Dmitry V. Levin
` (2 preceding siblings ...)
2006-08-30 20:29 ` Alexey Tourbin
@ 2006-09-03 4:36 ` Alexey Tourbin
2006-09-03 6:34 ` Alexey Tourbin
` (2 more replies)
3 siblings, 3 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-03 4:36 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 5724 bytes --]
On Wed, Aug 30, 2006 at 08:10:50PM +0400, Dmitry V. Levin wrote:
> > (Алгоритм оптимизации BuildRequires обсуждался вчера в частной
> > переписке. Правда, спросонья я потерял к нему интерес. Если это
> > интересно кому-то ещё, тогда можно перенести обсуждение сюда.)
>
> Думаю, что лучше перенести сюда - вдруг среди нас есть специалист/практик
> по теории графов?
Возможна даже более агрессивная оптимизация, чем предложенная
и реализованная в rpm-utils-0.9.2. Вот пример, когда этой оптимизации
как бы недостаточно:
$ cat sdltest.c
#include <SDL.h>
int main()
{
void *p = SDL_Init;
return !!p;
}
$ packagereq -o /dev/stdout -- gcc `sdl-config --cflags` sdltest.c -lSDL
packagereq: building requires list: esound libSDL-devel
esound libSDL-devel
$
Вопрос: почему остался esound?
Ситуация такая: при линковке используется только пакет libSDL-devel
(через симлинк /usr/lib/libSDL.so), но не сам libSDL. Вместе с тем,
при линковке через libSDL.so линкер цепляет все его пререквизиты,
включая /usr/lib/libesd.so.0 из пакета esound.
Получается, что список {esound,libSDL-devel} не поддается оптимизации,
потому что из списка выпал собственно libSDL. То есть как бы не удается
достроить цепочку libSDL-devel -> libSDL -> esound, с которой текущая
оптимизация дала бы результат.
Думаю, что эта ситуация довольно типична. Просто в списке
/etc/buildreqs/packages/essential присутствует паттерн ^lib[^-]+$,
из-за которого все библиотечные пакеты удаляются; а esound
не вписывается в это правило по названию. Этот паттерн сам по себе
довольно нечестный. Используя buildreq2 (где вся оптимизация
основывалась исключительно на зависимостях), я обнаружил несколько
ошибок в пакетах, когда пакет lib%name-devel не требовал
соответствующего пакета lib%name. В этом случае lib%name и
lib%name-devel подряд присутствовали в BuildRequires. См. напр.
#6753 libopenslp-devel should depend on libopenslp
#6754 libradiusclient-devel should depend on libradiusclient
#6755 libsubversion-devel should depend on libsubversion
#6756 libtidy-devel should depend on libtidy
Я вижу два подхода, которые в большей или меньшей степени способствуют,
с одной стороны, более агрессивной оптимизации, с другой -- избавлению
от нечестного паттерна.
1) Низкоуровневый подход (в меньшей степени). Добавить и использовать
специальную опцию в packageof. Для каждого заданного файла, помимо
того, чтобы пробивать его по rpmdb, нужно специальным образом
обрабатывать симлинки. А именно, для каждого симлинка делать realpath()
и полученный путь ещё раз пробивать по rpmdb.
Какой недостаток у этого подхода? Это вопрос философский. :)
То есть недостаток довольно тонкий -- настолько тонкий, что не является
препятствием для реализации, но непременно подлежит обсуждению.
Речь идет о том, что при использовании симлинка используется не cтолько
сам симлинк, сколько файл, на который показывает симлинк (симлинк и файл
могут находится в разных пакетах). При этом симлинк может показывать,
вообще говоря, куда угодно. Я ведь исхожу из того, что мы достраиваем
цепочку "вовнутрь", то есть вглубь дерева, а симлинк можеть дать
результат и "вовне". Здесь можно представить себе альтернативы.
То есть можно на выходе получить слишком специфические зависимости.
Далее, приходит в голову, что раскрывать симлинки таким образом нужно
только для системных вызовов типа open, но не для stat и особенно не для
lstat. Здесь опять же грёбаный Unix way оказывается недостаточно гибким.
2) Высокоуровневый подход (в большей степени). По списку пакетов на
входе выстраиваем транзитивное замыкание и далее уже оптимизируем
транзитивное замыкание, а не сам список пакетов. Это как раз изменение
в условии задачи, о котором я писал:
-P_0\subset P
+P_0\subset [P]
Прикол здесь в том, что в некоторых случаях на выходе оптимизации могут
появиться пакеты, которые не входят в начальный список P. Здесь есть
две проблемы. 1) Собственно выстраивание транзитивного замыкания по
текущей базе rpm. Поскольку будет использоваться что-то вроде
rpm --whatprovides, возможны двусмысленности, о которых писал vsu.
Если нечто предоставляется сразу двумя пакетами, тогда не ясно, что
делать. Например, если какой-то пакет требует webclient, при этом
webclient предоставляют elinks и konqueror, тогда уже страшно подумать,
в какую сторону может пойдет процесс. По двусмысленным зависимостям
транзитивное замыкание наверное лучше не достраивать. 2) Нельзя также
достраивать транзитивное замыкание в сторону увеличения количества
циклов. В общем этот подход более сложный, но над ним стоит подумать.
(vsu на самом деле написал о более тонкой проблеме, над которой также
стоит подумать.)
Что дает этот подход? Эксперименты с buildreq2 показывают, что этот
подход делает полностью ненужным список /etc/buildreqs/packages/essential.
Точнее, в buildreq2 этот список hardcoded и состоит всего из двух
пакетов -- basesystem и rpm-build. Фактически в списке essential содержатся
паттерны для транзитивного замыкания basesystem + rpm-build плюс один
нечестный паттерн -- ^lib[^-]+$. Если же добавить в rpm-build
зависимость на basesytem, тогда достаточно просто как бы "обрубать"
топологию пакетов на уровне rpm-build (точнее, "вычеркивать" rpm-build
в решете), вследствие чего все пререквизиты rpm-build будут
автоматически вычеркнуты. Таким образом, подход, основанный
на зависимостях, полностью себя оправдывает.
Короче, предлагаю в ближайшей перспективе реализовать подход №1 --
он достаточно прост в реализации, и у него не просматривается грубых
недостатков. Нечестный паттерн ^lib[^-]+$ после этого по идее станет
не нужен.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-09-03 4:36 ` Alexey Tourbin
@ 2006-09-03 6:34 ` Alexey Tourbin
2006-09-03 6:52 ` Alexey Tourbin
` (5 more replies)
2006-09-03 10:57 ` [devel] оптимизация сборочных зависимостей Alexey Tourbin
2006-09-03 17:07 ` Michael Shigorin
2 siblings, 6 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-03 6:34 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]
On Sun, Sep 03, 2006 at 08:36:15AM +0400, Alexey Tourbin wrote:
> Я вижу два подхода, которые в большей или меньшей степени способствуют,
> с одной стороны, более агрессивной оптимизации, с другой -- избавлению
> от нечестного паттерна.
>
> 1) Низкоуровневый подход (в меньшей степени). Добавить и использовать
> специальную опцию в packageof. Для каждого заданного файла, помимо
> того, чтобы пробивать его по rpmdb, нужно специальным образом
> обрабатывать симлинки. А именно, для каждого симлинка делать realpath()
> и полученный путь ещё раз пробивать по rpmdb.
С другой стороны, вклиниваться в packageof некорректно в том отношении,
что правила /etc/buildreqs/files/ignore.d к этому моменту уже отработали,
а раскрытие симлинков может дать новый повод для применения этих правил.
Таким образом, проблема декомпозиции оказывается сложнее -- вклинивать
обработку симлинков нужно раньше. Вот "модельный" патч, который
показывает, что, может быть, в действительности стоит сделать.
--- /usr/bin/filereq- 2006-09-03 00:03:03 +0000
+++ /usr/bin/filereq 2006-09-03 05:58:00 +0000
@@ -67,3 +67,9 @@
while [ -f "$LOCKFILE" ]; do
usleep 100000
done
+
+while read -r file; do
+ readlink -ms "$file" || echo "$file"
+ readlink -es "$file" ||:
+done <"$unsorted" >"$unsorted$$"
+mv "$unsorted$$" "$unsorted"
Здесь решаются две разные проблемы.
1) Предварительная каноникализация путей. Это нужно для того, чтобы
правила /etc/buildreqs/files/ignore.d работали всегда, а не от случая
к случаю (т.е. не зависели от путей типа /usr/bin/../lib/... -- такие
пути делает gcc! -- и т.п.).
2) Окончательная каноникализация путей. Это нужно для того, о чем я
писал в процитированном письме: чтобы требование на симлинки дополнительно
переходило в требование на файлы, на которые симлинки смотрят.
Проблема с этим патчем одна -- readlink'и в цикле будут работать долго.
Приходится ждать заметное время даже на мощной машине (порядка двух
секунд при линковке с -lSDL). Кстати, оптимизация {esound,libSDL-devel}
с этим патчем работает агрессивно.
К сожалению, readlink не работает с xargs (а xargs в свою очередь всегда
делает word splitting, что критически плохо для имен файлов). Также и
awk не умеет делать ничего вроде readlink или realpath. Остается только
перл. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-09-03 6:34 ` Alexey Tourbin
@ 2006-09-03 6:52 ` Alexey Tourbin
2006-09-03 6:56 ` Alexey Tourbin
` (4 subsequent siblings)
5 siblings, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-03 6:52 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
On Sun, Sep 03, 2006 at 10:34:41AM +0400, Alexey Tourbin wrote:
> --- /usr/bin/filereq- 2006-09-03 00:03:03 +0000
> +++ /usr/bin/filereq 2006-09-03 05:58:00 +0000
> @@ -67,3 +67,9 @@
> while [ -f "$LOCKFILE" ]; do
> usleep 100000
> done
> +
> +while read -r file; do
> + readlink -ms "$file" || echo "$file"
> + readlink -es "$file" ||:
> +done <"$unsorted" >"$unsorted$$"
> +mv "$unsorted$$" "$unsorted"
>
> Здесь решаются две разные проблемы.
>
> 1) Предварительная каноникализация путей. Это нужно для того, чтобы
> правила /etc/buildreqs/files/ignore.d работали всегда, а не от случая
> к случаю (т.е. не зависели от путей типа /usr/bin/../lib/... -- такие
> пути делает gcc! -- и т.п.).
>
> 2) Окончательная каноникализация путей. Это нужно для того, о чем я
> писал в процитированном письме: чтобы требование на симлинки дополнительно
> переходило в требование на файлы, на которые симлинки смотрят.
>
> Проблема с этим патчем одна -- readlink'и в цикле будут работать долго.
> Приходится ждать заметное время даже на мощной машине (порядка двух
> секунд при линковке с -lSDL). Кстати, оптимизация {esound,libSDL-devel}
> с этим патчем работает агрессивно.
Ой, там же в unsorted много-много дупов. Если предварительно
отсортировать unsorted, то работает гораздо быстрее, но задержка
всё равно заметна.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-09-03 6:34 ` Alexey Tourbin
2006-09-03 6:52 ` Alexey Tourbin
@ 2006-09-03 6:56 ` Alexey Tourbin
2006-09-03 13:38 ` [devel] readlink Dmitry V. Levin
` (3 subsequent siblings)
5 siblings, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-03 6:56 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
On Sun, Sep 03, 2006 at 10:34:41AM +0400, Alexey Tourbin wrote:
> --- /usr/bin/filereq- 2006-09-03 00:03:03 +0000
> +++ /usr/bin/filereq 2006-09-03 05:58:00 +0000
> @@ -67,3 +67,9 @@
> while [ -f "$LOCKFILE" ]; do
> usleep 100000
> done
> +
> +while read -r file; do
> + readlink -ms "$file" || echo "$file"
> + readlink -es "$file" ||:
> +done <"$unsorted" >"$unsorted$$"
> +mv "$unsorted$$" "$unsorted"
>
> Здесь решаются две разные проблемы.
>
> 1) Предварительная каноникализация путей. Это нужно для того, чтобы
> правила /etc/buildreqs/files/ignore.d работали всегда, а не от случая
> к случаю (т.е. не зависели от путей типа /usr/bin/../lib/... -- такие
> пути делает gcc! -- и т.п.).
Ой! Предварительная каноникализация путей работает не так, как я это
себе представлял.
$ readlink -ms /usr/lib/gcc/i586-alt-linux/4.1.1/../../../libSDL.so
/usr/lib/libSDL-1.2.so.0.7.3
$
Я же думал что он просто схлопывает s:/[^/]+/[.][.]/:/:g и т.п.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] readlink
2006-09-03 6:34 ` Alexey Tourbin
2006-09-03 6:52 ` Alexey Tourbin
2006-09-03 6:56 ` Alexey Tourbin
@ 2006-09-03 13:38 ` Dmitry V. Levin
2006-09-04 7:30 ` Alexey Tourbin
2006-09-03 17:08 ` [devel] оптимизация сборочных зависимостей Michael Shigorin
` (2 subsequent siblings)
5 siblings, 1 reply; 72+ messages in thread
From: Dmitry V. Levin @ 2006-09-03 13:38 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Sun, Sep 03, 2006 at 10:34:41AM +0400, Alexey Tourbin wrote:
> Проблема с этим патчем одна -- readlink'и в цикле будут работать долго.
> Приходится ждать заметное время даже на мощной машине (порядка двух
> секунд при линковке с -lSDL). Кстати, оптимизация {esound,libSDL-devel}
> с этим патчем работает агрессивно.
>
> К сожалению, readlink не работает с xargs
[порывшись в сундуке с шляпами мантейнерства разных пакетов]
Говоришь, readlink не работает с xargs? А как ему работать?
Можешь предложить семантику кода возврата?
> (а xargs в свою очередь всегда
> делает word splitting, что критически плохо для имен файлов).
Всегда, говоришь, делает word splitting? А как же -0?
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] readlink
2006-09-03 13:38 ` [devel] readlink Dmitry V. Levin
@ 2006-09-04 7:30 ` Alexey Tourbin
0 siblings, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-04 7:30 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On Sun, Sep 03, 2006 at 05:38:18PM +0400, Dmitry V. Levin wrote:
> On Sun, Sep 03, 2006 at 10:34:41AM +0400, Alexey Tourbin wrote:
> > Проблема с этим патчем одна -- readlink'и в цикле будут работать долго.
> > Приходится ждать заметное время даже на мощной машине (порядка двух
> > секунд при линковке с -lSDL). Кстати, оптимизация {esound,libSDL-devel}
> > с этим патчем работает агрессивно.
> >
> > К сожалению, readlink не работает с xargs
>
> [порывшись в сундуке с шляпами мантейнерства разных пакетов]
>
> Говоришь, readlink не работает с xargs? А как ему работать?
> Можешь предложить семантику кода возврата?
Я в общем-то и не предалагаю чтобы readlink брал несколько путей.
Просто некоторые программы берут, а некоторые не берут. UNIX way в этом
отношении не последователен, но в некоторых случаях удается извернуться.
> > (а xargs в свою очередь всегда
> > делает word splitting, что критически плохо для имен файлов).
> Всегда, говоришь, делает word splitting? А как же -0?
xargs не может брать по одному аргументу на строчку, как
while read -r; do ... ; done; но в дополнение к этому накапливать
аргументы. xargs -I как раз не накапливает аргументы, а тогда это
ничем не лучше чем цикл на шелле.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-09-03 6:34 ` Alexey Tourbin
` (2 preceding siblings ...)
2006-09-03 13:38 ` [devel] readlink Dmitry V. Levin
@ 2006-09-03 17:08 ` Michael Shigorin
2006-09-03 17:39 ` Damir Shayhutdinov
2006-09-04 9:42 ` [devel] xargs usage (Was: Re: оптимизация сборочных зависимостей) Andrei Bulava
5 siblings, 0 replies; 72+ messages in thread
From: Michael Shigorin @ 2006-09-03 17:08 UTC (permalink / raw)
To: ALT Devel discussion list
On Sun, Sep 03, 2006 at 10:34:41AM +0400, Alexey Tourbin wrote:
> К сожалению, readlink не работает с xargs (а xargs в свою
> очередь всегда делает word splitting, что критически плохо для
> имен файлов). Также и awk не умеет делать ничего вроде
> readlink или realpath. Остается только перл. :)
Или ма-аленький бинарник?
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-09-03 6:34 ` Alexey Tourbin
` (3 preceding siblings ...)
2006-09-03 17:08 ` [devel] оптимизация сборочных зависимостей Michael Shigorin
@ 2006-09-03 17:39 ` Damir Shayhutdinov
2006-09-04 7:26 ` Alexey Tourbin
2006-09-04 9:42 ` [devel] xargs usage (Was: Re: оптимизация сборочных зависимостей) Andrei Bulava
5 siblings, 1 reply; 72+ messages in thread
From: Damir Shayhutdinov @ 2006-09-03 17:39 UTC (permalink / raw)
To: ALT Devel discussion list
> К сожалению, readlink не работает с xargs (а xargs в свою очередь всегда
> делает word splitting, что критически плохо для имен файлов).
xargs -n1 поможет программке readlink подружиться с xargs. Правда с
word splitting это не поможет к сожалению :(
Ну вроде в именах пакетов у нас нету пробелов, не так ли?
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-09-03 17:39 ` Damir Shayhutdinov
@ 2006-09-04 7:26 ` Alexey Tourbin
2006-09-04 11:30 ` Денис Смирнов
0 siblings, 1 reply; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-04 7:26 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
On Sun, Sep 03, 2006 at 09:39:50PM +0400, Damir Shayhutdinov wrote:
> > К сожалению, readlink не работает с xargs (а xargs в свою очередь всегда
> > делает word splitting, что критически плохо для имен файлов).
> xargs -n1 поможет программке readlink подружиться с xargs. Правда с
> word splitting это не поможет к сожалению :(
Так смысл xargs в том, чтобы сократить количество exec'ов.
Иначе while read -r f; do readlink "$f"; done подходит гораздо лучше.
> Ну вроде в именах пакетов у нас нету пробелов, не так ли?
Хех.
$ mkdir -p ' /usr/bin'
$ l ' /usr/bin'
total 8
drwxr-xr-x 2 at at 4096 Sep 4 11:22 ./
drwxr-xr-x 3 at at 4096 Sep 4 11:22 ../
$
То есть это в системных файлах пробелов нету, а при сборке пакетов
локальные имена могут быть любыми. Появляется способ "обдурить"
filereq/buildreq, а этого способа быть не должно.
Точнее, я склоняюсь к тому, что следует исходить из того, что в именах
файлов не должно быть control characters, включая tab и newline, а вот
пробел к ним не относится. Если же допустить в именах файлов newline,
тогда список файлов нельзя хранить в текстовом файле, по одному имени
на строчку, а это в общем тоже не фонтан.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-09-04 7:26 ` Alexey Tourbin
@ 2006-09-04 11:30 ` Денис Смирнов
0 siblings, 0 replies; 72+ messages in thread
From: Денис Смирнов @ 2006-09-04 11:30 UTC (permalink / raw)
To: ALT Devel discussion list
On Mon, Sep 04, 2006 at 11:26:42AM +0400, Алексей Турбин wrote:
AT> Точнее, я склоняюсь к тому, что следует исходить из того, что в именах
AT> файлов не должно быть control characters, включая tab и newline, а вот
AT> пробел к ним не относится. Если же допустить в именах файлов newline,
AT> тогда список файлов нельзя хранить в текстовом файле, по одному имени
AT> на строчку, а это в общем тоже не фонтан.
Есть ещё такой чудесный разделитель как '\0'. С которым по крайней мере
find, grep и xargs справляются расчудесно.
--
С уважением, Денис
http://freesource.info
----------------------------------------------------------------------------
Programming is like a sex: one mistake and you have to support it for all your life...
^ permalink raw reply [flat|nested] 72+ messages in thread
* [devel] xargs usage (Was: Re: оптимизация сборочных зависимостей)
2006-09-03 6:34 ` Alexey Tourbin
` (4 preceding siblings ...)
2006-09-03 17:39 ` Damir Shayhutdinov
@ 2006-09-04 9:42 ` Andrei Bulava
2006-09-04 9:50 ` Alexey Tourbin
5 siblings, 1 reply; 72+ messages in thread
From: Andrei Bulava @ 2006-09-04 9:42 UTC (permalink / raw)
To: ALT Devel discussion list
Alexey Tourbin wrote:
> а xargs в свою очередь всегда делает word splitting, что критически
> плохо для имен файлов
Ай-ай-ай, тянет на свидетельство того, что at@ не читал ALT Secure
Packaging Policy http://docs.altlinux.ru/alt/devel/ch01s03.html :-D
2docs@: кстати, я не нашёл его среди
http://heap.altlinux.ru/alt-docs/modules/index.html, спасибо google.
--
// AB1002-UANIC
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] xargs usage (Was: Re: оптимизация сборочных зависимостей)
2006-09-04 9:42 ` [devel] xargs usage (Was: Re: оптимизация сборочных зависимостей) Andrei Bulava
@ 2006-09-04 9:50 ` Alexey Tourbin
0 siblings, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-04 9:50 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 341 bytes --]
On Mon, Sep 04, 2006 at 12:42:52PM +0300, Andrei Bulava wrote:
> > а xargs в свою очередь всегда делает word splitting, что критически
> > плохо для имен файлов
>
> Ай-ай-ай, тянет на свидетельство того, что at@ не читал ALT Secure
> Packaging Policy http://docs.altlinux.ru/alt/devel/ch01s03.html :-D
Ага, и согрешил с обезьяной.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [devel] оптимизация сборочных зависимостей
2006-09-03 4:36 ` Alexey Tourbin
2006-09-03 6:34 ` Alexey Tourbin
@ 2006-09-03 10:57 ` Alexey Tourbin
2006-09-03 17:07 ` Michael Shigorin
2 siblings, 0 replies; 72+ messages in thread
From: Alexey Tourbin @ 2006-09-03 10:57 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]
On Sun, Sep 03, 2006 at 08:36:15AM +0400, Alexey Tourbin wrote:
> 1) Низкоуровневый подход (в меньшей степени). Добавить и использовать
> специальную опцию в packageof. Для каждого заданного файла, помимо
> того, чтобы пробивать его по rpmdb, нужно специальным образом
> обрабатывать симлинки. А именно, для каждого симлинка делать realpath()
> и полученный путь ещё раз пробивать по rpmdb.
>
> Какой недостаток у этого подхода? Это вопрос философский. :)
> То есть недостаток довольно тонкий -- настолько тонкий, что не является
> препятствием для реализации, но непременно подлежит обсуждению.
>
> Речь идет о том, что при использовании симлинка используется не cтолько
> сам симлинк, сколько файл, на который показывает симлинк (симлинк и файл
> могут находится в разных пакетах). При этом симлинк может показывать,
> вообще говоря, куда угодно. Я ведь исхожу из того, что мы достраиваем
> цепочку "вовнутрь", то есть вглубь дерева, а симлинк можеть дать
> результат и "вовне". Здесь можно представить себе альтернативы.
> То есть можно на выходе получить слишком специфические зависимости.
Вот типичная ситуация, в которой проявляется этот недостаток.
/usr/lib/rpm/brp-bytecompile_python:
27 if [ -n "$RPM_PYTHON" -a -x "$RPM_PYTHON" ] && [ `find -type f -name \*.py |wc -l` -gt 0 ]; then
28 echo "Bytecompiling python modules in $PWD using $RPM_PYTHON"
Здесь делается stat (точнее, access) на /usr/bin/python. Этот файл
не принадлежит ни одному из пакетов. Но если следовать правилу
"требование на симлинки распространяется также на файлы, на которые
показывают симлинки", тогда при использовании buildreq -bi в
BuildRequires появится зависимость на текущий питон, установленный
в системе.
Поэтому задача усложняется: не следует применять это правило для
системных вызовов stat, lstat и access. Альтернативный вариант:
правильно не следует приминять, если симлинк не принадлежит какому-либо
пакету.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [devel] оптимизация сборочных зависимостей
2006-09-03 4:36 ` Alexey Tourbin
2006-09-03 6:34 ` Alexey Tourbin
2006-09-03 10:57 ` [devel] оптимизация сборочных зависимостей Alexey Tourbin
@ 2006-09-03 17:07 ` Michael Shigorin
2006-09-04 11:14 ` [devel] esound (was: Re: оптимизация сборочных зависимостей ) Igor Zubkov
2 siblings, 1 reply; 72+ messages in thread
From: Michael Shigorin @ 2006-09-03 17:07 UTC (permalink / raw)
To: ALT Devel discussion list
On Sun, Sep 03, 2006 at 08:36:15AM +0400, Alexey Tourbin wrote:
> Получается, что список {esound,libSDL-devel} не поддается
> оптимизации, потому что из списка выпал собственно libSDL. То
> есть как бы не удается достроить цепочку libSDL-devel -> libSDL
> -> esound, с которой текущая оптимизация дала бы результат.
> Думаю, что эта ситуация довольно типична. Просто в списке
> /etc/buildreqs/packages/essential присутствует паттерн
> ^lib[^-]+$, из-за которого все библиотечные пакеты удаляются; а
> esound не вписывается в это правило по названию.
(из зала) esound вообще запланирован на вписывание в obsolete ;-)
> Этот паттерн сам по себе довольно нечестный. [...]
> Короче, предлагаю в ближайшей перспективе реализовать подход ?1
> -- он достаточно прост в реализации, и у него не
> просматривается грубых недостатков. Нечестный паттерн
> ^lib[^-]+$ после этого по идее станет не нужен.
Раскрывая все дёргаемые симлинки?
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
^ permalink raw reply [flat|nested] 72+ messages in thread* [devel] esound (was: Re: оптимизация сборочных зависимостей )
2006-09-03 17:07 ` Michael Shigorin
@ 2006-09-04 11:14 ` Igor Zubkov
0 siblings, 0 replies; 72+ messages in thread
From: Igor Zubkov @ 2006-09-04 11:14 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 946 bytes --]
В сообщении от 3 сентября 2006 20:07 Michael Shigorin написал(a):
> On Sun, Sep 03, 2006 at 08:36:15AM +0400, Alexey Tourbin wrote:
> > Получается, что список {esound,libSDL-devel} не поддается
> > оптимизации, потому что из списка выпал собственно libSDL. То
> > есть как бы не удается достроить цепочку libSDL-devel -> libSDL
> > -> esound, с которой текущая оптимизация дала бы результат.
> > Думаю, что эта ситуация довольно типична. Просто в списке
> > /etc/buildreqs/packages/essential присутствует паттерн
> > ^lib[^-]+$, из-за которого все библиотечные пакеты удаляются; а
> > esound не вписывается в это правило по названию.
>
> (из зала) esound вообще запланирован на вписывание в obsolete ;-)
И уже очень скоро... В GNOME 2.18 его заменит pulseaudio (бывший polypaudio).
А в 2.20 esound вообще выкинут. Подробности здесь --
http://live.gnome.org/PulseAudio
--
Placebo - Without You I'm Nothing (Feat. David Bowie) (Unkle Remix)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread