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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
