Released in February 2005 and September 2008, respectively. Emacs 23 is stable since more than two years.
# Ulrich Mueller <ulm@gentoo.org> (13 Dec 2011) # SLOTs 21 and 22 of app-editors/emacs, corresponding to # GNU Emacs versions 21.4 and 22.3. These versions were # released in February 2005 and September 2008, respectively. # Please upgrade to app-editors/emacs-23.3 and update your # Emacs Lisp packages with emacs-updater. # Masked for removal in 60 days, or after the release of # GNU Emacs 24.1, whatever will occur later. Bug 394589. =app-editors/emacs-21* =app-editors/emacs-22* <virtual/emacs-23
I'd like to request that emacs-21 and emacs-22 be kept in the tree but indefinitely package.mask'ed to note that they're unsupported. I was talking with ulm earlier who mentioned the reason they're being masked is the maintenance burden of app-emacs/* getting high with 4 versions in the tree and having to test against all slots. ulm mentioned that NEED_EMACS could be increased to 23 in elisp.eclass and keep emacs-21 and -22 package.masked as mentioned above. This would remove a very large part of the maintenance burden and would allow people on systems constrained for resources to get many useful features that emacs-18 doesn't offer, but emacs-23 uses too many resources (one example is font-lock, which emacs-18 does not have).
The main problem are indeed add-on packages (app-emacs/* and others), because many of their upstreams don't test them with old Emacs versions any more. So, in order to claim that Emacs 21 and 22 are still supported, we'd have to test packages ourselves with four major Emacs versions. Also long time ago (before I joined as developer) the design decision in Gentoo was to keep all byte-compiled files in a single site-lisp tree. This works reasonably well in most cases. However, sometimes there are subtle incompatibilities between byte-compiled files (upgrading Emacs generally works better than downgrading). The alternative would be a system similar to the one used for Python, namely to byte-compile the elisp files with every installed Emacs version and to install the *.elc files in separate versioned trees. IMHO, the few incompatibilities that we observe wouldn't justify the large overhead for that. (Note that other distros have taken a different decision, see for example <http://www.debian.org/doc/packaging-manuals/debian-emacs-policy>.) But obviously, the problems get larger the more Emacs versions we keep. In summary: - We can keep Emacs 21.4 and 22.3 in the tree package.masked indefinitely. - Also the old virtuals can be kept (they have zero maintenance cost). - I may even accept user-submitted patches to fix severe bugs or incompatibilities (see the last libpng upgrade in bug 384553 as a recent example). - New features will not be backported to old Emacsen. - There won't be any support whatsoever for add-on packages. - Maybe it's worth noting that we've relocated the site-start.el file from /usr/share/emacs/site-lisp to /etc/emacs recently, where it won't be found by the old Emacs versions. - Not sure yet what to do if any security issues will arise. @Fauli: Any comments?
(In reply to comment #3) > Also long time ago (before I joined as developer) the design decision in Gentoo > was to keep all byte-compiled files in a single site-lisp tree. This was even before I joined. > IMHO, the few incompatibilities that we observe wouldn't justify the large > overhead for that. Agreed. > - We can keep Emacs 21.4 and 22.3 in the tree package.masked indefinitely. > - Also the old virtuals can be kept (they have zero maintenance cost). > - I may even accept user-submitted patches to fix severe bugs or > incompatibilities (see the last libpng upgrade in bug 384553 as a recent > example). > - New features will not be backported to old Emacsen. > - There won't be any support whatsoever for add-on packages. > - Maybe it's worth noting that we've relocated the site-start.el file from > /usr/share/emacs/site-lisp to /etc/emacs recently, where it won't be found > by the old Emacs versions. So the old Emacssen won't load the start-up code from Emacs packages. > - Not sure yet what to do if any security issues will arise. Hard masked is ok for vulnerable versions, but I would prefer a removal then if an easy fix is not possible. So we raise NEED_EMACS and beat people to upgrade once and for all.
I've changed the comment in package.mask: -# Masked for removal in 60 days, or after the release of -# GNU Emacs 24.1, whatever will occur later. Bug 394589. +# Keeping these versions in the tree masked indefinitely, +# by popular request. Bug 394589. (In reply to comment #4) > > - Maybe it's worth noting that we've relocated the site-start.el file > > from /usr/share/emacs/site-lisp to /etc/emacs recently, where it won't > > be found by the old Emacs versions. > > So the old Emacssen won't load the start-up code from Emacs packages. Right. I've fixed this one in 21.4-r24 and in 22.3-r9, because it doesn't make sense to leave things in such a broken (and confusing) state. And at some point I'd also like to remove =emacs-common-gentoo-1.2* (which supports the old site-start.el location).
Reopening, because these versions suffer from the security issues in bug 509830. Removal in 30 days from now, unless someone will provide backported patches. # Ulrich Müller <ulm@gentoo.org> (08 May 2014) # SLOTs 21 and 22 of app-editors/emacs, corresponding to # GNU Emacs versions 21.4 and 22.3. These versions were # released in February 2005 and September 2008, respectively. # Please upgrade to >=app-editors/emacs-23 and update your # Emacs Lisp packages with emacs-updater. # Multiple security issues with temporary files, bug 509830. # Masked since 13 Dec 2011, removal at 07 Jun 2014. Bug 394589. =app-editors/emacs-21* =app-editors/emacs-22* ~virtual/emacs-21 ~virtual/emacs-22
Note to self, to be done after removal: - Increase default for NEED_EMACS to 21 (in elisp.eclass) - Remove redundant NEED_EMACS assignments from ebuilds
(In reply to Ulrich Müller from comment #7) > - Increase default for NEED_EMACS to 21 (in elisp.eclass) This should read "23". It is 21 currently.
Removed.
