bug#65222: 29.1; Packages initialize but package--initialize is nil

[Philip Kaludercic <philipk@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: dalanicolai <dalanicolai@gmail.com>
>> Date: Fri, 11 Aug 2023 11:08:13 +0200
>> 
>> To reproduce the behavior we can not use 'emacs -Q', but otherwise the
>> bug is very simple. From a clean Emacs install simply install some
>> package. Now on (normal) startup (and `package-enable-at-startup` is t)
>> the packages get initialized before evaluating 'init.el' (indeed after
>> installing a single package, the package-alist wil be
>> populated). However, the value of `package--initialized` is still nil
>> (and I guess it should be t now).
>
> Philip, any comments?

I can reproduce the issue, but this isn't an issue, since
`package-enable-at-startup' is related to the activation of packages at
startup, not the initialisation of package.el.  In startup.el we find

--8<---------------cut here---------------start------------->8---
;; If any package directory exists, initialize the package system.
  (and user-init-file
       package-enable-at-startup
       (not (bound-and-true-p package--activated))
       (catch 'package-dir-found
	 ...)
       (package-activate-all))
--8<---------------cut here---------------end--------------->8---

And it makes sense, when we consider the difference between
`package-activate-all' and `package-initialize'.  The former goes
through all available packages ensures they can be used, the former sets
up package.el-internal variables in addition to what
`package-activate-all' does, which is not necessary at startup if we
just want the packages to be made available for the user.

So south I understand the confusion, I believe the behaviour is correct.
What we could do is to extend the documentation at some places to avoid
this confusion in the future.

>> This report is related to a subsequent bug report that I will send
>> directly after this one.
>
> Evidently, you never did, did you?