Bug 705851 - ppc64 is preferred to ppc when satisfying deps
Summary: ppc64 is preferred to ppc when satisfying deps
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum
Version: 5.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-18 17:27 UTC by Ales Zelinka
Modified: 2018-02-19 13:27 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-05 11:21:27 UTC
Target Upstream Version:


Attachments (Terms of Use)
depslove log from anaconda (387.96 KB, text/plain)
2011-05-25 14:13 UTC, Ales Kozumplik
no flags Details

Description Ales Zelinka 2011-05-18 17:27:07 UTC
Description of problem:
samba package requires samba-common. When anaconda tries to satisfy this dependency it picks samba-common.ppc64 over samba-common.ppc. This causes problems because the userspace is mostly ppc but libraries provided by samba-common.ppc64 obviously aren't.

When samba is installed by yum, both samba-common.ppc and samba-common.ppc64 are installed, creating sane multilib environment. 

Additional info:
beaker recipe with kickstart, list of packages installed and other logs: https://beaker.engineering.redhat.com/recipes/175722

Comment 1 Ales Kozumplik 2011-05-23 10:35:01 UTC
I talked to the reporter and he confirmed this is not a regression. 

Reassigning to yum, this looks like a problem with dependency resolution. We do set:

self.ts.ts.setColor(3)

if the architecture is ppc64 (yuminstall.py, line 675). We also set the transaction color to 3 for in /etc/rpm/macros on the installed system.

According to the logs this seems to be working for many packages, for instance search for "cracklib" in install.log. 

Yum maintainers, if there's something else that needs to be done from our side please describe it and assign back.

Comment 2 Ales Kozumplik 2011-05-23 10:38:55 UTC
For a possibly related rhel6 issue see bug 651091.

Comment 3 Ales Zelinka 2011-05-24 09:54:51 UTC
Both architectures were being installed in BZ#651091  which caused the problem. The issue here is that only one (wrong one) is installed.

Comment 4 James Antill 2011-05-24 17:49:06 UTC
Note that RHEL-6 is different anyway because we are _supposed_ to be ppc64 on RHEL-6.

Yum doesn't look at rpm color, we use the data in rpmUtils/arch.py ... which says to pick ppc (all other things being equal). So you shouldn't need to do anything.

Do we have a depsolving log?

Comment 5 Ales Kozumplik 2011-05-25 13:50:04 UTC
> Do we have a depsolving log?

I'm trying to get it but its tricky with rhel5 anaconda. Maybe tomorrow.

Comment 6 Ales Kozumplik 2011-05-25 14:13:05 UTC
Created attachment 500832 [details]
depslove log from anaconda

managed to get it. that's what yum's Depsolver logs.

Comment 7 James Antill 2011-05-25 19:17:08 UTC
Uh ... and there's no more information? I don't suppose it's easy to increase the debugging output?

The other thing is you could try doing "install samba-common", but changing multilib_policy to best before you run it ... and then we can get debug output from that, if it also chooses the .ppc64 version.

Comment 8 Ales Kozumplik 2011-05-26 08:51:25 UTC
(In reply to comment #7)
> Uh ... and there's no more information? I don't suppose it's easy to increase
> the debugging output?


This is what I used to max out the debug level in yum depsolving:

        file_verbose = logging.FileHandler("/tmp/yum.verbose.Depsolve.log")
        file_verbose.setLevel(yum.logginglevels.DEBUG_4)
        log_verb = logging.getLogger("yum.verbose.YumBase")
        log_verb.addHandler(file_verbose)
        log_verb.setLevel(yum.logginglevels.DEBUG_4)

What else can I try?
 
> The other thing is you could try doing "install samba-common", but changing
> multilib_policy to best before you run it ... and then we can get debug output
> from that, if it also chooses the .ppc64 version.

I don't think it would be easy to set everything up so one can run yum from the command line in Anaconda.

Comment 9 RHEL Program Management 2011-05-31 15:21:01 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 10 James Antill 2011-08-25 21:07:27 UTC
 What I meant was having anaconda install a base system, with a working yum and then have a reproducer like run "yum install blah" and watch it do the wrong thing.

 It's possible the bug is in yum, it's just hard for me to test that when the only reproducer is via. anaconda. Also it doesn't help that the behaviour has changed a lot.

Comment 13 RHEL Program Management 2012-06-12 01:23:14 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 14 Zdeněk Pavlas 2013-04-05 11:21:27 UTC
If this is really a bug in Yum depsolver, we'd need a Yum log with "Running compare_providers() for ..." messages to resolve this.  These are enabled at DEBUG_4 and up.

But since all other packages are resolved correctly, my guess is that there's just some conflict or packaging error in samba-common.ppc, so Yum uses ppc64 version instead.


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