On 11/06/2016 02:52 AM, Michał Górny wrote: > Hi, everyone. > > Following my previous RFC wrt version operator problems, I'd like to > start the second part of the discussion: how to improve version > operators in a Future EAPI? > > I've collected various ideas on operator changes on a wiki page [1]. > I've tried to stay open-minded and cover every possibility, even though > I doubt some of them would be even considered. > > I should warn you that some of the solutions are interlinked to each > other, and you probably need to look through the whole page first > before starting to construct an opinion. For example, specific > solutions to most of the problems depend on whether we enable version > ranges and in which form. > > I think we should start by loosely discussing the various ideas > on the wiki page. Feel free to also point out any missing ideas > or remarks that would be useful there. > > So, what are your comments? > > [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes > I think it complicates version matching. Of course, matching the correct version is a difficult task in itself. Anything that requires the least necessary change and improves readability and utility the most should get in. I like the idea of version ranges and slot ranges, but it's tough to figure out which form is best for that.
Then we have the pesky * that, when used in a version spec, doesn't
follow intuition. Unless a package is slotted for each major or
major.minor version, there isn't a way currently (that I know of) to
express "pull in any version 1.2.x of app-misc/foobar" in a single
declaration/line.
In an attempt at a solution: we already use [] for USE, and () are for
groupings. If bash doesn't yell at us much, maybe {} would be good for
version restrictions. Maybe something like:
>=app-misc/foobar-{1.2..1.4}:=[baz]
To mean "any version of 1.2 or greater, up to version 1.4, inclusive".
We could add in asterisk support to match any sub versions, e.g.
{1.2*..1.4}, but it could get really messy.
While the initial proposal to put the operator in a better place seems
nice on paper, I can only think of the massive amount of work that'd
need to be done to get that change pushed through and re-educate fellow
devs on how to do things going forward. Maybe we should go through some
particularly tricky ebuilds and "try out" the new ideas, to see what the
final product looks like.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
