rawhide vs. protected multilib versions

2012-04-05 Thread Jim Meyering 
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

Could part of the problem be that gcc requires a specific version of libgomp?
As seen in gcc.spec:

  Requires: libgomp = %{version}-%{release}

(i.e., =, not =), yet the x86_64 libgomp installed in rawhide was too
new to meet that criterion.  The = caused the matching i686 version to
be pulled in, and that triggered the protected multilib warning.

I was able to kludge around this by removing libgomp-4.7.0-1.fc17.x86_64
and all packages that depend on it (luckily only 2 or 3).

Then, installing gcc worked fine.

--

However, today when I try to install g++, something similar is
happening (symptom: yum wants to install i686 packages to meet
version constraints) but this time, my work-around is not an option.

root$ yum install --skip-broken gcc-c++ 
:
Loaded plugins: etckeeper, fastestmirror
Loading mirror speeds from cached hostfile
 * rawhide: fedora.mirrors.ovh.net
Resolving Dependencies
-- Running transaction check
--- Package gcc-c++.x86_64 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libstdc++-devel = 4.7.0-0.20.fc17 for package: 
gcc-c++-4.7.0-0.20.fc17.x86_64
-- Processing Dependency: libstdc++ = 4.7.0-0.20.fc17 for package: 
gcc-c++-4.7.0-0.20.fc17.x86_64
-- Running transaction check
--- Package libstdc++.i686 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libm.so.6(GLIBC_2.0) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libm.so.6 for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1(GLIBC_2.0) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1(GCC_4.2.0) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1(GCC_3.3) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1(GCC_3.0) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1 for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libc.so.6(GLIBC_2.4) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: ld-linux.so.2(GLIBC_2.3) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: ld-linux.so.2 for package: 
libstdc++-4.7.0-0.20.fc17.i686
--- Package libstdc++-devel.x86_64 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libstdc++(x86-64) = 4.7.0-0.20.fc17 for package: 
libstdc++-devel-4.7.0-0.20.fc17.x86_64
-- Running transaction check
--- Package glibc.i686 0:2.15-32.fc18 will be installed
-- Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: 
glibc-2.15-32.fc18.i686
-- Processing Dependency: libfreebl3.so for package: 
glibc-2.15-32.fc18.i686
--- Package libgcc.i686 0:4.7.0-0.20.fc17 will be installed
--- Package libstdc++-devel.x86_64 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libstdc++(x86-64) = 4.7.0-0.20.fc17 for package: 
libstdc++-devel-4.7.0-0.20.fc17.x86_64
-- Running transaction check
--- Package libstdc++-devel.x86_64 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libstdc++(x86-64) = 4.7.0-0.20.fc17 for package: 
libstdc++-devel-4.7.0-0.20.fc17.x86_64
--- Package nss-softokn-freebl.i686 0:3.13.4-0.1.fc18.beta1.1 will be 
installed

Packages skipped because of dependency problems:
gcc-c++-4.7.0-0.20.fc17.x86_64 from rawhide
glibc-2.15-32.fc18.i686 from rawhide
libgcc-4.7.0-0.20.fc17.i686 from rawhide
libstdc++-4.7.0-0.20.fc17.i686 from rawhide
libstdc++-devel-4.7.0-0.20.fc17.x86_64 from rawhide
nss-softokn-freebl-3.13.4-0.1.fc18.beta1.1.i686 from rawhide

Any suggestions?

Removing libstdc++ is not an option because it would remove far too
many things, including yum itself.

--
I guess this can be seen as my own damn fault ;-) for choosing
the netinst+minimal installation options rather than the more
mainstream install-from-liveCD approach...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread Colin Walters 
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.




From cad0bd517d205ca39850e0be8d835aab12499065 Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Thu, 5 Apr 2012 09:23:58 -0400
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}
 %if !%{build_ada}
 Obsoletes: gcc-gnat  %{version}-%{release}
 Obsoletes: libgnat  %{version}-%{release}
-- 
1.7.7.6

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread Jim Meyering 
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?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread John Reiser 
 -Requires: libgomp = %{version}-%{release}
 +Requires: libgomp%{?_isa} = %{version}-%{release}

 Can anyone explain why appending that %{?_isa} notation is necessary?

Because rpm did not adapt appropriately to multilib.  Instead
current rpm requires that each packager do the work in each package.

 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?

All that is true, but has not been implemented.  There should be
some accommodation when .noarch packages actually are present,
but by default an architecture-dependent package should propagate
its _isa to its dependencies.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread Adam Jackson 
On Thu, 2012-04-05 at 16:13 +0200, Jim Meyering wrote:

 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?

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.

- ajax


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread 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 -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread Ralf Corsepius 

On 04/05/2012 05:23 PM, Panu Matilainen wrote:


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


Really? I think %{_isa} is harmful, because it breaks arch - noarch 
updates, and tries to project depsolver bugs into rpms.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread Kalev Lember 
On 04/05/2012 06:23 PM, Panu Matilainen wrote:
 On 04/05/2012 05:13 PM, Jim Meyering wrote:
 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.

It's very understandable why rpm allows this. But yum's depsolver on the
other hand should be tailored to the way Fedora repos are set up and, in
my opinion, not install compat arch packages when it can solve the deps
with the primary arch packages.

-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread James Antill 
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.
[...]
 Packages skipped because of dependency problems:
 gcc-c++-4.7.0-0.20.fc17.x86_64 from rawhide
 glibc-2.15-32.fc18.i686 from rawhide
 libgcc-4.7.0-0.20.fc17.i686 from rawhide
 libstdc++-4.7.0-0.20.fc17.i686 from rawhide
 libstdc++-devel-4.7.0-0.20.fc17.x86_64 from rawhide
 nss-softokn-freebl-3.13.4-0.1.fc18.beta1.1.i686 from rawhide
 
 Any suggestions?

 You can probably work around the repo. problems by using something
like:

yum shell
downgrade libstdc++
install gcc-c++
run

...or even the full blown:

yum disto-sync full
yum install gcc-c++

...or even enable F17 again, and get the newer versions.

 Removing libstdc++ is not an option because it would remove far too
 many things, including yum itself.
 
 --
 I guess this can be seen as my own damn fault ;-) for choosing
 the netinst+minimal installation options rather than the more
 mainstream install-from-liveCD approach...

 Not really, I think the problem is that you installed with F17 and are
now on rawhide, but rawhide has older versions of a bunch of packages.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread Jim Meyering 
James Antill 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.
 [...]
 Packages skipped because of dependency problems:
 gcc-c++-4.7.0-0.20.fc17.x86_64 from rawhide
 glibc-2.15-32.fc18.i686 from rawhide
 libgcc-4.7.0-0.20.fc17.i686 from rawhide
 libstdc++-4.7.0-0.20.fc17.i686 from rawhide
 libstdc++-devel-4.7.0-0.20.fc17.x86_64 from rawhide
 nss-softokn-freebl-3.13.4-0.1.fc18.beta1.1.i686 from rawhide

 Any suggestions?

  You can probably work around the repo. problems by using something
 like:

 yum shell
 downgrade libstdc++
 install gcc-c++
 run

Perfect!
That did just what I wanted.  Thank you!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread James Antill 
On Thu, 2012-04-05 at 10:52 -0400, Adam Jackson wrote:
 On Thu, 2012-04-05 at 16:13 +0200, Jim Meyering wrote:
 
  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?
 
 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.

 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.)

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread 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


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread Kevin Kofler 
Kalev Lember wrote:
 It's very understandable why rpm allows this. But yum's depsolver on the
 other hand should be tailored to the way Fedora repos are set up and, in
 my opinion, not install compat arch packages when it can solve the deps
 with the primary arch packages.

The point is that it can't here.

You'd just get a different error message if it didn't try using the multilib 
version that way.

Rawhide will always have broken dependencies. Releases and branched 
prerelease trees may soon get their dependencies enforced by Bodhi through 
AutoQA, but due to how Rawhide works, that's not possible in Rawhide.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

2012-04-05 Thread Kevin Kofler 
James Antill wrote:
 Not really, I think the problem is that you installed with F17 and are
 now on rawhide, but rawhide has older versions of a bunch of packages.

… which is a blatant violation of upgrade path rules and should be filed as 
urgent bugs against the affected packages. We have the Rawhide first rule 
for a reason.

Due to how Rawhide works, there's no way to automatically enforce this on 
the Rawhide end, but AutoQA might enforce this on the Branched end at some 
point, which should catch most cases.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel