Re: Updating Elisp files while Emacs is running

[Bob Proulx]

Stefan Monnier wrote:
> > OS-level package managers such as Debian's dpkg generally replace files
> > unconditionally when upgrading.

But the Debian packages generally install new files when upgrading and
leave the old files behind.  (As I said in much more detail in my
other posting.)

> I think we'd be better off discussing it with concrete cases at hand.

Agreed.

> Let's try a few cases:
> - You have Emacs-24.5 running and upgrade to Emacs-25.1.  In this case,
>   making your Emacs process load files from the 25.1 version is risky,
>   because there can be (and there are) incompatibilities.  You might
>   still want to do it, since the incompatibilities won't always bite
>   you, and it can be better than failing right away.
> 
>   Note that the files have to be elsewhere, because Debian lets you have
>   both Emacs-24.5 and Emacs-25.1 installed at the same time.

The only way this case can occur is if the user removes emacs24 after
having installed emacs25.  But they shouldn't remove emacs24 if they
are still using it.  I think this is a local user error.  The default
actions are okay.

> - You have Emacs-24.4 running and upgrade to Emacs-24.5.  In this case,
>   there should be very few incompatibilities, so it might make sense to
>   try and redirect the running process to use the new 24.5 files.
>
>   One possible solution here is for the Debian package to use
>   directory names like /usr/share/emacs/24/... instead of
>   /usr/share/emacs/24.4/... since Debian doesn't let you have both 24.4
>   and 24.5 installed at the same time (contrary to the default Emacs
>   build's presumption).

This would only come up with upgrading from one distribution release
to another.  At which time a reboot is needed to boot the new kernel.
Because of the release schedules for both Emacs and distributions such
as Debian this is an unlikely case as Emacs will almost always have
rolled to a new major version.

Users of the daily bleeding edge Unstable or the rolling release
candidate Testing are expected to know a little more about how things
work in order to administer their system.  Being the daily bleeding
edge bits Unstable is not for the casual user and there is often much
breakage.  Even the rolling testing candidate Testing goes through
transitions which requires advanced knowledge of the system to unbreak
it at times.  Life is a compromise.  The upgrades that are very well
tested are the release upgrades.  But users want early access to the
development bits which are less well polished.  There aren't enough
volunteer resources to polish every package every day to release
quality.  You could search for CUT (Constantly Usable Testing) for a
proposal to deliver it but it has not yet been implemented.

> - You have ELPA package sm-c-mode-3.4 installed (and an Emacs is
>...

ELPA may be problematic and a place where improvements could be made
but the original poster indicated they were using Debian packages.  In
which case ELPA wasn't the fault.

Bob