Package: dh-elpa Version: 2.1.9 Severity: wishlist A recent bug#1101304 shows some limitation of version handling of dh-elpa for packages that are both built-in and packaged separately. Currently, dh-elpa can mark a package as packaged separately, and then detect the version from an addon comment header, much like non-built-in packages. However, when a built-in package is sufficiently new, an addon can directly depend on Emacs itself without requiring the separately packaged version.
As an improvement to avoid requiring the separated packaged version, for a package `foo' that is built-in, if the packaged version meets the requirement of an addon, ${elpa:Depends} can just generate "Emacs (>= <current version>)"; otherwise generate "elpa-foo (>= <required version>)" as before. Implementation wise, AFAIK there is no public API to query the version of a built-in package, so for now one may need to inspect `package--built-versions' directly. Not sure whether upstream would implement an API for querying built-package versions. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.12.21-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.24.2 ii emacs 1:30.1+1-5 ii emacs-gtk [emacs] 1:30.1+1-5 ii libarray-utils-perl 0.5-3 ii libconfig-tiny-perl 2.30-1 ii libdebian-source-perl 0.128 ii libdpkg-perl 1.22.18 ii libfile-find-rule-perl 0.34-3 ii libtext-glob-perl 0.11-3 ii perl 5.40.1-2 dh-elpa recommends no packages. dh-elpa suggests no packages. -- no debconf information
signature.asc
Description: PGP signature