On Thu, 2012-04-05 at 12:10 -0400, James Antill wrote:
On Thu, 2012-04-05 at 10:52 -0400, Adam Jackson wrote:
> So, at least on my F17 machine, gcc looks like this:
>
> black-lotus:~% rpm -q --requires gcc | grep gomp
> libgomp = 4.7.0-1.fc17
> libgomp.so.1()(64bit)
>
> To me that looks like enough information that yum should be able to
> figure it out without explicit handholding. I'd really call this a yum
> bug.
These are two different requires, one isn't arch. specific and has a
version ... the other is arch. specific but doesn't have a version.
I guess what you are saying is that it should be "easy" for yum to see
that both requires are provided by one package name, but the arch.
specific variant limits that ... and, yeh, maybe we could do something
like that and give a different error message in this case but it's far
from obvious how expensive that would be.
I guess I was assuming that the repo would have both the 32 and 64
versions in it, in which case you'd have both libgomp.i686 and
libgomp.x86_64 providing that E-V-R with A implicitly wildcarded, but
only the one of them providing the right soname-derived string, and so
then you'd not even try the i686 version. But...
This kind of thing has generally not been a high priority, because
the
repos. are obviously broken ... and anything we do on the yum side will
still have the repos. broken and the install not possible (without doing
manual downgrades etc.)
If the repos are broken like this, then I agree the issue is not in yum.
- ajax