Bug 146452
| Summary: | yum package upgrades should use one ACID transaction per package, not separate ones for package removal and package installation | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Robin Green <greenrd> |
| Component: | yum | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | jbj, katzj, spacewar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-04-19 20:01:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
There's nothing yum can do about this. yum doesn't control the granularity of the process. Yum packs an rpm transaction set and then runs the transaction. There's no way to make it more or less granular. and since transactions to your filesystem are not ACID, even if yum could control access to the rpmdb like that you can't make it all that much better. I'm reassigning this to rpm, see what Jeff thinks. yum surely chooses what goes into a transaction, and the size of the transaction determines how much needs to be cleaned up. Meanwhile, an rpmdb has never promised Durability in the face of execptional events like "kernel crashed while updating". Sure Durability could be added with apply/commit transactions to an rpmdb, but adding durability comes at a considerable maintenance cost for the database, and ultimately does not solve the real problem, that files can and will be changed on the file system unpacking payloads no matter whether an rpmdb has transactional durability support. So even if rpmlib provided durability, the problem of "kernel crashing while updating" cannot be solved adequately. I'd much prefer that yum do one package upgrade per transaction, rather than packing potentially hundreds into a single transaction. I've had a lot of problems that would have been much easier to clean up if it was done as many smaller transactions. Even if you don't make this the default behavior, please at least add it as an option. This is a yum, not an rpm, problem atm. So back to yum, as rpm ain't about to start providing Durable db4 transactions tomorrow, or next month. There's the infrastructure for transaction splitting in yum now -- if you want smaller transactions, it should be easy enough to write a plugin to break apart at the appropriate points, but it's not going to be the default. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: My kernel crashed in the middle of a yum upgrade, while yum was installing and upgrading packages. When I rebooted and run yum upgrade again, it failed with: --> Finished Dependency Resolution Error: Missing Dependency: xorg-x11 is needed by package xorg-x11-Xvfb Error: Missing Dependency: bind is needed by package bind-chroot Error: Missing Dependency: xorg-x11-devel is needed by package xorg-x11-deprecated-libs-devel Error: Missing Dependency: httpd is needed by package httpd-suexec Error: Missing Dependency: openoffice.org is needed by package openoffice.org-i18n Error: Missing Dependency: kdegraphics is needed by package kdegraphics-devel Error: Missing Dependency: xorg-x11-deprecated-libs is needed by package xorg-x11-deprecated-libs-devel The cause of this turns out to be that old packages were left hanging around in the rpm database - as shown below: [root@pob ~]# rpm -q xorg-x11-Xvfb bind-chroot xorg-x11-deprecated-libs-devel httpd-suexec openoffice.org-i18n kdegraphics-devel xorg-x11-deprecated-libs-devel xorg-x11-Xvfb-6.8.1-12 xorg-x11-Xvfb-6.8.1-12.FC3.21 bind-chroot-9.2.4-2 bind-chroot-9.2.4-8_FC3 xorg-x11-deprecated-libs-devel-6.8.1-12 xorg-x11-deprecated-libs-devel-6.8.1-12.FC3.21 httpd-suexec-2.0.52-3 httpd-suexec-2.0.52-3.1 openoffice.org-i18n-1.1.2-10 openoffice.org-i18n-1.1.3-2.5.fc3 kdegraphics-devel-3.3.1-2.1 kdegraphics-devel-3.3.1-2.3 xorg-x11-deprecated-libs-devel-6.8.1-12 xorg-x11-deprecated-libs-devel-6.8.1-12.FC3.21 I am not sure whether this is actually a bug in rpm or yum, but there you go. I am rating this as severity High because it is not obvious to a non-technical user what to do to work around it. Version-Release number of selected component (if applicable): yum-2.1.11-3 How reproducible: Didn't try Steps to Reproduce: Actual Results: See above Expected Results: The operations of 1. Removing the old version of a package 2. Installing the new version of a package should have been part of one single ACID transaction on the rpm database, so that if a crash or power failure occurs during the transaction, after a reboot, running yum upgrade again will fix everything. (The actual files on the filesystem, as opposed to the rpm database, are probably not transactionally updated, but that doesn't matter so much because yum upgrade would fix any transient problems caused by a half-done package upgrade.) Additional info: Root filesystem (which contains the rpm database) is ext3