On Thu, 26 Feb 2009 21:40:26 +0100
Luca Barbato <lu_zero@g.o> wrote:
> >> 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

So it doesn't work Right.

> 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.

No, with -scm the order works correctly.

> >> 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.

So if you do that, how does the package manager know that one version
is less than another if a particular use flag is enabled, but greater
than it if it is disabled?

> Again it had been answered in the summary anyway.

I thought you had a better answer than "it doesn't work" that I was
just missing. Evidently not...

-- 
Ciaran McCreesh