GNU bug report logs - #76567
30.1; package-install-upgrade-built-in upgrades built-ins to the same version

Previous Next

Package: emacs;

Reported by: Ship Mints <shipmints <at> gmail.com>

Date: Tue, 25 Feb 2025 20:36:01 UTC

Severity: normal

Merged with 77136

Found in versions 30.1, 31.0.50

Full log


Message #23 received at 76567 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76567 <at> debbugs.gnu.org
Subject: Re: bug#76567: 30.1; package-install-upgrade-built-in upgrades
 built-ins to the same version
Date: Wed, 26 Feb 2025 11:55:52 -0500
[Message part 1 (text/plain, inline)]
Okay, then this behavior is merely unexpected per "newer" in the
documentation, and it's not a bug, per se.

-Stephane

On Wed, Feb 26, 2025 at 11:48 AM Philip Kaludercic <philipk <at> posteo.net>
wrote:

> Ship Mints <shipmints <at> gmail.com> writes:
>
> > "replace with newer versions from the archives" is not what's happening.
> > It seems to replace with identical versions, just from the archives.
>
> The issue is that `package-install-upgrade-built-in' uses the phrasing
>
>   If disabled, then ‘package-install’ will not suggest to replace a
>   built-in package with a (possibly newer) version from a package archive.
>                            ^^^^^^^^^^^^^^
>
> Which is not to say that the behaviour you are describing is not
> good...  A related issue here is that package.el has two separate
> upgrade procedures (package-upgrade-all and the list-package one) that
> cause these kinds of irregularities to pop up.  I have been planning to
> rewrite the package list interface to use the same logic as the
> commands, but I have to find the time to do that properly :/
>
> >
> > On Wed, Feb 26, 2025 at 10:39 AM Philip Kaludercic <philipk <at> posteo.net>
> > wrote:
> >
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> >> From: Ship Mints <shipmints <at> gmail.com>
> >> >> Date: Tue, 25 Feb 2025 15:35:10 -0500
> >> >>
> >> >> As part of my production upgrade to 30.1, I wrote a program to
> install
> >> >> my local ELPA tree from scratch, and take the opportunity to prune
> and
> >> >> curate packages.
> >> >>
> >> >> One thing that surprised me, that I didn't notice in 29.4, is that if
> >> >> 'package-install-upgrade-built-in' is non-nil,
> 'package-list-packages'
> >> >> reports built-ins needing upgrades from ELPA but to the *identical
> >> >> versions* in the 30.1 tree.  I was expecting upgrades to be actual
> >> >> upgrades, not side-grades, as they say.  The reason I didn't see
> >> >> this on 29.4, is that the distro versions were older than ELPA so I
> >> >> was happy to take the upgrades.  This does not appear to be a
> >> >> regression, just a general bug report.
> >> >
> >> > Philip, could you please look into this?
> >>
> >> (emacs) Package Installation says:
> >>
> >>    If you customize ‘package-install-upgrade-built-in’ to a non-‘nil’
> >> value, be very careful when using commands that update many packages at
> >> once, like ‘package-upgrade-all’ and ‘U’ in the package menu: those
> >> might overwrite built-in packages that you didn't intent to replace with
> >> newer versions from the archives.  Don't use these bulk commands if you
> >> want to update only a small number of built-in packages.
> >>
> >> I read this as that OPs behaviour what the option intends to do.
> >>
>
[Message part 2 (text/html, inline)]

This bug report was last modified 88 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.