rawhide vs. protected multilib versions
james at fedoraproject.org
Thu Apr 5 20:49:56 UTC 2012
On Thu, 2012-04-05 at 13:44 -0400, Adam Jackson wrote:
> 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...
AIUI it's not possible for Fedora to be this broken (although other
people's repos. are :).
AIUI what is happening is:
bar-1-1.x86_64 => Requires: foo=2-1
...here yum policy dictates that we never remove/downgrade
automatically, so when the user does "yum install bar" the only answer
is some form of "I can't" but with multilib. the actual message is
basically "I tried to do it by installing foo-2-1.i686, but that gives
multilib. version problems with the installed foo-2-3.x86_64" (and I
realize the actual message isn't even this clear -- patches welcome).
More information about the devel