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).
We typically grant full membership to non-DDs who
- are already in the Uploaders field for several team packages, at least some of which they prepared for NEW themselves; and
- know when to ask for review before pushing, especially when it comes to importing new upstream releases.
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. Binary package 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. As a special case, if the upstream project name ends in '.el', replace this with '-el'. I.e. Do not add an elpa- prefix to the source package name.
- 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.
`:core` ELPA packages
":core ELPA packages" is upstream's name for Emacs Lisp packages that are included in Emacs releases but which also see independent new releases to GNU ELPA, more frequently than Emacs as a whole gets released.
For some of these packages, we package them twice: there is the copy installed when you install Emacs, and there is also an elpa- package. This is so that we can offer users newer releases than they would otherwise get in our stable releases, given how our release cycle and Emacs's do not line up well.
This scheme only works if addon packages are never allowed to fall behind the version shipped with Emacs. That is, after Emacs is updated in Debian, but before our freeze begins, all :core ELPA packages must be updated to at least the version shipped with Emacs.
- Otherwise, the version shipped with Emacs can take precedence over the version shipped separately, which is bad for users. See also Debian bug#1035757.
Meetings
Subpages
Useful links
Old team wiki content (not yet fully migrated to here)