* [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
@ 2009-03-11 5:42 Ryan Hill
2009-03-11 9:55 ` Luca Barbato
0 siblings, 1 reply; 9+ messages in thread
From: Ryan Hill @ 2009-03-11 5:42 UTC (permalink / raw
To: gentoo-council
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
2009-03-11 5:42 [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal Ryan Hill
@ 2009-03-11 9:55 ` Luca Barbato
2009-03-11 14:13 ` Ciaran McCreesh
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Luca Barbato @ 2009-03-11 9:55 UTC (permalink / raw
To: Ryan Hill; +Cc: gentoo-council
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
2009-03-11 9:55 ` Luca Barbato
@ 2009-03-11 14:13 ` Ciaran McCreesh
2009-03-11 15:20 ` Luca Barbato
2009-03-11 15:18 ` Alec Warner
2009-03-12 3:55 ` Ryan Hill
2 siblings, 1 reply; 9+ messages in thread
From: Ciaran McCreesh @ 2009-03-11 14:13 UTC (permalink / raw
To: gentoo-council
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
On Wed, 11 Mar 2009 10:55:52 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> 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]
That claim right there is enough to show that you haven't thought about
this at all. Your proposal is lots of handwaving magic, most of it
unimplementable. I suggest you put together a reference implementation
before promoting this idea any further.
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
2009-03-11 9:55 ` Luca Barbato
2009-03-11 14:13 ` Ciaran McCreesh
@ 2009-03-11 15:18 ` Alec Warner
2009-03-12 3:55 ` Ryan Hill
2 siblings, 0 replies; 9+ messages in thread
From: Alec Warner @ 2009-03-11 15:18 UTC (permalink / raw
To: Luca Barbato; +Cc: Ryan Hill, gentoo-council
On Wed, Mar 11, 2009 at 2:55 AM, Luca Barbato <lu_zero@gentoo.org> 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
>
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
2009-03-11 14:13 ` Ciaran McCreesh
@ 2009-03-11 15:20 ` Luca Barbato
2009-03-11 15:44 ` Ciaran McCreesh
0 siblings, 1 reply; 9+ messages in thread
From: Luca Barbato @ 2009-03-11 15:20 UTC (permalink / raw
To: Ciaran McCreesh; +Cc: gentoo-council
Ciaran McCreesh wrote:
> On Wed, 11 Mar 2009 10:55:52 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> 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]
>
> That claim right there is enough to show that you haven't thought about
> this at all. Your proposal is lots of handwaving magic, most of it
> unimplementable. I suggest you put together a reference implementation
> before promoting this idea any further.
What's wrong is U that should be R beside that there isn't much magic...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
2009-03-11 15:20 ` Luca Barbato
@ 2009-03-11 15:44 ` Ciaran McCreesh
2009-03-11 16:12 ` Luca Barbato
0 siblings, 1 reply; 9+ messages in thread
From: Ciaran McCreesh @ 2009-03-11 15:44 UTC (permalink / raw
To: Luca Barbato; +Cc: gentoo-council
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
On Wed, 11 Mar 2009 16:20:25 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> >> [ebuild U ] sys-devel/gcc-4.4.0_pre20090310 [from svn master
> >> r12345]
> >
> > That claim right there is enough to show that you haven't thought
> > about this at all. Your proposal is lots of handwaving magic, most
> > of it unimplementable. I suggest you put together a reference
> > implementation before promoting this idea any further.
>
> What's wrong is U that should be R beside that there isn't much
> magic...
The U isn't the problem. The svn revision is the problem. You need to
consider how the package manager would get the revision.
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
2009-03-11 15:44 ` Ciaran McCreesh
@ 2009-03-11 16:12 ` Luca Barbato
0 siblings, 0 replies; 9+ messages in thread
From: Luca Barbato @ 2009-03-11 16:12 UTC (permalink / raw
To: Ciaran McCreesh; +Cc: gentoo-council
Ciaran McCreesh wrote:
> On Wed, 11 Mar 2009 16:20:25 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>>>> [ebuild U ] sys-devel/gcc-4.4.0_pre20090310 [from svn master
>>>> r12345]
>>> That claim right there is enough to show that you haven't thought
>>> about this at all. Your proposal is lots of handwaving magic, most
>>> of it unimplementable. I suggest you put together a reference
>>> implementation before promoting this idea any further.
>> What's wrong is U that should be R beside that there isn't much
>> magic...
>
> The U isn't the problem. The svn revision is the problem. You need to
> consider how the package manager would get the revision.
>
I know, if you are re emerging you have those information, if you are
updating you won't have them. That's why either the U or the revision
information is wrong.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
^ permalink raw reply [flat|nested] 9+ messages in thread
* [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
2009-03-11 9:55 ` Luca Barbato
2009-03-11 14:13 ` Ciaran McCreesh
2009-03-11 15:18 ` Alec Warner
@ 2009-03-12 3:55 ` Ryan Hill
2009-03-12 13:56 ` Luca Barbato
2 siblings, 1 reply; 9+ messages in thread
From: Ryan Hill @ 2009-03-12 3:55 UTC (permalink / raw
To: gentoo-council
[-- Attachment #1: Type: text/plain, Size: 8515 bytes --]
On Wed, 11 Mar 2009 10:55:52 +0100
Luca Barbato <lu_zero@gentoo.org> 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]
As you said in another mail, this could only be shown for a rebuild,
but not an update, true?
>
> > 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}
Yeah, immediately after posting I remembered there would be certain
variables present. Even if they weren't you could just stick a
LIVE="yes" in the live ebuilds or check PROPERTIES or whatever.
> > 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.
Ooh, i really don't like that. This would force me to either do daily
updates manually package by package or mask any live ebuilds before i
do. That would _really_ suck if I were still running the kde-crazy
overlay and had 50+ live ebuilds installed.
> > 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.
Cool.
> > 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>
Will a list of date -> revision mappings be kept? Where is this info
stored?
> =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 was thinking about dynamic revisions, where the user could do
something like 'emerge -av gcc --rev 123456'. I just checked a couple
eclasses and it seems we already have this feature, for example
ESVN_REVISION in subversion.eclass, so let's abandon this train of
thought. ;)
> > 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
Thanks for your answers. I'd like to think about it a bit, but off the
top of my head what would you say to a hybrid approach where the ebuild
doesn't have the datestamp expansion on resolution, but rather this
information were available after building? In all cases, the ebuild
would be referred to by its proper name (ie. gcc-4.4.0_pre.live), but
enough information would be recorded at build time so the package
manager could do groovy things like
[ebuild U ] sys-devel/gcc-4.4.0_pre.live (last built 20090310 - rev.
14991) USE="use -flags"
and
# emerge --info gcc
sys-devel/gcc-4.4.0_pre9999 was built with the following:
CFLAGS="-O2 -march=core2 -pipe"
CXXFLAGS="-O2 -march=core2 -pipe"
>>> Attempting to run pkg_info() for 'sys-devel/gcc-4.4.0_pre9999'
svn: 20081206 23:31:22 - gcc-4.3.3_pre9999:4.3-svn was merged at revision 142535
svn: 20090123 17:09:12 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 143592
svn: 20090131 16:35:23 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 143833
svn: 20090131 17:05:29 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 143834
svn: 20090223 00:33:50 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144379
svn: 20090226 22:10:09 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144460
svn: 20090226 23:00:57 - gcc-4.3.3_pre9999:4.3-svn was merged at revision 144460
svn: 20090304 20:16:48 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144634
svn: 20090307 15:12:27 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144702
(note the latter is already possible with zero modifications to anything)
It seems to me that the datestamp expansion is a lot of complication
for very little gain.
Looking at the list of shortcomings in the draft:
> There are many obvious and non obvious shortcomings in this
> situations:
> - you have to hand produce "high enough" version values and be sure
> they do not clash (e.g. 2.3_pre9999 live ebuild being shadowed by
> 2.3_pre20050201 snapshot).
Solved by both this and the -scm GLEP.
> - you cannot track what did you install since you don't have a precise
> information about it, emerge logs will just provide you the build
> date.
Most SCM eclasses have facilities for storing this data, eg. ESVN_LOG_DIR.
Standardizing it could be helpful.
> - you cannot do exact reemerges and that may break revdep-rebuild
You can use eclass features that skip the updating phase and just build the
current sources (eg. ESVN_OFFLINE). And as I mentioned above, some can
build a specific revision.
> - the package manager isn't aware of the "liveness" condition.
Solved by both this and the -scm GLEP.
> - in order to refresh/update the installed package automatically you
> need either to rely on script or on sets hand produced or
> heuristically defined (e.g "all ebuilds that inherit eclass svn go in
> svn set").
Do people really want live ebuilds updating automatically? It sounds
like a recipe for breakage. I don't want live sources updating until
i explicitly tell them to, but maybe that's just me. If someone does
want this behaviour, I'd suggest using cron. Also, doesn't portage have
a @live-rebuild set that makes this trivial?
> - since you fetch on unpack phase you cannot use emerge --fetch
> consistently.
How does either proposal address this?
In the end, I don't see anything that datename expansion does that
can't be done more easily and less confusingly with other techniques.
Is there a specific problem it solves that can't be addressed through
other means?
--
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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
2009-03-12 3:55 ` Ryan Hill
@ 2009-03-12 13:56 ` Luca Barbato
0 siblings, 0 replies; 9+ messages in thread
From: Luca Barbato @ 2009-03-12 13:56 UTC (permalink / raw
To: Ryan Hill; +Cc: gentoo-council
Ryan Hill wrote:
> On Wed, 11 Mar 2009 10:55:52 +0100
> Luca Barbato <lu_zero@gentoo.org> 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]
>
> As you said in another mail, this could only be shown for a rebuild,
> but not an update, true?
on update you'd have the ref to the live template as in
[ebuild U ] sys-devel/gcc-4.4.0_prelive
Having src_fetch trigged by pretend is wrong.
>>> 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}
>
> Yeah, immediately after posting I remembered there would be certain
> variables present. Even if they weren't you could just stick a
> LIVE="yes" in the live ebuilds or check PROPERTIES or whatever.
Yes
>>> 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.
>
> Ooh, i really don't like that. This would force me to either do daily
> updates manually package by package or mask any live ebuilds before i
> do. That would _really_ suck if I were still running the kde-crazy
> overlay and had 50+ live ebuilds installed.
Well the alternative is to have the installed live templates reside in
@live.
>>> 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.
>
> Cool.
>
>>> 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>
>
> Will a list of date -> revision mappings be kept? Where is this info
> stored?
the same way USE or SLOT variables are stored.
>
>> =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 was thinking about dynamic revisions, where the user could do
> something like 'emerge -av gcc --rev 123456'. I just checked a couple
> eclasses and it seems we already have this feature, for example
> ESVN_REVISION in subversion.eclass, so let's abandon this train of
> thought. ;)
Could be interesting adding it later, it would depend in a standard
interface for live eclasses as well.
> Thanks for your answers. I'd like to think about it a bit, but off the
> top of my head what would you say to a hybrid approach where the ebuild
> doesn't have the datestamp expansion on resolution, but rather this
> information were available after building? In all cases, the ebuild
> would be referred to by its proper name (ie. gcc-4.4.0_pre.live), but
> enough information would be recorded at build time so the package
> manager could do groovy things like
>
> [ebuild U ] sys-devel/gcc-4.4.0_pre.live (last built 20090310 - rev.
> 14991) USE="use -flags"
>
> and
>
> # emerge --info gcc
>
> sys-devel/gcc-4.4.0_pre9999 was built with the following:
> CFLAGS="-O2 -march=core2 -pipe"
> CXXFLAGS="-O2 -march=core2 -pipe"
>
>>>> Attempting to run pkg_info() for 'sys-devel/gcc-4.4.0_pre9999'
>
> svn: 20081206 23:31:22 - gcc-4.3.3_pre9999:4.3-svn was merged at revision 142535
> svn: 20090123 17:09:12 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 143592
> svn: 20090131 16:35:23 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 143833
> svn: 20090131 17:05:29 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 143834
> svn: 20090223 00:33:50 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144379
> svn: 20090226 22:10:09 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144460
> svn: 20090226 23:00:57 - gcc-4.3.3_pre9999:4.3-svn was merged at revision 144460
> svn: 20090304 20:16:48 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144634
> svn: 20090307 15:12:27 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144702
>
> (note the latter is already possible with zero modifications to anything)
>
> It seems to me that the datestamp expansion is a lot of complication
> for very little gain.
There is some gain, still probably we could start implementing the rest
first and then decide later about that detail.
>> - you cannot do exact reemerges and that may break revdep-rebuild
>
> You can use eclass features that skip the updating phase and just build the
> current sources (eg. ESVN_OFFLINE). And as I mentioned above, some can
> build a specific revision.
That would work only if you aren't keeping different slots, looks like
standardizing eclasses and having portage exporting those data is
getting something we could consider alone. That gets problematic with
multislot we either have to rely on templates or try to support better
multislot otherwise.
>> - the package manager isn't aware of the "liveness" condition.
>
> Solved by both this and the -scm GLEP.
>
>> - in order to refresh/update the installed package automatically you
>> need either to rely on script or on sets hand produced or
>> heuristically defined (e.g "all ebuilds that inherit eclass svn go in
>> svn set").
>
> Do people really want live ebuilds updating automatically? It sounds
> like a recipe for breakage. I don't want live sources updating until
> i explicitly tell them to, but maybe that's just me. If someone does
> want this behaviour, I'd suggest using cron. Also, doesn't portage have
> a @live-rebuild set that makes this trivial?
Sure, that is a point that need to be considered thoroughly. I think
everybody agrees that the default behavior should be conservative.
>> - since you fetch on unpack phase you cannot use emerge --fetch
>> consistently.
>
> How does either proposal address this?
>
> In the end, I don't see anything that datename expansion does that
> can't be done more easily and less confusingly with other techniques.
The proposal requires src_fetch implemented so emerge -f will work as
expected about fetching the sources, then you can either rely on
variable/custom command or on the template generation to have portage
pick it. So, yes, you can do it in other ways, both have to be
implemented somehow.
> Is there a specific problem it solves that can't be addressed through
> other means?
The templating part alone is useful to get snapshot and binpkg easily,
having pkg-scm or pkg-9999 isn't as descriptive as pkg-${a definite time}.
Thank you again for the ideas and proposals =)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-03-12 13:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-11 5:42 [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal Ryan Hill
2009-03-11 9:55 ` 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox