On 2021-10-09, at 18:52:49 +0200, Andreas Metzler wrote: > On 2021-10-09 Jeremy Sowden <jer...@azazel.net> wrote: > > On 2019-08-13, at 19:09:33 +0200, Andreas Metzler wrote: > >> On 2019-06-16 Douglas Torrance wrote: > >>> On Sun, Jun 16, 2019 at 7:30 AM Andreas Metzler wrote: > >>>> /usr/lib/x86_64-linux-gnu/pkgconfig/dockapp.pc: > >>>> Requires: x11 xext xpm > > >>>> Therefore anything build-depending on libdockapp-dev and using > >>>> pkg-config to locate the library will FTBFS unless it has a > >>>> direct b-d on libxext-dev. > [...] > >> the respective patch moves "Requires: x11 xext xpm" to > >> Requires.private. That does not really fix the bug. pkg-config > >> --cflags requires that not only Requires but also Requires.private > >> are is resolvable (even when --static is not present) i.e. xext.pc > >> would still need to be present. > > >> I think this would be the correct fix: > >> - @echo 'Requires.private: x11 xext xpm' >> $@ > >> + @echo 'Requires.private: x11 xpm' >> $@ > >> + @echo 'Libs.private: -lext' >> $@ > > > Doesn't that mean that we lose information? What if libxext is > > installed in a non-standard location, and we need the -L${libdir} to > > find it? > > > I think the right thing to do is to add a b-d on libxext-dev to > > libdockapp-dev. > > <TLDR> Adding libxext-dev to libdockapp-dev's Depends would work > perfectly fine for me.
I've pushed a commit to add the dependency, plus a few other things. > ------- I think it is a little bit of grey area, not and black and > white. Having xext in Requires.private broke pkgconfig and introduced > this bug. Some third-party packages needed to work around this and we > could inflate libdockapp-dev's dependencies to fix it. There is no > real gain for e.g. Debian packages in having xext in > Requires.private. > > OTOH for non-dist packages you raise a valid point. However the > breakage seems to be constrained to a corner case: > + xext is installed in non-standard location and this non-standard > location is a different one than either x11 or xpm > + static linking is wanted. (Or we are on an exotic arch which > requires explicit linking against all indirect deps). Agreed. J.
signature.asc
Description: PGP signature