On Fri, 17 Dec 2021 at 10:05:39 +0100, Alexander Traud wrote: > I do not understand why: > a) pkg-config itself is *not* a dependency as well
Sometimes it is appropriate for it to be, and sometimes it is not. 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. Libraries with multiple parallel-installable versions, like GTK, often behave like this: you have to explicitly ask (via pkg-config) to add the version you want to use to the compiler's search paths, so that you will not get the <gtk/gtk.h> from GTK 2 or 4 where GTK 3 was expected. 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. > b) Lintian was not upgraded in 15 years to check the content of the .pc > file and aid the maintainer in not missing any required dependency. Lintian cannot know whether the required dependencies are present: that is outside its scope. Lintian analyzes each package in isolation, without referring to other packages. If your library depends on foo-bar, Lintian cannot know whether foo-bar.pc is in libfoo-bar-dev, libfoo-bar2-dev, libfoo-dev, libfoo2-dev or something else. > Simon McVittie wrote: > > this doesn't scale well > > Then, I do not understand static linking. I thought, please correct me > here, static linking is about the '.a' file in the package, the current > one. I have to suffice its links as it was built, not the links when I > build. Imagine you are packaging a library "libfoo" that makes use of GLib (glib-2.0.pc, from src:glib2.0) but does not expose GLib in its header files. This is an example of the class of dependency that you want to move from Requires.private to Libs.private. glib-2.0 currently depends on libpcre, which it uses to implement GRegex. It does not include libpcre headers in its header files (the GRegex API completely wraps libpcre), so libpcre is another example of the class of dependency that you want to move from Requires.private to Libs.private. Imagine that GLib had done this. When you statically link your library libfoo into a program, you want to end up with something like this: gcc -static ... -lfoo -lglib-2.0 -lpcre libfoo.a provides symbols used by the program, libglib-2.0.a provides symbols used by libfoo, and libpcre.a provides symbols used by libglib-2.0.a. So far, everything is working. If we were using Libs.private as you suggest, then glib-2.0.pc and libfoo.pc would have something like: # glib-2.0.pc ... Libs: -L/usr/lib/MULTIARCH -lglib-2.0 # generated from: Libs.private: $(pkg-config --static --libs libpcre) Libs.private: -L/usr/lib/MULTIARCH -lpcre # libpcre.pc ... Libs: -L/usr/lib/MULTIARCH -lfoo # generated from: Libs.private: $(pkg-config --static --libs glib-2.0) Libs.private: -L/usr/lib/MULTIARCH -lglib-2.0 -lpcre Now imagine that GLib switches to libpcre2 (libpcre2-8.pc, -lpcre2-8) as requested in #1000082. This will change the contents of glib-2.0.pc to: # glib-2.0.pc ... Libs: -L/usr/lib/MULTIARCH -lglib-2.0 # generated from: Libs.private: $(pkg-config --static --libs libpcre2-8) Libs.private: -L/usr/lib/MULTIARCH -lpcre2-8 Without changing anything in libfoo, you'll find that libfoo.pc is now wrong (until it is rebuilt and has the opportunity to update its idea of what GLib depends on). Programs that depend on libfoo will fail to link, because the new libglib-2.0.a requires symbols from libpcre2-8.a instead of the old libpcre.a, but libfoo.pc still says "Libs.private: ... -lpcre" because that's what it captured at libfoo's build-time. 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. smcv