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