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