Deps of -dev packages with pkg-config .pc file: Policy Change?
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: