Kurt Roeckx <k...@roeckx.be> writes: > My understanding is that the point of virtual packages is so that > several *can* provide it. But you're now telling 1 package that it > can't do that, while you instead could say only one (other) package can > do it in this case.
That's one use of virtual packages. However, that's not the primary use of virtual packages for -dev packages. As a general rule, we do not want multiple packages in the archive providing the same -dev package name, because that leads to nondeterministic builds for any package that Build-Depends on the virtual -dev package name, and nondeterministic builds are bad. Rather, for -dev packages, it's more typical to have a virtual package with a single provider at any given point. This is a simpler version of the mechanism used by, e.g., gcc-defaults or boost-defaults, avoiding maintaining as separate source package when there's no need to provide additional supporting files like symlinks. It allows multiple versions of the package to be in the archive at the same time but one of them designated as the "default" version, using the virtual package Provides, for the purposes of building other packages. This allows packages that actually need a specific version to Build-Depend on that specific version, while moving most of the archive to a new version by moving the Provides and then scheduling binNMUs. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
