* [gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09
[not found] ` <20090213194141.24d44a37@snowcone>
@ 2009-02-13 20:29 99% ` Luca Barbato
0 siblings, 0 replies; 1+ results
From: Luca Barbato @ 2009-02-13 20:29 UTC (permalink / raw
To: Ciaran McCreesh; +Cc: gentoo-dev
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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <20090212214925.GA21532@dodo.hsd1.nj.comcast.net>
[not found] ` <20090213155445.GA31550@dodo.hsd1.nj.comcast.net>
[not found] ` <4995ABE2.4000907@gentoo.org>
[not found] ` <20090213172725.34258824@snowcone>
[not found] ` <4995CB0B.80209@gentoo.org>
[not found] ` <20090213194141.24d44a37@snowcone>
2009-02-13 20:29 99% ` [gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09 Luca Barbato
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox