On Sat, 2006-09-09 at 16:57, Lamar Owen wrote:
In the general case, I'd like to issue something like:
# acidfs-begin-transaction # yum -y update [bunch of output] # if yum-no-error-condition; # acidfs-commit # else # acidfs-rollback # fi
Isn't that what LVM snapshots are supposed to provide?
Yum is managing the whole system.
It is currently managing the whole filesystem. But what about in-memory program text?
That's up to the rpm layer and the scripts contained in the packages. Yum doesn't know much about that other than dependencies.
The currently loaded programs need to continue to have the older libs available if needed;
This would not be possible without massive changes in the way RPM works. The new installs won't happen if they can't see their dependent libs.
a single 'commit' operation at the end needs to atomically reload program text and provide consistent library dependencies post-run (the only way you can do this now is shut down the system, boot rescue media, and yum update to a chroot (which is the system), then reboot the system (aka 'booting an update CD'; anaconda does this quite well)). The in core text needs to be isolated from what's going on on the filesystem, and if an error occurs (out of space, for instance, or a locked file) an atomic rollback would be very nice (anaconda does not do this, though).
The only hope would be to make the equivalent of a virtual machine where the old system keeps running until the new one is completely constructed.
Given an ACID database, would you expect to be able to upgrade it to a new, potentially incompatible version of an ACID database with transactions in progress?
Of course I would; a filesystem/database (hmm, let's see, similar to, but farther beyond what NILFS claims) would have to be guaranteed backwards compatible.
Backwards compatibility? You seem to have confused Linux distributions with something else. Try, for example, to copy a Centos 3.x distro onto filesystems created by 4.x and make it boot.
That's a given for a filesystem; it is unreasonable for the authors of a filesystem to introduce such changes and expect seamless updates of the filesystem code itself.
Are filesystem authors required to be reasonable?
What yum needs is just some special consideration when modifying its own components.
Ok, let me repeat: I updated the yum components in the right order. This is NOT the sqlite/python-sqlite issue. In my case, after following the advice of updating python-sqlite, then sqlite, then yum and its dependencies, I got a system with a lot of dupes and out of sync libraries. Lots of out of sync libraries; I've not finished the recovery yet, although bind at least is working.
I think I'm missing something here. If yum itself or the rpm database wasn't broken, what went wrong?
If there were a 'yum rollback' (or a 'acidfsrollback snapshot-prior-to-yum') then I could at least try it again. But there isn't, and I know there isn't, and I know all the deal about no support, etc etc.
But you've made a big assumption here that yum itself would work properly while doing this. If yum was working right you wouldn't have dups now.
Just throwing an idea out, that's all, for discussion. This systemic non-atomicity and inconsistency is endemic to all linuxen at the moment.
And necessarily so, since each rpm package installs independently and may have to complete with both process and filesystem changes before some of the others will work.