Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for newer emacs.

From: Liliana Marie Prikler <[email-masked]>
Date: Thu, 02 May 2024 06:24:00 +0200

Am Mittwoch, dem 01.05.2024 um 16:06 -0400 schrieb Morgan Smith:
> 
> I still feel like I'm conceptually missing something here.  Emacs 30
> doesn't actually exist, right?  We are currently on Emacs 29.
> emacs-next is the closest thing we have to Emacs 30.  Regardless of
> if we create a new file or use my phase I sent, we will only be
> rebuilding the emacs-next stuff.  The current emacs (29) is being
> left alone.
> 
> > 
> [...]
> Ok I think I now sort of see your point.  You don't want a build up
> of legacy support code in our files.  I do understand and support
> that and will send a patch of that nature if you would like. 
> However, I do think at least supporting all of the current Emacs
> packages in guix is a nice thing to do.
> 
> It is my personal opinion, that we should have the file support Emacs
> 29 and 30 for simplicity sake.  But again, if you disagree with me
> (which is valid), I'll send you a patch creating a new file.
TL;DR: If we do a new file or a phase, we only rebuild emacs-next.  If
we modify the file in-place, we rebuild emacs, because it uses it. 
Between a phase and a new file, a new file is preferable, because we
can then 'mv' it over the old one.

> In guix/build/emacs-utils.scm:emacs-generate-autoloads, there is a
> condition to support emacs 28.  I don't think we ever use that path
> anymore but it is nice to have a robust function that "just works".
> Espiaclly back when we did have emacs 28 and 29 packages in guix.
This is somewhat legacy code that has grown that way back when Emacs 29
was emacs-next.  There was no good reason to drop it with the switch,
but come Emacs 30, 31, and maintainability might be one.

Cheers