bug#40971: Status: Updating built-in packages that seq depends on is broken due to a bug in package.el

[Stefan Monnier]

> I believe the bug lies in `package--list-loaded-files'.
> Theoretically, after upgrading a package, it should be reloaded if it
> was already in the load history.  But the code to find previously
> loaded files uses file-name-sans-extension to match load-history
> entries to library file names.  This fails because seq.el is installed
> as seq.el.gz, so file-name-sans-extension returns seq.el, not seq.

Hmm... have you traced this function to see how it's called and what
it returns?

AFAIK `seq.el.gz` should "never" be loaded (it's `seq.elc` which is
loaded), so I'm not sure it can make much difference.  Furthermore,
I think that when activating packages at startup we don't bother to look
for already loaded files and reload them.  We only do that *during*
a package upgrade (in order to try and avoid having the old version's
macros&functions get in the way while compiling the new code, mostly).

I was about to look at tweaking `package.el` so it doesn't depend on
`seq` (and hence delay loading `seq` just enough that we end up loading
the right version) but then remembered that `seq.el` may very well
become preloaded in some not too distant future, so we should come up
with a better fix.  E.g. improve `package-activate-all` so it can handle
the situation where some packages have already been activated and where
some of those are now obsolete.  This would also be useful for users who
want to change some `package.el` settings from the `.emacs` (i.e. after
`package-activate-all` has already been called) and then call
`package-activate-all` manually to take those changes into account.

> although it might also be enough to use
> find-library--from-load-history, which seems to already do most of the
> needed work.

Sounds like a good idea, indeed.


        Stefan