Hi Paul, Paul Gevers <elbrus@debian.org> writes: > Hi, > > On 23-08-2025 12:35, Xiyue Deng wrote: >> While admittedly this is good to fix, I >> wonder whether relying on some periodic package rebuild service >> (automatically or manually) to find such issue and file RC bug for >> removing from testing is an acceptable compromise? > > > That's exactly what I'm doing here, which is of course why I rather want > it solved. I'll not remember this case in a year from now, and I'd be > spending time on the investigation. Having it tied to a fresh upload of > emacs will make that easier. > The status quo means extra work from you, and I understand that you'd like this to be fixed. On the other hand, as I mentioned in my previous email, blocking Emacs migration due to this means that the Emacsen team will probably need to file 3-4 RM bugs for packages like this to let Emacs migrate each time this happens, which is also some extra efforts that IMHO not well spent as there is no user facing issues. As a result, IMHO the best action to deal with this situation that saves the most energy from everyone is probably to just remove compat-el (or just keeping this bug open as-is). I'm CCing spwhitton and bremner to hear their thoughts (FTR, my reason for removing compat-el can be found in the last paragraph at [1]). P.S. I think compat-el is a particular package that it's more useful for older versions of Emacs when backported, e.g. Emacs 28.2 in Bookworm would benefit from the utilities it provides. However, IIUC, the backporting policy requires that the package exists in testing to be a candidate for backporting to stable, and this won't happen due to this bug, so it's still moot. > Paul > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111856#45 -- Regards, Xiyue Deng
Attachment:
signature.asc
Description: PGP signature