Package: emacs Version: 1:28.2+1-15 Severity: normal X-Debbugs-Cc: Xiyue Deng <[email protected]> Control: affects modus-themes
Arguably modus-themes and leuven-theme are different than the other built-in themes, because they have an ELPA counterpart; however, this is why they need to be tracked like any other elpa-foo Debian packages. I first became aware of this issue (see Bug#1037135) during bookworm, and I confirmed it's still a problem in trixie and forky at the time I'm filing this bug. It's the same class of elpa-foo package is behind the built-in version, masks it, and causes breakage. The specific case I'm looking at is modus-themes (although leuven-theme is also affected). /usr/share/emacs/*/etc/themes/modus-themes.el has everything needed for dh-elpa to generate modus-themes-pkg.el, and if upstream doesn't want to start treating it as a built-in then we need to do the system-integration work of limiting breakage. Because upstream doesn't generate a modus-themes-pkg.el, Emacs doesn't count it built-in package. Upstream can argue that they don't need to track themes, because: 1. The user uses the built-in copy OR 2. The user automatically receives updates from ELPA, which is enabled by default, and thus the packaged version is always newer than the built-in copy that isn't tracked as a built-in package. Thus, they are able to somewhat reasonably maintain that it's out-of-scope for them on practical grounds. Unfortunately, that limited scope causes problems in Debian with modus-themes, as well as a future leuven-theme. Please forward this bug to them, and if this isn't fixed upstream, please use dh-elpa to generate foo-theme-pkg.el data for themes that provide the necessary metadata. Here is a simple heuristic to find affected themes, because presumably there will be more in the future: grep Version /usr/share/emacs/*/etc/themes/* Regards, Nicholas
