[Please CC me on replies.] dpkg-shlibdeps automatically generates Depends on library packages corresponding to any libraries pulled in by the linker for the binaries in a package. However, library -dev packages still have to manually specify Depends on -dev packages that they require. In many cases, we could infer this information from pkg-config dependencies: if a library -dev package ships a pkg-config file, and that file includes Requires pointing to other pkg-config files, we could infer Depends on the packages shipping those other pkg-config files.
I'd like to build some tools (possibly including a dh_pkgconfig) to do this automatically; those tools could generate a pkgconfig:Depends substvar for use in debian/control. Before starting on those tools, I'd like to get some feedback on this idea. For me, this problem came up while working on Debian packaging for Rust libraries. I needed a solution to handle Rust libraries that provide FFI wrappers for C libraries, and need Depends on the corresponding -dev packages. I can currently autogenerate all the packaging for Rust packages, and I'd like to handle this case automatically as well. Most Rust libraries use pkg-config to find the C libraries they depend on. I have some work in progress to make those pkg-config dependencies programmatically parseable. In the course of doing so, I realized that the same work could simplify the Depends of C library -dev packages as well. Assume we can parse a list of pkg-config (name, minimum version) pairs from a package. This would ideally come from declarative metadata, though I can also think of multiple ways to obtain it from more programmatic sources. Given such a list, dh_pkgconfig could find all the corresponding pkg-config files, and add a substvar containing the corresponding Depends. For each version requirement, dh_pkgconfig would turn that into a versioned Depends on the corresponding -dev package. (Insert some handwaving here about how to generate a Debian version from a pkg-config version. In 99% of cases ">= version" will work; in the other 1% of cases, -dev packages could provide some kind of mapping expression.) Does this seem like a reasonable approach? - Josh Triplett
