Differences between revisions 13 and 14
Revision 13 as of 2020-06-28 05:50:22
Size: 2714
Editor: LevLamberov
Comment: Add links to meetings of Debian Emacsen team
Revision 14 as of 2020-06-28 05:51:17
Size: 2723
Editor: LevLamberov
Comment: Make links to meeting a proper list
Deletions are marked like this. Additions are marked like this.
Line 40: Line 40:
 * [[Teams/DebianEmacsenTeam/Meetings/DC15]]
 * [[Teams/DebianEmacsenTeam/Meetings/DC16]]
 * [[Teams/DebianEmacsenTeam/Meetings/DC17]]

Debian Emacsen team



  • Emacs Lisp addon packages
  • GNU Emacs backports

i.e. does not (yet) include any main archive Emacsen themselves.


Defined by our salsa group (not (yet) by tracker.debian.org).

Addons packaging policy

  • All projects must have a real upstream. This can be a release tarball, VCS, or webpage with a bare file-version.el. The important point is that Upstream-Contact must be in control of releases. This means that projects that only exist on "emacswiki.org" should not be part of Debian. If you find a package that has Emacswiki as the source, and doesn't have a new project upstream, please bring it to the attention of the team.

  • All binary packages installing into site-lisp/elpa (in particular all packages using dh_elpa) should be named elpa-foo where foo is the ELPA package name.

    • + Note that this is often different to the upstream repository name. E.g. elpa-f is called 'f.el' by upstream.

  • Source package names are upstream project names. Prefix 'emacs-' or suffix '-el' if and only if that name is too generic.
  • We use one git repository for each upstream package.
  • We keep the upstream source in the packaging git repository.
  • Versions should be based on those used by the upstream author, not e.g. MELPA
    • + Though if there is a discrepancy, try to get it resolved with upstream before uploading.
  • The ELPA version declared in a package's headers should match its actual version in all but unusual cases; This is needed for proper dependency resolution, but many upstreams rely on MELPA infrastructure to generate correct headers.
    • + The dh_elpa(1) man page documents the most elegant method to generate this metadata at build time.
  • Maintainer field should be
    • Debian Emacsen team <debian-emacsen@lists.debian.org>

  • We generally expect to be able to work on packages as a team

  • See elpa-hello for sample debian/* files snippets that use dh_elpa and follow policy.