Re: Deps of -dev packages with pkg-config .pc file: Policy Change?
This is all pretty straightforward. If foo.pc in libfoo-dev references
bar.pc that lives in libbar-dev, then libfoo-dev needs a dependency on
libbar-dev, and the missing dependency is a serious bug. That has been
the case for as long as I remember, and doesn't require more long
discussions or policy changes IMO.
Libs.private is a bit different because static linking is not typically
used for Debian packages, but Requires and Requires.private are quite
clear cut.
Cheers,
Julien
On Thu, Dec 09, 2021 at 03:24:27PM +0100, Alexander Traud wrote:
> Linux distributions, which have separate packages for developers, like
> Debian, are not really supported [1] by the developer tool pkg-config
> [2]. The problems are C/C++ libraries which depend on other libraries at
> runtime. Let us pick one, a security library for utilizing DNSSEC:
>
> $ sudo apt install libunbound-dev
> $ pkg-config --print-errors --short-errors --cflags libunbound
> $ pkg-config --print-errors --short-errors --exists libunbound
> Package 'hogweed', required by 'libunbound', not found
>
> 1) The error message is misleading because pkg-config talks about the
> *runtime* package 'hogweed', although (in Debian) a *-dev* package is
> required to get the .pc file. Should I report that, where?
>
> 2) In this case, the package name is not simply an added '-dev' like
> 'hogweed-dev'. Instead, the developer has to search the contents of all
> packages [3] for the file 'hogweed.pc'. That is part of the package
> 'nettle-dev'.
>
> 3) Are 'nettle-dev' (and 'libevent-dev', by the way) missing
> dependencies of 'libunbound-dev'?
>
> The latter seems to be an ongoing question on debian-devel [4] if the
> package includes a static library '.a' as libunbound-dev still does. At
> least I found no conclusive answer. Position No: It is not a missing
> dependency because I can use that package perfectly (as a shared
> library) without pkg-config. Position Yes: pkg-config has to be
> required, recommended, suggested - for each level of dependency, you
> find an argument on debian-devel, see [5][6][7][8].
>
> 16 years. This topic has come up for 16 years now, again and again on
> the mailing list debian-devel, documenting the uncertainty of package
> maintainers. Furthermore, bug reports come in, again and again for that
> topic. Again, libunbound-dev as example for the Debian bug report [9]:
> Upstream, in the pkg-config .pc file, the maintainer moved the libraries
> from 'Requires' to 'Requires.private'. That was the correct approach.
> However, the maintainer closed the Debian bug report because he falsely
> believed to have fixed the issue that way.
>
> Requires -> -I/subfolder -lfuu, avoid if possible, see [10]
> Requires.private -> -I/subfolder , a header includes that header
> Libs -> -lfoo, lib itself
> Libs.private -> -lfuu, exclusively for static linking
> Cflags -> -I/subfolder , lib headers itself and/or
> header includes that header
>
> Any idea how to approach this?
> a) Leave as is. Do not depend on 'Require.private' automatically because
> the package can be used without pkg-config. Only depend on other -devs
> if one of those headers is included in a header.
> b) Fix/convert. Upstream, move everything into 'Requires.private'.
> Downstream, in the Debian package, remove 'Requires.private' and convert
> to 'Libs.private'; again, except if one of those headers is included in
> a header.
>
> These uncertainties create repeated frustration, even for core Debian
> members. Proposal: Why not decide, or at least give a recommendation on
> these questions:
>
> i) pkg-config tool itself: When is it a depend (which dep level?), and
> when not? My suggestions: Because I can use a '-dev' package without any
> tool, because of the FHS, just -lfoo should be needed [11].
>
> ii) .pc file and its 'Require': Leave it or change it? My suggestion:
> Report upstream that those libs have to be moved to 'Requires.private'.
>
> iii) .pc file and its 'Require[.private]': Depend on each lib? My
> suggestion: Only if the headers include it. For Debian, convert all
> others to 'Libs.private' because the built '.a' file (for static
> linking) has a known dependency tree. This gets a Debian patch in that
> source package.
>
> iv) Cflags: If I got it correctly, back in the year 2005, the cause of
> this drama were -I flags [12]; if the header included another header,
> and that header included further headers but was not in the root but in
> a subfolder, an -I flag *might* be required. For example, the package
> 'libopusfile-dev' has its header file in '/usr/include/opus/opusfile.h'
> with #include <opus_multistream.h> which is part of the package
> 'libopus-dev' and is not within '/usr/include/' but within
> '/usr/include/opus/'. Therefore,
> $ pkg-config --cflags opusfile
> -I/usr/include/opus
>
> After reading, understanding, and researching so much, I really wonder
> if this was correct. For example, if the header did
> #include <opus/opus_multistream.h>
> no include directory would be needed to be figured out via pkg-config.
> Actually, if the world was like that, I could shelf pkg-config and go
> just for linking libraries.
>
> Long story short:
> After 16 years of back and forth, several hundred bug reports, still new
> ones coming in, and existing reports not fixed completely, I wonder if
> someone in the Debian world is able to decide this finally and provide
> that decision either as policy change, or recommendation, or at least as
> a hint for future -dev package maintainers. And please, tell me, what I
> should do about libunbound-dev; re-open that bug report [9]?
>
> [1] <https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/7#note_656054>
> [2] <https://people.freedesktop.org/~dbn/pkg-config-guide.html>
> [3] <https://packages.debian.org>
> [4] <https://lists.debian.org/debian-devel/2008/02/msg01189.html>
> [5] <https://lists.debian.org/debian-devel/2004/11/msg00319.html>
> [6] <https://www.mail-archive.com/debian-devel@lists.debian.org/msg258710.html>
> [7] <https://www.mail-archive.com/debian-policy@lists.debian.org/msg21816.html>
> [8] <https://www.mail-archive.com/debian-user@lists.debian.org/msg729223.html>
> [9] <https://bugs.debian.org/958331>
> [10] <https://lists.debian.org/debian-devel/2005/10/msg00959.html>
> [11] <https://lists.debian.org/debian-devel-announce/2005/11/msg00016.html>
> [12] <https://lists.debian.org/debian-devel/2006/09/msg01053.html>
>
>
Reply to: