Bug 506323 - rpm looks for deps outside of chroot?
Summary: rpm looks for deps outside of chroot?
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 11
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-06-16 17:05 UTC by Mike McLean
Modified: 2014-01-21 06:13 UTC (History)
6 users (show)

Fixed In Version: 4.7.0-2.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-11 16:55:34 UTC
Type: ---

Attachments (Terms of Use)

Description Mike McLean 2009-06-16 17:05:13 UTC
Description of problem:
In some instances, during a chroot transaction, rpmlib seems to be checking outside the chroot for deps. The problem first appeared on a rhel5-ish build system, but once I isolated the problem I was able to replicate it on F11

Version-Release number of selected component (if applicable):
(up to date F11 host)

How reproducible:

Steps to Reproduce:
1. create a RHEL-4 chroot that includes xorg-x11-font-utils, but not xorg-x11-75dpi-fonts (I used mock to do this)
2. ensure /usr/X11R6 is not present in main system (outside chroot)
3. attempt to install xorg-x11-75dpi-fonts in the chroot... failure
4. now try 1-3 with /usr/X11R6 present (an empty dir will do)

I've replicated step 3 with both yum and rpm directly.
[root@megadoomer ~]# rpm --root /var/lib/mock/mikem/root -ivh fonts-xorg-75dpi-6.8.2-1.EL.noarch.rpm 
warning: fonts-xorg-75dpi-6.8.2-1.EL.noarch.rpm: Header V3 DSA signature: NOKEY, key ID db42a60e
error: Failed dependencies:
	/usr/X11R6/bin/mkfontdir is needed by fonts-xorg-75dpi-6.8.2-1.EL.noarch
[root@megadoomer ~]# ls -l /var/lib/mock/mikem/root/usr/X11R6/bin/mkfontdir
-rwxr-xr-x. 1 root root 137 2009-03-31 14:15 /var/lib/mock/mikem/root/usr/X11R6/bin/mkfontdir

Actual results:
install fails when /usr/X11R6 is not missing outside the chroot

Expected results:
data outside the chroot should not affect dependency resolution in the chroot

Additional info:
This is not the first time I've seen rpm behave badly with chroots (bug 192153).

Comment 1 Mike McLean 2009-06-16 17:09:56 UTC
erg, "Actual results" in the description should read:
install fails when /usr/X11R6 is missing outside the chroot

Comment 3 Panu Matilainen 2009-06-17 09:10:21 UTC
Ok, easily reproduced. The issue is that rpmdbFindByFiles() doesn't take chroot into account when fingerprinting, that part of the bug is like 10 years or more old. Something between rpm 4.4.x and 4.6.x has caused the failing stat() to cause the item to be not found at all despite being present in the rpmdb.

Taking chroot into account there isn't hard (I've a patch already), just hunting down what exactly causes the behavior change between 4.4.x and 4.6.x first.

Comment 4 Panu Matilainen 2009-06-17 10:32:27 UTC
The first half of the fix is here: http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=0055fecfde5404c5106ac0fc58052e9264da8592

That still leaves rpm doing fingerprint lookup outside chroot, will fix that too but at least with the above it doesn't cause bogus failure in this case.

Comment 5 Mike McLean 2009-06-17 21:35:54 UTC
Thanks for the quick turnaround! Tested out the patch and it does resolve the issue for us.

Comment 6 Fedora Update System 2009-06-18 16:19:31 UTC
rpm-4.7.0-2.fc11 has been submitted as an update for Fedora 11.

Comment 7 Fedora Update System 2009-06-19 13:45:23 UTC
rpm-4.7.0-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update rpm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6772

Comment 8 Mike McLean 2009-06-23 21:01:29 UTC
Is the second half of the fix in git?

Comment 9 Fedora Update System 2009-07-11 16:55:02 UTC
rpm-4.7.0-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

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