1 |
Dnia 2015-09-20, o godz. 16:40:16 |
2 |
konsolebox <konsolebox@×××××.com> napisał(a): |
3 |
|
4 |
> On Sat, Sep 19, 2015 at 10:54 PM, Michał Górny <mgorny@g.o> wrote: |
5 |
> > Here's my old proposal: https://bugs.gentoo.org/show_bug.cgi?id=526456 |
6 |
> > |
7 |
> > Dnia 19 września 2015 14:59:35 CEST, konsolebox <konsolebox@×××××.com> napisał(a): |
8 |
> >>On Sat, Sep 19, 2015 at 6:55 PM, Michał Górny <mgorny@g.o> |
9 |
> >>wrote: |
10 |
> >>> Dnia 19 września 2015 12:27:32 CEST, konsolebox |
11 |
> >><konsolebox@×××××.com> napisał(a): |
12 |
> >>>>On Sat, Sep 19, 2015 at 4:01 PM, Michał Górny <mgorny@g.o> |
13 |
> >>>>wrote: |
14 |
> >>> Which one is simpler: |
15 |
> >>> |
16 |
> >>> 1. _pre, _alpha, _beta, _rc... is earlier than no suffix, _p is newer |
17 |
> >>than no suffix, |
18 |
> >>> |
19 |
> >>> 2. ~ is earlier than no suffix? |
20 |
> >>> |
21 |
> >> |
22 |
> >>Ok I have to admit that no. 2 is simpler. It's less descriptive and |
23 |
> >>requires general or specific guidelines on representing common |
24 |
> >>suffixes, but it allows more flexibility. I actually had the idea |
25 |
> >>earlier of using _pre but using a symbol is more appropriate. Besides |
26 |
> >>_pre already has a position which is > _beta and < _rc. |
27 |
> >> |
28 |
> >>So what would pkg-1.4_alpha1_p20 look like if you convert it to a form |
29 |
> >>that uses ~? |
30 |
> > |
31 |
> > You shouldn't start with old gentoo version but with whatever upstream uses. The goal is that the scheme is really upstream friendly. |
32 |
> > |
33 |
> > So Python-3.5.0a2 would be 3.5.0~a2. We just add the tilde to indicate it's alpha-a and not post-version a. |
34 |
> |
35 |
> > Then, instead of full alpha/beta substitution we just strip the tilde. |
36 |
> |
37 |
> Strip the tilde? |
38 |
|
39 |
SRC_URI=".../Python-${PV/~/}.tar.xz" |
40 |
|
41 |
> |
42 |
> > So in your case, it could be 1.4~alpha1_p20, or 1.4~a1_20, or… |
43 |
> |
44 |
> Or just like my idea of using multiple nodes which is 1.4~a1.20? |
45 |
> Although I don't agree about concatenating the patch (_p) or another |
46 |
> custom suffix's value against the preceding suffix - because the |
47 |
> preceding suffix could actually have a dotted value in _alpha in which |
48 |
> case comparing the minor numbers would be ambiguous. |
49 |
> |
50 |
> >>Also what about if the package has a custom "newer than no suffix" |
51 |
> >>suffix used like pkg-1.4-sr5-p20? |
52 |
> > |
53 |
> > Well, sr would be used as letter version component but it shouldn't hurt. |
54 |
> |
55 |
> So we add `sr` as a known suffix, what about other possible suffixes? |
56 |
|
57 |
No, we don't. There are *no* known magical suffixes. 'sr' is just |
58 |
text version part, like 'a', 'b', 'c', 'za'... |
59 |
|
60 |
> The point is, how would you compare custom suffixes when you don't |
61 |
> apply definite levels to them? Which one would come before or after |
62 |
> another? And comparing lexicographically does not always apply. Would |
63 |
> everyone have to convert them to presentable values where you could |
64 |
> calculate a number or compare in lexicographical order? |
65 |
|
66 |
You can't solve every single problem. Instead, you can apply simple |
67 |
and generic rules that could work in majority of cases, and be clearly |
68 |
changed in the remaining cases. |
69 |
|
70 |
> |
71 |
> > We could even extend this to allow multiple tildes and add another symbol that evaluates as higher than any version component. |
72 |
> |
73 |
> Yes, like adding _post? |
74 |
|
75 |
No, 'post' is string which again imposes limitation on upstream naming |
76 |
of versions. Use symbols as separators are symbols already. |
77 |
|
78 |
> This really sounds like it can be solved by allowing multiple version |
79 |
> nodes on _pre and _post just like what I said earlier. |
80 |
> |
81 |
> If you want you can have symbol versions of those but it would not be |
82 |
> necessary to actually remove the existing suffixes. |
83 |
|
84 |
You really can't think flexibly, can you? You always try to hardcode |
85 |
some strings, some arbitrary limitations because someone happened to |
86 |
implement Portage like this without too much thinking years ago. |
87 |
|
88 |
-- |
89 |
Best regards, |
90 |
Michał Górny |
91 |
<http://dev.gentoo.org/~mgorny/> |