Bug 230194
Summary: | broken deps in release updates / multi-lib fun | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michael Schwendt <bugs.michael> |
Component: | distribution | Assignee: | David Cantrell <dcantrell> |
Status: | CLOSED WONTFIX | QA Contact: | Bill Nottingham <notting> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6 | CC: | dcantrell, lmacken, rvokal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-11-15 16:43:47 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: |
Description
Michael Schwendt
2007-02-27 13:03:09 UTC
how are you generating this list of broken deps? I thought the update tool was doing a repoclosure to make sure we didn't have broken things.... Luke? They are found and ignored when running extras-repoclosure. The full logs are in /srv/extras-push/work/extras-repoclosure/rc-fe*.txt on buildsys.fedoraproject.org -- I only noticed them when I started doing experiments with running extras-repoclosure on temporary repos built from the needsign queue. I did a "full" install of Core 6 for x86_64, then just did a yum update with updates and updates-testing enabled. There were no conflicts or unresolved deps listed. Could repoclosure be finding false negatives? Can you prove that for any of the reports? As a specific question, what provides libpython2.4.so.1.0 and yumibdns.so.22 on that test machine? Notice that both are 32-bit libraries which are not available in form of i386 packages in the x86_64 repositories. s/yumibdns.so.22/libdns.so.22/ I'm pretty sure we blacklisted some of those packages from being multilib. I've already re-installed the box in question, so I don't have access to it again, guess I'll have to do another install. Why spend time on a test-install? These broken deps are easy to verify, e.g. bind-devel.i386 requires i386 sonames from bind.i386, but bind.i386 is not available in the x86_64 repo. Most likely you installed only x86_64 devel packages. Same game for the other i386 -devel packages in the broken deps list. And kdeedu.i386 requires i386 Python, which is not available either. No, I did a full install and didn't strip the x86_64. By default I get all i386 that is available for the packages I selected. I'll verify again, but i think we "fixed" the glitch with many of these by fixing up the packaging in further update releases. In rawhide? - Yes. In FC6 Release Updates? - No. FC6 is what I installed. Well, if you can tell me what packages in the x86_64 repositories provide the 32-bit SONAMEs, which repoclosure lists as missing, we could close this ticket quickly. I cannot assist further than pointing out that the packages are missing in base, updates-released and updates-testing. Indeed. I can confirm the problem here. Once you have an x86_64 box you need to issue: yum install kdeedu.i386 Just doing yum update will only update what was installed on the machine. I'm guessing anaconda didn't install the i386 version of those packages for some reason. perhaps the packages are in the update repo but not in Core final or anaconda handles broken-deps differently than yum. Ah, yes kdeedu was NOT multilib in stock FC6, an update must have been pushed that accidentally made it multilib. Really these problems are a bit hard to track all in one bug. Michael, can you file new bugs for each of these packages, against the package and cc me on them? We'll need to tackle these one at a time anyway, and that's going to be too noisy for just one bug. I'm closing this now confusing bug. Individual bugs need to be filed for specific multilib cases. |