Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 4315 - [Future EAPI] add support for version ranges in DEPEND
Summary: [Future EAPI] add support for version ranges in DEPEND
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: x86 Linux
: High enhancement
Assignee: Package Manager Specification
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi 598525
  Show dependency tree
 
Reported: 2002-06-29 04:17 UTC by Spider (RETIRED)
Modified: 2021-09-25 12:31 UTC (History)
20 users (show)

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


Attachments
patch for portage.py/emerge (bugs.4229.patch,1.29 KB, patch)
2003-08-04 10:46 UTC, Masatomo Nakano (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Spider (RETIRED) gentoo-dev 2002-06-29 04:17:40 UTC
with a depend on: 
    ( >=gnome-base/libglade-0.17
      <gnome-base/libglade-0.99.0 )


Darkmere gnome-panel # emerge -p gnome-panel-1.4.1.ebuild

These are the packages that I would merge, in order.

Calculating dependencies ...done!
[ebuild  N   ] gnome-base/libglade-0.17-r6 to /
[ebuild  N   ] gnome-base/libglade-2.0.0 to /
[ebuild   R  ] gnome-base/gnome-panel-1.4.1 to /
Comment 1 Daniel Robbins (RETIRED) gentoo-dev 2002-06-29 15:01:18 UTC
OK, let me get this straight.  You have a need to have *both* >=libglade-0.17
*and* >=libglade-0.99.0 installed?
Comment 2 Spider (RETIRED) gentoo-dev 2002-06-29 16:35:25 UTC
No, 
I want Any version higher than glade 0.17  but still below 0.99.0 
The "highest" avaiable are 1.x and 2.0.0, 1.x was never "stable" or released,
2.0.0 is in completely new libraries and headers, and not compatible.

Comment 3 Daniel Robbins (RETIRED) gentoo-dev 2002-07-02 02:00:10 UTC
OK, syntax not supported currently....
Comment 4 Martin Schlemmer (RETIRED) gentoo-dev 2002-12-03 01:50:05 UTC
Nick, lot of work to get in ?  Sorda critical for gnome.  Else I guess depending
on SLOT may do the trick ...
Comment 5 Spider (RETIRED) gentoo-dev 2003-04-01 17:34:21 UTC
adding aliz to cc, since he just recently added xpm as deps to packages.
Comment 6 Spider (RETIRED) gentoo-dev 2003-04-01 17:41:31 UTC
wrong bug.
Comment 7 Masatomo Nakano (RETIRED) gentoo-dev 2003-08-04 10:46:23 UTC
Created attachment 15489 [details, diff]
patch for portage.py/emerge
Comment 8 Masatomo Nakano (RETIRED) gentoo-dev 2003-08-04 10:48:11 UTC
oops, i mistook upload the patch. it is for #4229.
sorry.
Comment 9 Radek Podgorny 2003-09-09 17:11:53 UTC
Is this version of portage still supported? :-)

I suspect this bug should be considered solved. Or am I wrong? :-)))

Radek
Comment 10 SpanKY gentoo-dev 2003-10-23 09:16:04 UTC
you are wrong, this is still broken

you currently cannot say:
DEPEND="<cat/pkg-4
>cat/pkg-1"

in this case, pkg is SLOT-ed accordingly, and the package will not work with
pkg-1 or lower, or with pkg-4 and higher ...
and yes, this is needed sometimes :P
Comment 11 Marius Mauch (RETIRED) gentoo-dev 2004-06-09 19:33:28 UTC
proposed syntax for this is DEPEND="&& ( >=foo-1 <=foo-3 )"
Comment 12 Brian Harring (RETIRED) gentoo-dev 2005-02-27 21:34:28 UTC
So... whats going on here?  Recall discussing this, but don't recall the results/outcome...
Comment 13 Jason Stubbs (RETIRED) gentoo-dev 2005-04-02 22:48:56 UTC
If one package can satisfy two atoms in the one DEPEND string, that one package should be used. In other words, AND should be implicit.
Comment 14 Dan Armak (RETIRED) gentoo-dev 2005-07-02 06:26:52 UTC
Bug 33545 is a special case of this one... 
KDE split ebuilds also need this functionality and to work without it use the 
ugly deprange() hack. Can we expect this in at least portage 2.1? 
Comment 15 Jason Stubbs (RETIRED) gentoo-dev 2005-07-28 07:25:31 UTC
Putting a hold on feature requests for portage as they are drowning out the 
bugs. Most of these features should be available in the next major version of 
portage. But for the time being, they are just drowning out the major bugs and 
delaying the next version's progress. 
 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;) 
Comment 16 Zac Medico gentoo-dev 2006-10-10 18:23:44 UTC
(In reply to comment #13)
> If one package can satisfy two atoms in the one DEPEND string, that one package
> should be used. In other words, AND should be implicit.

Can anybody think of a reason why it shouldn't be implicit like that?
Comment 17 Zac Medico gentoo-dev 2006-10-10 23:22:49 UTC
*** Bug 150368 has been marked as a duplicate of this bug. ***
Comment 18 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2006-10-11 00:42:48 UTC
(In reply to comment #16)
> (In reply to comment #13)
> > If one package can satisfy two atoms in the one DEPEND string, that one package
> > should be used. In other words, AND should be implicit.
> 
> Can anybody think of a reason why it shouldn't be implicit like that?

I think some form of explicit syntax would be easier to read and grok, and also somewhat less prone to error. If somebody removes/masks (maybe just on one arch) the only one version that satisfies both atoms, suddenly you might silently end up pulling in two completely different versions you didn't want, and e.g. repoman won't complain because it won't know it wasn't meant like this. Explicit syntax would fail on not satisfied deps.
Comment 19 Ciaran McCreesh 2006-10-11 12:11:27 UTC
(In reply to comment #16)
> Can anybody think of a reason why it shouldn't be implicit like that?

Yes. There are times when you need to DEPEND upon multiple versions of the same package. Having to wrap them in extra ( )s is confusing. It's much more obvious to use some explicity syntax for ranged deps.

Having said that, handling this purely through SLOT + single range deps is a much cleaner solution...
Comment 20 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-03-15 12:57:53 UTC
(In reply to comment #18)
> I think some form of explicit syntax would be easier to read and grok and also somewhat less prone to error.

Yeah, something like "package-[1.0,1.9[" instead of ">=package-1.0 <package-1.9" might spare some characters; not sure if it is necessarily more readable as you are putting the version numbers close to each other, it is kind of a cosmetic change.

> If somebody removes/masks (maybe just on
> one arch) the only one version that satisfies both atoms, suddenly you might
> silently end up pulling in two completely different versions you didn't
> want, and e.g. repoman won't complain because it won't know it wasn't meant
> like this. 

Not sure where this idea comes from, but I haven't seen this happen.
Comment 21 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-08-30 10:35:20 UTC
Anything interesting happening here lately?

To be honest, I wouldn't mind something like:

  =dev-foo/bar-{1.2.3..1.2.9}

though it's hardly readable. Maybe if we would go with '...' it would be a little better but still it sounds like triumph of form over substance.

I think the underlying issue that was discussed first in this bug is gone already. Plus then there's the problem of intersection with slots, subslots and possibly more future stuff.

So, do we still want this? It's open for 11 years already, so we may as well close it as WONTFIX.
Comment 22 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-08-31 08:42:27 UTC
(Quoting Ciaran McCreesh from comment #19)
> Having said that, handling this purely through SLOT + single range deps is a
> much cleaner solution...

Thinking about this again; while nice to have, would there an actual use where SLOTs don't suffice? Restricting by version inside a SLOT is kind of nasty as you deny your package from being used simultaneously with other packages depending on the same package SLOT. So, it kind of sounds like the need for a new SLOT rather than to introduce a version restriction within an existing SLOT.
Comment 23 Ulrich Müller gentoo-dev 2013-08-31 09:04:53 UTC
(In reply to Michał Górny from comment #21)
> So, do we still want this? It's open for 11 years already, so we may as well
> close it as WONTFIX.

Actually, the original issue from comment #0 and comment #10 appears to be fixed. I don't know why we would need another syntax for it.
DEPEND="<cat/pkg-4 >cat/pkg-1" works well enough.
Comment 24 Zac Medico gentoo-dev 2013-08-31 19:06:29 UTC
(In reply to Ulrich Müller from comment #23)
> Actually, the original issue from comment #0 and comment #10 appears to be
> fixed. I don't know why we would need another syntax for it.
> DEPEND="<cat/pkg-4 >cat/pkg-1" works well enough.

It's handled by portage since bug #285767:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=51140af8783fae99ff2b2f5ca5f45bcfeb689b91
Comment 25 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-19 19:55:40 UTC
I think we should restart the discussion on this. People are repeatedly getting in trouble trying to express multiple version constraints for a package.

Common issues I've seen:

a. plain version ranges need to be expressed in less readable form of two dependencies,

b. non-contiguous version ranges are expressed in ugly form of || (), which also makes it impossible to use := correctly,

c. version ranges on slotted packages are pretty much impossible to be expressed correctly (e.g. on sys-libs/db).

I think it's about time we consider some way to provide multiple version constraints on a single package dependency specification.
Comment 26 Ulrich Müller gentoo-dev 2016-06-19 23:00:58 UTC
(In reply to Michał Górny from comment #25)
That doesn't convince me. Most cases can nowadays be handled by slot dependencies instead (see comment 22). For the ones that cannot, the ||= operator of bug 489458 will provide a solution to express := correctly in an any-of-many group.

Also, it looks like in the 14 years since this bug was first opened, nobody was able to come up with a decent syntax. Suggestions so far:

    && ( >=foo-1 <=foo-3 )
    package-[1.0,1.9[
    =dev-foo/bar-{1.2.3..1.2.9}

The first isn't much of an improvement over existing syntax, the second collides with use dependencies, and the third cannot distinguish between open and closed intervals.
Comment 27 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-20 19:43:18 UTC
(In reply to Ulrich Müller from comment #26)
> (In reply to Michał Górny from comment #25)
> That doesn't convince me. Most cases can nowadays be handled by slot
> dependencies instead (see comment 22). For the ones that cannot, the ||=
> operator of bug 489458 will provide a solution to express := correctly in an
> any-of-many group.

The problem is not 'it can not be done'. It's 'it can not be done reasonably, with concern for readability'. I can imagine some people will be using huge blocks of ||= to enforce a particular range. But:

a. this will be unreadable and hard to figure out,

b. it has pitfalls.

In fact, as long as we have no version ranges, developers are still likely to assume that e.g. dep like '>=foo-1 <foo-4' is guaranteed not to install two slots of a package.

> Also, it looks like in the 14 years since this bug was first opened, nobody
> was able to come up with a decent syntax. Suggestions so far:
> 
>     && ( >=foo-1 <=foo-3 )
>     package-[1.0,1.9[
>     =dev-foo/bar-{1.2.3..1.2.9}
> 
> The first isn't much of an improvement over existing syntax, the second
> collides with use dependencies, and the third cannot distinguish between
> open and closed intervals.

Well, that's a problem that needs to be solved. We also need to consider the possibility of having multiple ranges for a single package, i.e. >1 <=4 || >6.
Comment 28 wolfgang 2021-01-07 15:13:29 UTC
> as long as we have no version ranges, developers are still likely
> to assume that e.g. dep like '>=foo-1 <foo-4' is guaranteed not to
> install two slots of a package

This is definitely my assumption. I believe this is also why in ::haskell we do `>=foo-1:= <foo-4:=`, but even then, I believe it is fragile b/c it relies on *not* using slots the way they're intended to be used.

Despite this issue being 18 years-old, and despite Ulrich's comments above, I still think there is value  to pursuing something as discussed in 598627[1]

This would allow something as follows (which is exactly how haskell does it, and similar to how other programming languages do it)

foo-1 >=1 && <4

While I realize this is a big change with large implications, I think it is worthwhile to continue tho conversation and try to find a way to make something work.

[1]: https://bugs.gentoo.org/598627
Comment 29 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-03-27 23:19:11 UTC
Thinking about it more, it would probably make sense to cover GLSA use case here and look into unifying the syntax used in ebuilds and in GLSAs.

My current rough idea right now is to allow one or more ranges using a syntax alike:

  app-foo/bar{<RANGES>}

(not sure if we should include '-' or not)

RANGES are list of RANGE specifiers, separated by ',' acting as logical OR.

RANGE lists one or more OPERATOR VERSION pairs, acting as logical AND.


So e.g. in the simplest form:

  dev-foo/bar{>=1<2,>=2.4}

but I suppose sooner or later we're also going to see use cases for slots, negated != and !~.  In the end we might see Python-style lists of:

  dev-foo/bar{>=4!~4.1.1!~4.1.2}
Comment 30 Allen Webb 2021-09-09 15:50:36 UTC
I will probably file a separate bug, but figured I would post here because it is related and it looks like this usage isn't truly supported yet.

If you currently use a '>=' constraint followed by a '<' constraint, and both packages have different slots under some circumstances the wrong slot is used for the DEPEND value used in binary packages.

I have steps to reproduce this on Chrome OS and it reproduces on both Portage 3.0.21 and 2.3.75. I end up with the slot from a package that passes the first constraint and fails the second constraint even though the package version that is selected meets both constraints, so the version:slot value is actually impossible to achieve for SLOT="${PV}/${PR}".
Comment 31 Allen Webb 2021-09-16 14:19:47 UTC
(In reply to Allen Webb from comment #30)
> I will probably file a separate bug, but figured I would post here because
> it is related and it looks like this usage isn't truly supported yet.
> 
> If you currently use a '>=' constraint followed by a '<' constraint, and
> both packages have different slots under some circumstances the wrong slot
> is used for the DEPEND value used in binary packages.
> 
> I have steps to reproduce this on Chrome OS and it reproduces on both
> Portage 3.0.21 and 2.3.75. I end up with the slot from a package that passes
> the first constraint and fails the second constraint even though the package
> version that is selected meets both constraints, so the version:slot value
> is actually impossible to achieve for SLOT="${PV}/${PR}".

I found a workaround. **The slot operator needs to be on the upper bound constraint** because the depgraph calculation is bugged in the sense it fills in a package for both constraints. Max versions are used in both cases so slot for the lower bound can be greater than the upper bound leading to the problem I saw. If the slot operator is placed on the upper bound, the selected version meets both constraints.