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

#1138884#5
Date:
2026-06-05 06:58:26 UTC
From:
To:
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

#1138884#10
Date:
2026-06-05 08:58:42 UTC
From:
To:
control: severity -1 wishlist

Xiyue Deng [04/Jun 11:58pm -07] wrote:

Yes, I think you're right, we can change this now.

#1138884#17
Date:
2026-06-05 09:14:17 UTC
From:
To:
Sean Whitton <spwhitton@spwhitton.name> writes:

It sounds reasonable to me also.
Sean knows the requires/provides details better than I (since he worked
on that part), so I trust his judgement here.

#1138884#22
Date:
2026-06-11 06:23:13 UTC
From:
To:
Hi Sean, David,

David Bremner <david@tethera.net> writes:

Thanks for confirming! I actually thought of a potential problematic
case: what if the generated package name that emacs-common provides does
not exist in Debian (e.g. elpa-cl-lib)? And it turns out to be a
non-issue as shown below (tested in a sid Docker image):

,----
| $ sudo apt install elpa-cl-lib
| Note, selecting 'emacs-common' instead of 'elpa-cl-lib'
| Installing:
|   emacs-common
|
| Installing dependencies:
|   emacs-el  emacsen-common  install-info
|
| Suggested packages:
|   emacs-common-non-dfsg  emacs-editing-major-modes  ncurses-term
|
| Summary:
|   Upgrading: 0, Installing: 4, Removing: 0, Not Upgrading: 0
|   Download size: 35.6 MB
|   Space needed: 103 MB / 426 GB available
|
| Continue? [Y/n] n
| Abort.
`----

So I guess this can really work!

Will continue with this after the integration test is merged so that we
have some test coverage.

#1138884#27
Date:
2026-06-11 10:07:05 UTC
From:
To:
Xiyue Deng [10/Jun 11:23pm -07] wrote:

Nice.

IMO this is more important than that other work and can merge first.

#1138884#32
Date:
2026-06-12 02:13:09 UTC
From:
To:
Hi Sean,

Sean Whitton <spwhitton@spwhitton.name> writes:

Ah I was hoping that the test branch is safer as it doesn't change any
functions and can go in first.

Anyway, I experimented a change[1] and tested it in the
`built-in-addon-handling' branch, and rebased it on to the test branch
for testing. One of the test cases has cl-lib in Package-Requires, and
the generated diff looked OK[2].

So now we only remove `emacs' from the list of dependencies. The code
can be further simplified, but I'd like to keep the current structure in
case we want to do more later.

Thanks!

[1] https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/7eb8779e4a76392d04fd1fee4ac1936cdfd8a9d7
[2] https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/5c6df966e53069b8e0ade0697fddef0a1cbafdc7

#1138884#37
Date:
2026-06-12 10:59:29 UTC
From:
To:
Xiyue Deng [11/Jun  7:13pm -07] wrote:

I think I'd prefer to strip out everything we don't need anymore -- it's
always there in the Git history if required again.

#1138884#42
Date:
2026-06-13 06:23:04 UTC
From:
To:
Sean Whitton <spwhitton@spwhitton.name> writes:

Ack. Now I only keep the comparison with "emacs". Also shortened the doc
string. PTAL.

#1138884#47
Date:
2026-06-25 17:37:34 UTC
From:
To:
Xiyue Deng <manphiz@gmail.com> writes:

Friendly ping.