GNU bug report logs - #63536
Function to update Emacs itself (for example 29.1 to 29.2)

Previous Next

Full log

Message #41 received at 63536-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrew Goh <andrewgoh95 <at> yahoo.com.sg>,
 63536-done <at> debbugs.gnu.org
Subject: Re: bug#63536: Function to update Emacs itself (for example 29.1 to
 29.2)
Date: Sat, 15 Feb 2025 03:18:13 +0000

close 63536
tags 63536 + wontfix
thanks

Jim Porter <jporterbugs <at> gmail.com> writes:

> On 5/17/2023 6:37 AM, Eli Zaretskii wrote:
>> So you want a command to check whether a newer Emacs is available?
>> But where should this command look?  Many (most?) people install
>> precompiled binaries prepared by their distros, and I assume those
>> distros have their "check for updates" service or something?
>> We could check on the GNU FTP site, but how many users will want to
>> download and build Emacs from sources?
>> What do other people think about this?
>
> I think we could fairly easily *check* for the existence of a newer Emacs
> release, but the hard part is what to do about it. Is it enough to merely tell
> the user, "Emacs 29.1 is released," and just expect the user to figure out how
> to update?
>
> For users who get their Emacs from their distro, the distro is responsible for
> updates then. We can ignore that case.[1] (Ditto for any other package manager:
> PPAs, Homebrew, etc.)
>
> However, for users who get their Emacs from GNU FTP, the only update mechanism
> right now is 100% manual. It would be interesting to try to fix that, but it
> also seems difficult: if the user downloaded Emacs and compiled from source, can
> we make 100% sure that we can do that programmatically for the next release?
> What if Emacs adds a new library dependency? Maybe GNU FTP could also distribute
> binaries in some fashion instead[2], but that's yet another complexity to work
> out. If we distributed binaries, how would we do so?
>
> If someone wanted to spend the time to figure out all the issues with this, I
> think there'd be value in it, but I also think it's more effort than it's worth
> (unless this is literally just a notification, nothing more).

I tend to agree, so I'm closing this as wontfix.  I just don't see it
happening with all the complications it would entail.  Sorry.

If someone were to present a full-blown working patch, the situation
might be different, but even then I'd be slightly reluctant to merge it
due to the difficulty in maintaining it.  This should properly be
handled by distros on GNU/Linux, on macOS there's Homebrew, on
MS-Windows I have no idea but I assume whatever you do there applies.

Thanks for the feature proposal, nevertheless.

Previous Next

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