1 |
Thomas Anderson wrote: |
2 |
> On Tue, Mar 10, 2009 at 03:26:39AM +0100, Luca Barbato wrote: |
3 |
>> Thomas Anderson wrote: |
4 |
>>> Hi, |
5 |
>>> Attached is my comparison of the two proposals for live sources. |
6 |
>>> Sorry about getting it out late, I had to get ahold of a number of |
7 |
>>> people to finish writing it up. |
8 |
>> I'd be happier if you actually provided it with a better description and/or |
9 |
>> updated drafts along. |
10 |
> |
11 |
> As per the Council summary we were suppose to write up a comparison of |
12 |
> the advantages/disadvantages of both. It was not in the summary that I |
13 |
> had to update the Glep as well as write a comparison. |
14 |
|
15 |
having the updated drafts would be useful to highlight better and state |
16 |
what probably is lost in the countless mail threads. |
17 |
|
18 |
>> The glep54 doesn't state anything about how/where the specific revision is |
19 |
>> stored nor what the live property is and it implicitly provides/triggers in |
20 |
>> the package manager. |
21 |
> |
22 |
> For one, the live property is rendered useless with glep54. |
23 |
|
24 |
Try to explain why without defining it or at least tell what's supposed |
25 |
to provide. Glep54 doesn't state anything about it. |
26 |
|
27 |
> Secondly, |
28 |
> the glep does state that those are outside the scope of this particular |
29 |
> glep, but can later be implemented once this goes through. Doug and I |
30 |
> had a conversation about this yesterday, and glep54 is the first |
31 |
> incremental step. |
32 |
|
33 |
That should be stated in the glep and should help knowing the other |
34 |
steps (see below why) |
35 |
|
36 |
>> The main technical objection could be stated as "does nothing beside giving |
37 |
>> a token to describe infinity for a version component as version suffix". |
38 |
> |
39 |
> That's not a technical objection in my opinion. That's an objection that |
40 |
> the doc doesn't go far enough, to which the answer is that it's the |
41 |
> first step. Just because the first step doesn't go as far as some would |
42 |
> like isn't a reason to take the first step. |
43 |
|
44 |
first step -> "does nothing, but you need to change the eapi in a pretty |
45 |
radical way" |
46 |
|
47 |
I cannot disagree with people that are against it either because they |
48 |
don't use even -9999 or they consider worthless doing anything since |
49 |
they are about 0.003 of portage and shouldn't be used at all by common |
50 |
users. The technical objection is about the effort/usefulness ratio. |
51 |
|
52 |
If the usefulness is next to 0 the ratio goes next to too big quite easily. |
53 |
|
54 |
>>> Similar to the above problem is what occurs when a user understandably |
55 |
>>> puts =media-tv/mythtv-0.20_20090301 in package.{use,keywords} and the |
56 |
>>> date changes. Also, what happens if the user |
57 |
>>> =media-tv/mythtv-0.20.live in package.{use,keywords}? Is live expanded |
58 |
>>> that early so it is invalid or is it still valid? |
59 |
>> Having =cat/pkg-ver.live in package.{use, keywords} would translate to a |
60 |
>> sort of =cat/pkg-ver* but would be nicer putting directly an isodate to |
61 |
>> restrict better what you want in and what you want out. |
62 |
> |
63 |
> Hm, so according the the wildcard way: |
64 |
> |
65 |
> Keywording media-tv/mythtv-live in package.keywords keywords every |
66 |
> single version of mythtv!? |
67 |
|
68 |
Let me explain better: |
69 |
|
70 |
Having =media-tv/mythtv-1.2.3.live would always let you unmask or define |
71 |
useflags for whatever is the ebuild that is resolved. So it works as |
72 |
you'd expect. |
73 |
That also means that having =media-tv/mythtv-1.2.3.live will apply to |
74 |
the whole set of =media-tv/mythtv-1.2.3.{ebuilds you installed using |
75 |
that template}. |
76 |
|
77 |
In that regard is a sort of =cat/pkg-ver* since it covers a list of |
78 |
ebuild and not just one (consider that you can issue re-emerge of |
79 |
ebuilds and you want to keep the same useflag set you'd expect) |
80 |
|
81 |
I'll update the draft with those two specific usecases (package.* files |
82 |
and behaviour with a long list of applications to be emerged). |
83 |
|
84 |
lu |
85 |
|
86 |
BTW: what happens when you take much time to emerge a set of -scm |
87 |
ebuilds? Assuming that in a determined timespan the sources are more or |
88 |
less stable, once you add up hours between merges the chance you have |
89 |
glitches raises a lot. |
90 |
With live templates you can use emerge -f to reduce the risk with -9999 |
91 |
and -scm you should be quite careful if you have large sets and upstream |
92 |
is quite active. |
93 |
|
94 |
|
95 |
|
96 |
-- |
97 |
|
98 |
Luca Barbato |
99 |
Gentoo Council Member |
100 |
Gentoo/linux Gentoo/PPC |
101 |
http://dev.gentoo.org/~lu_zero |