Description of problem: make a new installation of xfce. ( Just for information, at first I install LXDE with the CD Dual-Arch) urpmi --no-suggest task-xfce-minimal During the installation, I have to choose between libgarcon0-0.1.10 and libgarcon1_0-0.2.0 I also have to choose between libthunar2_0-1.3.0 and libthunarx2_0-1.4.0 A not warned user will not know which to choose.
this seems not really a bug, but maybe there is a versionned (?) require possible can you add the output of the same command with --debug ?
I have no possibility of making one copy - paste in my test computer, but this is what I found: libgarcon-1.so.0 is needed by - xfce4-panel-4.10.0 (Without specifying a minimal version) - xfdesktop-4.10.0 (Without specifying a minimal version) - xfce4-appfinder-4.10.0 (Without specifying a minimal version) libthunarx-2.so.0 is needed by thunar-1.4.0 (Without specifying a minimal version) It is the simultaneous presence of the former and the new version that provokes the ambiguity
I'll check this out.
CC: (none) => jani.valimaaAssignee: bugsquad => jani.valimaa
(I'm CC'ing this also to tv). I'm not sure how we could fix this. New thunar and garcon libs in core/updates_testing obsoletes the old and wrongly named libs in core/release, but urpmi still provides them as a alternative as both, old and new lib, provides the needed lib. I guess this is a flaw in urpmi. Thierry, tell us what you think about this. However, it doesn't matter which ones are selected as they get upgraded to latest and correct versions when update is performed next time.
CC: (none) => thierry.vignaud
Maybe it is necessary to add a dependence of the type Requires: xfce4-panel >= 4.10
Thierry, any thoughts about this (comment 4)?
There's no flaw in urpmi. First why the hell did you fix package name in updates? There was no need. Secondly, our policy has always been to both obsoletes & provides the package to replace. B/c of that, one can install either one (of course, if one then run urpmi --auto-select, the newer one will upgrade the bogus one) So you can either not fix naming bug or fix it appropriately (by adding the missing Provides tags)
Source RPM: ? => thunar-1.4.0-1.mga2.src.rpm, garcon-0.2.0-1.mga2.src.rpm
what is the status of this bug ?
Blocks: (none) => 7369
(In reply to comment #7) > > So you can either not fix naming bug or fix it appropriately (by adding the > missing Provides tags) It doesn't change anything if I add Provides: %{_lib}garcon0 = %{version}-%{release} to garcon. Installing task-xfce still asks which one I want to install, new one (from my local testing repo) or old one with old name from Core. All this happens if I don't have garcon installed previously. Everything works just fine without added Provides if I have old one installed and I'm updating it.
Added some strict deps to pkgs needing those libs. It's not the best solution, but working one.
(In reply to comment #10) > Added some strict deps to pkgs needing those libs. It's not the best solution, > but working one. When I had made the essays of construction of packages, I had found a solution with the following line: Obsoletes: %mklibname garcon 0 It is necessary to make him(it) for every package which needs libgarcon-1.so.0
I have just made a netinstall. The success is total. All the packages for which I asked settle down automatically, without ambiguité.
Status: NEW => RESOLVEDResolution: (none) => FIXED