Ciaran McCreesh wrote:
On Thu, 26 Feb 2009 21:40:26 +0100
Luca Barbato <lu_z...@gentoo.org> 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.
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 1.2.live 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
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?
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.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
