ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Alexey Tourbin <at@altlinux.ru>
To: ALT Devel discussion list <devel@lists.altlinux.org>
Subject: Re: [devel] оптимизация сборочных зависимостей
Date: Sun, 3 Sep 2006 08:36:15 +0400
Message-ID: <20060903043615.GF7789@localhost.localdomain> (raw)
In-Reply-To: <20060830161050.GA31919@basalt.office.altlinux.org>

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

  parent reply	other threads:[~2006-09-03  4:36 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 14:58 [devel] libpixman Alexey Tourbin
2006-08-30 15:01 ` Dmitry V. Levin
2006-08-30 15:10   ` Alexey Tourbin
2006-08-30 15:20     ` Valery V. Inozemtsev
2006-08-30 15:29     ` Dmitry V. Levin
2006-08-30 15:36       ` Valery V. Inozemtsev
2006-08-30 15:41         ` Dmitry V. Levin
2006-08-30 16:00       ` Alexey Tourbin
2006-08-30 16:10         ` [devel] оптимизация сборочных зависимостей Dmitry V. Levin
2006-08-30 16:28           ` Alexey Tourbin
2006-08-30 16:43             ` Dmitry V. Levin
2006-08-30 18:30               ` Alexey Tourbin
2006-08-30 20:12               ` Sergey Vlasov
2006-08-30 21:01                 ` Alexey Tourbin
2006-08-30 22:48                   ` Alexey Tourbin
2006-08-30 23:19                     ` Alexey Tourbin
2006-08-31  0:17                       ` Денис Смирнов
2006-08-31  4:05                       ` Alexey Tourbin
2006-09-05 13:10                         ` [devel] оптимизация сборочных зависимостей (buildreq) Ildar Mulyukov
2006-09-05 13:48                           ` Alexey Tourbin
2006-09-05 14:57                             ` Ildar Mulyukov
2006-09-05 18:15                           ` Michael Shigorin
2006-09-05 19:08                             ` Alexey Tourbin
2006-09-05 19:15                               ` Michael Shigorin
2006-09-06  4:06                                 ` Ildar Mulyukov
2006-08-30 23:45                     ` [devel] оптимизация сборочных зависимостей Dmitry V. Levin
2006-08-31  0:27                       ` Alexey Tourbin
2006-08-31  0:59                         ` Alexey Tourbin
2006-09-02 16:34                         ` Michael Shigorin
2006-09-03  2:12                           ` Alexey Tourbin
2006-08-30 19:07           ` Alexey Tourbin
2006-08-30 20:29           ` Alexey Tourbin
2006-08-30 20:57             ` Damir Shayhutdinov
2006-08-30 21:17               ` Dmitry V. Levin
2006-08-31 12:29                 ` Sergey Vlasov
2006-09-05 14:28                 ` Alexey Tourbin
2006-09-03  4:36           ` Alexey Tourbin [this message]
2006-09-03  6:34             ` Alexey Tourbin
2006-09-03  6:52               ` Alexey Tourbin
2006-09-03  6:56               ` Alexey Tourbin
2006-09-03 13:38               ` [devel] readlink Dmitry V. Levin
2006-09-04  7:30                 ` Alexey Tourbin
2006-09-03 17:08               ` [devel] оптимизация сборочных зависимостей Michael Shigorin
2006-09-03 17:39               ` Damir Shayhutdinov
2006-09-04  7:26                 ` Alexey Tourbin
2006-09-04 11:30                   ` Денис Смирнов
2006-09-04  9:42               ` [devel] xargs usage (Was: Re: оптимизация сборочных зависимостей) Andrei Bulava
2006-09-04  9:50                 ` Alexey Tourbin
2006-09-03 10:57             ` [devel] оптимизация сборочных зависимостей Alexey Tourbin
2006-09-03 17:07             ` Michael Shigorin
2006-09-04 11:14               ` [devel] esound (was: Re: оптимизация сборочных зависимостей ) Igor Zubkov
2006-09-02 16:24         ` [devel] buildreq2 (was: libpixman) Michael Shigorin
2006-09-03  1:29           ` Alexey Tourbin
2006-09-03 17:11             ` Michael Shigorin
2006-09-03  2:00           ` [devel] buildreq FRs Alexey Tourbin
2006-09-03 17:16             ` Michael Shigorin
2006-08-30 19:28       ` [devel] libpixman Kirill Maslinsky
2006-08-30 19:38         ` Andrey Rahmatullin
2006-08-30 19:52           ` Alexey Tourbin
2006-08-30 20:20             ` Sergey Vlasov
2006-08-30 20:31               ` Alexey Tourbin
2006-08-31 20:06                 ` [devel] buildreq ignore.d/fonts-cache Alexey Tourbin
2006-09-02 16:42                   ` Michael Shigorin
2006-09-02 17:17                     ` Dmitry V. Levin
2006-08-31  5:36             ` [devel] libpixman Andrey Rahmatullin
2006-08-31  6:11             ` Alexey I. Froloff
2006-09-02 16:40             ` Michael Shigorin
2006-08-30 19:57           ` [devel] buildreq при каждой сборке? Kirill Maslinsky
2006-08-30 19:39         ` [devel] libpixman Alexey Tourbin
2006-08-30 19:45           ` Konstantin A. Lepikhov
2006-08-30 19:53             ` Alexey Tourbin
2006-08-30 20:19           ` Kirill Maslinsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060903043615.GF7789@localhost.localdomain \
    --to=at@altlinux.ru \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git