GNU bug report logs - #19390
25.0.50; `package-activate' is too slow

Previous Next

Full log

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

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19390 <at> debbugs.gnu.org
Subject: Re: bug#19390: 25.0.50; `package-activate' is too slow
Date: Tue, 16 Dec 2014 20:00:00 -0200

2014-12-16 14:53 GMT-02:00 Dmitry Gutov <dgutov <at> yandex.ru>:
> That aside, it's too bad not the whole of discussion leading to this
> implementation is public.

The discussion started here:
http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00567.html
Oddly enough, I can't find the end of it. =/
I'll be glad to explain any of the considerations.

> Have the following alternative implementation options been considered?
> Since we only actually want to reload when upgrading, or reinstalling
> packages, maybe some key logic can move into `package-delete'.

Besides the points I mention below, there's one edge case where this
could be a problem. Built-in packages can be upgraded too, and they
can't be deleted.

> For instance:
>
> 1. Instead of scanning through the whole load-history when activating a
> package, we could have a list of paths that belonged to packages that we
> uninstalled during the current session. It would be collected in
> `package-delete', and it would certainly be empty at startup.

The way it's done right now, package-delete is called after
package-install during upgrades, so that would need to change in order
for this implementation to work.
I would rather ask on the devel-list before making a change like this
(I don't know if there's a particular reason behind the original
choice), but other than that, that sounds like a good solution.

> 2. Instead of saving paths, remove elements from the `features' list
> when a package is deleted. Then when a dependency of this package is
> installed (or even autoloaded [0]), it would load the new files, because
> they're not in features.

Again, this relies on us deleting before installing, but I prefer you
first idea. Removing elements from `features' could have unintended
consequences. We're pretending the package isn't loaded even though it
is (all its functions and variables are bound).

>
> [0] IIUC, the current approach doesn't cover this situation.

The current approach does cover autoloads. The autoloads file of a
package is always `load'ed when a package is activated (which always
happens when a package is installed, even after an upgrade). Calling
`load' on a file which contains a new definition for an already
defined autoload (which is what happens on upgrades) redefines the
autoload to the new definition.

Previous Next

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