SPECS: obconf.spec - BR: pkgconfig, startup-notification-devel

[Jakub Bogusz]

On Thu, Dec 02, 2004 at 10:38:22PM +0100, Fryderyk Dziarmagowski wrote:
> On Thu, 2 Dec 2004 22:07:28 +0100
> Jakub Bogusz <qboosh w pld-linux.org> wrote:
[...]
> > > Nadrzędne zależności dla programów z BR: gtk+2-devel powinny być _w_
> > > gtk+2-devel. Dodawanie do każdego speca zależnego od gtk+2-devel BR:
> > > pkgconfig jest absolutnie niepotrzebną duplikacją. Byłoby to
> > > uzasadnione gdyby jakiś spec wymagał konkretnego
> > > %{epoch}:%{version}-%{release}, ale w tym przypadku jest to
> > > oczywiste.
> > 
> > configure(.ac) z obconfa używa wprost pkgconfiga, zresztą nie tylko do
> > gtk+2.
> > Pliki nagłówkowe i linki do bibliotek z gtk+2-devel pkgconfiga (ani
> > automake'a) nie używają.
> > Z gtk+2-devel pkgconfiga używa tylko (opcjonalne) makro
> > AM_PATH_GTK_2_0.
> 
> _Znakomita większość_ programów wymagających gtk+2-devel wymaga
> pkgconfig. Czy nie jest to wystarczający argument za uproszczeniem sobie
> życia? Czy tok myślenia PLD ma się sprowadzać do BRs czy ku budowaniu i
> kształtowaniu odpowiedniego środowiska do pracy developera?

Programisty sprawa, czego chce używać - czy woli pkgconfig, czy
np. AC_CHECK_LIB i szukanie nagłówków.
autoconfa wymaga dużo więcej pakietów (coś ponad 1000 speców?), a nie
jest wymagany przez glibc-devel czy nic w tym rodzaju - tylko przez
pakiety faktycznie go używające.

Szukanie zależności od pkgconfig w gtk+2 jest zresztą nietrafione
- gtk+2 wymaga gliba2, który z pkgconfigiem jest powiązany w dokładnie
ten sam sposób.
Sam kiedyś chciałem dopisywać R: pkgconfig do glib2-devel - ale
ostatecznie uznałem, że zależności mają być w faktycznym miejscu ich
występowania.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/