Re: Bug#1121601: debian-policy: encourage keeping backwards compatibility with older releases past current minus one
Hi!
> >I agree with those saying that the Debian Project should strongly
> >discourage skip upgrading.
>
> Agreed.
+1
> >However, it would be polite if upgrade handling (like Breaks/Replaces)
> >be kept until it has shipped in both the latest Debian stable release
> >and the latest Ubuntu LTS release.
>
> Agreed as well.
>
> The Debian Perl Group internal policy [0] and also the code in
> cme/libconfig-model-dpkg-perl remove dependency versions only when
> they are already fulfilled in oldstable. This helps backporting or
> installing newer packages on older installations.
+1
Quoting my own first email:
> I propose the Debian policy to include some kind of generic statement,
> that while skipping releases is not supported in the sense that it is
> not guaranteed, packages should avoid dropping backwards compatibility
> code purely for the sake of cleanup. Code that facilitates upgrades
> and backwards compatibility should be kept around if there is no
> special cost to keeping it, and if the code facilitates upgrades from
> a version currently still in LTS or ELTS support.
Here I meant Debian LTS or ELTS, but of course keeping backwards
compatibility code around for at least past one Debian release would
also help Ubuntu LTS users upgrade from LTS to LTS. A large amount of
Debian users are in Ubuntu and helping them helps the overall
ecosystem.
In the examples I provided the upgrade issues are typically files that
have been moved around in essential packages, such as linux-utils,
login, libcrypt etc. These upgrades work as long as the Break/Replaces
stanzas are kept around and not removed immediately after a new Debian
stable release (with the usrmerge being an exception of course, as it
moved everything). Those Breaks/Replaces stanzas are not in particular
brittle or hard to maintain - just postpone removing them. My
suggestion was not to ask people to invest *extra* work in adding
backwards compatibility, but just to keep it around a bit longer.
Also, if Debian really thinks that skipping releases is always bad,
shouldn't the solution then be to just outright block them? That would
settle the situation once and for all, as nobody would ever get far
enough to discover any backwards compatibility code that was removed
too early as something else earlier in the upgrade process would
categorically always fail/block such upgrades.
Reply to: