[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1111856: compat-el: autopkgtest regression: dh_elpa_test: command not found



Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Sat 23 Aug 2025 at 03:26pm -07, Xiyue Deng wrote:
>
>> 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.
>
> ISTM that doing the extra work to file those bugs is okay, and better
> than potentially having to go through NEW again.  I.e., it doesn't seem
> to me that RMing compat-el would be a good idea.
>

Specifically for compat-el, I don't think it's useful in Debian anymore.
In upstream Emacs, its `package--builtin-versions' always contains a
dummy entry of compat that is strictly higher than its own version (see
code point at [1]), e.g. for Emacs 30.1, it has `(30 1 9999)' as compat
version.  And for compat, it will never have a version higher than the
latest released version of Emacs (which is what compat for, provide
utility from newer Emacs versions to older Emacs versions).  This means
that if we ensure that the latest Emacs is packaged in Debian, compat-el
will never be installable with the breaks/replaces/provides generated
for built-in packages,

Well, strictly speaking (as I mentioned in a previous email), compat is
more useful when backported, e.g. for Emacs 28.2 in bookworm.  But as it
cannot enter testing because of this bug, this is also moot.

[1] https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/compat.el?h=emacs-30.2#n83

> -- 
> Sean Whitton

-- 
Regards,
Xiyue Deng

Attachment: signature.asc
Description: PGP signature


Reply to: