GNU bug report logs - #74604
30.0.92; FR: M-x package-upgrade - offer an option to show a diff on upgrade

Previous Next

Full log

View this message in rfc822 format

From: Stéphane Marks <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mail <at> daniel-mendler.de, philipk <at> posteo.net, Nobuyuki Kamimoto <kamimoto527 <at> gmail.com>, 74604 <at> debbugs.gnu.org
Subject: bug#74604: [PATCH v1] package.el: Add diff display and confirmation for package upgrades (Bug#74604)
Date: Sat, 13 Sep 2025 08:17:18 -0400

[Message part 1 (text/plain, inline)]

On Sat, Sep 13, 2025 at 7:34 AM Stéphane Marks <shipmints <at> gmail.com> wrote:

> On Sat, Sep 13, 2025 at 3:10 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > Cc: 74604 <at> debbugs.gnu.org
>> > Date: Sat, 13 Sep 2025 09:01:33 +0900
>> > From: Nobuyuki Kamimoto <kamimoto527 <at> gmail.com>
>> >
>> > +(defcustom package-upgrade-confirmation-policy t
>>
>> The default value sounds problematic to me.  For starters, it changes
>> previous behavior, which already should have a good reason.  Moreover,
>> IME most people don't care about the changes, and consider any display
>> that insists of showing them, let alone wants a confirmation, an
>> annoyance.  Consider the case that a user upgrades many packages at
>> once, for example.
>>
>> So my suggestion is to leave the default at nil, preserving previous
>> behavior.  This option is a very good feature, but only for users who
>> are actually interested in reviewing the changes when they upgrade.
>>
>> > +Possible values:
>> > +
>> > +\\=`t\\=' - Default
>> > +    Show diffs and prompt for all package upgrades.
>> > +
>> > +\\=`nil\\='
>> > +    Automatically upgrade all packages without showing diffs.
>>
>> We don't quote t and nil in doc strings, so please don't.
>>
>> > +  :type '(choice
>> > +          (const :tag "Always show diffs" t)
>> > +          (const :tag "Never show diffs" nil)
>> > +          (repeat :tag "Specific packages/archives to confirm"
>>
>> If we are going to request confirmation, the first two tags should
>> also mention that.  As written, the first two tags only talk about
>> showing the diffs and never mention that showing changes also requires
>> a confirmation.
>>
>
> I think I'd prefer a whitelist of packages I choose to trust vs. a
> blacklist of those I don't.  I'm guessing that for the people who want this
> feature (like me), their blacklist would be much longer than the whitelist,
> and we will not want to maintain that blacklist by hand.  Maintaining the
> whitelist will be easy, with so few packages to not warrant a review.
>

An option to automatically whitelist built-ins might also be useful, as
those are "core."

[Message part 2 (text/html, inline)]

Previous Next

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