Quoting Philipp Kern (2022-10-20 14:29:13) > On 20.10.22 13:40, Johannes Schauer Marin Rodrigues wrote: > > Quoting Andreas Henriksson (2022-10-20 12:13:24) > >> Cannot be used for packages that are used in build dependencies, as several > >> build tools (like sbuild) do not support virtual packages in those > >> dependencies by design, to guarantee deterministic builds. > > Wait what? If sbuild doesn't support virtual packages I'd like to hear about > > that. Can I just remove this reason from the wiki page? It is obviously > > wrong. > > If it is not, please file a bug against sbuild. > > The correct statement here is that you ought to pick a default choice > first[1] before a virtual alternative. We don't want to leave it up to > the resolver to pick an arbitrary available build-dependency. So this is > more of a policy rather than a technical question. Behavior for > experimental might currently differ due to a different resolver choice > that's more flexible by design - to get newer versions from experimental > if necessary. > > Kind regards > Philipp Kern > > [1] This might require an overall agreement across Debian at times. But that > seems to be more relevant for dependencies than build-dependencies.
Is that really the correct statement? Even after excluding all virtual packages with a single provider, there are literally thousands of source packages for which their first alternative is a virtual package. Is this "policy" documented somewhere? Because if it is, then it either should change or the archive has to be changed to match that policy. In any case, this was not my original question. Andreas presented a way to use a transitional package to rename a package which will work fine I guess except that we have to carry an empty package for a release and that empty package has to be cleaned up at some point, for example by deborphan. My original question was why using a virtual package for the same purpose is a bad idea. The wiki page https://wiki.debian.org/RenamingPackages lists reasons against it that are incorrect. So why is it really a bad idea? Is there any reason not to delete the first reason (the sbuild one) completely? And either I misunderstand the second reason or I implemented my POC incorrectly or apt (as of 2022-10-21) is perfectly capable of replacing the old with the new one. Can somebody shed some light on this? Thanks! cheers, josch
signature.asc
Description: signature
