1 |
Dnia 19 września 2015 09:43:14 CEST, konsolebox <konsolebox@×××××.com> napisał(a): |
2 |
>On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny <mgorny@g.o> |
3 |
>wrote: |
4 |
>> Dnia 2015-09-19, o godz. 03:50:52 |
5 |
>> konsolebox <konsolebox@×××××.com> napisał(a): |
6 |
>> |
7 |
>>> On Sat, Sep 19, 2015 at 2:23 AM, Michał Górny <mgorny@g.o> |
8 |
>wrote: |
9 |
>>> > And similarly to the current solution it's full of silly special |
10 |
>cases and magical rules. If you really want something simple and clean, |
11 |
>take a look at the scheme used by pkg-config and rpm. |
12 |
>>> |
13 |
>>> Silly because it uses a not-so-monolithic approach which is more |
14 |
>>> convenient to implement and actually works? What special cases or |
15 |
>>> magical rules where you could find it more complex than the current |
16 |
>>> spec? |
17 |
>> |
18 |
>> It's silly because it shifts the existing terrible structure a bit |
19 |
>> and doesn't really solve most of its issues |
20 |
> |
21 |
>What issues? My spec was not meant to solve issues which can't be |
22 |
>solved by any universal algorithm. And it's not meant to add a |
23 |
>feature, but it can be used as a basis for one that would. |
24 |
> |
25 |
>Perhaps provide your own spec on how you could solve those issues then |
26 |
>let's see if your point is correct. |
27 |
|
28 |
If you did the necessary research before sending your first mail, you'd know I did. If you can't use archives, I'll drop you a link when I get home. |
29 |
|
30 |
> |
31 |
>> It's silly because you |
32 |
>> still have a fair number of limitations which make parsing harder |
33 |
>> rather than easier. |
34 |
> |
35 |
>What limitations specifically? I'm not sure why you'd find it harder, |
36 |
>as compared to the current spec. And it's not even hard generally. |
37 |
|
38 |
Once again, I repeat: if your goal is to change the current spec a bit just to make one or two of your packages happier, then you're wasting time. The spec is to be judged generally, not compared to current state. |
39 |
|
40 |
> |
41 |
>> It's silly because you still have to remember |
42 |
>> the relation between 'alpha', 'beta', 'rc' and 'pre'. |
43 |
> |
44 |
>What kind of implementation would you have where you don't remember |
45 |
>those? Do you imply to completely avoid them? How would you get to |
46 |
>compare versions having alpha, beta, pre and rc then? Do you mean to |
47 |
>use another library to get each one's priority? Wouldn't that still |
48 |
>need to be specified in the spec? |
49 |
|
50 |
I've already told you. Explicit operator in rpm distinguishes post-version 'a' from pre-version alpha-'a'. |
51 |
|
52 |
> |
53 |
>> It's silly |
54 |
>> because those magical suffixes never match what upstreams use. |
55 |
>> And those are just a few sillinesses. |
56 |
> |
57 |
>Yeah unfortunately there could be just unlimited number of possible |
58 |
>suffixes and unlimited ways on how they could be used so the best |
59 |
>thing you could do is provide what's commonly used and just let the |
60 |
>ebuild maintainer decide how he could work around with those suffixes |
61 |
>so he could present it well on the ebuild. |
62 |
|
63 |
No. The solution is to provide a simple, universal scheme and let it express any version. |
64 |
|
65 |
> |
66 |
>>> And about pkg-config and rpm: I haven't thoroughly examined them |
67 |
>yet, |
68 |
>>> but you sure their implementation is applicable to Gentoo? It might |
69 |
>>> just turn simpler because it's more limited or strict. Gentoo |
70 |
>allows |
71 |
>>> stages, patches and revisions and uses predefined prefixes. Mine |
72 |
>>> starts on a flexible approach where "version nodes" are allowed |
73 |
>>> everywhere. |
74 |
>> |
75 |
>> Then you should have. It is appreciated when people do some |
76 |
>*research* |
77 |
>> before throwing out random ideas on areas they have almost no idea |
78 |
>of. |
79 |
> |
80 |
>It's not a random idea as it only intends to simplify the current |
81 |
>spec, not drastically change it. And it doesn't really matter for me |
82 |
>to thoroughly understand them if you only intend to completely change |
83 |
>Gentoo's packaging system to be like them. It's not my spec's concern |
84 |
>to change things that way. |
85 |
|
86 |
So you want to introduce a lot of work to introduce a minor change. Plus confuse developers even more because they'll have to remember the tiny differences between versions in EAPI 5 and 6. |
87 |
|
88 |
> |
89 |
>> And to save you some time reading: the rpm implementation is simpler |
90 |
>> and more flexible. It's free of stupidities like hardcoded suffix |
91 |
>> lists or forced component ordering. Ordering (pre/post) is expressed |
92 |
>> explicitly, and in many more cases you can avoid writing something |
93 |
>> completely different than what upstream uses. |
94 |
> |
95 |
>I'm not sure what you mean, but you sure that adding the ability to |
96 |
>expression pre/post ordering does not make the algorithm even more |
97 |
>complicated? Note that you have to consider how you'd be able to |
98 |
>compare versions against other versions. |
99 |
|
100 |
No. Having 'less than' operator is simpler than long list of rules. But you clearly aren't interested in learning what we're discussing, so I don't see a point in discussing this any further. |
101 |
|
102 |
> |
103 |
>That also sounds to me like you just have to add a _post stage with a |
104 |
>+1 value and it would be enough, rather than having a complete |
105 |
>overhaul. |
106 |
|
107 |
Again, more limitations. Because someone knows exactly what's the best version scheme and everything else needs to be bent to match it. |
108 |
|
109 |
> |
110 |
>You say that you can express ordering explicitly: I find that it's |
111 |
>just the same problem you encounter when deciding what value to give |
112 |
>on _pre when encountering word versions like trial, devel, testing, |
113 |
>etc. |
114 |
> |
115 |
>I really think adding more commonly used suffixes should be enough. |
116 |
|
117 |
Longer lists of 'common'stuff definitely are the way to make spec simpler. |
118 |
|
119 |
> |
120 |
>Btw, can you give a link on how the pre/post ordering is expressed? I |
121 |
>can't find any RPM versioning spec that describes how it's done. |
122 |
|
123 |
Look for my spec of pkg-config. I'm pretty sure I've described the algorithm used for versions there. |
124 |
|
125 |
> |
126 |
>>> If perhaps you mean to completely overhaul Gentoo's way of |
127 |
>>> implementing package versions, I don't think that would work. |
128 |
>> |
129 |
>> And is your change going to work? Because if you understood how |
130 |
>ebuilds |
131 |
>> work, you'd know you practically can't change versioning because |
132 |
>you'd |
133 |
>> immediately break compatibility between 'old' and 'new' ebuilds. |
134 |
> |
135 |
>Except that mine is unlikely to break compatibility with current |
136 |
>packages. You have issues against the very foundations of the current |
137 |
>implementation, but that's not really about my spec per se. You seem |
138 |
>to be barking at the wrong tree and I don't think that would help. |
139 |
|
140 |
It will. If you believe it doesn't, you don't understand how package managers work in Gentoo. |
141 |
|
142 |
If you change anything about version, most of silly assumptions break. Like you can't any longer depend on package using newer EAPI than yours. |
143 |
|
144 |
> |
145 |
>> This |
146 |
>> isn't something that was designed to support changes in version |
147 |
>scheme, |
148 |
>> and changing that won't be anywhere close to easy. And if we ever |
149 |
>agree |
150 |
>> on doing that, we should go for a complete and useful solution rather |
151 |
>> than some minor change with even smaller benefit. |
152 |
> |
153 |
>Unfortunately doing an overhaul may never happen unless you create |
154 |
>Gentoo 2.0 where a mirror of every package would work on it. So |
155 |
>simplifying it first (and optionally enhancing without breaking) could |
156 |
>be a good choice whether an overhaul happens later or not. |
157 |
|
158 |
-- |
159 |
Best regards, |
160 |
Michał Górny |