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

Attachment: signature.asc
Description: PGP signature

Reply via email to