Gentoo Archives: gentoo-dev

From: konsolebox <konsolebox@×××××.com>
To: gentoo-dev@l.g.o
Cc: pms-bugs@g.o
Subject: Re: [gentoo-dev] RFC: Future EAPI version operator changes
Date: Tue, 08 Nov 2016 08:18:00
Message-Id: CAJnmqwa+6DXTTjSPMPACLXwDU=cz5NctVxdbCCLyKqw6n0Wptw@mail.gmail.com
In Reply to: Re: [gentoo-dev] RFC: Future EAPI version operator changes by konsolebox
1 On Tue, Nov 8, 2016 at 3:09 PM, konsolebox <konsolebox@×××××.com> wrote:
2 > On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgorny@g.o> wrote:
3 >> Hi, everyone.
4 >>
5 >> Following my previous RFC wrt version operator problems, I'd like to
6 >> start the second part of the discussion: how to improve version
7 >> operators in a Future EAPI?
8 >>
9 >> I've collected various ideas on operator changes on a wiki page [1].
10 >> I've tried to stay open-minded and cover every possibility, even though
11 >> I doubt some of them would be even considered.
12 >>
13 >> I should warn you that some of the solutions are interlinked to each
14 >> other, and you probably need to look through the whole page first
15 >> before starting to construct an opinion. For example, specific
16 >> solutions to most of the problems depend on whether we enable version
17 >> ranges and in which form.
18 >>
19 >> I think we should start by loosely discussing the various ideas
20 >> on the wiki page. Feel free to also point out any missing ideas
21 >> or remarks that would be useful there.
22 >>
23 >> So, what are your comments?
24 >>
25 >> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes
26 >>
27 >> --
28 >> Best regards,
29 >> Michał Górny
30 >> <http://dev.gentoo.org/~mgorny/>
31 >
32 > I also like the idea of moving the operator as it's more consistent
33 > and opens new doors to other solutions.
34 >
35 > As for the use of operator & and |, they're quite good, but I'd prefer
36 > the use of Gmail's style where expressions placed in () are processed
37 > with AND, and expressions placed inside {} are processed with OR:
38 >
39 > dev-foo/bar[>=1.3&<1.5] dev-foo/bar(>=1.3 <1.5)
40 > dev-foo/bar[>=1.3&<1.5&!=1.4.1] dev-foo/bar(>=1.3 <1.5 !=1.4.1)
41 > dev-foo/bar[<1.1|>=1.5] dev-foo/bar{<1.1 >=1.5}
42 > dev-foo/bar[=1.1*|=1.3*|>=1.5] dev-foo/bar{=1.1* =1.3* >=1.5}
43 >
44 > I find it more readable. The former looks too compressed.
45
46 I should also add that we can allow slots and repositories in the expressions:
47
48 dev-foo/bar{:1.3 :1.4 :1.5} ## Solves "A. Range dependencies vs slotting"
49 dev-foo/bar(:1.6 {::local ::devel}) ## Especially useful in
50 /etc/portage/package.{keywords,mask}
51
52 Along with it, we should also drop the strict order of the slot,
53 version, and repo expressions (just change it to "recommended"). It
54 makes things more flexible and makes it easier for the parser to be
55 implemented.
56
57 Arithmetic ranges on the other hand should only be in the form of
58 being "inclusive" in both ends, and not exclusive in any. Not only is
59 it simpler; it is also easier to parse. There's also no need to use
60 special grouping operators like {}. E.g. 1.3..1.5. Grouping is only
61 necessary if the form would cause other possible conflicts, where in
62 that case (1.3..1.5) and {1.3..1.5} should just be the same, unless
63 there would be more added expressions in the group.
64
65 --
66 konsolebox

Replies

Subject Author
Re: [gentoo-dev] RFC: Future EAPI version operator changes "Michał Górny" <mgorny@g.o>