[arch-general] User actions following system package upgrades?

[Tom Gundersen]

On Thu, Jan 26, 2012 at 12:11 PM, Paul Gideon Dann <pdgiddie at gmail.com> wrote:
> I've looked everywhere, but I can't find any reference to what the accepted
> wisdom is:
>
> I know that due to the way the kernel is upgraded, it is best to save kernel
> upgrade until the system can be rebooted, since the running kernel will be
> unable to load modules because the modules directory (/lib/modules/<version>)
> changes when a new kernel package is installed.
>
> For this reason, I have the "linux" package in my IgnorePkg line in
> pacman.conf, and upgrade it explicitly before a planned reboot.
>
> However, for what other packages is this true?  I also have "udev" in
> IgnorePkg, but is this necessary?  Is it safe to upgrade udev without
> rebooting?  I suspect that certain rules may disappear or change, and the
> running udev may not be happy about that.
>
> I'm guessing it's also best to shut down X and restart DBus after a DBus
> upgrade too, although in practice a reboot is usually simpler, and that it
> would also be sensible to reboot after a "glibc" upgrade too, although that's
> rare.  Any other thoughts?  Are these sorts of considerations documented
> anywhere?
>
> This issue of upgrading system packages while the system is running feels like
> a potentially dangerous situation to me.  Are we lucky that it doesn't cause
> too much trouble, or are in-place upgrades specifically handled gracefully by
> core system components such as udev?  (I don't see anything special in udev's
> install script.)  I suspect that most of us shrug it off and reboot only when
> we see breakage, but I hope you agree that's not a very safe way to work.

The kernel is the only package that we support ignoring on upgrade
(though even that within reason).

Upgrading udev without restarting it (or better yet, rebooting) is a
bad idea. The reason for this is that the default rules might have
changed, and they might not be supported in the existing instance
running on your machine. An almost seamless stop/upgrade/restart of
udev would be possible (fully seamless if we used systemd), but there
seems to be resistance to that kind of "magic".

Ignoring udev on upgrade is a bad idea as other packages that are
being upgraded might depend on changes it introduces (typically udisks
et al.).

Similar problems probably apply to other packages, but I haven't given
it a great deal of thought.

Cheers,

Tom