Ryan Hill wrote:
> I have some questions about the -live proposal.  I'm sorry if some of
> this has been answered already; I haven't had the opportunity to
> follow it more closely.
> 
> The draft (http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst) says
> that "At resolution the live keyword is substituted with a timestamp in
> the form of iso date".  What is meant by "resolution" here?  Does this
> mean that, having a gcc-4.4.0_prelive ebuild, 'emerge -p gcc' would show
> something like:
> 
> [ebuild     U ] sys-devel/gcc-4.4.0_pre20090310
> 
> If so, is there any way to identify that this is a live ebuild?

The ebuild itself has some embedded information so portage could/should 
provide something like.

[ebuild     U ] sys-devel/gcc-4.4.0_pre20090310 [from svn master r12345]

> If I have an eclass that needs to do stuff to only live ebuilds (like
> kde4-base.eclass setting SLOT=live when PV is 9999), how can I
> differentiate between live ebuilds and snapshots?  Do eclasses see
> -live or the expanded datestamp in PV?

it see the expanded datestamp but sees also LIVE_URI LIVE_REVISION 
LIVE_BRANCH (the variables that keep track of the exact revision of the 
sources you are going to use), so you can also slot by branch

SLOT=${LIVE_BRANCH}

> How do I know if a user has a live ebuild installed when they file a
> bug without having to check if there's a snapshot with that date in the
> tree every single time the PV has a datestamp in it?  (minor gripe
> admittedly)

He will provide the revision and branch so you have more information not 
less.

> If I build a live package today, will I see it as an update when
> running emerge -pu @world tomorrow?

the template will be evaluated again so you get another snapshot 
proposed for update.

> If I have 20090309 installed what does 'emerge =gcc-4.4.0_pre20090309'
> do tomorrow?  (It might be a neat trick to disable fetch and just
> rebuild the current checkout in this case.)

it will try to build the exact revision it used by the time you issued 
the previous emerge.

> Does 'emerge =gcc-4.4.0_pre<date>' even work, or just `..._prelive`?

=gcc-4.4.0_pre<date> will try to reinstall what you installed by <date>

=gcc-4.4.0_prelive will get resolved out of the template and then 
installed as =gcc-4.4.0_pre<now>

> Does the user at any point ever see "live" in the ebuild version or is
> it always replaced by the date?  If the latter, how do users know they
> have to put '=sys-devel/gcc-4.4.0_prelive' in package.* and not
> pre<date>?

the user will get the version render but also from where it is

> Are there any facilities to allow a user to checkout a specific
> revision from the repo, or is that beyond the scope of this GLEP?  If
> we ever do implement such a thing, it seems like the datestamp approach
> wouldn't mesh well; 20090310 doesn't make much sense when the
> revision is from a month ago.

if you want to checkout a specific revision from the repo you aren't 
creating a live ebuild but a snapshot with a specific src uri.

so you don't use a template but just the specific eclasses and mark the 
ebuild so you can show up on emerge -p the informations as stated above.

> I'll be honest, I much prefer the -scm proposal.  But I want to
> make sure I'm not completely out-to-lunch about -live before
> making judgements.

At least now we have some more scenarios we could consider as use-cases.

Thank you for the input

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero