rawhide vs. protected multilib versions

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120405/299d7784/attachment.sig>