Gentoo Archives: gentoo-dev

From: Luca Barbato <lu_zero@g.o>
To: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
Cc: gentoo-dev@l.g.o
Subject: [gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09
Date: Fri, 13 Feb 2009 20:29:39
Message-Id: 4995D82C.9080107@gentoo.org
1 I moved the discussion on -dev since it should be the right place to
2 discuss this.
3
4 Ciaran McCreesh wrote:
5 > On Fri, 13 Feb 2009 20:33:31 +0100
6 > Luca Barbato <lu_zero@g.o> wrote:
7 >> Ciaran McCreesh wrote:
8 >>> On Fri, 13 Feb 2009 18:20:34 +0100
9 >>> Luca Barbato <lu_zero@g.o> wrote:
10 >>>> Live template provide correct ordering since generates ebuilds
11 >>>> with a proper version.
12 >>> *sigh* Please stop pushing your epic fail of a non-solution until
13 >>> you understand the issue at hand.
14 >> go back to 4chan.
15 >
16 > No. Really. You need to step back and think before you try to solve a
17 > problem.
18
19 I focused on one of the issues I found in the current -9999 and that
20 your -scm proposal doesn't solve and that annoys me a bit.
21
22 >>> There is no way of using conventional version rules to accurately
23 >>> represent scm versions across multiple version-branches. _pre does
24 >>> not order correctly, since you don't know what the next release
25 >>> will be, and it collides with upstream release names.
26 >> pre works perfectly fine with snapshots.
27 >
28 > No it doesn't. _pre1, _pre2 etc does not accurately represent how
29 > upstream do releases.
30
31 upstream is an undefined entity. We knows already upstreams that follow
32 a specific version numbering, that tag their release before time and
33 that even have playground branches where interesting&scary thing happen,
34 upstreams that keep everything on a single branch and people doing
35 something insane or worse.
36
37 so NOTHING could represent something unpredictable.
38
39 >> you cannot track separate branches/versions w/out the very same
40 >> issues you have merging separate versions of normal packages, and
41 >> glep54 doesn't say anything about how it should track multiple
42 >> branches in any different way than the current version components.
43 >
44 > Uh... There's no merging involved.
45
46 Pardon, typo, I meant emerging.
47
48 > And GLEP 54 solves the entire thing.
49 > It lets you have foo-scm tracking master, foo-2.0-scm tracking the 2.0
50 > branch and foo-1.0-scm tracking the 1.0 branch, and the ordering all
51 > works correctly. It's the only solution anyone's come up with that gets
52 > this right.
53
54 That doesn't cover the "pu" case brought up by ferdy or another case in
55 which you plan to track a branch that isn't a version branch or hasn't a
56 version target, if you want to be strict. So scm solve the same problem
57 _live solves or plain usage of "property live" within current ebuilds
58 solves.
59
60 In short any proposal that includes the "live property" gives you the
61 same benefits. The live template proposal gives added value to the thing
62 since it makes possible do more and something more useful since the
63 reduced scope of interest tracking upstream has in the end.
64
65 lu
66
67 --
68
69 Luca Barbato
70 Gentoo Council Member
71 Gentoo/linux Gentoo/PPC
72 http://dev.gentoo.org/~lu_zero

Replies