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

Previous Next

Full log

Message #23 received at 70632 <at> debbugs.gnu.org (full text, mbox):

From: Morgan Smith <morgan.j.smith <at> outlook.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, 70632 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for
 newer emacs.
Date: Wed, 01 May 2024 12:32:19 -0400

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

> Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
>> Liliana Marie Prikler <liliana.prikler <at> 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.

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.

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

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.

Previous Next

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