1 |
On Wed, 9 Nov 2016 14:32:33 +0800 |
2 |
konsolebox <konsolebox@×××××.com> wrote: |
3 |
|
4 |
> On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny <mgorny@g.o> wrote: |
5 |
> >>dev-foo/bar{:1.3 :1.4 :1.5} ## Solves "A. Range dependencies vs |
6 |
> >>slotting" |
7 |
> > |
8 |
> > I'm not sure about this. Slots are kinda special, especially with regard to slot operators. Problems I see: |
9 |
> > |
10 |
> > 1. := binds to slot of newest version matching the spec. How does this work with your spec? |
11 |
> > |
12 |
> > 2. Should we allow using := on some of the listed slots? What would happen? |
13 |
> > |
14 |
> > 3. It's asymmetric since we can't use an AND variant. |
15 |
> |
16 |
> I had to ask help from #gentoo-dev-help in order to properly |
17 |
> understand slot operators since I haven't become too familiar with |
18 |
> them so sorry for the late reply. (Thanks to desultory and _AxS_). |
19 |
> |
20 |
> Here I find it that we could just follow the simple AND/OR rule |
21 |
> against every condition from left to right, and the interpreter would |
22 |
> just do fine. A user may create insensible rules just like how one |
23 |
> could create meaningless codes in C, but that won't stop the compiler |
24 |
> from compiling the code, just like how this would not prevent the |
25 |
> package manager from interpreting it. We're also free to detect |
26 |
> ambiguous rules if we want to, and warn the user, or just disallow it |
27 |
> completely. But it's still optional and wouldn't yield a difference |
28 |
> to a stable operation. |
29 |
> |
30 |
> Examples: |
31 |
> |
32 |
> dev-foo/bar:={:1.3= :1.4= :1.5=} OR dev-foo/bar(:= {:1.3= :1.4= |
33 |
> :1.5=}) renders := being an "any" operator meaningless since the |
34 |
> condition requires {:1.3= :1.4= :1.5=} to also be true. It looks |
35 |
> insensible, but it's still algorithmically correct, and can be |
36 |
> interpreted by the package manager. |
37 |
|
38 |
Wrong. It means 'any OR 1.3 OR 1.4 ...'. Making 'any' no longer mean |
39 |
'any' in this context is confusing. |
40 |
|
41 |
What about {:1.3/2 :1.3/3 :1.3=}? |
42 |
|
43 |
> dev-foo/bar(:* :=) renders :* meaningless since := restricts any |
44 |
> installed runtime dependency's slot and subslot to be currently |
45 |
> available. It's still algorithmically correct. |
46 |
|
47 |
'any AND newest'? Why would you ever do that? The only purpose for :* |
48 |
is to disable warnings on missing slot specifications when package has |
49 |
multiple slots. |
50 |
|
51 |
> dev-foo/bar{:* :=} renders := meaningless since :* would already be |
52 |
> true, if it becomes false, := would still be false anyway. But it's |
53 |
> still algorithmically correct. In many ways, the rule doesn't make |
54 |
> sense at all since virtually is just boils down to be just about |
55 |
> dev-foo/bar, but it's not an issue that would stop the implementation |
56 |
> of the interpreter. And, it's also not something that would |
57 |
> jeopardize how the package manager operates. |
58 |
|
59 |
It's worse than meaningless. It requires the PM to record installed |
60 |
slot for no reason whatsoever, since you allow it to switch to another |
61 |
slot anyway. |
62 |
|
63 |
> dev-foo/bar:={:1.3 :1.4 :1.5} OR dev-foo/bar(:= {:1.3 :1.4 :1.5}) |
64 |
> implies that the currently installed package's slot and subslot should |
65 |
> be available and that the version of the slot should be 1.3, 1.4, or |
66 |
> 1.5. The interpreter could read that condition checking from left to |
67 |
> right easily. Is the currently installed package's slot and subslot |
68 |
> currently available? If no, this condition renders false and the |
69 |
> currently installed package is invalid. If yes, we follow the next |
70 |
> condition. Is the slot version any of 1.3, 1.4, or 1.5? If yes, then |
71 |
> that condition yields true. |
72 |
|
73 |
I see a lot of added complexity here, for no benefit whatsoever. |
74 |
|
75 |
> > 4. Do we allow different ranges per slots? |
76 |
> |
77 |
> Seems possible like {:>=1.3 :<=1.5}. Comparing subslots is also just |
78 |
> about grouping where in x/y, x is the major and y is the minor. Major |
79 |
> versions are compared first, and minor versions are only compared if |
80 |
> major versions are equal. |
81 |
|
82 |
Slots are not numbers nor versions. You can't compare them. |
83 |
|
84 |
> I hope I understand you correctly. |
85 |
> |
86 |
> If you're talking about combining ranges of versions with slots, then |
87 |
> yes it's possible. You just check every condition independently. |
88 |
> It's pretty simple. |
89 |
|
90 |
That's what I was asking for. |
91 |
|
92 |
> > How do we combine various order of data? |
93 |
> |
94 |
> I need specific example/detail on that, or perhaps I already have that |
95 |
> answered above. |
96 |
|
97 |
dev-foo/bar(:1.6 {>=3.4 :5[foo]} ([bar] <3.7)) |
98 |
|
99 |
> >>Along with it, we should also drop the strict order of the slot, |
100 |
> >>version, and repo expressions (just change it to "recommended"). It |
101 |
> >>makes things more flexible and makes it easier for the parser to be |
102 |
> >>implemented. |
103 |
> > |
104 |
> > Problems: |
105 |
> > |
106 |
> > 1. This could result in fairly ambiguous variants with some syntaxes purposes. |
107 |
> |
108 |
> I think that would only apply to older versions of Portage that would |
109 |
> not recognize loose arrangement of conditions. Can you give a |
110 |
> specific variant where would this become an issue? |
111 |
|
112 |
dev-foo/bar:1===3 |
113 |
|
114 |
> > 2. This makes 'simple validation' harder. Strict order makes it possible to write a simple regular expression that validates that are elements are in place and correct, and are not repeated. |
115 |
> |
116 |
> It's quite the opposite. |
117 |
> |
118 |
> Before that 'simple validation', parsing would come first (unless |
119 |
> parsing comes along with (the only) validation itself), and parsing |
120 |
> itself [with/without the validation] has already become difficult due |
121 |
> to many conditions that one should come or could come before/after |
122 |
> another. If every condition would just be elements with different |
123 |
> classes, it would be easier to do a validation. You'll just need a |
124 |
> single loop with case statements for that, rather than have a tree of |
125 |
> if conditions. |
126 |
> |
127 |
> If there's another validation stage that's necessary to do after |
128 |
> parsing, the same holds true for it: just one single loop, and no |
129 |
> check if an element follows one after another. Checking whether stuff |
130 |
> are repeated is still doable (if it still becomes necessary). |
131 |
> |
132 |
> I also hope you're not after grep-ability. If not, just ignore this. |
133 |
> Grep/regex scanning itself is slow, and is a bit of a hack to me, |
134 |
> especially if it's used in parsing. Not that I'm saying it's a bad |
135 |
> solution for doing validations, but it shouldn't be something to rely |
136 |
> upon when judging this. |
137 |
|
138 |
Yes, I am. In some cases, regexp is the only thing you have |
139 |
(e.g. in XSD). The major problem with current syntax is that you can't |
140 |
properly validate restrict="" in XSD because you'd have to |
141 |
backreference operator. |
142 |
|
143 |
> > 3. Do we allow multiple occurrences of the same type of element? I'm specifically thinking of multiple disjoint USE dependency blocks. |
144 |
> |
145 |
> I'm sorry but I'm not sure what you mean there. I hope you can give an example. |
146 |
|
147 |
dev-foo/bar[foo][bar] |
148 |
|
149 |
-- |
150 |
Best regards, |
151 |
Michał Górny |
152 |
<http://dev.gentoo.org/~mgorny/> |