Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)

[Lynn Winebarger <owinebar@gmail.com>]

On Wed, Apr 19, 2023 at 2:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Wed, 19 Apr 2023 11:22:10 -0700
> > Cc: joaotavora@gmail.com, emacs-devel@gnu.org
> > From: Jim Porter <jporterbugs@gmail.com>
> >
> > On 4/19/2023 5:47 AM, Eli Zaretskii wrote:
> > > Also, does package.el support "downgrading" to the bundled version?
> > > Did anyone actually try that?  In particular, what happens with the
> > > dependencies the user upgraded together with the package being
> > > "uninstalled", due to the minimum requirements of that package?
> >
> > I've done this in the past and everything works pretty much as expected
> > from my recollection: you can uninstall a package that you got from
> > ELPA, so afterwards, you'd just get the bundled version (you might need
> > to restart; I always do).
> >
> > In addition, any automatically-installed dependent packages are marked
> > with the status "dependency". You can remove no-longer-needed deps via
> > 'package-autoremove'. When uninstalling a package interactively in the
> > *Packages* buffer, it will even suggest that you remove unneeded deps
> > when appropriate (see 'package-menu-execute').
>
> IMO, downgrading to the bundled version should be much simpler and by
> default should remove all the dependencies without asking and without
> any need for manual user actions.
>
> In any case, I don't think this use case was considered or tried
> enough for us to consider it a solved issue.  I'm quite sure there's
> more here than meets the eye, simply because this is rarely if ever
> done.

One of the design points of the unboxing package-management-wrapper
I'm writing is maintaining distinct package areas with a notion of
scoping.  My purpose was to enable separate management of
site-packages and user packages.  A site administrator might have one
set of packages, and a user might want different versions of those
packages.  So, the dependency calculation for user packages should
allow for dependencies to be satisfied by site packages, but not vice
versa (that's the scoping).  The "delta" of the package set installed
in the user area has to be enough to make the set of libraries "seen"
by the user coherent.  That is, say package A and B both depend on
package C and all are in the site-level packaging area.  Then the user
wants a different version of package A, which requires a different
version of package C.  Coherence means that if the version of package
B installed at the site level is incompatible with the desired version
of package C, then a compatible version of package B will also have to
be installed in the user packaging area.  That set has to be
transitively closed.

But the separation into those two is just a default configuration.
Arbitrary package areas can be defined, each with their own set of
"in-scope" areas.  One easily reversible way to add a new version of
eglot would be to set up a new package area for it, with whatever
other package areas are loaded being put in its scope, then install
the minimum coherent set of packages into the new area.  Then rolling
back the update would be trivial, and it could be "committed" to the
usual package area once the user was satisfied.

My only other thought on this discussion, as a package (ab)user
running multiple versions of emacs, is that package releases should be
dependent on the emacs version installing it.  What I see as available
packages/upgrades when I list packages while running emacs 28 should
probably be different (for some packages) than what I see while
running emacs 25 or emacs 29.  It seems like the release philosophy
after version 24 has been conservative about changes to the run-time
semantics per major release, so the versioning probably doesn't need
to be conditioned on the minor version of the Emacs binary.

Lynn