1 |
On Wed, 9 Nov 2016 18:17:25 +0800 |
2 |
konsolebox <konsolebox@×××××.com> wrote: |
3 |
|
4 |
> On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny <mgorny@g.o> wrote: |
5 |
> > On Wed, 9 Nov 2016 14:32:33 +0800 |
6 |
> > konsolebox <konsolebox@×××××.com> wrote: |
7 |
> >> dev-foo/bar:={:1.3= :1.4= :1.5=} OR dev-foo/bar(:= {:1.3= :1.4= |
8 |
> >> :1.5=}) renders := being an "any" operator meaningless since the |
9 |
> >> condition requires {:1.3= :1.4= :1.5=} to also be true. It looks |
10 |
> >> insensible, but it's still algorithmically correct, and can be |
11 |
> >> interpreted by the package manager. |
12 |
> > |
13 |
> > Wrong. It means 'any OR 1.3 OR 1.4 ...'. Making 'any' no longer mean |
14 |
> > 'any' in this context is confusing. |
15 |
> |
16 |
> Isn't that 'any AND (1.3 OR 1.4 OR 1.5)'? Would that make sense to |
17 |
> have it the other way around instead? |
18 |
|
19 |
I'm sorry, I misread that. |
20 |
|
21 |
> >> dev-foo/bar(:* :=) renders :* meaningless since := restricts any |
22 |
> >> installed runtime dependency's slot and subslot to be currently |
23 |
> >> available. It's still algorithmically correct. |
24 |
> > |
25 |
> > 'any AND newest'? Why would you ever do that? The only purpose for :* |
26 |
> > is to disable warnings on missing slot specifications when package has |
27 |
> > multiple slots. |
28 |
> |
29 |
> I hope you're only arguing against the misuse, and not about whether |
30 |
> it's feasible when it comes to the implementation. |
31 |
> |
32 |
> But anyway, "newest" is not what's being said in ebuild(5): |
33 |
> |
34 |
> ":= Indicates that any slot value is acceptable. In addition, |
35 |
> for runtime dependencies, indicates that the package will break unless |
36 |
> a matching package with slot and sub-slot equal to the slot and |
37 |
> sub-slot of the best installed version at the time the package was |
38 |
> installed is available." |
39 |
|
40 |
I meant newest installed. |
41 |
|
42 |
> >> dev-foo/bar:={:1.3 :1.4 :1.5} OR dev-foo/bar(:= {:1.3 :1.4 :1.5}) |
43 |
> >> implies that the currently installed package's slot and subslot should |
44 |
> >> be available and that the version of the slot should be 1.3, 1.4, or |
45 |
> >> 1.5. The interpreter could read that condition checking from left to |
46 |
> >> right easily. Is the currently installed package's slot and subslot |
47 |
> >> currently available? If no, this condition renders false and the |
48 |
> >> currently installed package is invalid. If yes, we follow the next |
49 |
> >> condition. Is the slot version any of 1.3, 1.4, or 1.5? If yes, then |
50 |
> >> that condition yields true. |
51 |
> > |
52 |
> > I see a lot of added complexity here, for no benefit whatsoever. |
53 |
> |
54 |
> No, it's not complex at all as everything would just be packaged in |
55 |
> one logical code. I just had to explain detail by detail so I could |
56 |
> prove that it's doable. |
57 |
> |
58 |
> The current check-if-some-specific-element-comes-before-or-after-another |
59 |
> which propagates everywhere in every context of every different type |
60 |
> of conditional element being checked makes things more complex. |
61 |
|
62 |
I think you're forgetting the most important point here. Dependency |
63 |
specifications are not only used to check some installed package for |
64 |
match. They also need to make it possible to semi-reasonably pull |
65 |
in additional packages that could be used to satisfy the dependency. |
66 |
|
67 |
The more complex conditions you allow, the harder the task becomes for |
68 |
the PM and the slower Portage becomes (because it needs to consider |
69 |
more variants of a possible solution). |
70 |
|
71 |
> >> > 4. Do we allow different ranges per slots? |
72 |
> >> |
73 |
> >> Seems possible like {:>=1.3 :<=1.5}. Comparing subslots is also just |
74 |
> >> about grouping where in x/y, x is the major and y is the minor. Major |
75 |
> >> versions are compared first, and minor versions are only compared if |
76 |
> >> major versions are equal. |
77 |
> > |
78 |
> > Slots are not numbers nor versions. You can't compare them. |
79 |
> |
80 |
> Not that I really care about ranges for slots, but can you explain |
81 |
> why? Is that somehow dependent to a current implementation? |
82 |
|
83 |
Slots are free-form strings by design. This has its uses, including |
84 |
named slots ('stable', 'testing'...), subslots representing SONAMEs of |
85 |
multiple libraries ('liba0-libb4')... |
86 |
|
87 |
> >> > How do we combine various order of data? |
88 |
> >> |
89 |
> >> I need specific example/detail on that, or perhaps I already have that |
90 |
> >> answered above. |
91 |
> > |
92 |
> > dev-foo/bar(:1.6 {>=3.4 :5[foo]} ([bar] <3.7)) |
93 |
> |
94 |
> I'm yet to add opinion on allowing use flags to be used anywhere |
95 |
> besides outside a group and only once. But that looks doable, |
96 |
> although seems more complicated to implement, or at least heavier, |
97 |
> maybe. You should also correct that a bit: |
98 |
> |
99 |
> dev-foo/bar(:1.6 {>=3.4 (:5 [foo])} ([bar] <3.7)) |
100 |
|
101 |
Why are you forcing whitespace in some contexts and not in other |
102 |
contexts? Does this mean the common case would look like: |
103 |
|
104 |
dev-foo/bar >= 1.4 :1.6 [bar] |
105 |
|
106 |
? |
107 |
|
108 |
> > Yes, I am. In some cases, regexp is the only thing you have |
109 |
> > (e.g. in XSD). The major problem with current syntax is that you can't |
110 |
> > properly validate restrict="" in XSD because you'd have to |
111 |
> > backreference operator. |
112 |
> |
113 |
> I don't know XSD, but it's good if we can improve it as well so we can innovate. |
114 |
|
115 |
Err, are you talking Gentoo is supposed to request full FSM to be |
116 |
included in XML Schema? I honestly doubt standard bodies will seriously |
117 |
consider that. |
118 |
|
119 |
> >> > 3. Do we allow multiple occurrences of the same type of element? I'm specifically thinking of multiple disjoint USE dependency blocks. |
120 |
> >> |
121 |
> >> I'm sorry but I'm not sure what you mean there. I hope you can give an example. |
122 |
> > |
123 |
> > dev-foo/bar[foo][bar] |
124 |
> |
125 |
> Again, I never really thought about allowing the [use] block to be |
126 |
> more re-arrangeable in the sense that it can be used more than once |
127 |
> and that it can be allowed inside condition blocks, but so far it |
128 |
> really looks doable, and we could drop the restrictions. This would |
129 |
> be possible along with having everything changed to independent |
130 |
> conditional elements. |
131 |
|
132 |
'I never really thought' is the core problem. When you want to change |
133 |
PMS, you really have to think about everything. Otherwise, you end up |
134 |
with screwups like := in || (). |
135 |
|
136 |
-- |
137 |
Best regards, |
138 |
Michał Górny |
139 |
<http://dev.gentoo.org/~mgorny/> |