Hello, On Sun 13 Apr 2025 at 06:28pm -07, Xiyue Deng wrote:
> 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.
Right.
> 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.
There are a couple of options here:
- Emacs adds versioned Provides: and then it satisfies the dependencies
without the dependencies getting more complicated
- We generate dependencies "elpa-foo (>= ...) | emacs (>= ...)".
I think I prefer the former, because it retains the possibility of not
installing Emacs along with addons, an invariant we've had for a while.
But what's your opinion?
> 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.
I think they probably would, if you'd like to ask about it.
--
Sean Whitton
signature.asc
Description: PGP signature
