Bug 772039 - yum crashes during dependence resolution
Summary: yum crashes during dependence resolution
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-05 17:59 UTC by Elmar Stellnberger
Modified: 2014-01-21 23:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-12 08:30:43 UTC
Type: ---


Attachments (Terms of Use)
all yum.repos.d/*.repo-s cated in one (3.33 KB, application/octet-stream)
2012-01-05 18:00 UTC, Elmar Stellnberger
no flags Details
screen output of yum in debug level 10 (highest) (3.08 KB, application/x-gzip)
2012-01-05 18:01 UTC, Elmar Stellnberger
no flags Details
strace of yum until it crashes (899.29 KB, application/x-gzip)
2012-01-05 18:03 UTC, Elmar Stellnberger
no flags Details

Description Elmar Stellnberger 2012-01-05 17:59:09 UTC
I have installed fedora16/yum in a chroot environment and want to use yum to update openSUSE. This seems to work quite well in the first place; however then yum crashes during dependence resolution. Is the dependence resolution of yum too weak to deal with openSUSE packages or do we have another error in here?

# yum --version
3.4.3
  Installiert: rpm-4.9.1.2-1.fc16.i686 am 2012-01-05 11:04
  Gebaut    : Fedora Project am 2011-09-29 13:58
  Übermittelt: Panu Matilainen <pmatilai> am 2011-09-29

  Installiert: yum-3.4.3-7.fc16.noarch am 2012-01-05 11:14
  Gebaut    : Fedora Project am 2011-12-09 19:06
  Übermittelt: J??n ONDREJ (SAL) <ondrejj(at)salstar.sk> am 2011-12-09


How reproducible: always
Steps to Reproduce:
# chroot /fedora
# yum --installroot /suse update -d 10

  
Actual results:
...
---> Package yast2-metapackage-handler.noarch 0:0.8.2-2.1 will be updated
---> Package yast2-metapackage-handler.noarch 0:0.8.11-2.1 will be an update
--> Running transaction check
---> Package libSDL_gfx13.i586 0:2.0.19-11.1 will be installed
Segmentation fault


Expected results:
full dependence resolution without errors.

additional comments:
disabling some repos or using dist-sync will also produce a similar crash.

Comment 1 Elmar Stellnberger 2012-01-05 18:00:06 UTC
Created attachment 550978 [details]
all yum.repos.d/*.repo-s cated in one

Comment 2 Elmar Stellnberger 2012-01-05 18:01:48 UTC
Created attachment 550979 [details]
screen output of yum in debug level 10 (highest)

Comment 3 Elmar Stellnberger 2012-01-05 18:03:10 UTC
Created attachment 550980 [details]
strace of yum until it crashes

Comment 4 Zdeněk Pavlas 2012-01-06 09:31:49 UTC
> looking for ('/sbin/ldconfig', None, (None, None, None)) as a requirement of libSDL_gfx13.i586 0:2.0.19-11.1 - u

This is the first file dep, maybe your /suse/var/rpm/Basenames DB is corrupt. Can you try to reproduce the following?

$ python
>>> from rpmUtils.transaction import initReadOnlyTransaction
>>> ts=initReadOnlyTransaction('/suse')
>>> [i.name for i in ts.dbMatch('basenames', '/sbin/ldconfig')]
['glibc']

Comment 5 Elmar Stellnberger 2012-01-06 11:33:39 UTC
>>> from rpmUtils.transaction import initReadOnlyTransaction
>>> ts=initReadOnlyTransaction('/suse')
>>> [i.name for i in ts.dbMatch('basenames', '/sbin/ldconfig')]
Segmentation Fault / Memory Access Error

  In deed this reproduces the segmentation fault.
An "rpm --rebuilddb" in the suse chroot could not fix the problem. However an "rpm --root=/suse --rebuilddb" did the thing:

>>> [i.name for i in ts.dbMatch('basenames', '/sbin/ldconfig')]
['glibc']

 I wonder on how SuSEs rpm-db format is incompatible with yum or rpmlib/Fedora and where to look for this issue. Basically I would have considered python-rpm/Fedora to be compatible with any rpm based distribution like RedHat, Mandrake and SUSE.

Comment 6 Panu Matilainen 2012-01-12 08:30:43 UTC
Suse used to carry a "tagged fileindex" patch in their rpm which speeds up certain file queries but breaks fingerprinting semantics and worse, makes file name database indexes incompatible with upstream rpm. The patch has been removed from OpenSuse rpm at some point "recently" (dunno about specific versions but at least current version in their "factory" repo no longer has it) so the good news is that with later OpenSuse versions this particular problem is gone.

In general, it's not safe to assume any rpm version will work correctly with a database created by another one unless --rebuilddb is done with the "currently used" rpm version first. The number and format of indexes can and does change between versions, so switching between rpm versions used to access a given database can result in index inconsistencies even without incompatible patches.

Comment 7 Elmar Stellnberger 2012-01-12 14:56:42 UTC
  What about fingerprinting semantics?
When will there be a support for sha256/512sums for individual files in the rpm header? I currently don`t really like online-rpm distros as the file checksum algorithm is too week for security purposes (md5) although the current header tags provided place for a better hashing algorithm (f.i. sha-512/sha-256).


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