unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefankangas@gmail.com>
To: Jonas Bernoulli <jonas@bernoul.li>, 62751@debbugs.gnu.org
Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#62751: 29.0.90; New libraries that still need to be assigned to packages
Date: Mon, 18 Sep 2023 00:34:42 -0700	[thread overview]
Message-ID: <CADwFkmn0UYr6AE8gQsPyijYZ_KSX2MJR8D9xduaNtOkFHBFZRw@mail.gmail.com> (raw)
In-Reply-To: <87wmwobgk6.fsf@bernoul.li>

Jonas Bernoulli <jonas@bernoul.li> writes:

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

Right, so we either need to remove the "use-package" from
package--builtins, or move it out of the lisp/use-package directory.
Otherwise, it will show up in `M-x package-list-packages' as "available"
rather than "built-in" (as it's now considered part of 'use-package').

Given that it is its own package on GNU ELPA, I can see some logic in
moving it out of the use-package directory.  It's never ideal to move
files with git, but OTOH it's not been with us for that long yet.

Eli, Stefan, any opinions/preferences?

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

Yes, that's the other option.  That's also less than ideal, as it
involves tedious manual work.

Do we have some way to list new additions to package--builtins?

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

Thanks again for paying attention to this aspect.

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

You're right, now 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)

Also done, on emacs-29.

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

Is that needed given the entry in finder--builtins-alist?





  reply	other threads:[~2023-09-18  7:34 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-10 13:04 bug#62751: 29.0.90; New libraries that still need to be assigned to packages Jonas Bernoulli
2023-04-10 13:30 ` Eli Zaretskii
2023-04-11 16:03 ` Michael Albinus
2023-04-11 17:16   ` Jonas Bernoulli
2023-09-05 23:49     ` Stefan Kangas
2023-09-16  9:21       ` Stefan Kangas
2023-09-16 14:23 ` Stefan Kangas
2023-09-17 22:06   ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-18  7:34     ` Stefan Kangas [this message]
2023-09-18 11:02       ` Eli Zaretskii
2023-09-18 11:10         ` Stefan Kangas
2023-09-18 11:49           ` Eli Zaretskii
2023-09-21  0:15             ` Stefan Kangas
2023-09-21  2:29               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-21  7:26                 ` Stefan Kangas
2023-09-21 14:01                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-22 12:36                     ` Stefan Kangas
2023-09-21  7:15               ` Eli Zaretskii
2023-09-21  7:29                 ` Stefan Kangas
2023-09-23 14:42                 ` Stefan Kangas
2023-09-24 18:07                   ` John Wiegley
2023-09-24 20:22                     ` Stefan Kangas
2023-09-24 21:05                       ` John Wiegley
2023-09-26 22:37                       ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-18 11:58       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-21  0:06         ` Stefan Kangas
2023-09-18 15:19       ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-20 15:59         ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24 12:29           ` Stefan Kangas
2023-10-01 13:11         ` Stefan Kangas
2023-10-01 13:56           ` Eli Zaretskii
2023-10-01 15:46             ` Stefan Kangas
2023-10-01 16:52               ` Eli Zaretskii
2023-10-01 17:46                 ` Stefan Kangas
2023-09-18 15:33       ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-21  0:04         ` Stefan Kangas
2023-09-21 21:12           ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-22 15:30             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-23 11:35               ` Stefan Kangas
2023-10-13 23:33                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-14  6:45                   ` Eli Zaretskii
2023-10-14 14:39                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-14 16:21                     ` Stefan Kangas
2023-09-19 23:12       ` Richard Stallman
2023-09-20 23:45         ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADwFkmn0UYr6AE8gQsPyijYZ_KSX2MJR8D9xduaNtOkFHBFZRw@mail.gmail.com \
    --to=stefankangas@gmail.com \
    --cc=62751@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=jonas@bernoul.li \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).