Bug 146452 - yum package upgrades should use one ACID transaction per package, not separate ones for package removal and package installation
yum package upgrades should use one ACID transaction per package, not separat...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
3
All Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-28 08:02 EST by Robin Green
Modified: 2014-01-21 17:51 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-19 16:01:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robin Green 2005-01-28 08:02:06 EST
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
Comment 1 Seth Vidal 2005-01-28 08:42:39 EST
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.
Comment 2 Jeff Johnson 2005-04-02 08:28:29 EST
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.
Comment 3 Eric Smith 2005-10-07 04:21:17 EDT
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.
Comment 4 Jeff Johnson 2005-10-25 18:26:28 EDT
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.
Comment 5 Jeremy Katz 2006-04-19 16:01:01 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.