Differences between revisions 11 and 12
Revision 11 as of 2020-06-28 05:32:09
Size: 2549
Editor: LevLamberov
Comment: Fix links after renaming
Revision 12 as of 2020-06-28 05:33:43
Size: 2567
Editor: LevLamberov
Comment: Fix links a bit more (previously I forgot to add Teams/)
Deletions are marked like this. Additions are marked like this.
Line 36: Line 36:
 * We generally expect to be able to work on packages as a [[DebianEmacsenTeam/Team|team]]
 * See [[DebianEmacsenTeam/elpa-hello|elpa-hello]] for sample debian/* files snippets that use dh_elpa and follow policy.
 * We generally expect to be able to work on packages as a [[Teams/DebianEmacsenTeam/Team|team]]
 * See [[Teams/DebianEmacsenTeam/elpa-hello|elpa-hello]] for sample debian/* files snippets that use dh_elpa and follow policy.
Line 41: Line 41:
 * [[DebianEmacsenTeam/Tips|Tips]]  * [[Teams/DebianEmacsenTeam/Tips|Tips]]

Debian Emacsen team

Contact

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.

Subpages