Bug#1138884: dh-elpa: simplify emacs-bundled addon handling

Xiyue Deng <[email protected]> Thu, 04 Jun 2026 23:58:26 -0700
Newsgroups	gmane.linux.debian.devel.emacsen
Message-ID	<87zf19iict.fsf__21460.6974319153$1780642894$gmane$org@debian-qemu>
Package: dh-elpa
Version: 2.1.9
Severity: important

Currently dh-elpa has special handling of addons that are built-in to
emacs so that instead of adding the addon to the Depends field, it adds
emacs-common instead to fulfill the requirement. This has been causing
issues that if an addon requires a version of the addon that is higher
than the one bundled in emacs, dh-elpa will not know. As an example:
recently a few packages start to require compat 31.0, while the current
Emacs 30.2 bundles compat of version 30.2.9999. As dh-elpa does not
handle the version, it still only provides emacs-common as part of
"${elpa:Depends}". The current work around is to manually add
"elpa-compat (>= 31.0)" to Depends of the addon package[1][2], which
would be error-prone if there is no test to catch this.

On the other hand, emacs-common generates breaks/replaces/provides for
all bundled addons with their elpa-* names since 1:30.1+1-7. Using
compat as an example, emacs-common will have the following:

,----
| Break: elpa-compat (<< 30.2.9999)
| Replaces: elpa-compat (<< 30.2.9999)
| Provides: elpa-compat (= 30.2.9999)
`----

With this info, dh-elpa does not really have to do any special handling
anymore, and just issuing the standard versioned elpa-compat as part of
`${elpa:Depends}', and apt should do the right thing. Consider the
following 2 cases:

* emacs-git-modes depends on "elpa-compat (>= 29.1.4.1)"; emacs-common
  30.2 provides a higher version of compat, so emacs-common can fulfill
  this dependency (you can also install elpa-compat 31.0.0.1 of course,
  which will also take precedence.)

* transient depends on "elpa-compat (>= 31.0)"; emacs-common 30.2 cannot
  fulfill this requirement, so elpa-compat 31.0.0.1 will be installed.

So it looks like after emacs 1:30.1+1-7, dh-elpa does not need to have
special handling of bundled addons anymore.

If this sounds good, I'll prepare an implementation.

(It would be good if dh-elpa has a unit/integration test for easier
verification, which I also planned to work on but didn't find time yet.)

[1] https://salsa.debian.org/emacsen-team/transient/-/blob/master/debian/control?ref_type=heads#L26
[2] https://salsa.debian.org/emacsen-team/with-editor/-/blob/master/debian/control?ref_type=heads#L22 

-- System Information:
Debian Release: forky/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (200, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 7.0.10+deb14-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-elpa depends on:
ii  debhelper               13.31
ii  emacs                   1:30.2+1-3
ii  emacs-gtk [emacs]       1:30.2+1-3
ii  libarray-utils-perl     0.5-3
ii  libconfig-tiny-perl     2.30-1
ii  libdebian-source-perl   0.133
ii  libdpkg-perl            1.23.7
ii  libfile-find-rule-perl  0.35-1
ii  libtext-glob-perl       0.11-3
ii  perl                    5.40.1-7+b1

dh-elpa recommends no packages.

dh-elpa suggests no packages.

-- no debconf information

-- 
Regards,
Xiyue Deng
signature.asc (application/pgp-signature, 861 B)