Bug 705851

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.

For a possibly related rhel6 issue see bug 651091.

Both architectures were being installed in BZ#651091  which caused the problem. The issue here is that only one (wrong one) is installed.

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?

> Do we have a depsolving log?

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

Created attachment 500832 [details]
depslove log from anaconda

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

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.

(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.

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.

 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.

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.

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.