> 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