GNU bug report logs - #65222
29.1; Packages initialize but package--initialize is nil

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 65222 <at> debbugs.gnu.org, dalanicolai <at> gmail.com
Subject: bug#65222: 29.1; Packages initialize but package--initialize is nil
Date: Sat, 19 Aug 2023 12:24:32 +0300

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: dalanicolai <dalanicolai <at> gmail.com>,  65222 <at> debbugs.gnu.org
> Date: Sat, 19 Aug 2023 09:02:55 +0000
> 
> 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.

Please suggest documentation patches you think are in order, and
thanks.

Previous Next

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