On 4 November 2013 14:31, Miloslav Trmač <mitr@xxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
