https://bugzilla.novell.com/show_bug.cgi?id=668060 https://bugzilla.novell.com/show_bug.cgi?id=668060#c1 Richard Guenther changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |coolo@novell.com, | |mls@novell.com --- Comment #1 from Richard Guenther 2011-01-31 10:23:19 UTC --- 1) libgomp43 should not be on the media (coolo CCed) 2) libgomp45 and libgomp43 conflict now, which is the solution I settled with after a discussion with mls 3) on product upgrade (11.2 to 11.4) the above conflict resolutions may appear (there is no way to specify an upgrade path without explicitly listing all _package names_) - a solver solution hint can be easily provided by the opensuse-release package (or however that is done now) thus, it all works as designed apart from 1) and eventually 3) missing. The conflict mechanism works as follows (given that all manual dependencies follow the shlib policy in naming but due to autobuild/obs limitations the actual package names have to differ (*sigh*)): %package -n libgomp@base_ver@ License: GPL v3 or later Summary: The GNU compiler collection OpenMP runtime library Group: System/Base Provides: libgomp1@variant@ = %{version}-%{release} Conflicts: libgomp1@variant@ < %{version}-%{release} Autoreqprov: on substitute 43 and 45 for @base_ver@ for your case. The gcc@base_ver@ packages depend on libgomp1 >= %{version}-%{release}. Any tags like Obsoletes: libgomp1@variant@ < %{version}-%{release} do not work as the solver does not look at this indirect information. conflicts is the only tag that works this way. Due to the ordering the solver will always select the most recent variant (but still will prompt the user). There is no solution that works with rpm (of course solver hacks are always possible). Previously we had Provides: libgomp1@variant@ = %{version}-%{release} Obsoletes: libgomp1@variant@ < %{version}-%{release} # make rpm happy Obsoletes: libgomp42@variant@ libgomp43@variant@ libgomp44@variant@ # make zypp happy Provides: libgomp42@variant@ libgomp43@variant@ libgomp44@variant@ but that does not prevent parallel install of two libgomp versions (which was reported as a bug multiple times). That solution also does not scale or is anywhere near something one wants to maintain. Now, it would be nicest if the Obsoletes: libgomp1... variant would just work but according to mls it does not by design. mls suggested some Conflicts/Provides: package$MAGIC(fooblah) stuff, but that's of course suse (solver) specific again. Thus, just live with it, work around the update issue in suse-release. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=668060 https://bugzilla.novell.com/show_bug.cgi?id=668060#c3 --- Comment #3 from Richard Guenther 2011-01-31 11:46:08 UTC --- None of the packages are for the media. libada43 and libgcj43 might be needed by old programs (shlib versions changed for them, so they'd be -compat in the old sense). The gcc43 package is really for SLE maintainance now (similar to the gcc41 and gcc33 ones). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.