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

[Liliana Marie Prikler]

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.

> Just to be clear: what do you mean by adding another file?  I assume
> you mean adding a comp-integrity-next.el file which is almost
> identical to comp-integrity.el with these small changes in place.
Yes.

> > > If we believe that a core-updates merge will occur before Emacs
> > > 30 then I would like to see my original patch applied there.
> > It'd be only emacs-team, not core-updates, but we could do this
> > "quickly" either way.  But the point behind those is to keep them
> > small and manageable in a sense, so core-updates is typically not
> > concerned with leaves or leaf-like stuff.
> 
> I don't think I understand how our branch development stuff works.  I
> thought we put large dependency changes on core-updates so that the
> CI could chew through everything and make sure it's good before
> merging.
Most stuff is now organized within teams that have "smaller"
responsibilities.  I'm responsible for getting Emacs and Gnome updates
way later than we could…

> 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.

Cheers