Gentoo Archives: gentoo-dev

From: Luca Barbato <lu_zero@g.o>
To: gentoo-dev@l.g.o
Subject: Regarding live sources management proposals (Was: [gentoo-dev] Gentoo Council Reminder for February 26)
Date: Sat, 28 Feb 2009 13:04:19
In Reply to: Re: [gentoo-dev] Gentoo Council Reminder for February 26 by Ciaran McCreesh
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 that is shadowed only by
9 >> 0.35.x
10 >
11 > So it doesn't work Right.
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.
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.
23 "works correctly"
25 You are always not stating what correctly is in your opinion or why
26 other solutions are broken.
28 In my opinion is correct to mark a version component as it will be the
29 higher within that boundary, so 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.
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 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?
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]?
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
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.
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")
74 Still this is something could enjoy some more discussion.
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.
81 lu
83 --
85 Luca Barbato
86 Gentoo Council Member
87 Gentoo/linux Gentoo/PPC