rawhide vs. protected multilib versions

[Panu Matilainen]

On 04/05/2012 05:13 PM, Jim Meyering wrote:
> Colin Walters wrote:
>> On Thu, 2012-04-05 at 14:40 +0200, Jim Meyering wrote:
>>> I installed x86_64 F17 from the netinst.iso yesterday, selected
>>> a minimal install, and immediately upgraded to rawhide.
>>> Worked like a charm.
>>>
>>> However, now that I try to use the resulting system and need a
>>> few packages, I find that installing them is um, ... challenging.
>>>
>>> For example, yesterday I couldn't even install gcc due to this:
>>>
>>>      Error: Protected multilib versions: \
>>>        libgomp-4.7.0-0.20.fc17.i686 != \
>>>        libgomp-4.7.0-1.fc17.x86_64
>>
>> I believe it needs a patch like this to the spec:
>>
>> There may be other subpackages that need patching here too; I didn't
>> have a chance to test the patch yet.  Tried running it by Jakub but
>> he was away.
> ...
>> Subject: [PATCH] Use isa for libgomp
>>
>> Fixes multilib versioning issues.
>> ---
>>   gcc.spec |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/gcc.spec b/gcc.spec
>> index fc7e476..1928326 100644
>> --- a/gcc.spec
>> +++ b/gcc.spec
>> @@ -146,7 +146,7 @@ Requires: glibc-devel>= 2.2.90-12
>>   Requires: glibc>= 2.3.90-35
>>   %endif
>>   Requires: libgcc>= %{version}-%{release}
>> -Requires: libgomp = %{version}-%{release}
>> +Requires: libgomp%{?_isa} = %{version}-%{release}
>
> Thanks.
> Can anyone explain why appending that %{?_isa} notation is necessary?
> Shouldn't dependency-tracking tools already know that libgomp is
> an arch-dependent binary, and that of course if gcc.x86_64 is depending
> on libgomp, it really wants the x86_64 version and not the i686 one,
> at least by default?

They know no such thing. All they see is a string that could be just as 
well "foo" with a version attached, and anything at all (could be 
different arch or even entirely different package) that provides "foo" 
with a suitable version is a perfectly legal match for it.

Soname dependencies do kinda encode the arch (the (64bit) trailing 
marker) but that doesn't help when the soname doesn't change:
Say you have x86_64 and i686 variants of libgomp-4.6.3-2.fc16 installed, 
providing libgomp.so.1()(64bit) and libgomp.so.1() respectively. Now in 
comes a gcc update that requires libgomp = 4.6.3-3.fc16, but mirrors are 
out of sync so that yum only sees libgomp-4.6.3-3.fc16.i686. When 
%{_isa} is not part of the dependency name, the i686 satisfies the 
dependency. And since the soname of libgomp did not change, gcc soname 
dependencies on libgomp are still matched even if just the i686 part was 
updated, although the end result "obviously" is not what you want. 
Complaining about "protected multilib versions" thing is yum's way to 
guard against that (and other similar things).

The point with %{_isa} in dependency names is that it eliminates the 
problematic ambiguity.

	- Panu -