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
