these represent the upper bound (inclusive) for stuff within openstack https://github.com/openstack/requirements/blob/master/upper-constraints.txt It would be nice if I could use these versions with <~ as <= makes it so that I don't include revbumps. I've had to add -r9999 to some <= lines already and don't really want to add it everywhere <= is defined. Reproducible: Always
does it have to be in a future eapi? can I sneak it into eapi6? why not just use < with the version you're limiting to plus 1 ? It's harder to track mainly, but also because a package refrences what it knows works. If it says 1.0 works and you do <category/package-1.1 then 1.0.1 comes out (this happens more then you'd think) 1.0.1 will be allowed which isn't good. || ( <atom ~atom ) this is basically the same but much more cluttery see https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-cluster/nova/nova-2015.2.9999.ebuild?id=af0e8b432acc614a2025d47fee2c0317c8a39e00 for the number of packages I'm dealing with
~ is only needed when defining an upper bound, >= already covers revbumps so >~ is not needed
!>~ could be useful though !<~ as well, but at that point you'd likely know what you need like with >= could be added for completeness, but not really needed
(In reply to Matthew Thode ( prometheanfire ) from comment #1) > does it have to be in a future eapi? Yes. > can I sneak it into eapi6? Extremely bad timing, since the EAPI 6 draft is already in its review phase. > why not just use < with the version you're limiting to plus 1 ? > It's harder to track mainly, but also because a package refrences what it > knows works. If it says 1.0 works and you do <category/package-1.1 then > 1.0.1 comes out (this happens more then you'd think) 1.0.1 will be allowed > which isn't good. Couldn't you use subslots for these dependencies?
might be able to do subslots but I'm not sure that's the best solution
If we are to consider this, we should probably establish some relation to r* GLEP operators. There's really no point in having two distinct sets.
(In reply to Michał Górny from comment #6) > r* GLEP operators I have no idea what that is. Please explain.
(In reply to Ulrich Müller from comment #7) > (In reply to Michał Górny from comment #6) > > r* GLEP operators > > I have no idea what that is. Please explain. After reading the request multiple times, I figured out it's a different thing. I've filed the 'request' for GLSA ops as [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=598523
(In reply to Michał Górny from comment #6) > If we are to consider this, we should probably establish some relation to r* > GLEP operators. There's really no point in having two distinct sets. Sorry, I meant GLSA there. So as far as I understand, <~ would be like <X-r9999999..., and >~ would be like >X-r9999999... Maybe it'd be simpler to have some kind of -rINF ;-).
(In reply to Michał Górny from comment #9) > So as far as I understand, <~ would be like <X-r9999999..., and >~ would be > like >X-r9999999... Maybe it'd be simpler to have some kind of -rINF ;-). One could argue that r9999 is equivalent to rINF for all practical purposes.
I've seen -r20161030 style stuff show up in overlays...
Especially considering we don't enforce any numerical limits. Let's use -r∞.
I'm good with ascii or unicode :P (though I think we are limited to ascii for ebuilds.
