[devel] libpixman

[devel] libpixman

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

Пакеты libpixman и libpixman-devel до недавнего времени предоставлялись
пакетами libcairo и libcairo-devel соответственно.  Недавно эти provides
были из cairo удалены.  Используйте buildreq при каждой сборке пакета!

> Package: eclipse-3.1.1-alt2
> E: Couldn't find package libpixman-devel

> Package: firefox-1.5.0.6-alt3
> E: Couldn't find package libpixman-devel

> Package: ksquirrel-libs-0.6.3-alt1
> E: Couldn't find package libpixman-devel

> Package: libgdiplus-1.1.13.6-alt1
> E: Couldn't find package libpixman-devel

> Package: libsvg-cairo-0.1.6-alt1.1
> E: Couldn't find package libpixman-devel

> Package: xulrunner-1.8.0.1-alt2
> E: Couldn't find package libpixman-devel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

On Wed, Aug 30, 2006 at 06:58:57PM +0400, Alexey Tourbin wrote:
> Пакеты libpixman и libpixman-devel до недавнего времени предоставлялись
> пакетами libcairo и libcairo-devel соответственно.  Недавно эти provides
> были из cairo удалены.

Есть ли смысл добавить в пакет libcairo-devel зависимость на
libpixman-devel?

> Используйте buildreq при каждой сборке пакета!

Ну это, пожалуй, overkill.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Wed, Aug 30, 2006 at 07:01:42PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 30, 2006 at 06:58:57PM +0400, Alexey Tourbin wrote:
> > Пакеты libpixman и libpixman-devel до недавнего времени предоставлялись
> > пакетами libcairo и libcairo-devel соответственно.  Недавно эти provides
> > были из cairo удалены.
> 
> Есть ли смысл добавить в пакет libcairo-devel зависимость на
> libpixman-devel?

Нет.  Нет такого пакета libpixman-devel.  Точнее, libpixman лежит в
orphaned.  А в libcairo-devel предыдущий maintainer дописал Provides:
libpixman-devel.  Я эту клаузу Provides недавно удалил.

> > Используйте buildreq при каждой сборке пакета!
> Ну это, пожалуй, overkill.

Так почему бы не проверить, что список BuildRequires не изменился?
А если изменился, почему бы не попытаться это осознать?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

> > > Используйте buildreq при каждой сборке пакета!
> >
> > Ну это, пожалуй, overkill.
>
> Так почему бы не проверить, что список BuildRequires не изменился?
> А если изменился, почему бы не попытаться это осознать?

золотые слова! Спасибо, Лешь.

"Лучше день потерять, потом за пять минут долететь" (с)

-- 
Valery V. Inozemtsev

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Wed, Aug 30, 2006 at 07:10:53PM +0400, Alexey Tourbin wrote:
> On Wed, Aug 30, 2006 at 07:01:42PM +0400, Dmitry V. Levin wrote:
> > On Wed, Aug 30, 2006 at 06:58:57PM +0400, Alexey Tourbin wrote:
> > > Пакеты libpixman и libpixman-devel до недавнего времени предоставлялись
> > > пакетами libcairo и libcairo-devel соответственно.  Недавно эти provides
> > > были из cairo удалены.
> > 
> > Есть ли смысл добавить в пакет libcairo-devel зависимость на
> > libpixman-devel?
> 
> Нет.  Нет такого пакета libpixman-devel.  Точнее, libpixman лежит в
> orphaned.  А в libcairo-devel предыдущий maintainer дописал Provides:
> libpixman-devel.  Я эту клаузу Provides недавно удалил.

Да, пожалуй.

> > > Используйте buildreq при каждой сборке пакета!
> > Ну это, пожалуй, overkill.
> 
> Так почему бы не проверить, что список BuildRequires не изменился?
> А если изменился, почему бы не попытаться это осознать?

Ну не при каждой же сборке!


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

> > > > Используйте buildreq при каждой сборке пакета!
> > >
> > > Ну это, пожалуй, overkill.
> >
> > Так почему бы не проверить, что список BuildRequires не изменился?
> > А если изменился, почему бы не попытаться это осознать?
>
> Ну не при каждой же сборке!

хотя бы раз в год. последний раз разговор о xvfb-run был как раз с год назад

-- 
Valery V. Inozemtsev

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

On Wed, Aug 30, 2006 at 07:36:24PM +0400, Valery V. Inozemtsev wrote:
> > > > > Используйте buildreq при каждой сборке пакета!
> > > >
> > > > Ну это, пожалуй, overkill.
> > >
> > > Так почему бы не проверить, что список BuildRequires не изменился?
> > > А если изменился, почему бы не попытаться это осознать?
> >
> > Ну не при каждой же сборке!
> 
> хотя бы раз в год. последний раз разговор о xvfb-run был как раз с год назад

С тех пор xvfb-run просто никто не собирал. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]

On Wed, Aug 30, 2006 at 07:29:46PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 30, 2006 at 07:10:53PM +0400, Alexey Tourbin wrote:
> > On Wed, Aug 30, 2006 at 07:01:42PM +0400, Dmitry V. Levin wrote:
> > > On Wed, Aug 30, 2006 at 06:58:57PM +0400, Alexey Tourbin wrote:
> > > > Пакеты libpixman и libpixman-devel до недавнего времени предоставлялись
> > > > пакетами libcairo и libcairo-devel соответственно.  Недавно эти provides
> > > > были из cairo удалены.
> > > 
> > > Есть ли смысл добавить в пакет libcairo-devel зависимость на
> > > libpixman-devel?
> > 
> > Нет.  Нет такого пакета libpixman-devel.  Точнее, libpixman лежит в
> > orphaned.  А в libcairo-devel предыдущий maintainer дописал Provides:
> > libpixman-devel.  Я эту клаузу Provides недавно удалил.
> 
> Да, пожалуй.

Ситуация на самом деле вот какая.  Когда-то пакеты libcairo для сборки и
для работы фактически требовали пакеты libpixman:

$ rpm -qpR archive/Sisyphus/2005/01/01/files/i586/RPMS/libcairo-0.1.23-alt2.i586.rpm |grep pixman
libpixman.so.1  
$ rpm -qpR archive/Sisyphus/2005/01/01/files/i586/RPMS/libcairo-devel-0.1.23-alt2.i586.rpm |grep pixman
libpixman-devel
$

Потом libpixman стал частью библиотеки libcairo, а сам пакет libpixman
стал не нужен.  Но, поскольку buildreq не оптимизирует зависимости, во
всех пакетах, в которых была зависимость на libcairo-devel, осталась
также зависимость и на libpixman-devel.  Поэтому на переходный период
имело смысл вставить в libcairo-devel "зависимость" Provides:
libpixman-devel, чтобы сохранить пересобираемость пакетов с новым cairo.
Семантически этот provides в данном случае означает "пакет
libpixman-devel для сборки с cairo больше не нужен".  Но это не совсем
корректно.  Поэтому пришло время этот provides удалить.

Кстати, большая часть перечисленных пакетов, которые теперь не
собираются из-за сборочной зависимости на libpixman-devel, на самом деле
не собирались и раньше по другим причинам.  Поэтому "собственные"
разрушения от этого изменения невелики.

Если бы buildreq оптимизировал спискок BuildRequires по принципу
"libcairo-devel требует libpixman-devel, поэтому libpixman-devel можно
выкинуть из списка BuildRequires", тогда этой проблемы вообще не
возникло.  Но оптимизация по этому принципу семантически тоже не совсем
корректна.  Ведь Пакет libpixman-devel может требоваться не только для
сборки с cairo, но и собственно для сборки пакета.  В последнем случае
зависимость на libpixman-devel стоило бы оставить.  Но имея на руках вывод
strace, в общем-то нелегко определить, использовался ли libpixman-devel
*исключительно* для сборки с cairo или нет.  И всё же оптимизация списка
BuildRequires в большинстве случаев предпочтительнее: при сборке сложных
пакетов неоптимизированный список становится настолько большим, что
теряется информативность.

(Алгоритм оптимизации BuildRequires обсуждался вчера в частной
переписке.  Правда, спросонья я потерял к нему интерес.  Если это
интересно кому-то ещё, тогда можно перенести обсуждение сюда.)

> > Так почему бы не проверить, что список BuildRequires не изменился?
> > А если изменился, почему бы не попытаться это осознать?
> Ну не при каждой же сборке!

Проверять можно всегда.  Меняется не только сам пакет (тогда стоило бы
поверять только при увеличении версии), меняется и репозиторий, и
сборочная среда.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] оптимизация сборочных зависимостей

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Wed, Aug 30, 2006 at 08:00:36PM +0400, Alexey Tourbin wrote:
[...]
> Потом libpixman стал частью библиотеки libcairo, а сам пакет libpixman
> стал не нужен.  Но, поскольку buildreq не оптимизирует зависимости,

Оптимизирует, ещё как оптимизирует.

[...]
> Если бы buildreq оптимизировал спискок BuildRequires по принципу
> "libcairo-devel требует libpixman-devel, поэтому libpixman-devel можно
> выкинуть из списка BuildRequires",

buildreq делает эту оптимизацию, причём не самым честным образом.
Если зависимости образуют цикл, то packagereq выкинет весь цикл.

[...]
> (Алгоритм оптимизации BuildRequires обсуждался вчера в частной
> переписке.  Правда, спросонья я потерял к нему интерес.  Если это
> интересно кому-то ещё, тогда можно перенести обсуждение сюда.)

Думаю, что лучше перенести сюда - вдруг среди нас есть специалист/практик
по теории графов?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] libpixman

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

> > > > Используйте buildreq при каждой сборке пакета!
> > > Ну это, пожалуй, overkill.
> > 
> > Так почему бы не проверить, что список BuildRequires не изменился?
> > А если изменился, почему бы не попытаться это осознать?
> 
> Ну не при каждой же сборке!

Отчего же не при каждой. Только если не вручную.
Какие есть сложности в том, чтобы при пересборке пакета запустить 
buildreq, сравнить возвращённую им строку с имеющейся в спеке, 
при любом несовпадении выдать предупреждение/ошибку?
Это не риторический вопрос.

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Wed, Aug 30, 2006 at 11:28:37PM +0400, Kirill Maslinsky wrote:
> Какие есть сложности в том, чтобы при пересборке пакета запустить 
> buildreq, сравнить возвращённую им строку с имеющейся в спеке, 
> при любом несовпадении выдать предупреждение/ошибку?
Ужасно.
Тут практически все присутствующие правят билдреки руками в той или иной
степени.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

У нас много всяких примеров разной степени правильности ;)
		-- inger in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libpixman

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Wed, Aug 30, 2006 at 11:28:37PM +0400, Kirill Maslinsky wrote:
> > > > > Используйте buildreq при каждой сборке пакета!
> > > > Ну это, пожалуй, overkill.
> > > 
> > > Так почему бы не проверить, что список BuildRequires не изменился?
> > > А если изменился, почему бы не попытаться это осознать?
> > 
> > Ну не при каждой же сборке!
> 
> Отчего же не при каждой. Только если не вручную.
> Какие есть сложности в том, чтобы при пересборке пакета запустить 
> buildreq, сравнить возвращённую им строку с имеющейся в спеке, 
> при любом несовпадении выдать предупреждение/ошибку?
> Это не риторический вопрос.

И где же предлагается автоматически запускать buildreq?
Уж не в чруте ли, инициализированном предыдущем значением buildreq? :)

(В том то и проблема, что buildreq имеет смысл делать в достаточно
богатой хост-системе, чтобы посмотреть, что он ещё может зацепить.
А когда цеплять больше нечего, он ничего и не зацепит.)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

Hi Alexey!

Wednesday 30, at 11:39:23 PM you wrote:

> On Wed, Aug 30, 2006 at 11:28:37PM +0400, Kirill Maslinsky wrote:
> > > > > > Используйте buildreq при каждой сборке пакета!
> > > > > Ну это, пожалуй, overkill.
> > > > 
> > > > Так почему бы не проверить, что список BuildRequires не изменился?
> > > > А если изменился, почему бы не попытаться это осознать?
> > > 
> > > Ну не при каждой же сборке!
> > 
> > Отчего же не при каждой. Только если не вручную.
> > Какие есть сложности в том, чтобы при пересборке пакета запустить 
> > buildreq, сравнить возвращённую им строку с имеющейся в спеке, 
> > при любом несовпадении выдать предупреждение/ошибку?
> > Это не риторический вопрос.
> 
> И где же предлагается автоматически запускать buildreq?
> Уж не в чруте ли, инициализированном предыдущем значением buildreq? :)
> 
> (В том то и проблема, что buildreq имеет смысл делать в достаточно
> богатой хост-системе, чтобы посмотреть, что он ещё может зацепить.
> А когда цеплять больше нечего, он ничего и не зацепит.)
тогда какой в этом смысл, если это недостижимо? Проще сделать один раз
buildreq в hasher, а потом отслеживать ситуацию самостоятельно. В добавок,
при наличии --as-needed, перебор в buildrequires - это не страшно.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

On Thu, Aug 31, 2006 at 01:38:41AM +0600, Andrey Rahmatullin wrote:
> > Какие есть сложности в том, чтобы при пересборке пакета запустить 
> > buildreq, сравнить возвращённую им строку с имеющейся в спеке, 
> > при любом несовпадении выдать предупреждение/ошибку?
> Ужасно.
> Тут практически все присутствующие правят билдреки руками в той или иной
> степени.

Можно примеры?

При достаточно агрессивном алгоритме оптимизации вручную править
билдреки уже будет очень рискованно.  Так, удаляя какой-либо пакет
из BuildRequires, тем самым удаляются и все его пререквизиты (кроме
тех, которые по случаю являются пререквизитами оставшихся пакетов).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

On Wed, Aug 30, 2006 at 11:45:55PM +0400, Konstantin A. Lepikhov wrote:
> > (В том то и проблема, что buildreq имеет смысл делать в достаточно
> > богатой хост-системе, чтобы посмотреть, что он ещё может зацепить.
> > А когда цеплять больше нечего, он ничего и не зацепит.)
> тогда какой в этом смысл, если это недостижимо? Проще сделать один раз
> buildreq в hasher, а потом отслеживать ситуацию самостоятельно. В добавок,
> при наличии --as-needed, перебор в buildrequires - это не страшно.

Я и говорю: наибольший смысл есть делать buildreq в хост-системе,
в которой вы собираете и тестируете пакет.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] buildreq при каждой сборке?

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

> > Какие есть сложности в том, чтобы при пересборке пакета запустить 
> > buildreq, сравнить возвращённую им строку с имеющейся в спеке, 
> > при любом несовпадении выдать предупреждение/ошибку?
> Ужасно.
> Тут практически все присутствующие правят билдреки руками в той или иной
> степени.

Так-так. 
Проблема номер 1: 
В строке BuildRequires спека фактически оказывается смешана 
информация двух типов: 
a) автоматически полученный список сборочных зависимостей (buildreq)
б) список исключений (в обе стороны: по сокращению и расширению зависимостей),
   внесённых вручную сопровождающим пакет.

Вариант решения: 
Таки разделить разнородную информацию. Отдельно хранить список, полученный
автоматически, отдельно -- исключения.

Обоснование:
Сравнение списка а) полученного в сборке A пакета со списком a) полученного 
в сборке B может выполняться автоматически и давать ненулевую информацию.

/ Временно забудем про хост-системы, в которых проходили сборки A и B. 
Предположим, что это были "хорошие" для данной задачи системы. :) /

Пример для сравнения:
Автопоиск зависимостей для питоньих модулей. 
И макросы для внесения исключений в результаты поиска.

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] оптимизация сборочных зависимостей

[Sergey Vlasov]

[-- 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 --]

Re: [devel] libpixman

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

> > Отчего же не при каждой. Только если не вручную.
> > Какие есть сложности в том, чтобы при пересборке пакета запустить 
> > buildreq, сравнить возвращённую им строку с имеющейся в спеке, 
> > при любом несовпадении выдать предупреждение/ошибку?
> > Это не риторический вопрос.
> 
> И где же предлагается автоматически запускать buildreq?
> Уж не в чруте ли, инициализированном предыдущем значением buildreq? :)
> 
> (В том то и проблема, что buildreq имеет смысл делать в достаточно
> богатой хост-системе, чтобы посмотреть, что он ещё может зацепить.
> А когда цеплять больше нечего, он ничего и не зацепит.)

Так-так.
Проблема номер 2:
При выполнении buildreq требования к сборочной среде удивительным
образом отличаются от требований к ней же при собственно сборке.
Если при сборке так или иначе ставится задача минимизации сборочной
среды, то при построении списка сборочных зависимостей задача 
прямо противоположная -- максимизация сборочной среды.

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

Возможное решение:
Почему бы не сделать ту систему, в которой нужно запускать buildreq 
не "релевантно максимальной", как это делает человек, а 
абсолютно максимальной? (условно -- все пакеты репозитория)
Тогда операцию автовычисления зависимостей можно было бы проводить
при каждой сборке пакета автоматически, и результаты этих 
операций для соседних сборок, мне кажется, были бы небесполезно сравнимы.

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libpixman

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Wed, Aug 30, 2006 at 11:52:07PM +0400, Alexey Tourbin wrote:
> On Thu, Aug 31, 2006 at 01:38:41AM +0600, Andrey Rahmatullin wrote:
> > > Какие есть сложности в том, чтобы при пересборке пакета запустить 
> > > buildreq, сравнить возвращённую им строку с имеющейся в спеке, 
> > > при любом несовпадении выдать предупреждение/ошибку?
> > Ужасно.
> > Тут практически все присутствующие правят билдреки руками в той или иной
> > степени.
> 
> Можно примеры?
> 
> При достаточно агрессивном алгоритме оптимизации вручную править
> билдреки уже будет очень рискованно.  Так, удаляя какой-либо пакет
> из BuildRequires, тем самым удаляются и все его пререквизиты (кроме
> тех, которые по случаю являются пререквизитами оставшихся пакетов).

Во многих случаях buildreq даёт плохие результаты не из-за плохой
оптимизации, а из-за того, что применяемый в нём метод определения
используемых при сборке пакетов (отслеживание обращений к файлам через
strace) подвержен ложным срабатываниям.  Например, довольно часто в
выводе buildreq оказываются все установленные в системе шрифтовые
пакеты.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] libpixman

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On Thu, Aug 31, 2006 at 12:20:11AM +0400, Sergey Vlasov wrote:
> Во многих случаях buildreq даёт плохие результаты не из-за плохой
> оптимизации, а из-за того, что применяемый в нём метод определения
> используемых при сборке пакетов (отслеживание обращений к файлам через
> strace) подвержен ложным срабатываниям.  Например, довольно часто в
> выводе buildreq оказываются все установленные в системе шрифтовые
> пакеты.

Где-нибудь в ignore есть что-нибудь вроде
^/usr/share/fonts/.*/fonts[.]cache
?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] оптимизация сборочных зависимостей

[Damir Shayhutdinov]

> Далее, я знаю, как обнаруживать циклы.  Нужно сделать соединение ещё раз
> само на себя и проверить, не совпадают ли начальный и конечный элементы.
> Не понтяно правда, что потом делать с обнаруженными таким образом циклами.
Заменять на любой пакет из цикла - то есть, как говорил Сергей,
схлопывать циклы в одну вершину.

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Денис Смирнов]

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@

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] libpixman

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Wed, Aug 30, 2006 at 11:52:07PM +0400, Alexey Tourbin wrote:
> Можно примеры?
g77


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Да, создание коммьюнити техписов -- это вам не пряники под
одеялом хрумкать. Техписов всегда мало, тем более грамотных
техписов. А их ещё и организовать надо.
		-- avp in docs@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libpixman

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

* Alexey Tourbin <at@> [060830 23:53]:
> > > Какие есть сложности в том, чтобы при пересборке пакета запустить 
> > > buildreq, сравнить возвращённую им строку с имеющейся в спеке, 
> > > при любом несовпадении выдать предупреждение/ошибку?
> > Ужасно.
> > Тут практически все присутствующие правят билдреки руками в той или иной
> > степени.
> Можно примеры?
*-devel-static, linux-libc-headers, gcc-fortran.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] оптимизация сборочных зависимостей

[Sergey Vlasov]

[-- 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 --]

[devel] buildreq ignore.d/fonts-cache

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Thu, Aug 31, 2006 at 12:31:00AM +0400, Alexey Tourbin wrote:
> On Thu, Aug 31, 2006 at 12:20:11AM +0400, Sergey Vlasov wrote:
> > Во многих случаях buildreq даёт плохие результаты не из-за плохой
> > оптимизации, а из-за того, что применяемый в нём метод определения
> > используемых при сборке пакетов (отслеживание обращений к файлам через
> > strace) подвержен ложным срабатываниям.  Например, довольно часто в
> > выводе buildreq оказываются все установленные в системе шрифтовые
> > пакеты.
> 
> Где-нибудь в ignore есть что-нибудь вроде
> ^/usr/share/fonts/.*/fonts[.]cache
> ?

Вот что buildreq изначально вычислил при сборке perl-Gtk2:

# Automatically added by buildreq on Thu Aug 31 2006
BuildRequires: dmtr40in-fonts fonts-bitmap-terminus fonts-bitmap-univga fonts-ttf-dejavu fonts-type1-urw freefont-fonts-ttf gost-fonts-ttf gw-fonts-ttf icon-theme-hicolor latex-xft-fonts-ttf libXcursor-devel libgtk+2-devel ms-fonts-ttf perl-Cairo-devel perl-ExtUtils-Depends perl-ExtUtils-PkgConfig perl-Glib-devel phonetic-fonts-type1 val-fonts-ttf vera-fonts-ttf xvfb-run znamen-fonts-ttf

Вот что buildreq вычислил при добавлении предложенного правила:

# Automatically added by buildreq on Fri Sep 01 2006
BuildRequires: icon-theme-hicolor libXcursor-devel libgtk+2-devel ms-fonts-ttf perl-Cairo-devel perl-ExtUtils-Depends perl-ExtUtils-PkgConfig perl-Glib-devel xvfb-run

То есть, похоже, при сборке и make test реально использовались только
шрифты ms-fonts-ttf.  Что похоже на правду.

$ cat /etc/buildreqs/files/ignore.d/fonts 
^/usr/share/fonts/.*/fonts[.]cache
$

В какой пакет лучше всего положить этот файл?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] buildreq2 (was: libpixman)

[Michael Shigorin]

On Wed, Aug 30, 2006 at 08:00:36PM +0400, Alexey Tourbin wrote:
> (Алгоритм оптимизации BuildRequires обсуждался вчера в частной
> переписке.  Правда, спросонья я потерял к нему интерес.  Если это
> интересно кому-то ещё, тогда можно перенести обсуждение сюда.)

Переноси, конечно.  Мне buildreq2 уже однажды здорово помог при
создании дистрибутивоопределяющей "пустышки".  С меня причитается.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] оптимизация сборочных зависимостей

[Michael Shigorin]

[-- 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 --]

Re: [devel] libpixman

[Michael Shigorin]

On Wed, Aug 30, 2006 at 11:52:07PM +0400, Alexey Tourbin wrote:
> > Тут практически все присутствующие правят билдреки руками в
> > той или иной степени.
> Можно примеры?

Фортран.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] buildreq ignore.d/fonts-cache

[Michael Shigorin]

On Fri, Sep 01, 2006 at 12:06:13AM +0400, Alexey Tourbin wrote:
> $ cat /etc/buildreqs/files/ignore.d/fonts 
> ^/usr/share/fonts/.*/fonts[.]cache
> $
> В какой пакет лучше всего положить этот файл?

fontconfig или rpm-utils? (/usr/share/fonts/ принадлежит filesystem)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] buildreq ignore.d/fonts-cache

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On Sat, Sep 02, 2006 at 07:42:47PM +0300, Michael Shigorin wrote:
> On Fri, Sep 01, 2006 at 12:06:13AM +0400, Alexey Tourbin wrote:
> > $ cat /etc/buildreqs/files/ignore.d/fonts 
> > ^/usr/share/fonts/.*/fonts[.]cache
> > $
> > В какой пакет лучше всего положить этот файл?
> 
> fontconfig или rpm-utils? (/usr/share/fonts/ принадлежит filesystem)

OK, пусть будет rpm-utils.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] buildreq2 (was: libpixman)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Sat, Sep 02, 2006 at 07:24:44PM +0300, Michael Shigorin wrote:
> On Wed, Aug 30, 2006 at 08:00:36PM +0400, Alexey Tourbin wrote:
> > (Алгоритм оптимизации BuildRequires обсуждался вчера в частной
> > переписке.  Правда, спросонья я потерял к нему интерес.  Если это
> > интересно кому-то ещё, тогда можно перенести обсуждение сюда.)
> 
> Переноси, конечно.  Мне buildreq2 уже однажды здорово помог при
> создании дистрибутивоопределяющей "пустышки".  С меня причитается.

Чем именно помог?  Не понял.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] buildreq FRs

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

On Sat, Sep 02, 2006 at 07:24:44PM +0300, Michael Shigorin wrote:
> On Wed, Aug 30, 2006 at 08:00:36PM +0400, Alexey Tourbin wrote:
> > (Алгоритм оптимизации BuildRequires обсуждался вчера в частной
> > переписке.  Правда, спросонья я потерял к нему интерес.  Если это
> > интересно кому-то ещё, тогда можно перенести обсуждение сюда.)
> 
> Переноси, конечно.  Мне buildreq2 уже однажды здорово помог при
> создании дистрибутивоопределяющей "пустышки".  С меня причитается.

Мне в buildreq не хватало нескольких вещей, вседствие чего и появился
экспериментальный buildreq2.

1) Оптимизация списка пакетов.  У сложных пакетов список не умещался ни
в одну строчку, ни в две, а иногда занимал и больше трёх.  Список был
мало информативным для человека.  Многие редактировали его вручную.
Оптимизация там была, но она была основна на назвинии пакетов, а не на
зависимостях между пакетами (вследствие чего иногда лажалась).

Я писал об этом ещё в 2003 году "buildreq proposal".  Правда, тогда я
не понимал многих вещей, таких как "всякий частичный порядок может быть
дополнен до линейного".  В buildreq2 реализован эвристический алгоритм,
в котором вместо топологической сортировки используется сортировка по
числу зависимостей у пакета.

Теперь я предложил более правильный алгоритм для buildreq.

2) Полный список файлов, которые зацепились при сборке, сгруппированный
по пакетам.  Это сделать несложно, но в рамках нескольких маленьких
скриптов это сложно сделать красиво.

3) Трассировка.  Иногда хочется знать, где именно при сборке цепляется
тот или иной файл, или любой файл из какого-либо пакета.  Здесь есть
неприятные тонкости, потому что имя путей на выходе из strace не
каноникализировано, а каноникализация типа realpath() может дать совсем
другой пакет (если исходный путь -- симлинк).  Дёргать же на каждый файл
rpmdb -- очень дорого.  Опять же возможны подходы (в buildreq2
реализован не совсем корректный), но в рамках нескольких скриптов,
каждый из который "хорошо делает только одну вещь", трудно найти
красивый подход.

UNIX way оказывается недостаточно гибким, когда нужно вклиниться где-то
внутри.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] readlink

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Michael Shigorin]

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/

Re: [devel] оптимизация сборочных зависимостей

[Michael Shigorin]

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/

Re: [devel] buildreq2 (was: libpixman)

[Michael Shigorin]

On Sun, Sep 03, 2006 at 05:29:48AM +0400, Alexey Tourbin wrote:
> > > (Алгоритм оптимизации BuildRequires обсуждался вчера в частной
> > > переписке.  Правда, спросонья я потерял к нему интерес.  Если это
> > > интересно кому-то ещё, тогда можно перенести обсуждение сюда.)
> > Переноси, конечно.  Мне buildreq2 уже однажды здорово помог
> > при создании дистрибутивоопределяющей "пустышки".  С меня
> > причитается.
> Чем именно помог?  Не понял.

Надо было минимизировать список пакетов уже сформированной 
системы для организации "контрольного пакета" (к которому 
потом отдельные добавления руками делались после причёсывания,
но это уже другая песня).  Вот тут и помог сделать из `rpm -qa` 
нечто обозримое и понятное ("листочки").

Бишь для реверса модельных систем в правила построения тех же
VA такие тулзени тоже полезны.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] buildreq FRs

[Michael Shigorin]

On Sun, Sep 03, 2006 at 06:00:02AM +0400, Alexey Tourbin wrote:
> Дёргать же на каждый файл rpmdb -- очень дорого.

Да, тут явно не хватает caching layer.  В голову пришёл
contents_index, но его наличие настолько факультативно,
положение настолько малоопределённо, а актуальность так
сомнительна, что это не вариант.

> UNIX way оказывается недостаточно гибким, когда нужно
> вклиниться где-то внутри.

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] оптимизация сборочных зависимостей

[Damir Shayhutdinov]

> К сожалению, readlink не работает с xargs (а xargs в свою очередь всегда
> делает word splitting, что критически плохо для имен файлов).
xargs -n1 поможет программке readlink подружиться с xargs. Правда с
word splitting это не поможет к сожалению :(

Ну вроде в именах пакетов у нас нету пробелов, не так ли?

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] readlink

[Alexey Tourbin]

[-- 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 --]

[devel] xargs usage (Was: Re: оптимизация сборочных зависимостей)

[Andrei Bulava]

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

Re: [devel] xargs usage (Was: Re: оптимизация сборочных зависимостей)

[Alexey Tourbin]

[-- 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 --]

[devel] esound (was: Re: оптимизация сборочных зависимостей )

[Igor Zubkov]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Денис Смирнов]

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...

Re: [devel] оптимизация сборочных зависимостей (buildreq)

[Ildar Mulyukov]

	Дорогой Алексей Турбин,
сегодня Ваше творение доехало до репозитария и было мной опробовано.  
Результат радует.

Что бросилось в глаза:
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
=========================================

Re: [devel] оптимизация сборочных зависимостей (buildreq)

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей (buildreq)

[Ildar Mulyukov]

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
=========================================

Re: [devel] оптимизация сборочных зависимостей (buildreq)

[Michael Shigorin]

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/

Re: [devel] оптимизация сборочных зависимостей (buildreq)

[Alexey Tourbin]

[-- 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 --]

Re: [devel] оптимизация сборочных зависимостей (buildreq)

[Michael Shigorin]

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/

Re: [devel] оптимизация сборочных зависимостей (buildreq)

[Ildar Mulyukov]

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
=========================================