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

[Led]

On Tuesday, 25 November 2008 21:39:31 Alexey Tourbin wrote:
> 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 спеках); либо полностью
> оптимизировать список на основе топологической сортировки (тогда в
> списке останутся только "вершины" дерева, а все остальные пакеты,
> которые "вытягиваются" этими вершинами, будут удаляться).

Очень жаль.

-- 
Led