This page explains why I want to maintain a separate Emacs package, and not just use Debian's packaging for Emacs.

History

As a result of the Debian anti-GFDL vote, the emacs21 package was stripped of its documentation. There was a public outcry about this from several people on the debian-emacsen mailing list, with several very long threads. I felt very strongly that Debian had made the wrong decision, and decided to do something to counteract it. I switched to Ubuntu, a distribution known for its lenient and fair stance concerning the GFDL, and decided to try to get their emacs21 package changed back so that it included the manuals.

It turned out that reversing the breakage was somewhat of a pain, due to some of the things that Debian had removed. When Emacs 22 came out, I decided to take the packaging for emacs-snapshot (whose maintainer resisted the stripping of the manuals for long time, until he eventually had to make his own separate APT repository for it) and rebase it to work with the Emacs 22 release. The task was easier than expected, and I soon had a working emacs22 package. I contacted several people about getting this into Ubuntu, and was greatly helped by Reinhard Tartler, who now also helps to maintain this package.

The manuals can be installed by means of a separate package. So why do you care?

Emacs has an unusually deep level of integration with its manuals. Links to manuals may be inserted into function documentation, including very specific links to chapters and anchors. Emacs has a built-in Info reader to accommodate the viewing of these manuals from within Emacs, so no external program needs to be called. It is nontrivial to separate Emacs and its manuals, and to provide useful error messages when such links to manuals are followed. To the best of my knowledge, there was no serious attempt made in the Debian Emacs 22 packaging to programmatically explain to users why they could not browse these manuals, beyond perhaps a backtrace or an "Info file does not exist" warning.

There are also certain expectations of manual availability with respect to new users. New users are expected to visit the Emacs Help menu, and start browsing documentation. Much in the same way that vim users are expected to go through at least some of the tutorial that shows up in the splash screen, Emacs has a high enough learning curve that new users need a tutorial, a how-to-use-it sort of manual, and a FAQ.

As users become more acclimated with Emacs, it is expected that they will want to learn how to customize their configuration file (called either ~/.emacs or ~/.emacs.d/init.el). In order to do this, they may need to pick up a rudimentary knowledge of Emacs Lisp. The Emacs Lisp Intro manual is a must for this use case.

There were some other files besides the manuals that were split out from the main Emacs package because they have a "verbatim copying only" license. Among these are:

• The GNU Manifesto (etc/GNU)
• An explanation of the motivations of the GNU Project (etc/THE-GNU-PROJECT)
• An essay entitled "Why Software Should Not Have Owners" (etc/WHY-FREE)
• An explanation of the difference between Linux and GNU (etc/LINUX-GNU)

Since Emacs was one of the first GNU projects, these papers belong with Emacs, for the sake of historicity.

Also, since an editor can be among the first few things that people try out when they evaluate a GNU/Linux distribution (particularly so if they read about GNU/Linux from a book), it is very important to preserve the messages that the progenitors of the GNU Project wish to present. The maintainers of the Debian package were not only obligated to separate these files from Emacs, but also had to classify these landmarks of Software Freedom in their "non-free" archive! Is it not an absurdity that Debian, which was one of the first to adopt the label "GNU/Linux" to describe its distribution, now makes the file (etc/LINUX-GNU) which explains this distinction unavailable by default?

Why not just Depend on Debian's emacs22-common-non-dfsg?

• Our README.Debian file is generated in a superior way. Namely, it categorizes the patches that we have included with this package so that users can more easily tell the kinds of changes we have made. We use the name of the patch to determine what kind of patch it is.

• Debian includes the file /usr/share/emacs/22.1/etc/THE-GNU-PROJECT.dfsg in their emacs22-common package, which I do not want installed.

• I don't like having the phrase "non-dfsg" appearing anytime someone upgrades their emacs22 package. I find it insulting to have the reminder of (what I feel to be) a poor decision on Debian's part gratuitously waved in my face.

Goals

During an IRC discussion on #ubuntu-devel in summer 2007, a Ubuntu archive admin expressed that he was concerned about the large debdiff between the Debian and Ubuntu packages for emacs22. As a result, I have been trying to reconcile the differences in debian/rules (which have been mostly superficial, so far, with a few exceptions). I used Ediff-mode to compare the two versions of that file, and have been reorganizing the Ubuntu version so that the unimportant changes are minimized. I am about halfway done with this effort, and expect to complete some work on it in late Dec. 2007 or early Jan. 2008.

Another goal is to collaborate in various ways with the maintainer of the emacs-snapshot packages. This includes both packaging updates and important upstream bug fixes.

Other Emacs-related goals may be found on the drafting-stage Emacs Community document.

Maintenance

The emacs22 package is group-maintained by the members of the Ubuntu-elisp group (in practice, this has meant Reinhard and myself).

During the past few months (Aug. - Nov. 2006) I have not had much time for package maintenance due to needing to finish strong in my last semester as a college undergraduate. Now that I have graduated, I expect to allocate a significant amount of time to answering bug reports in this and other Emacs-related packages.