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 |
> |