Re: Planning for libidn shared library version transition
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
Reply to: