Thomas Anderson wrote:
> On Tue, Mar 10, 2009 at 03:26:39AM +0100, Luca Barbato wrote:
>> Thomas Anderson wrote:
>>> Hi,
>>>     Attached is my comparison of the two proposals for live sources.
>>>     Sorry about getting it out late, I had to get ahold of a number of
>>>     people to finish writing it up.
>> I'd be happier if you actually provided it with a better description and/or 
>> updated drafts along.
> 
> As per the Council summary we were suppose to write up a comparison of
> the advantages/disadvantages of both. It was not in the summary that I
> had to update the Glep as well as write a comparison.

having the updated drafts would be useful to highlight better and state 
what probably is lost in the countless mail threads.

>> The glep54 doesn't state anything about how/where the specific revision is 
>> stored nor what the live property is and it implicitly provides/triggers in 
>> the package manager.
> 
> For one, the live property is rendered useless with glep54.

Try to explain why without defining it or at least tell what's supposed 
to provide. Glep54 doesn't state anything about it.

> Secondly,
> the glep does state that those are outside the scope of this particular
> glep, but can later be implemented once this goes through. Doug and I
> had a conversation about this yesterday, and glep54 is the first
> incremental step.

That should be stated in the glep and should help knowing the other 
steps (see below why)

>> The main technical objection could be stated as "does nothing beside giving 
>> a token to describe infinity for a version component as version suffix".
> 
> That's not a technical objection in my opinion. That's an objection that
> the doc doesn't go far enough, to which the answer is that it's the
> first step. Just because the first step doesn't go as far as some would
> like isn't a reason to take the first step.

first step -> "does nothing, but you need to change the eapi in a pretty 
radical way"

I cannot disagree with people that are against it either because they 
don't use even -9999 or they consider worthless doing anything since 
they are about 0.003 of portage and shouldn't be used at all by common 
users. The technical objection is about the effort/usefulness ratio.

If the usefulness is next to 0 the ratio goes next to too big quite easily.

>>> Similar to the above problem is what occurs when a user understandably
>>> puts =media-tv/mythtv-0.20_20090301 in package.{use,keywords} and the
>>> date changes. Also, what happens if the user
>>> =media-tv/mythtv-0.20.live in package.{use,keywords}? Is live expanded
>>> that early so it is invalid or is it still valid?
>> Having =cat/pkg-ver.live in package.{use, keywords} would translate to a 
>> sort of =cat/pkg-ver* but would be nicer putting directly an isodate to 
>> restrict better what you want in and what you want out.
> 
> Hm, so according the the wildcard way:
> 
> Keywording media-tv/mythtv-live in package.keywords keywords every
> single version of mythtv!?

Let me explain better:

Having =media-tv/mythtv-1.2.3.live would always let you unmask or define 
useflags for whatever is the ebuild that is resolved. So it works as 
you'd expect.
That also means that having =media-tv/mythtv-1.2.3.live will apply to 
the whole set of =media-tv/mythtv-1.2.3.{ebuilds you installed using 
that template}.

In that regard is a sort of =cat/pkg-ver* since it covers a list of 
ebuild and not just one (consider that you can issue re-emerge of 
ebuilds and you want to keep the same useflag set you'd expect)

I'll update the draft with those two specific usecases (package.* files 
and behaviour with a long list of applications to be emerged).

lu

BTW: what happens when you take much time to emerge a set of -scm 
ebuilds? Assuming that in a determined timespan the sources are more or 
less stable, once you add up hours between merges the chance you have 
glitches raises a lot.
With live templates you can use emerge -f to reduce the risk with -9999 
and -scm you should be quite careful if you have large sets and upstream 
is quite active.



-- 

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