Simon McVittie <s...@debian.org> writes: > For some libraries, the only maintainer-supported way to consume the > library is via pkg-config. If that's the case, then a dependency on > pkg-config can be appropriate - although we don't add a dependency on > cc or binutils, which is equally necessary.
Well, cc and binutils are in build-essential, so this isn't entirely equivalent. > For other libraries, either there are other supported ways to consume > the library (CMake metadata or sdl2-config or similar), or the library > is in the compiler's default search paths (not parallel-installable) > like libjpeg - so you *can* use pkg-config, but you don't *have* to. Yeah, I think this is the key point: it's entirely possible to use most libraries without pkg-config because they're installed into the default search paths, so you can just... use them. If they *require* special flags (non-standard paths, non-standard compiler flags, etc.) such that pkg-config is the only supported interface, then I think one could make a good argument that pkg-config should be a dependency of the -dev package. > That's why I think it is best that the information about which libraries > GLib depends on is shipped with GLib and included by reference (via > either Requires.private: glib-2.0, or the Requires.internal: glib-2.0 > proposed on https://bugs.freedesktop.org/show_bug.cgi?id=105572), > instead of copying the information about GLib's dependencies into > libfoo-dev where it will become outdated when GLib changes. Yes. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>