[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for newer emac
From: |
Liliana Marie Prikler |
Subject: |
[bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for newer emacs. |
Date: |
Thu, 02 May 2024 06:24:00 +0200 |
User-agent: |
Evolution 3.48.4 |
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