List Archive: gentoo-council
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Fri, 13 Feb 2009 20:33:31 +0100
Luca Barbato <email@example.com> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 13 Feb 2009 18:20:34 +0100
> > Luca Barbato <firstname.lastname@example.org> wrote:
> >> Live template provide correct ordering since generates ebuilds
> >> with a proper version.
> > *sigh* Please stop pushing your epic fail of a non-solution until
> > you understand the issue at hand.
> go back to 4chan.
No. Really. You need to step back and think before you try to solve a
> > There is no way of using conventional version rules to accurately
> > represent scm versions across multiple version-branches. _pre does
> > not order correctly, since you don't know what the next release
> > will be, and it collides with upstream release names.
> pre works perfectly fine with snapshots.
No it doesn't. _pre1, _pre2 etc does not accurately represent how
upstream do releases.
> you cannot track separate branches/versions w/out the very same
> issues you have merging separate versions of normal packages, and
> glep54 doesn't say anything about how it should track multiple
> branches in any different way than the current version components.
Uh... There's no merging involved. And GLEP 54 solves the entire thing.
It lets you have foo-scm tracking master, foo-2.0-scm tracking the 2.0
branch and foo-1.0-scm tracking the 1.0 branch, and the ordering all
works correctly. It's the only solution anyone's come up with that gets