Re: Accepted emacs 1:26.1+1-3.2 (source amd64 all) into unstable, unstable
- Date: Mon, 4 Feb 2019 14:51:45 +0100
- From: Andreas Beckmann <anbe@xxxxxxxxxx>
- Subject: Re: Accepted emacs 1:26.1+1-3.2 (source amd64 all) into unstable, unstable
On 2019-02-04 12:38, Holger Levsen wrote:
> in #916758 you wrote:
> --- begin ---
> These were additional emacs variants available in lenny that may have
> survived upgrading on a long-grown system.
> I'm doing piuparts tests simulating such long grown systems locally and
> would expect to find some ancient packages that break once a modern
> emacs gets installed. So we would generate a list of Breaks against
> cruft packages that would need to be added to the appropriate modern
> emacs package.
> --- end ---
> in other words - and please correct me if I'm wrong - you added
> long gone transitional packages back only to make some (more or less)
> pointless upgrades from lenny behave better today?
emacs has had a bad history (from piuparts point of view) of providing
clean upgrade paths to newer versions. All versioned emacs packages were
co-installable and there were no transitional packages provided ever to
ensure upgrading to the next version. There were unversioned
meta-packages, but many extension packages (that may be the wrong term,
I'm not an emacs guy) also depended just on (some) (ancient) versioned
emacs packages. This lead to cruft being kept installed that
occasionally blew up some (seemingly unrelated) upgrade path in case an
extension that was not compatible with several more current emacs
releases already, suddenly was attempted to be compiled with a modern
emacs. I vaguely remember fixing some of these via proposed-updates over
the years, especially if the package was already gone from sid...
This will all get better in buster which switched to unversioned emacs
25, now 26.1 - Yeah! for doing this - we just need to polish up all the
upgrade paths that may lead to buster ... which probably means another
round of Breaks being added to emacs-common ...
> I'm really not sure this is a sensible approach. Usually we try to get
> rid off transitional packages, not to add new ones???!
... s.t. we can finally drop the transitional packages that were
introduced in buster for buster +1
And if we can be sure that no ancient emacs may have survived buster, a
lot of conditional code depending on the emacs version can be dropped
from emacs-install scripts in extension packages.
> lenny was released almost exactly 10 years ago. We should let it go.
It's just fascinating to see that we provide an operating system that
can be successfully upgraded from release to release without ever
requiring complete reinstallation :-) Just the hardware needs to be
exchanged from time to time ;-P