[devel] libpixman

[devel] libpixman

[@ 2006-08-30 14:58 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 15:01 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 15:10 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 15:20 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 15:29 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 15:36 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 15:41 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 16:00 UTC (permalink / raw)]

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

[@ 2006-08-30 16:10 UTC (permalink / raw)]

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

[@ 2006-08-30 16:28 UTC (permalink / raw)]

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

[@ 2006-08-30 16:43 UTC (permalink / raw)]

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

[@ 2006-08-30 18:30 UTC (permalink / raw)]

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

[@ 2006-08-30 19:07 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 19:28 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 19:38 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 19:39 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 19:45 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 19:52 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 19:53 UTC (permalink / raw)]

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

[@ 2006-08-30 19:57 UTC (permalink / raw)]

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

[@ 2006-08-30 20:12 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 20:19 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 20:20 UTC (permalink / raw)]

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

[@ 2006-08-30 20:29 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-30 20:31 UTC (permalink / raw)]

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

[@ 2006-08-30 20:57 UTC (permalink / raw)]

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

[@ 2006-08-30 21:01 UTC (permalink / raw)]

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

[@ 2006-08-30 21:17 UTC (permalink / raw)]

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

[@ 2006-08-30 22:48 UTC (permalink / raw)]

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

[@ 2006-08-30 23:19 UTC (permalink / raw)]

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

[@ 2006-08-30 23:45 UTC (permalink / raw)]

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

[@ 2006-08-31 0:17 UTC (permalink / raw)]

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

[@ 2006-08-31 0:27 UTC (permalink / raw)]

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

[@ 2006-08-31 0:59 UTC (permalink / raw)]

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

[@ 2006-08-31 4:05 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-31 5:36 UTC (permalink / raw)]

Re: [devel] libpixman

[@ 2006-08-31 6:11 UTC (permalink / raw)]

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

[@ 2006-08-31 12:29 UTC (permalink / raw)]

[devel] buildreq ignore.d/fonts-cache

[@ 2006-08-31 20:06 UTC (permalink / raw)]

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