Gentoo Archives: gentoo-council

From: Luca Barbato <lu_zero@g.o>
To: Ryan Hill <dirtyepic@g.o>
Cc: gentoo-council@g.o
Subject: Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
Date: Wed, 11 Mar 2009 09:55:59
Message-Id: 49B78AA8.4000101@gentoo.org
In Reply to: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal by Ryan Hill
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

Replies