GNU bug report logs - #55388
28.1; New libraries that neither belong to a package nor provide a feature

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55388 in the body.
You can then email your comments to 55388 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; New libraries that neither belong to a package nor provide a
 feature
Date: Thu, 12 May 2022 20:35:31 +0200

"lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
a "Package" library header.  I think "Package: emacs" should be added.

Like other files in that directory "lisp/leim/quail/cham.el" neither
provides a feature nor is it explicitly made part of a package.  Would
it make sense to add ("leim" . emacs) to `finder--builtins-alist'?

Maybe another such entry should be added for the "obsolete" directory?

Unlike other "epa-*" libraries, "lisp/epa-ks.el" isn't made part of
the "epa" package and fails to provide a feature.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 55388 <at> debbugs.gnu.org
Subject: Re: bug#55388: 28.1; New libraries that neither belong to a package
 nor provide a feature
Date: Fri, 13 May 2022 14:45:01 +0200

Jonas Bernoulli <jonas <at> bernoul.li> writes:

> "lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
> a "Package" library header.  I think "Package: emacs" should be added.
>
> Like other files in that directory "lisp/leim/quail/cham.el" neither
> provides a feature nor is it explicitly made part of a package.  Would
> it make sense to add ("leim" . emacs) to `finder--builtins-alist'?

Are all .el files supposed to have either a Package: header or a
`provides' these days?  I wasn't aware of that...

Hm...  I see that Chong did something like that with all the preloaded
.el files in bd78fa1d544, so I guess that's true?

> Maybe another such entry should be added for the "obsolete" directory?
>
> Unlike other "epa-*" libraries, "lisp/epa-ks.el" isn't made part of
> the "epa" package and fails to provide a feature.

I think it's separate thing, but it should have a provides, so I've now
added that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55388 <at> debbugs.gnu.org, Jonas Bernoulli <jonas <at> bernoul.li>
Subject: Re: bug#55388: 28.1; New libraries that neither belong to a package
 nor provide a feature
Date: Tue, 28 Jun 2022 14:37:41 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Jonas Bernoulli <jonas <at> bernoul.li> writes:
>
>> "lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
>> a "Package" library header.  I think "Package: emacs" should be added.

The same is true for smie.el, syntax.el, tabulated-list.el, testcover.el
and possibly others.  Should they have such a header as well?

>> Like other files in that directory "lisp/leim/quail/cham.el" neither
>> provides a feature nor is it explicitly made part of a package.  Would
>> it make sense to add ("leim" . emacs) to `finder--builtins-alist'?
>
> Are all .el files supposed to have either a Package: header or a
> `provides' these days?  I wasn't aware of that...
>
> Hm...  I see that Chong did something like that with all the preloaded
> .el files in bd78fa1d544, so I guess that's true?

It seems like it's not consistent.  What do we use such a header for?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 55388 <at> debbugs.gnu.org, Jonas Bernoulli <jonas <at> bernoul.li>,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#55388: 28.1; New libraries that neither belong to a package
 nor provide a feature
Date: Wed, 29 Jun 2022 11:58:18 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

>> Hm...  I see that Chong did something like that with all the preloaded
>> .el files in bd78fa1d544, so I guess that's true?
>
> It seems like it's not consistent.  What do we use such a header for?

The commit message only says:

    Add "Package:" file headers to denote built-in packages.

So...  I don't know?  Perhaps Stefan M remembers; added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 55388 <at> debbugs.gnu.org
Subject: Re: bug#55388: 28.1; New libraries that neither belong to a package
 nor provide a feature
Date: Wed, 29 Jun 2022 07:35:34 -0400

>> Jonas Bernoulli <jonas <at> bernoul.li> writes:
>>> "lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
>>> a "Package" library header.  I think "Package: emacs" should be added.
> The same is true for smie.el, syntax.el, tabulated-list.el, testcover.el
> and possibly others.

Hmm... smie.el, syntax.el, and tabulated-list.el do `provide`
themselves, AFAICT.  Indeed it seems to be missing from `testcover.el`.

> Should they have such a header as well?
[...]
> It seems like it's not consistent.  What do we use such a header for?

IIRC the question is whether we want to present these files as "a
package" or as "a file part of some other package" in things like
the finder.


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 55388 <at> debbugs.gnu.org, Jonas Bernoulli <jonas <at> bernoul.li>,
 Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#55388: 28.1; New libraries that neither belong to a package
 nor provide a feature
Date: Thu, 30 Jun 2022 10:58:58 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Hmm... smie.el, syntax.el, and tabulated-list.el do `provide`
> themselves, AFAICT.  Indeed it seems to be missing from `testcover.el`.

Yup.  I've now added one.

>> Should they have such a header as well?
> [...]
>> It seems like it's not consistent.  What do we use such a header for?
>
> IIRC the question is whether we want to present these files as "a
> package" or as "a file part of some other package" in things like
> the finder.

So somebody should go through all the files that lack a package: and see
if they feel it belongs in some package?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #27 received at 55388-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 55388-done <at> debbugs.gnu.org
Subject: Re: bug#55388: 28.1; New libraries that neither belong to a package
 nor provide a feature
Date: Sun, 17 Sep 2023 16:15:29 -0700

Version: 29.2

Jonas Bernoulli <jonas <at> bernoul.li> writes:

> "lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
> a "Package" library header.  I think "Package: emacs" should be added.

Done.

> Like other files in that directory "lisp/leim/quail/cham.el" neither
> provides a feature nor is it explicitly made part of a package.  Would
> it make sense to add ("leim" . emacs) to `finder--builtins-alist'?
>
> Maybe another such entry should be added for the "obsolete" directory?

Fixed in Bug#62751.

> Unlike other "epa-*" libraries, "lisp/epa-ks.el" isn't made part of
> the "epa" package and fails to provide a feature.

Done.

Thanks for paying attention to this aspect.  I installed the fixes on
emacs-29 (commit 71a1f0fdc9e), and am consequently closing this bug
report.

Previous Next

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