Gentoo Archives: gentoo-council

From: Alec Warner <antarus@g.o>
To: Luca Barbato <lu_zero@g.o>
Cc: Ryan Hill <dirtyepic@g.o>, gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
Date: Wed, 11 Mar 2009 15:18:52
Message-Id: b41005390903110818l37b63d7asabb3b92b0983eddf@mail.gmail.com
In Reply to: Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal by Luca Barbato
1 On Wed, Mar 11, 2009 at 2:55 AM, Luca Barbato <lu_zero@g.o> wrote:
2 > Ryan Hill wrote:
3 >>
4 >> I have some questions about the -live proposal. I'm sorry if some of
5 >> this has been answered already; I haven't had the opportunity to
6 >> follow it more closely.
7 >>
8 >> The draft (http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst) says
9 >> that "At resolution the live keyword is substituted with a timestamp in
10 >> the form of iso date". What is meant by "resolution" here? Does this
11 >> mean that, having a gcc-4.4.0_prelive ebuild, 'emerge -p gcc' would show
12 >> something like:
13 >>
14 >> [ebuild U ] sys-devel/gcc-4.4.0_pre20090310
15 >>
16 >> If so, is there any way to identify that this is a live ebuild?
17 >
18 > The ebuild itself has some embedded information so portage could/should
19 > provide something like.
20 >
21 > [ebuild U ] sys-devel/gcc-4.4.0_pre20090310 [from svn master r12345]
22
23 To perhaps be more explicit with what I think Ciaran means in his
24 comment later in the thread.
25 Your proposal seems to infer that you will generate LIVE_REVISION at
26 'resolution time' (which is still vague). That means to do
27 'resolution' I have to do expensive activities like 'figure out what
28 revision the sources are at'. This may require network access, which
29 was not previously required for -p actions.
30
31 At best I could see
32
33 [ebuild U ] sys-devel/gcc-4.4.0_pre20090310 [LIVE]
34
35 Which uses local information in the cache (PROPERTIES).
36
37 >
38 >> If I have an eclass that needs to do stuff to only live ebuilds (like
39 >> kde4-base.eclass setting SLOT=live when PV is 9999), how can I
40 >> differentiate between live ebuilds and snapshots? Do eclasses see
41 >> -live or the expanded datestamp in PV?
42 >
43 > it see the expanded datestamp but sees also LIVE_URI LIVE_REVISION
44 > LIVE_BRANCH (the variables that keep track of the exact revision of the
45 > sources you are going to use), so you can also slot by branch
46 >
47 > SLOT=${LIVE_BRANCH}
48 >
49 >> How do I know if a user has a live ebuild installed when they file a
50 >> bug without having to check if there's a snapshot with that date in the
51 >> tree every single time the PV has a datestamp in it? (minor gripe
52 >> admittedly)
53 >
54 > He will provide the revision and branch so you have more information not
55 > less.
56 >
57 >> If I build a live package today, will I see it as an update when
58 >> running emerge -pu @world tomorrow?
59 >
60 > the template will be evaluated again so you get another snapshot proposed
61 > for update.
62 >
63 >> If I have 20090309 installed what does 'emerge =gcc-4.4.0_pre20090309'
64 >> do tomorrow? (It might be a neat trick to disable fetch and just
65 >> rebuild the current checkout in this case.)
66 >
67 > it will try to build the exact revision it used by the time you issued the
68 > previous emerge.
69 >
70 >> Does 'emerge =gcc-4.4.0_pre<date>' even work, or just `..._prelive`?
71 >
72 > =gcc-4.4.0_pre<date> will try to reinstall what you installed by <date>
73 >
74 > =gcc-4.4.0_prelive will get resolved out of the template and then installed
75 > as =gcc-4.4.0_pre<now>
76 >
77 >> Does the user at any point ever see "live" in the ebuild version or is
78 >> it always replaced by the date? If the latter, how do users know they
79 >> have to put '=sys-devel/gcc-4.4.0_prelive' in package.* and not
80 >> pre<date>?
81 >
82 > the user will get the version render but also from where it is
83 >
84 >> Are there any facilities to allow a user to checkout a specific
85 >> revision from the repo, or is that beyond the scope of this GLEP? If
86 >> we ever do implement such a thing, it seems like the datestamp approach
87 >> wouldn't mesh well; 20090310 doesn't make much sense when the
88 >> revision is from a month ago.
89 >
90 > if you want to checkout a specific revision from the repo you aren't
91 > creating a live ebuild but a snapshot with a specific src uri.
92 >
93 > so you don't use a template but just the specific eclasses and mark the
94 > ebuild so you can show up on emerge -p the informations as stated above.
95 >
96 >> I'll be honest, I much prefer the -scm proposal. But I want to
97 >> make sure I'm not completely out-to-lunch about -live before
98 >> making judgements.
99 >
100 > At least now we have some more scenarios we could consider as use-cases.
101 >
102 > Thank you for the input
103 >
104 > lu
105 >
106 > --
107 >
108 > Luca Barbato
109 > Gentoo Council Member
110 > Gentoo/linux Gentoo/PPC
111 > http://dev.gentoo.org/~lu_zero
112 >
113 >
114 >