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 /
OK, let me get this straight. You have a need to have *both* >=libglade-0.17 *and* >=libglade-0.99.0 installed?
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.
OK, syntax not supported currently....
Nick, lot of work to get in ? Sorda critical for gnome. Else I guess depending on SLOT may do the trick ...
adding aliz to cc, since he just recently added xpm as deps to packages.
wrong bug.
Created attachment 15489 [details, diff] patch for portage.py/emerge
oops, i mistook upload the patch. it is for #4229. sorry.
Is this version of portage still supported? :-) I suspect this bug should be considered solved. Or am I wrong? :-))) Radek
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
proposed syntax for this is DEPEND="&& ( >=foo-1 <=foo-3 )"
So... whats going on here? Recall discussing this, but don't recall the results/outcome...
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.
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?
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. ;)
(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?
*** Bug 150368 has been marked as a duplicate of this bug. ***
(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.
(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...
(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.
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.
(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.
(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.
(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
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.
(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.
(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.
> 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
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}
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}".
(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.
