1 |
> Hi, |
2 |
> |
3 |
> Attached is my comparison of the two proposals for live sources. |
4 |
> Sorry about getting it out late, I had to get ahold of a number of |
5 |
> people to finish writing it up. |
6 |
> |
7 |
> Cheers, |
8 |
> Thomas |
9 |
|
10 |
I have some questions about the -live proposal. I'm sorry if some of |
11 |
this has been answered already; I haven't had the opportunity to |
12 |
follow it more closely. |
13 |
|
14 |
The draft (http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst) says |
15 |
that "At resolution the live keyword is substituted with a timestamp in |
16 |
the form of iso date". What is meant by "resolution" here? Does this |
17 |
mean that, having a gcc-4.4.0_prelive ebuild, 'emerge -p gcc' would show |
18 |
something like: |
19 |
|
20 |
[ebuild U ] sys-devel/gcc-4.4.0_pre20090310 |
21 |
|
22 |
If so, is there any way to identify that this is a live ebuild? |
23 |
|
24 |
If I have an eclass that needs to do stuff to only live ebuilds (like |
25 |
kde4-base.eclass setting SLOT=live when PV is 9999), how can I |
26 |
differentiate between live ebuilds and snapshots? Do eclasses see |
27 |
-live or the expanded datestamp in PV? |
28 |
|
29 |
How do I know if a user has a live ebuild installed when they file a |
30 |
bug without having to check if there's a snapshot with that date in the |
31 |
tree every single time the PV has a datestamp in it? (minor gripe |
32 |
admittedly) |
33 |
|
34 |
If I build a live package today, will I see it as an update when |
35 |
running emerge -pu @world tomorrow? |
36 |
|
37 |
If I have 20090309 installed what does 'emerge =gcc-4.4.0_pre20090309' |
38 |
do tomorrow? (It might be a neat trick to disable fetch and just |
39 |
rebuild the current checkout in this case.) |
40 |
|
41 |
Does 'emerge =gcc-4.4.0_pre<date>' even work, or just `..._prelive`? |
42 |
|
43 |
Does the user at any point ever see "live" in the ebuild version or is |
44 |
it always replaced by the date? If the latter, how do users know they |
45 |
have to put '=sys-devel/gcc-4.4.0_prelive' in package.* and not |
46 |
pre<date>? |
47 |
|
48 |
Are there any facilities to allow a user to checkout a specific |
49 |
revision from the repo, or is that beyond the scope of this GLEP? If |
50 |
we ever do implement such a thing, it seems like the datestamp approach |
51 |
wouldn't mesh well; 20090310 doesn't make much sense when the |
52 |
revision is from a month ago. |
53 |
|
54 |
I'll be honest, I much prefer the -scm proposal. But I want to |
55 |
make sure I'm not completely out-to-lunch about -live before |
56 |
making judgements. |
57 |
|
58 |
|
59 |
-- |
60 |
gcc-porting, by design, by neglect |
61 |
treecleaner, for a fact or just for effect |
62 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |