Gentoo Archives: gentoo-council

From: Alec Warner <antarus@g.o>
To: Luca Barbato <lu_zero@g.o>
Cc: Ryan Hill <dirtyepic@g.o>, gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
Date: Wed, 11 Mar 2009 15:18:52
In Reply to: Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal by Luca Barbato
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 ( 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 > > > >