1 |
Ciaran McCreesh wrote: |
2 |
> On Thu, 26 Feb 2009 21:40:26 +0100 |
3 |
> Luca Barbato <lu_zero@g.o> wrote: |
4 |
>>>> Be specific. Explain how this works when, say, 0.34.4 is current, |
5 |
>>>> you have a 0.34.5_live and 0.34.5 comes out. |
6 |
>> being live working as substitute for 0.34.5_preN (_live) component |
7 |
>> the appearance of 0.34.5 will be higher than those. If we consider |
8 |
>> the .live alternative you'd have 0.34.live that is shadowed only by |
9 |
>> 0.35.x |
10 |
> |
11 |
> So it doesn't work Right. |
12 |
|
13 |
I'd like to have more details on this point since it works the very same |
14 |
-scm does: the version component substituted gets higher than any other |
15 |
value when is resolved. |
16 |
|
17 |
>> That is pretty much the same you get with -scm, what happens is that |
18 |
>> in the case of live template you have portage installing 0.34.5_preN |
19 |
>> with revision informations and adding the template to the "live" set. |
20 |
> |
21 |
> No, with -scm the order works correctly. |
22 |
|
23 |
"works correctly" |
24 |
|
25 |
You are always not stating what correctly is in your opinion or why |
26 |
other solutions are broken. |
27 |
|
28 |
In my opinion is correct to mark a version component as it will be the |
29 |
higher within that boundary, so 1.2.live means 1.2.x when x is the |
30 |
highest value, no matter which are the others at that time. Using a |
31 |
timestamp to replace x is the simplest way to grant this property. |
32 |
|
33 |
>>>> How do I track an upstream who has a 0.34 branch (which is equal |
34 |
>>>> to or ahead of the most recent 0.34.x release), a 0.36 branch |
35 |
>>>> (which is equal to or ahead of the most recent 0.36.x release) and |
36 |
>>>> a master branch (which is ahead of any release) using the live |
37 |
>>>> property? |
38 |
>> the live property doesn't tell much about versioning |
39 |
>> so you could use 9999 as the "x" version component or .live or -scm, |
40 |
>> the live property just makes portage aware that the sources are live. |
41 |
>> |
42 |
>> This situation is one in those pkg-scm and pkg.live work better, but |
43 |
>> just for one branch. |
44 |
>> |
45 |
>> As you said you could address the problem using useflags, so you |
46 |
>> could by extension you can use the same way to address the single |
47 |
>> case in proposals not supporting the tip of a single non version |
48 |
>> branch as well: |
49 |
>> |
50 |
>> have the all the ebuilds in a package having IUSE=-live that if |
51 |
>> enabled triggers the live property and changes the src_uri to the |
52 |
>> live branch you desire. |
53 |
> |
54 |
> So if you do that, how does the package manager know that one version |
55 |
> is less than another if a particular use flag is enabled, but greater |
56 |
> than it if it is disabled? |
57 |
|
58 |
The same argument is valid about the case of more than one tip branch |
59 |
you'd like to follow, how pkg-scm[master] is higher than pkg-scm[pu]? |
60 |
|
61 |
With property live you just know that it was from a live sources, so you |
62 |
can consider it always new when it comes to resolve it and that pretty |
63 |
much gives you the same behavior you get out -scm as is detailed in the |
64 |
glep-54 |
65 |
|
66 |
With live template you know when you installed it and what you installed |
67 |
so you can re-emerge or update depending on what you want and you get at |
68 |
least the timestamp giving some more information. |
69 |
|
70 |
If you throw in the mix SLOT alteration depending on or not on useflags |
71 |
or timestamps then you may also archive the property of having multiple |
72 |
version installed within any proposed framework. (e.g SLOT="$branch") |
73 |
|
74 |
Still this is something could enjoy some more discussion. |
75 |
|
76 |
As I stated long ago the main issue with the glep you proposed are the |
77 |
lack of informations in the document. You can fill every detail in |
78 |
mailing list as you like but if the document remains this way it doesn't |
79 |
get more informative. |
80 |
|
81 |
lu |
82 |
|
83 |
-- |
84 |
|
85 |
Luca Barbato |
86 |
Gentoo Council Member |
87 |
Gentoo/linux Gentoo/PPC |
88 |
http://dev.gentoo.org/~lu_zero |