On Thu, 27 May 2021 at 08:30:11 +0200, Simon Josefsson wrote: > I do think it would be a wortwhile release > goal, at some point, to fix tooling so that dummy packages are no longer > necessary for package transitions.
Transitional packages have the huge advantage that they already work (and the reason they work is a side-effect of how ordinary non-transition upgrades work, so it isn't going to go away). Making them unnecessary seems likely to be more code (therefore more bugs), so it would have to be counterbalanced with a real advantage. If we are replacing a "real" package with a transitional package, then by definition that package name is no longer in use, so having the transitional package "occupy" the name is harmless. The one non-cosmetic reason I can think of why transitional packages are potentially bad is that they aren't removed automatically, so systems that have been upgraded many times can end up with a lot of transitional packages; not needing transitional packages would make https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#obsolete somewhat less necessary (although still necessary, to deal with packages that were removed with no direct replacement). That doesn't seem hugely compelling to me? If you want to pursue this, the right way to do it would be to send a bug report to apt. I'm not sure how feasible it is to make superseded packages identifiable and make apt assign a more favourable "score" to removing them, but apt maintainers would know. One possible route would be an equivalent of rpm's Obsoletes field. If it's feasible to solve this, then I suspect the only packages that would need code changes would be apt and cupt (and maybe aptitude). Packages undergoing transitions would likely also need metadata to tell apt which older packages they supersede. Bear in mind that if apt is changed to not need transitional packages (somehow) in stable release n, packages cannot take advantage of that change until the n+1 cycle. smcv
