Gentoo Archives: gentoo-council

From: Luca Barbato <lu_zero@g.o>
To: Thomas Anderson <gentoofan23@g.o>
Cc: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Comparison of GLEP 54 and 'live ebuild' proposal
Date: Tue, 10 Mar 2009 14:56:27
In Reply to: Re: [gentoo-council] Comparison of GLEP 54 and 'live ebuild' proposal by Thomas Anderson
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/ in package.{use,keywords}? Is live expanded >>> that early so it is invalid or is it still valid? >> Having =cat/ 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/ 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/ 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