[gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09

[Luca Barbato <lu_zero@gentoo.org>]

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_zero@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> On Fri, 13 Feb 2009 18:20:34 +0100
>>> Luca Barbato <lu_zero@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