Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Luca Barbato <lu_zero@gentoo.org>]

Ciaran McCreesh wrote:
> On Thu, 26 Feb 2009 20:34:07 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
> I'm still waiting for you to answer this:
> 
>> Be specific. Explain how this works when, say, 0.34.4 is current, you
>> have a 0.34.5_live and 0.34.5 comes out.

being live working as substitute for 0.34.5_preN (_live) component the 
appearance of 0.34.5 will be higher than those. If we consider the .live 
alternative you'd have 0.34.live that is shadowed only by 0.35.x

That is pretty much the same you get with -scm, what happens is that in 
the case of live template you have portage installing 0.34.5_preN with 
revision informations and adding the template to the "live" set.

This way you can either emerge =0.34.5_preN or emerge @live depending on 
your needs. And you know that what you have installed since the 
information is available.

I replied in the summary but I guess I had been overly implicit =\

> and this:
> 
>> How do I track an upstream who has a 0.34 branch (which is equal to or
>> ahead of the most recent 0.34.x release), a 0.36 branch (which is
>> equal to or ahead of the most recent 0.36.x release) and a master
>> branch (which is ahead of any release) using the live property?

the live property doesn't tell much about versioning
so you could use 9999 as the "x" version component or .live or -scm,
the live property just makes portage aware that the sources are live.

This situation is one in those pkg-scm and pkg.live work better, but 
just for one branch.

As you said you could address the problem using useflags, so you could 
by extension you can use the same way to address the single case in 
proposals not supporting the tip of a single non version branch as well:

have the all the ebuilds in a package having IUSE=-live that if enabled 
triggers the live property and changes the src_uri to the live branch 
you desire.

Not exactly the nicest thing but having portage highlighting the case of 
live ebuilds on -p would maybe partially address it.

Again it had been answered in the summary anyway.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero