On 21.10.22 20:06, Johannes Schauer Marin Rodrigues wrote:
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.
Hm, good point. I thought it was documented in a way stronger way than
it actually is. In [1] it says:
To specify which of a set of real packages should be the default to satisfy a
particular dependency on a virtual package, list the real package as an
alternative before the virtual one.
Which does not say that you have to, only what you should do if you want
to specify a real package.
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?
Yeah, I think that line should be deleted as it might never have been
true. I checked the first code in git from 2004 and it doesn't reject
virtual packages either. It does pick a winner manually in the resolver
and it looks random (or rather in "apt showpkg" order). But it's not
like it didn't work.
Kind regards
Philipp Kern
[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides
