I moved the discussion on -dev since it should be the right place to
discuss this.
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 20:33:31 +0100
Luca Barbato <lu_z...@gentoo.org> wrote:
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 18:20:34 +0100
Luca Barbato <lu_z...@gentoo.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
problem.
I focused on one of the issues I found in the current -9999 and that
your -scm proposal doesn't solve and that annoys me a bit.
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.
upstream is an undefined entity. We knows already upstreams that follow
a specific version numbering, that tag their release before time and
that even have playground branches where interesting&scary thing happen,
upstreams that keep everything on a single branch and people doing
something insane or worse.
so NOTHING could represent something unpredictable.
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.
Pardon, typo, I meant emerging.
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.
That doesn't cover the "pu" case brought up by ferdy or another case in
which you plan to track a branch that isn't a version branch or hasn't a
version target, if you want to be strict. So scm solve the same problem
_live solves or plain usage of "property live" within current ebuilds
solves.
In short any proposal that includes the "live property" gives you the
same benefits. The live template proposal gives added value to the thing
since it makes possible do more and something more useful since the
reduced scope of interest tracking upstream has in the end.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
