Re: Summary and next steps for (package-initialize)

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Thu, 24 Aug 2017 23:52:19 -0400
> 
> >> - Change package-initialize so it keeps track of what it activated and if
> >> called a second time, perform a diff between what was activated before
> >> and what should be activated now and based on this activate the new pkgs
> >> and deactivate the excess ones?
> > This could prove tricky, if some package that shouldn't be loaded
> > affects another package that should.  Right?
> 
> Not sure what "This" refers to.  I'll assume you're referring to
> "deactivate"

Good assumption.

> I was thinking of doing it via unload-feature and declare that if it
> doesn't work quite-right, it's a bug in the package.

What about packages that include accommodations to, and dependencies
on, other packages?  Imagine the following situation:

 . package B modifies its behavior if package A is loaded
 . the user sets up package-load-list such that package B should be
   loaded, but package A should not be
 . package B is activated by package-initialize after package A was
   activated, so B modifies its behavior
 . package-initialize unloads A
 . the result is that B behaves as if A is loaded, contrary to what
   the user wanted, and will probably produce weird errors at some
   point, or subtly incorrect behavior

I don't think we can claim in this case that there's a bug in either
of these two packages, can we?  Or is there a way for the packages to
be prepared for such situations?