Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: Luca Barbato <lu_zero@g.o>
Cc: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Council log and summary for meeting on 02/12/09
Date: Fri, 13 Feb 2009 19:43:06
Message-Id: 20090213194141.24d44a37@snowcone
In Reply to: Re: [gentoo-council] Council log and summary for meeting on 02/12/09 by Luca Barbato
On Fri, 13 Feb 2009 20:33:31 +0100
Luca Barbato <lu_zero@g.o> wrote:
> Ciaran McCreesh wrote: > > On Fri, 13 Feb 2009 18:20:34 +0100 > > Luca Barbato <lu_zero@g.o> 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 problem.
> > 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 this right. -- Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature