Hi Luca, On Wed, Jul 01, 2020 at 05:23:05PM +0100, Luca Boccassi wrote: > This is how upstream generates the pkg-config files for all components > of util-linux - and it's how most libraries with optional features that > I've come across do as well. If a feature is not built, and thus the > binary does not link to the library, the dependency is not listed in > pkg-config. And to me it would appear the correct thing to do - the > point of pkg-config is to list what is needed to link against that > library, not a hypotethical version with everything enabled - so I > don't see upstream changing that any time soon.
This is not an upstream aspect. Upstream can provide different interfaces under the same name, but we're talking about the Debian package name "libmount-dev" as an interface here. What means "libmount-dev" mostly is a decision of the respective package maintainer. The meaning can change over time and we have a version to account for this. A major cause for RC bugs is when a package maintainer changes (removes) an interface that other packages previously relied upon. The thing is, other packages depend on "libmount-dev" and they expect to get the same thing no matter how you build it. So what makes up "libmount-dev" should be independent of which build profiles you use to build it. However, certain build profiles can result in libmount-dev not being built at all. Compare this with hurd. There is hurd-dev and during bootstrap, we need a stripped-down version of it. So we invented hurd-headers-dev. Normally, hurd-dev provides hurd-headers-dev and a real hurd-headers-dev package is not build. Only during bootstrap, there is a hurd-headers-dev package that does not provide hurd-dev. Now when you need hurd development stuff, you need to decide whether you just need the headers or whether you need the full hurd-dev. Another example is lighttpd-modules-*. What these packages contain is explicitly left unspecified. If you need a particular module, you must depend on the particular lighttpd-mod-* package provided by some of the real module packages. This wasn't made up by upstream. It's about how the package is maintained and about how other packages interface with it. Does that make more sense to you now? > For libmount for example you get the exact same result w.r.t. > libselinux. That doesn't make it any better. I guess that's why the Debian package makes libselinux-dev a mandatory dependency. Indeed, we build libselinux quite early during bootstrap. > I'll likely provide a backported patch as soon as the PR is merged - > I'd really like to get more stress-test under way long before the > bullseye freeze. I think experimental would be a good target for such a feature. I admit that it gets way less testing there. I'm looking forward to seeing it included in Debian bullseye. Helmut
