Why multiple Emacs flavours?

[Jérôme Marant]

Rob Browning <rlb@defaultvalue.org> writes:


>> But isn't it what's happening for most programs in Debian?
>
> Yes, but I think it's accurate to think of Emacs as similar to
> something like perl, python, zope, or c++.  It's an entire
> environment; it's not like xterm, or ssh, or any other package where
> an upgrade mostly just affects the package itself.  So it may be
> necessary to continue to provide some level of support for older
> versions for some period of time (just as is the case for perl,
> python, zope, c++, ....)

You're right. I thought it was just a text editor :-)

...
>> I think we should not support old flavour at all. It is not reasonnable
>> to spend some time on fixing bugs that have already been released
>> in the last stable release.
>
> Agreed, though in practice, I've handled that by just not fixing
> things very much in the older packages.  Ideally, one approach I have
> recently considered is to just mark the bugs "wontfix -- please
> upgrade to emacsXY".

Or maybe check bugs in the new version and reassign them to it
if necessary.

>> We can leave the old version in the archive until all emacs packages
>> have been ported to this new version.
>>
>> For instance, once all packages have been ported to emacs22, we can
>> remove emacs21: people willing to stay with emacs21 can always grab
>> the version from sarge.
>
> Hmm.  Let me think about that.  Up until now, I had just allowed the
> older flavor to hang around until the next stable distribution
> release, but we could also (as you suggest) just assert that "unstable
> is unstable", and remove the older flavor before the next release.

Hmm, well, it can be removed just before releasing. However, this shall
not be an encouragement to stay with the old version.

> Though one concern I have about that is as follows.  Imagine that the
> last version of emacs in sarge is 21.4a-1, and imagine that we get up
> to 21.9 in unstable before we transition to emacs22, i.e. 22.1.  If we
> drop emacs21 from unstable, there will be users who have much newer
> versions of emacs21 installed, versions that are no longer available
> anywhere.  I could imagine finding myself in that situation (though
> probably not with emacs ;>), and it might be a bit undesirable.
>
> Perhaps that just falls under the general unstable motto, "caveat
> emptor" , but if the more recent unstable version of emacs21 was
> substantially improved with respect to the one in sarge, then I wonder
> whether I'd rather have etch release with the newer emacs21 and the
> new emacs22, or just with the new emacs22, and pretend that the
> improved unstable version of emacs21 never existed...

Hmm, OK. This makes me think of having a dummy "emacs" package
pointing to a real emacsXY one.

> Overall though, I'm OK with the general idea here.  I think we'll just
> have to take it on a case-by-case basis.  Also, if Debian really does
> manage to significantly shorten its release cycle, then the issue
> becomes substantially less significant.  In that case, the idea of
> letting the release cycle handle the pruning is somewhat more viable.

OK. We'll see.

-- 
Jérôme Marant