Wondering about possibility of removing emacs24 from stretch

[Rob Browning <rlb@defaultvalue.org>]

We've been hoping (#debian-emacs and I) for a while that we might be
able to remove emacs24 from stretch, and while there was some initial
trouble with emacs25's stability, we finally got that sorted, and we've
been trying to nudge maintainers to adjust their package deps to not
depend solely on emacs24.

But there are a few packages that still have either (1) a dependency on
emacs24 or (2) on the emacs/emacs-nox metapackages, which still point at
emacs24.

Packages in the first category require at least a trivial change to
broaden their deps, assuming they work fine with emacs25, i.e. to say:

  emacs25-nox | emacs25 | emacs24

Packages in the second category require no changes as long as they work
with emacs25 since they'll be unaffected by the eventual upload of
metapackages pointing to emacs25 instead of emacs24.


To date, we've contacted the maintainers of all of the affected
packages, filed bugs against the packages in the first category (and
have been helping fix them), and are in the process of testing all of
the packages in the second category using the emacs-defaults in
experimental (which points to emacs25), sbuild, and evaluating the
resulting debs with emacs25.

We've been documenting our progress here:

   https://wiki.debian.org/Emacs25InStretch

And at the moment, we have:

  First category:
    - two packages that are likely fine once the deps are broadened
    - five still to evaluate

  Second category:
    - four packages that appear fine
    - one that's probably fine, but requires a bit more testing (doxymacs)
    - one that has known sbuild issues delaying evaluation (automake)
    - one that should be fixed soon (magit)
    - six still to evaluate

For what it's worth, we've been managing to evaluate a few packages a
day lately, and I expect that pace to continue for at least the next
5-10 days.

Our intent was to continue with this work until we either had everything
sorted out, or we found some issue that made it clear removing emacs24
wasn't going to be feasible right now -- and of course one such issue
would be us already being too late with respect to the release schedule,
hence this message.

If we aren't too late, we suspect that many of the required changes will
be trivial and might be handled reasonably via NMUs, or (as mentioned)
no changes will be required at all.

Of course if after testing, that doesn't appear to be the case, then we
can just leave things as-is, but I think we'd all be substantially
better off if we can avoid having to support both emacs24 and emacs25
for the lifetime of stretch.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4