Re: [devel] greycstoration-2.9-alt2 -lXext (Sisyphus-20081124 i586 beehive_status)

[Alexey Tourbin <at@altlinux.ru>]

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

On Tue, Nov 25, 2008 at 09:16:22PM +0200, Led wrote:
> On Tuesday, 25 November 2008 19:49:13 Alexey Tourbin wrote:
> > On Mon, Nov 24, 2008 at 11:32:23PM +0000, QA Team Robot wrote:
> > > greycstoration-2.9-alt2
> > > 	CImg.h:28076: warning: argument 'filename' might be clobbered by
> > > 'longjmp' or 'vfork' /usr/bin/ld: cannot find -lXext
> > > 	collect2: ld returned 1 exit status
> >
> > Пакет libXrand-devel раньше содержал искуственную зависимость
> > на libXext-devel, которая недавно была удалена (раньше buildreq
> > оптимизировал зависимость на libXext-devel, а при новом раскладе
> > эта оптимизация приводит к недостаточным сборочным зависимостям).
> > Так что распрямление зависимостей чревато некоторыми неудобствами:
> 
> Есть подозрение, что от "распрямления" зависимостей больше вреда, чем пользы.
> Например, очень неудобно зачастую писать зависимости типа
> %{?_with_foo:BuildRequires: libfoo-devel}
> потому как libfoo-devel может просто не попасть в зависимости, генерируемые 
> buildreq

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

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

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