[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Phasing out emacs23 support

Hi David,

On 22 May 2016 at 13:42, David Bremner wrote:
| Dirk Eddelbuettel <edd@debian.org> writes:
| > The last release no longer builds/installs on emacs23.  Upstream recommends
| > that I simply exclude emacs23. Upon reflection I think I concur but I now
| > wonder how to best implement this.
| >
| > So far, and all these years, I just used (indented for email) this:
| >
| >      Depends: ${misc:Depends}, emacsen-common (>= 2.0.8),
| >               dpkg (>= 1.15.4) | install-info
| >      Recommends: r-base-core
| >      Conflicts: dhelp (<= 0.3.12)
| >      Suggests: xlispstat, pspp, jags, julia
| >
| > and I could of course have a 'Conflicts: emacs23' but I am a little weary of
| > side-effects.
| the files debian/${package}.emacsen-{install,remove} contain shell
| script, that probably already switches on "flavour". You can look at the
| notmuch source package for an example that ignores emacs21 and 22.

I was actually thinking about just that too (of course only after I sent the
email).  No need to conflict and create trouble with the package hierarchy
when I can just skip the elisp compilation on emacs23.

I was a little bit involved in the earliest version of these scripts (for
octave when I still maintained it) which is why name keeps getting copied in
some of the headers.
| You might (or might not) find the dh-elpa tool interesting; it maintains
| these scripts for you, and already ignores emacs23.

Will discuss with upstream. ESS is now on one of these, and I was quite
impressed with how magit now does this.  Not a bad plan at all.  What was the
thinking behind requiring internet access?  I guess we do anyway for normal
apt mode?

Thanks again for the very helpful (and timely!) mail.


http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Reply to: