Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1241905 > unrolled thread

Bug#1103033: dh-elpa: Handle version of built-in package better

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1103033: dh-elpa: Handle version of built-in package better Xiyue Deng <manphiz@gmail.com> - 2025-04-14 03:40 +0200
    Bug#1103033: dh-elpa: Handle version of built-in package better Sean Whitton <spwhitton@spwhitton.name> - 2025-04-14 04:50 +0200
      Bug#1103033: dh-elpa: Handle version of built-in package better Xiyue Deng <manphiz@gmail.com> - 2025-04-14 06:00 +0200
        Bug#1103033: dh-elpa: Handle version of built-in package better Sean Whitton <spwhitton@spwhitton.name> - 2025-04-14 06:30 +0200
          Bug#1103033: dh-elpa: Handle version of built-in package better Xiyue Deng <manphiz@gmail.com> - 2025-04-14 06:40 +0200

#1241905 — Bug#1103033: dh-elpa: Handle version of built-in package better

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#1241909

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1241913

[Multipart message — attachments visible in raw view] — view raw

Sean Whitton <spwhitton@spwhitton.name> writes:

> 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?
>

Option 1 also sounds good to me.  This may also be useful to handle
security update for stable version, though I'm not sure whether it will
automatically handle the upgrades.

(Wondering for the situation that Emacs version A provides foo 1.0, and
when foo 1.0 founds a security issue, and Emacs version A+deb12u1 fixes
it by providing foo 1.1, will foo 1.0 automatically upgrade to Emacs
A+deb12u1, or it still requires user manually uninstalling foo 1.0?)

>> 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.
>

Sounds good.  Will propose to upstream.

> -- 
> Sean Whitton

-- 
Regards,
Xiyue Deng

[toc] | [prev] | [next] | [standalone]

#1241915

[Multipart message — attachments visible in raw view] — view raw

control: reassign -1 src:emacs
control: retitle -1 emacs: generate versioned Provides for all :core packages

Hello,

On Sun 13 Apr 2025 at 08:55pm -07, Xiyue Deng wrote:

> Option 1 also sounds good to me.

Cool.  I'm not planning to work on it but I can review patches.

> This may also be useful to handle security update for stable version,
> though I'm not sure whether it will automatically handle the upgrades.
>
> (Wondering for the situation that Emacs version A provides foo 1.0, and
> when foo 1.0 founds a security issue, and Emacs version A+deb12u1 fixes
> it by providing foo 1.1, will foo 1.0 automatically upgrade to Emacs
> A+deb12u1, or it still requires user manually uninstalling foo 1.0?)

No, and in fact the foo with the security hole would override the one
shipped with Emacs.  We'd have to patch both packages.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1241916

[Multipart message — attachments visible in raw view] — view raw

Sean Whitton <spwhitton@spwhitton.name> writes:

> [...]
>>
>> (Wondering for the situation that Emacs version A provides foo 1.0, and
>> when foo 1.0 founds a security issue, and Emacs version A+deb12u1 fixes
>> it by providing foo 1.1, will foo 1.0 automatically upgrade to Emacs
>> A+deb12u1, or it still requires user manually uninstalling foo 1.0?)
>
> No, and in fact the foo with the security hole would override the one
> shipped with Emacs.  We'd have to patch both packages.
>

Ack.  Sigh.

> -- 
> Sean Whitton

-- 
Regards,
Xiyue Deng

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web