[opensuse-factory] 13.1 conflict
Hi, I'm getting this when I try to install gcc: ox:~ # zypper in gcc Loading repository data... Warning: Repository 'openSUSE-13.1-Update-Non-Oss' appears to outdated. Consider using a different mirror or server. Reading installed packages... Resolving package dependencies... Problem: gcc-4.8-2.1.2.x86_64 requires gcc48, but this requirement cannot be provided uninstallable providers: gcc48-4.8.1_20130909-3.2.1.i586[openSUSE-13.1-1.19] gcc48-4.8.1_20130909-3.2.1.x86_64[openSUSE-13.1-1.19] Solution 1: deinstallation of libgcc43-4.3.4_20091019-19.1.3.x86_64 Solution 2: do not install gcc-4.8-2.1.2.x86_64 Solution 3: do not install gcc-4.8-2.1.2.x86_64 Solution 4: break gcc-4.8-2.1.2.x86_64 by ignoring some of its dependencies zypper is configured for http://download.opensuse.org/distribution/13.1/repo/oss/ Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 11.10.2013 16:57, schrieb Wolfgang Rosenauer:
Hi,
I'm getting this when I try to install gcc:
ox:~ # zypper in gcc Loading repository data... Warning: Repository 'openSUSE-13.1-Update-Non-Oss' appears to outdated. Consider using a different mirror or server. Reading installed packages... Resolving package dependencies...
Problem: gcc-4.8-2.1.2.x86_64 requires gcc48, but this requirement cannot be provided uninstallable providers: gcc48-4.8.1_20130909-3.2.1.i586[openSUSE-13.1-1.19] gcc48-4.8.1_20130909-3.2.1.x86_64[openSUSE-13.1-1.19] Solution 1: deinstallation of libgcc43-4.3.4_20091019-19.1.3.x86_64 Solution 2: do not install gcc-4.8-2.1.2.x86_64 Solution 3: do not install gcc-4.8-2.1.2.x86_64 Solution 4: break gcc-4.8-2.1.2.x86_64 by ignoring some of its dependencies
Solution 1 :-) I'm wondering why libgcc43 was installed at all before; and why it is included in 13.1: if you want to install it, you need to uninstall lots of compiler and devel packages... -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 11.10.2013 17:25, schrieb Stefan Seyfried:
Am 11.10.2013 16:57, schrieb Wolfgang Rosenauer:
Hi,
I'm getting this when I try to install gcc:
ox:~ # zypper in gcc Loading repository data... Warning: Repository 'openSUSE-13.1-Update-Non-Oss' appears to outdated. Consider using a different mirror or server. Reading installed packages... Resolving package dependencies...
Problem: gcc-4.8-2.1.2.x86_64 requires gcc48, but this requirement cannot be provided uninstallable providers: gcc48-4.8.1_20130909-3.2.1.i586[openSUSE-13.1-1.19] gcc48-4.8.1_20130909-3.2.1.x86_64[openSUSE-13.1-1.19] Solution 1: deinstallation of libgcc43-4.3.4_20091019-19.1.3.x86_64 Solution 2: do not install gcc-4.8-2.1.2.x86_64 Solution 3: do not install gcc-4.8-2.1.2.x86_64 Solution 4: break gcc-4.8-2.1.2.x86_64 by ignoring some of its dependencies
Solution 1 :-)
Thanks, I was afraid of doing it but it seems to work. Also removed libgcc43-32bit.
I'm wondering why libgcc43 was installed at all before; and why it is included in 13.1: if you want to install it, you need to uninstall lots of compiler and devel packages...
I don't know why it is in 13.1 but it is. And why it was installed I also don't know. I installed the system from 13.1b1 Gnome LiveCD IIRC in the first place. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-10-11 18:12, Wolfgang Rosenauer wrote:
I'm wondering why libgcc43 was installed at all before; and why it is included in 13.1: if you want to install it, you need to uninstall lots of compiler and devel packages...
I don't know why it is in 13.1 but it is.
talk to rguenther (maintainer of gcc43)? Indeed, I too feel it should not be in 13.1, because it is obsoleted by libgcc1.
And why it was installed I also don't know.
Because zypper has a choice; both libgcc43 and libgcc1 provide libgcc_s.so.1. Which is also why libgcc43 really should not be shipped, because it's redundant. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2013-10-12 00:19, Jan Engelhardt wrote:
On Friday 2013-10-11 18:12, Wolfgang Rosenauer wrote:
I'm wondering why libgcc43 was installed at all before; and why it is included in 13.1: if you want to install it, you need to uninstall lots of compiler and devel packages...
I don't know why it is in 13.1 but it is. And why it was installed I also don't know.
Because zypper has a choice; both libgcc43 and libgcc1[sic] provide libgcc_s.so.1. Which is also why libgcc43 really should not be shipped, because it's redundant.
Not only that, there also turns out to be a third choice for installation: libgcc_s1-gcc47-4.7.x (besides libgcc43-4.3.x and libgcc_s1-4.8.x). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 12 Oct 2013, Jan Engelhardt wrote:
On Saturday 2013-10-12 00:19, Jan Engelhardt wrote:
On Friday 2013-10-11 18:12, Wolfgang Rosenauer wrote:
I'm wondering why libgcc43 was installed at all before; and why it is included in 13.1: if you want to install it, you need to uninstall lots of compiler and devel packages...
I don't know why it is in 13.1 but it is. And why it was installed I also don't know.
Because zypper has a choice; both libgcc43 and libgcc1[sic] provide libgcc_s.so.1. Which is also why libgcc43 really should not be shipped, because it's redundant.
Not only that, there also turns out to be a third choice for installation: libgcc_s1-gcc47-4.7.x (besides libgcc43-4.3.x and libgcc_s1-4.8.x).
The fun of media building (of which package maintainers have no
control over - so the one to blame is Coolo). Indeed only
libgcc_s1 and libgcc_s1-{32,64}bit should be on the media.
RC1 doesn't seem to be in our SLP tree yet, but Beta1
has only those. I hope we didn't regress here from Beta1 to RC1 ;)
Did you perform an update by chance and not a fresh install?
Richard.
--
Richard Biener
On 14.10.2013 10:49, Richard Biener wrote:
On Sat, 12 Oct 2013, Jan Engelhardt wrote:
On Saturday 2013-10-12 00:19, Jan Engelhardt wrote:
On Friday 2013-10-11 18:12, Wolfgang Rosenauer wrote:
I'm wondering why libgcc43 was installed at all before; and why it is included in 13.1: if you want to install it, you need to uninstall lots of compiler and devel packages...
I don't know why it is in 13.1 but it is. And why it was installed I also don't know.
Because zypper has a choice; both libgcc43 and libgcc1[sic] provide libgcc_s.so.1. Which is also why libgcc43 really should not be shipped, because it's redundant.
Not only that, there also turns out to be a third choice for installation: libgcc_s1-gcc47-4.7.x (besides libgcc43-4.3.x and libgcc_s1-4.8.x).
The fun of media building (of which package maintainers have no control over - so the one to blame is Coolo). Indeed only libgcc_s1 and libgcc_s1-{32,64}bit should be on the media. RC1 doesn't seem to be in our SLP tree yet, but Beta1 has only those. I hope we didn't regress here from Beta1 to RC1 ;)
Did you perform an update by chance and not a fresh install?
Can you please create a complete list of binary packages of gcc43 and gcc47 that should not end be on any media? Greetings, Stephan -- A gentleman never strikes a lady with his hat on. -- Fred Allen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2013-10-14 10:49, Richard Biener wrote:
Not only that, there also turns out to be a third choice for installation: libgcc_s1-gcc47-4.7.x (besides libgcc43-4.3.x and libgcc_s1-4.8.x).
The fun of media building (of which package maintainers have no control over - so the one to blame is Coolo). Indeed only libgcc_s1 and libgcc_s1-{32,64}bit should be on the media.
Well, package maintainers certainly have some control ;-) In fact, devel:gcc has the same issue that there are multiple libgcc binrpms that provide the same file. Fix it there, and it will autofix all other repos too. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 14 Oct 2013, Jan Engelhardt wrote:
On Monday 2013-10-14 10:49, Richard Biener wrote:
Not only that, there also turns out to be a third choice for installation: libgcc_s1-gcc47-4.7.x (besides libgcc43-4.3.x and libgcc_s1-4.8.x).
The fun of media building (of which package maintainers have no control over - so the one to blame is Coolo). Indeed only libgcc_s1 and libgcc_s1-{32,64}bit should be on the media.
Well, package maintainers certainly have some control ;-) In fact, devel:gcc has the same issue that there are multiple libgcc binrpms that provide the same file. Fix it there, and it will autofix all other repos too.
I have fixed it for gcc47 and gcc48 and will not touch legacy GCC.
IMHO this should have been fixed a level higher as requested in
some Fate entry, but people chose to ignore that and instead
suggest the setup we have now (%define product_libs_gcc_ver in
your project config, yeah, and I didn't bother to do that properly
for devel:gcc yet - tons of %if "%_repository" stuff required).
Oh, and that "solution" doesn't "solve" the multiple packages
with the same binaries in them issue but only the issue that
we cannot follow the shared library policy (same binary package
names from multiple source packages).
Richard.
--
Richard Biener
On Monday 2013-10-14 16:17, Richard Biener wrote:
Well, package maintainers certainly have some control ;-) In fact, devel:gcc has the same issue that there are multiple libgcc binrpms that provide the same file. Fix it there, and it will autofix all other repos too.
I have fixed it for gcc47 and gcc48 and will not touch legacy GCC. IMHO this should have been fixed a level higher as requested in some Fate entry, but people chose to ignore that and instead suggest the setup we have now (%define product_libs_gcc_ver in your project config, yeah, and I didn't bother to do that properly for devel:gcc yet - tons of %if "%_repository" stuff required). Oh, and that "solution" doesn't "solve" the multiple packages with the same binaries in them issue but only the issue that we cannot follow the shared library policy (same binary package names from multiple source packages).
Is removing {the production of libgcc33} in gcc33.spec not sufficient? As in, killing the %files part and doing a rm -f in %install instead. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 14 Oct 2013, Jan Engelhardt wrote:
On Monday 2013-10-14 16:17, Richard Biener wrote:
Well, package maintainers certainly have some control ;-) In fact, devel:gcc has the same issue that there are multiple libgcc binrpms that provide the same file. Fix it there, and it will autofix all other repos too.
I have fixed it for gcc47 and gcc48 and will not touch legacy GCC. IMHO this should have been fixed a level higher as requested in some Fate entry, but people chose to ignore that and instead suggest the setup we have now (%define product_libs_gcc_ver in your project config, yeah, and I didn't bother to do that properly for devel:gcc yet - tons of %if "%_repository" stuff required). Oh, and that "solution" doesn't "solve" the multiple packages with the same binaries in them issue but only the issue that we cannot follow the shared library policy (same binary package names from multiple source packages).
Is removing {the production of libgcc33} in gcc33.spec not sufficient? As in, killing the %files part and doing a rm -f in %install instead.
Sure, but that's not maintainable (you need it for SLE9). And how do you for example handle the introduction of a newer GCC in devel:gcc for people to install? Like if I'm on 12.1 (I am) and want to install gcc48 I actually _need_ the libgcc_s1 from gcc48, so I cannot remove it in the openSUSE_12.1 repo where gcc46 is the default (and thus its libgcc prevails). Believe me, we have thought about this a lot ;) Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2013-10-14 16:26, Richard Biener wrote:
Sure, but that's not maintainable (you need it for SLE9). And how do you for example handle the introduction of a newer GCC in devel:gcc for people to install? Like if I'm on 12.1 (I am) and want to install gcc48 I actually _need_ the libgcc_s1 from gcc48, so I cannot remove it in the openSUSE_12.1 repo where gcc46 is the default (and thus its libgcc prevails).
In the openSUSE_12.1 repository, you would run gcc46 with libgcc48 (removing libgcc46). Not a "perfect" state, but it should be a usable one, should it not? In all this, it looks to me like zypper should prefer the highest version when multiple packages satisfy a dependency (in terms of SAT: all dependencies). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt
On Monday 2013-10-14 16:26, Richard Biener wrote:
Sure, but that's not maintainable (you need it for SLE9). And how do you for example handle the introduction of a newer GCC in devel:gcc for people to install? Like if I'm on 12.1 (I am) and want to install gcc48 I actually _need_ the libgcc_s1 from gcc48, so I cannot remove it in the openSUSE_12.1 repo where gcc46 is the default (and thus its libgcc prevails).
In the openSUSE_12.1 repository, you would run gcc46 with libgcc48 (removing libgcc46). Not a "perfect" state, but it should be a usable one, should it not?
No, because at the time 12.1 chooses gcc 4.6 as compiler gcc 4.8 does not yet exist.
In all this, it looks to me like zypper should prefer the highest version when multiple packages satisfy a dependency (in terms of SAT: all dependencies).
It can choose any candidate that satisfies all dependencies. IIRC for the very old gcc 4.3 packages the requires and or provides are not exactly correct. The easiest solution is to avoid dragging this old compilers onto the media. Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 14.10.2013 10:49, schrieb Richard Biener:
On Sat, 12 Oct 2013, Jan Engelhardt wrote:
On Saturday 2013-10-12 00:19, Jan Engelhardt wrote:
On Friday 2013-10-11 18:12, Wolfgang Rosenauer wrote:
I'm wondering why libgcc43 was installed at all before; and why it is included in 13.1: if you want to install it, you need to uninstall lots of compiler and devel packages...
I don't know why it is in 13.1 but it is. And why it was installed I also don't know.
Because zypper has a choice; both libgcc43 and libgcc1[sic] provide libgcc_s.so.1. Which is also why libgcc43 really should not be shipped, because it's redundant.
Not only that, there also turns out to be a third choice for installation: libgcc_s1-gcc47-4.7.x (besides libgcc43-4.3.x and libgcc_s1-4.8.x).
The fun of media building (of which package maintainers have no control over - so the one to blame is Coolo). Indeed only libgcc_s1 and libgcc_s1-{32,64}bit should be on the media. RC1 doesn't seem to be in our SLP tree yet, but Beta1 has only those. I hope we didn't regress here from Beta1 to RC1 ;)
Did you perform an update by chance and not a fresh install?
If that question is to me ;-) No, this was for sure a fresh install with beta1 (AFAICR from Gnome LiveCD). Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Jan Engelhardt -
Richard Biener -
Stefan Seyfried -
Stephan Kulow -
Wolfgang Rosenauer