Ciaran McCreesh wrote:
On Thu, 26 Feb 2009 21:40:26 +0100
Luca Barbato <> 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 that is shadowed only by

So it doesn't work Right.

I'd like to have more details on this point since it works the very same -scm does: the version component substituted gets higher than any other value when is resolved.

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.

"works correctly"

You are always not stating what correctly is in your opinion or why other solutions are broken.

In my opinion is correct to mark a version component as it will be the higher within that boundary, so means 1.2.x when x is the highest value, no matter which are the others at that time. Using a timestamp to replace x is the simplest way to grant this property.

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

The same argument is valid about the case of more than one tip branch you'd like to follow, how pkg-scm[master] is higher than pkg-scm[pu]?

With property live you just know that it was from a live sources, so you can consider it always new when it comes to resolve it and that pretty much gives you the same behavior you get out -scm as is detailed in the glep-54

With live template you know when you installed it and what you installed so you can re-emerge or update depending on what you want and you get at least the timestamp giving some more information.

If you throw in the mix SLOT alteration depending on or not on useflags or timestamps then you may also archive the property of having multiple version installed within any proposed framework. (e.g SLOT="$branch")

Still this is something could enjoy some more discussion.

As I stated long ago the main issue with the glep you proposed are the lack of informations in the document. You can fill every detail in mailing list as you like but if the document remains this way it doesn't get more informative.



Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC

Reply via email to