From: Ryan Hill <dirtyepic@gentoo.org>
To: gentoo-council@gentoo.org
Subject: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
Date: Tue, 10 Mar 2009 23:42:31 -0600 [thread overview]
Message-ID: <20090310234231.3e664575@halo.dirtyepic.sk.ca> (raw)
[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]
> Hi,
>
> 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.
>
> Cheers,
> Thomas
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?
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
admittedly)
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
pre<date>?
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
making judgements.
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next reply other threads:[~2009-03-11 5:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-11 5:42 Ryan Hill [this message]
2009-03-11 9:55 ` [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal Luca Barbato
2009-03-11 14:13 ` Ciaran McCreesh
2009-03-11 15:20 ` Luca Barbato
2009-03-11 15:44 ` Ciaran McCreesh
2009-03-11 16:12 ` Luca Barbato
2009-03-11 15:18 ` Alec Warner
2009-03-12 3:55 ` Ryan Hill
2009-03-12 13:56 ` Luca Barbato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090310234231.3e664575@halo.dirtyepic.sk.ca \
--to=dirtyepic@gentoo.org \
--cc=gentoo-council@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox