On 4 November 2013 14:31, Miloslav Trmač <mitr(a)volny.cz> wrote:
That's true in the _general_ case, and therefore the ability to
have
off-line updates is a good _general_ default. We should be able to do
_much_ better for many common cases (at the very least, a package that
only has one executable, or one shared library, and no other
executables or shared libraries or data files with unknown function).
Even that's basically impossible to do in a race-free way. The way rpm
works is when you update a package, you actually install the new
package, then remove the old one. So there's a small but significant
time where just launching a command line utility makes it crash.
Without actually stopping the application from starting (for all
users) it's impossible to do correctly with rpm.
(How can rpmdb get "hosed", and how are offline updates
supposed to
prevent that?)
The idea is you have a small self contained "known good" environment.
There are no locale overrides, no LD_PRELOAD hacks and no debuggers
running, and all the things that make the transaction hang. Similarly,
because there's such a small runtime environment, there's less to go
wrong, e.g. X crashing and that kind of thing. I like what ChromeOS
does where it has a rescue-ish partition, to do the upgrade, but
without something like btrfs that can switch roots on a running
filesystem that's basically impossible on Linux.
Richard.