List Archive: gentoo-council
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
> Attached is my comparison of the two proposals for live sources.
> Sorry about getting it out late, I had to get ahold of a number of
> people to finish writing it up.
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
[ebuild U ] sys-devel/gcc-4.4.0_pre20090310
If so, is there any way to identify that this is a live ebuild?
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?
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
If I build a live package today, will I see it as an update when
running emerge -pu @world tomorrow?
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.)
Does 'emerge =gcc-4.4.0_pre<date>' even work, or just `..._prelive`?
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
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.
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
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662