Regarding live sources management proposals (Was: [gentoo-dev] Gentoo Council Reminder for February 26)

[Luca Barbato <lu_zero@gentoo.org>]

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