Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via or IRC
Bug 33545 - [req]: Range Operator for dependencies
Summary: [req]: Range Operator for dependencies
Status: RESOLVED DUPLICATE of bug 1343
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Portage team
: 27218 45939 (view as bug list)
Depends on:
Reported: 2003-11-15 02:35 UTC by Klaus Kusche
Modified: 2005-10-07 08:19 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Kusche 2003-11-15 02:35:02 UTC

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.
Comment 1 Marius Mauch (RETIRED) gentoo-dev 2003-11-15 19:20:11 UTC
AND-dependecies are not implemented (probably another 2.0.50 feature), guess you have to find another creative way to fix that Spanky ;)
Comment 2 SpanKY gentoo-dev 2003-11-15 21:00:12 UTC
since i've moved the SLOT-ed stuff to stable i can change it

*** This bug has been marked as a duplicate of 27218 ***
Comment 3 Klaus Kusche 2003-11-16 06:50:31 UTC
27218 only describes problem number2: Portage does not resolve combined < and >=
depends correctly.

Problem number 1 remains open: Portage forgot to update the slot!
Comment 4 TGL 2003-11-26 02:00:40 UTC
Problem #1 sounds very related to bug #4698
Comment 5 Klaus Kusche 2003-11-26 13:08:20 UTC
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!
Comment 6 Klaus Kusche 2003-12-24 01:52:31 UTC

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!
Comment 7 Nicholas Jones (RETIRED) gentoo-dev 2003-12-24 18:27:17 UTC
*** Bug 27218 has been marked as a duplicate of this bug. ***
Comment 8 Ioannis Aslanidis (RETIRED) gentoo-dev 2003-12-25 02:00:04 UTC
*** 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.
Comment 9 Klaus Kusche 2003-12-25 08:56:53 UTC
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)!
Comment 10 Ioannis Aslanidis (RETIRED) gentoo-dev 2003-12-27 03:23:50 UTC
For what I see we are being ignored and... the number of the bug is constantly changing... better not lose it ;)
Comment 11 Marius Mauch (RETIRED) gentoo-dev 2004-01-04 05:48:27 UTC
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.
Comment 12 Klaus Kusche 2004-01-04 06:05:43 UTC
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.
Comment 13 SpanKY gentoo-dev 2004-04-20 10:12:18 UTC
*** Bug 45939 has been marked as a duplicate of this bug. ***
Comment 14 Sven 2004-09-12 18:51:11 UTC
BTW: a very limited possibility to express a range is, to have a dependency like
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.
Comment 15 Dan Armak (RETIRED) gentoo-dev 2004-12-10 12:58:34 UTC
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.
Comment 16 Dan Armak (RETIRED) gentoo-dev 2005-07-02 05:48:39 UTC
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. 
Comment 17 Jason Stubbs (RETIRED) gentoo-dev 2005-10-07 08:19:06 UTC
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 ***