1 |
I moved the discussion on -dev since it should be the right place to |
2 |
discuss this. |
3 |
|
4 |
Ciaran McCreesh wrote: |
5 |
> On Fri, 13 Feb 2009 20:33:31 +0100 |
6 |
> Luca Barbato <lu_zero@g.o> wrote: |
7 |
>> Ciaran McCreesh wrote: |
8 |
>>> On Fri, 13 Feb 2009 18:20:34 +0100 |
9 |
>>> Luca Barbato <lu_zero@g.o> wrote: |
10 |
>>>> Live template provide correct ordering since generates ebuilds |
11 |
>>>> with a proper version. |
12 |
>>> *sigh* Please stop pushing your epic fail of a non-solution until |
13 |
>>> you understand the issue at hand. |
14 |
>> go back to 4chan. |
15 |
> |
16 |
> No. Really. You need to step back and think before you try to solve a |
17 |
> problem. |
18 |
|
19 |
I focused on one of the issues I found in the current -9999 and that |
20 |
your -scm proposal doesn't solve and that annoys me a bit. |
21 |
|
22 |
>>> There is no way of using conventional version rules to accurately |
23 |
>>> represent scm versions across multiple version-branches. _pre does |
24 |
>>> not order correctly, since you don't know what the next release |
25 |
>>> will be, and it collides with upstream release names. |
26 |
>> pre works perfectly fine with snapshots. |
27 |
> |
28 |
> No it doesn't. _pre1, _pre2 etc does not accurately represent how |
29 |
> upstream do releases. |
30 |
|
31 |
upstream is an undefined entity. We knows already upstreams that follow |
32 |
a specific version numbering, that tag their release before time and |
33 |
that even have playground branches where interesting&scary thing happen, |
34 |
upstreams that keep everything on a single branch and people doing |
35 |
something insane or worse. |
36 |
|
37 |
so NOTHING could represent something unpredictable. |
38 |
|
39 |
>> you cannot track separate branches/versions w/out the very same |
40 |
>> issues you have merging separate versions of normal packages, and |
41 |
>> glep54 doesn't say anything about how it should track multiple |
42 |
>> branches in any different way than the current version components. |
43 |
> |
44 |
> Uh... There's no merging involved. |
45 |
|
46 |
Pardon, typo, I meant emerging. |
47 |
|
48 |
> And GLEP 54 solves the entire thing. |
49 |
> It lets you have foo-scm tracking master, foo-2.0-scm tracking the 2.0 |
50 |
> branch and foo-1.0-scm tracking the 1.0 branch, and the ordering all |
51 |
> works correctly. It's the only solution anyone's come up with that gets |
52 |
> this right. |
53 |
|
54 |
That doesn't cover the "pu" case brought up by ferdy or another case in |
55 |
which you plan to track a branch that isn't a version branch or hasn't a |
56 |
version target, if you want to be strict. So scm solve the same problem |
57 |
_live solves or plain usage of "property live" within current ebuilds |
58 |
solves. |
59 |
|
60 |
In short any proposal that includes the "live property" gives you the |
61 |
same benefits. The live template proposal gives added value to the thing |
62 |
since it makes possible do more and something more useful since the |
63 |
reduced scope of interest tracking upstream has in the end. |
64 |
|
65 |
lu |
66 |
|
67 |
-- |
68 |
|
69 |
Luca Barbato |
70 |
Gentoo Council Member |
71 |
Gentoo/linux Gentoo/PPC |
72 |
http://dev.gentoo.org/~lu_zero |