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. Hello Jeremy, <TLDR> Adding libxext-dev to libdockapp-dev's Depends would work perfectly fine for me. ------- 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). When I submitted the report I probably had my mindset in a Debian context not an upstream one and suggested the optimal-for-Debian solution. But it is probably an error to micro-optimize and invest that much thought into it. cu Andreas