GNU bug report logs - #62751
29.0.90; New libraries that still need to be assigned to packages

Previous Next

Package: emacs;

Reported by: Jonas Bernoulli <jonas <at> bernoul.li>

Date: Mon, 10 Apr 2023 13:06:02 UTC

Severity: normal

Found in version 29.0.90

Fixed in version 30.1

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Stefan Kangas <stefankangas <at> gmail.com>, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Mon, 18 Sep 2023 00:06:33 +0200
Thanks!

Stefan Kangas <stefankangas <at> gmail.com> writes:
> Jonas Bernoulli <jonas <at> bernoul.li> writes:

>> 4. All, or most, of the *-ts-mode.el probably should be treated as
>>    separate packages.
>
> I might be missing something, but isn't this already the case?

It is.

>> 9. It seems a bit excessive to consider each use-package*.el a separate
>>    package.  Maybe they should all be part of a single use-package
>>    package.  An entry in finder--builtins-alist should be used to
>>    accomplish that.
>
> Done.

Maybe lisp/use-package/bind-key.el should be a separate package (and
maybe it should be moved out of that directory).

>> Maybe we should stop falling though to assign a new library to its own
>> separate package, if nothing else is specified explicitly?  It is of
>> course nice not having to either add a "Package" library header or a
>> finder--builtins-alist entry, but it also makes it easy to forget to
>> explicitly specify the package when doing that would be necessary.
>
> Hmm, yes that might make more sense.  One would have to add package
> statements to a ton of libraries, though.  So there'll be a lot of
> churn.
>
> Maybe it's worth it in the end, I don't know.

Probably not, but "carefully check any additions to package--builtins"
should be added to the release steps.

For the Emacsmirror I run code similar to `finder-compile-keywords'.
(I don't use that function, mainly because I need more details for the
Emacsmirror database, but also because for the last few releases there
have always been issues like this, which I had to override.)

For 29.1 I opened this issue, for 28.1 bug#55388.  I have done that
early enough so that it could have been taken into account before these
releases shipped with questionable entries in package--builtins.

I intend to do that well before the next release again.

By the way, IMO it would make sense to apply these on "emacs-29", not
just "master".

>> Speaking of finder--builtins-alist, what about adding these entries?:
>>   ("leim" . emacs)
>>   ("obsolete" . emacs)
>
> Done.

I think that has to be extended for "leim", similar to how there is a
separate entry for every subdirectory of "lisp/semantic":

 ("leim" . emacs)
+("ja-dic" . emacs)
+("quail" . emacs)

In addition to adding an entry for "lisp/obsolete", the "Package" header
should be removed from all files in that directory.

Please also have a look at bug#55388, a similar report for Emacs 28.1,
which also has not been fully addressed yet.

"lisp/emacs-lisp/shorthands.el" should provide a feature and be added to
the "emacs" package.




This bug report was last modified 1 year and 278 days ago.

Previous Next


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