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> > >
