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

[Morgan Smith]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Mittwoch, dem 01.05.2024 um 12:32 -0400 schrieb Morgan Smith:
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> 
>> > Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
>> > > Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> > > 
>> > > I'm not a fan of adding another file so I came up with this
>> > > solution.  See attached patch.
>> > Hmm, I'm a bit torn on the solution.  On one hand, it is a local
>> > solution with just a phase, on the other having the file makes it
>> > easier to just mv it.
>> 
>> I don't understand the trade-offs here.  I'm a fan of keeping data as
>> close to where it's used as possible (so ideally in emacs.scm).  I'm
>> not sure what advantages putting it in a file gives over this
>> solution.
> The advantage lies in only rebuilding Emacs 30.
>
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.

>> Regardless, I trust the team to do the proper procedures.  I simply
>> believe we might do more package fiddling before Emacs 30 and that
>> potential problems might be assuaged if the comp-integrity file was
>> more forgiving and supported every Emacs equally.  Thus, I would
>> encourage it to be applied in the appropriate place now to avoid
>> potential headache but if we wish to wait for Emacs 30 that would
>> also be a valid choice.
> There are tradeoffs to be made here.  In principle, we could support
> "every Emacs ever", in practice, it hardly makes sense.  If you need an
> old Emacs in the future, you might as well use the built-in time
> machine.
>
> The right place is a new comp-integrity.el.  We can just mv it over the
> old one once Emacs 30 is the default Emacs.  We don't yet know how the
> help changes for 31, so we can't really ask a crystal ball to insert
> the right check.

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.

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.

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.