portage-2.0.49-r15: Installed are: libnet-1.0.2a-r2, libnet-1.1.0-r3, arping-1.06 but *not* libnet-1.0.2a-r3 The arping-1.06-r1 ebuild depends on <libnet-1.1 and >=libnet-1.0.2a-r3 Problem number 1: "emerge --pretend --deep world" does *not* show libnet-1.0.2a-r3! It should, because libnet-1.0 has its own slot (separate from 1.1), and libnet-1.0.2a-r3 is marked stable. Problem number 2: emerge happily starts to install arping-1.06-r1 (and fails) without installing libnet-1.0.2a-r3 first. It ignores the depends in arping's ebuild, which are not satisfied on my system.
AND-dependecies are not implemented (probably another 2.0.50 feature), guess you have to find another creative way to fix that Spanky ;)
since i've moved the SLOT-ed stuff to stable i can change it *** This bug has been marked as a duplicate of 27218 ***
27218 only describes problem number2: Portage does not resolve combined < and >= depends correctly. Problem number 1 remains open: Portage forgot to update the slot!
Problem #1 sounds very related to bug #4698
Yes, but the basic problem of bug 4698 was solved one year ago by adding the --deep option, only marginal problems are left in 4698. Comment number 13 in 4698 shows that "emerge --deep world" did the right thing for gconf in July (it listed the update available for the old slot). Why doesn't the same thing work for me now? It didn't show the upgrade available for an old slot of libnet!
??? Please undo the last changes to this bug: What |Removed |Added ---------------------------------------------------------------------------- Component|Portage |Enhancement/Feature Requests Product|Gentoo Linux |Portage Development Summary|Version and dependency mess |[req]: Range Operator for |in portage |dependencies Version|1.2 |unspecified The "range operator for dependencies" part of this bug has been moved to bug 27218. The problem which remains in this bug is why the --deep option did not work as specified and why portage "forgot" to update the slot. In my opinion, this is not related to ranges and dependencies at all!
*** Bug 27218 has been marked as a duplicate of this bug. ***
*** Bug 27218 has been marked as a duplicate of this bug. *** What have you done??? You put bug 27965 as duplicate of 33545?????? It must be 33545 marked as duplicate of 27965 as 27965 was reported BEFORE 33545.
Is it that difficult??? Initially, this bug described two different, unrelated problems: 1. "range dependencies" don't work. 2. "emerge --deep" doesn't work. Problem 1 is a duplicate of 27218 and should be treated there, not here. Hence, please reopen 27218!!! Problem 2 is a different problem (not related to 27218 at all) and should be treated here. Hence, please change the component, the summery, the version, ... back to what it was before 2003-12-24 to properly reflect the problem this bug report deals with (see my comment at that day)!
For what I see we are being ignored and... the number of the bug is constantly changing... better not lose it ;)
check the SLOT file for all libnet versions in /var/db/pkg/net-libs/libnet*, maybe some of them are still unslotted (have SLOT="0") as the re-slot command wasn't implemented back then.
libnet-1.0.2a-r3 and libnet-1.1.0-r3 definitely have the correct slot set. However, at that time, I had libnet-1.0.2a-r2 installed. As I can't find the ebuild file of it any more (it has been deleted from portage and also from my installed packages database), I've no idea if SLOT was set in -r2 or not. libnet-1.0.2a-r1 (the version initially installed on my system according to /var/db) definitely has SLOT="0". However, according to the ChangeLog, SLOT was already introduced with -r2.
*** Bug 45939 has been marked as a duplicate of this bug. ***
BTW: a very limited possibility to express a range is, to have a dependency like =libnet-1.0* which is, what i'd have expected as a first fix for the arping and tcptraceroute ebuilds. Still, portage should be abled to internally handle more genric ranges.
I add my vote for this functionality to be added. My use case: each minor version of kdelibs (3.0.x, 3.3.x, 4.0.x...) has a separate SLOT. I need for an ebuild to depend on eg a 3.3 kdelibs newer than 3.3.1. >=3.3.1 will accept 3.4 or 4.0 across SLOTs. What I'm probably going to do is accept all versions that might one day be added to the slot, like so: "|| ( ~3.3.10 ~3.3.9 ... ~3.3.1 )" - but that's an ugly kludge.
Belated update: I talked with the portage people after posting my previous comment and they told me this functionality wouldn't be available before portage 2.1. Well, is it in portage-cvs now? If not can it be added please? :-) My own implementation in kde-functions.eclass, for the split ebuilds, involves a function deprange() called inside $DEPEND. Very ugly and I hope portage allows me to throw it away, the sooner the better.
There's a number of complaints on this bug, but they are covered by bug #1343, bug #4698 and bug #16365. *** This bug has been marked as a duplicate of 1343 ***