| 1 |
On Fri, 13 Feb 2009 20:33:31 +0100 |
| 2 |
Luca Barbato <lu_zero@g.o> wrote: |
| 3 |
> Ciaran McCreesh wrote: |
| 4 |
> > On Fri, 13 Feb 2009 18:20:34 +0100 |
| 5 |
> > Luca Barbato <lu_zero@g.o> wrote: |
| 6 |
> >> Live template provide correct ordering since generates ebuilds |
| 7 |
> >> with a proper version. |
| 8 |
> > |
| 9 |
> > *sigh* Please stop pushing your epic fail of a non-solution until |
| 10 |
> > you understand the issue at hand. |
| 11 |
> |
| 12 |
> go back to 4chan. |
| 13 |
|
| 14 |
No. Really. You need to step back and think before you try to solve a |
| 15 |
problem. |
| 16 |
|
| 17 |
> > There is no way of using conventional version rules to accurately |
| 18 |
> > represent scm versions across multiple version-branches. _pre does |
| 19 |
> > not order correctly, since you don't know what the next release |
| 20 |
> > will be, and it collides with upstream release names. |
| 21 |
> |
| 22 |
> pre works perfectly fine with snapshots. |
| 23 |
|
| 24 |
No it doesn't. _pre1, _pre2 etc does not accurately represent how |
| 25 |
upstream do releases. |
| 26 |
|
| 27 |
> you cannot track separate branches/versions w/out the very same |
| 28 |
> issues you have merging separate versions of normal packages, and |
| 29 |
> glep54 doesn't say anything about how it should track multiple |
| 30 |
> branches in any different way than the current version components. |
| 31 |
|
| 32 |
Uh... There's no merging involved. And GLEP 54 solves the entire thing. |
| 33 |
It lets you have foo-scm tracking master, foo-2.0-scm tracking the 2.0 |
| 34 |
branch and foo-1.0-scm tracking the 1.0 branch, and the ordering all |
| 35 |
works correctly. It's the only solution anyone's come up with that gets |
| 36 |
this right. |
| 37 |
|
| 38 |
-- |
| 39 |
Ciaran McCreesh |
Archives