Debian Emacsen team
Contact
- #debian-emacs on irc.debian.org
Scope
- Emacs Lisp addon packages
- GNU Emacs backports
i.e. does not (yet) include any main archive Emacsen themselves.
Membership
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.
Meetings
Subpages
Useful links
Old team wiki content (not yet fully migrated to here)