Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-council
Navigation:
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: Luca Barbato <lu_zero@g.o>
From: Alec Warner <antarus@g.o>
Subject: Re: Re: Comparison of GLEP 54 and 'live ebuild' proposal
Date: Wed, 11 Mar 2009 08:18:43 -0700
On Wed, Mar 11, 2009 at 2:55 AM, Luca Barbato <lu_zero@g.o> wrote:
> 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]

To perhaps be more explicit with what I think Ciaran means in his
comment later in the thread.
Your proposal seems to infer that you will generate LIVE_REVISION at
'resolution time' (which is still vague).  That means to do
'resolution' I have to do expensive activities like 'figure out what
revision the sources are at'.  This may require network access, which
was not previously required for -p actions.

At best I could see

[ebuild     U ] sys-devel/gcc-4.4.0_pre20090310 [LIVE]

Which uses local information in the cache (PROPERTIES).

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


References:
Re: Comparison of GLEP 54 and 'live ebuild' proposal
-- Ryan Hill
Re: Re: Comparison of GLEP 54 and 'live ebuild' proposal
-- Luca Barbato
Navigation:
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: Comparison of GLEP 54 and 'live ebuild' proposal
Next by thread:
Re: Comparison of GLEP 54 and 'live ebuild' proposal
Previous by date:
Re: Re: Comparison of GLEP 54 and 'live ebuild' proposal
Next by date:
Re: Re: Comparison of GLEP 54 and 'live ebuild' proposal


Updated Jun 17, 2009

Summary: Archive of the gentoo-council mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.