Unless you’ve set package-native-compile to t so you’ll rarely see this buffer. Installing new packages is not a frequent operation in normal Emacs usage, and when a user installs a new package and loads it, he’ll expect that buffer, not when simply having a package that requires that a package.
On 3 Jun 2023 at 3:10 PM +0100, Eli Zaretskii <eliz@gnu.org>, wrote:
> > Date: Sat, 3 Jun 2023 15:02:18 +0100
> > From: Jimmy Wong <wyuenho@gmail.com>
> > Cc: 63871-done@debbugs.gnu.org
> >
> > The problem is this:
> >
> > 1 There’s no-native-compile:r set in the file, so a eln file was never produced.
> > 2 nativecomp does not know which file should not be compiled until it opens the file
> > 3 Whenever a require is encountered, nativecomp can’t find its eln, doesn’t know it can’t be compiled
> > until it reads the file, and it can’t read the file until it unzips the file.
> > 4 This unnecessary work is done every time any package requires one of these packages that
> > cannot be compiled, again and again, generating an extra buffer that mess up the buffer orders in
> > the buffer list.
>
> Sorry, I don't see any problem. This is normal and expected behavior,
> and one more buffer cannot possibly be a problem. Especially since
> that buffer will be created soon enough anyway, once you load some
> previously-uncompiled package.
>
> I fail to understand why another buffer could be a problem.
>
> I don't see any bug here.