Bug#930603: libdockapp-dev: pkg-config file Requires xext without dependency on libxext-dev

[Andreas Metzler]

On 2021-10-09 Jeremy Sowden <jeremy at 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