Gentoo Archives: gentoo-council

From: Ryan Hill <dirtyepic@g.o>
To: gentoo-council@l.g.o
Subject: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal
Date: Thu, 12 Mar 2009 03:54:11
Message-Id: 20090311215531.6074e045@halo.dirtyepic.sk.ca
In Reply to: Re: [gentoo-council] Re: Comparison of GLEP 54 and 'live ebuild' proposal by Luca Barbato
1 On Wed, 11 Mar 2009 10:55:52 +0100
2 Luca Barbato <lu_zero@g.o> wrote:
3
4 > Ryan Hill wrote:
5 > > I have some questions about the -live proposal. I'm sorry if some
6 > > of this has been answered already; I haven't had the opportunity to
7 > > follow it more closely.
8 > >
9 > > The draft (http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst) says
10 > > that "At resolution the live keyword is substituted with a
11 > > timestamp in the form of iso date". What is meant by "resolution"
12 > > here? Does this mean that, having a gcc-4.4.0_prelive ebuild,
13 > > 'emerge -p gcc' would show something like:
14 > >
15 > > [ebuild U ] sys-devel/gcc-4.4.0_pre20090310
16 > >
17 > > If so, is there any way to identify that this is a live ebuild?
18 >
19 > The ebuild itself has some embedded information so portage
20 > could/should provide something like.
21 >
22 > [ebuild U ] sys-devel/gcc-4.4.0_pre20090310 [from svn master
23 > r12345]
24
25 As you said in another mail, this could only be shown for a rebuild,
26 but not an update, true?
27
28 >
29 > > If I have an eclass that needs to do stuff to only live ebuilds
30 > > (like kde4-base.eclass setting SLOT=live when PV is 9999), how can I
31 > > differentiate between live ebuilds and snapshots? Do eclasses see
32 > > -live or the expanded datestamp in PV?
33 >
34 > it see the expanded datestamp but sees also LIVE_URI LIVE_REVISION
35 > LIVE_BRANCH (the variables that keep track of the exact revision of
36 > the sources you are going to use), so you can also slot by branch
37 >
38 > SLOT=${LIVE_BRANCH}
39
40 Yeah, immediately after posting I remembered there would be certain
41 variables present. Even if they weren't you could just stick a
42 LIVE="yes" in the live ebuilds or check PROPERTIES or whatever.
43
44 > > How do I know if a user has a live ebuild installed when they file a
45 > > bug without having to check if there's a snapshot with that date in
46 > > the tree every single time the PV has a datestamp in it? (minor
47 > > gripe admittedly)
48 >
49 > He will provide the revision and branch so you have more information
50 > not less.
51 >
52 > > If I build a live package today, will I see it as an update when
53 > > running emerge -pu @world tomorrow?
54 >
55 > the template will be evaluated again so you get another snapshot
56 > proposed for update.
57
58 Ooh, i really don't like that. This would force me to either do daily
59 updates manually package by package or mask any live ebuilds before i
60 do. That would _really_ suck if I were still running the kde-crazy
61 overlay and had 50+ live ebuilds installed.
62
63 > > If I have 20090309 installed what does 'emerge
64 > > =gcc-4.4.0_pre20090309' do tomorrow? (It might be a neat trick to
65 > > disable fetch and just rebuild the current checkout in this case.)
66 >
67 > it will try to build the exact revision it used by the time you
68 > issued the previous emerge.
69
70 Cool.
71
72 > > Does 'emerge =gcc-4.4.0_pre<date>' even work, or just `..._prelive`?
73 >
74 > =gcc-4.4.0_pre<date> will try to reinstall what you installed by
75 > <date>
76
77 Will a list of date -> revision mappings be kept? Where is this info
78 stored?
79
80 > =gcc-4.4.0_prelive will get resolved out of the template and then
81 > installed as =gcc-4.4.0_pre<now>
82 >
83 > > Does the user at any point ever see "live" in the ebuild version or
84 > > is it always replaced by the date? If the latter, how do users
85 > > know they have to put '=sys-devel/gcc-4.4.0_prelive' in package.*
86 > > and not pre<date>?
87 >
88 > the user will get the version render but also from where it is
89 >
90 > > Are there any facilities to allow a user to checkout a specific
91 > > revision from the repo, or is that beyond the scope of this GLEP?
92 > > If we ever do implement such a thing, it seems like the datestamp
93 > > approach wouldn't mesh well; 20090310 doesn't make much sense when
94 > > the revision is from a month ago.
95 >
96 > if you want to checkout a specific revision from the repo you aren't
97 > creating a live ebuild but a snapshot with a specific src uri.
98 >
99 > so you don't use a template but just the specific eclasses and mark
100 > the ebuild so you can show up on emerge -p the informations as stated
101 > above.
102
103 I was thinking about dynamic revisions, where the user could do
104 something like 'emerge -av gcc --rev 123456'. I just checked a couple
105 eclasses and it seems we already have this feature, for example
106 ESVN_REVISION in subversion.eclass, so let's abandon this train of
107 thought. ;)
108
109 > > I'll be honest, I much prefer the -scm proposal. But I want to
110 > > make sure I'm not completely out-to-lunch about -live before
111 > > making judgements.
112 >
113 > At least now we have some more scenarios we could consider as
114 > use-cases.
115 >
116 > Thank you for the input
117
118 Thanks for your answers. I'd like to think about it a bit, but off the
119 top of my head what would you say to a hybrid approach where the ebuild
120 doesn't have the datestamp expansion on resolution, but rather this
121 information were available after building? In all cases, the ebuild
122 would be referred to by its proper name (ie. gcc-4.4.0_pre.live), but
123 enough information would be recorded at build time so the package
124 manager could do groovy things like
125
126 [ebuild U ] sys-devel/gcc-4.4.0_pre.live (last built 20090310 - rev.
127 14991) USE="use -flags"
128
129 and
130
131 # emerge --info gcc
132
133 sys-devel/gcc-4.4.0_pre9999 was built with the following:
134 CFLAGS="-O2 -march=core2 -pipe"
135 CXXFLAGS="-O2 -march=core2 -pipe"
136
137 >>> Attempting to run pkg_info() for 'sys-devel/gcc-4.4.0_pre9999'
138
139 svn: 20081206 23:31:22 - gcc-4.3.3_pre9999:4.3-svn was merged at revision 142535
140 svn: 20090123 17:09:12 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 143592
141 svn: 20090131 16:35:23 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 143833
142 svn: 20090131 17:05:29 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 143834
143 svn: 20090223 00:33:50 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144379
144 svn: 20090226 22:10:09 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144460
145 svn: 20090226 23:00:57 - gcc-4.3.3_pre9999:4.3-svn was merged at revision 144460
146 svn: 20090304 20:16:48 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144634
147 svn: 20090307 15:12:27 - gcc-4.4.0_pre9999:4.4-svn was merged at revision 144702
148
149 (note the latter is already possible with zero modifications to anything)
150
151 It seems to me that the datestamp expansion is a lot of complication
152 for very little gain.
153
154 Looking at the list of shortcomings in the draft:
155
156 > There are many obvious and non obvious shortcomings in this
157 > situations:
158 > - you have to hand produce "high enough" version values and be sure
159 > they do not clash (e.g. 2.3_pre9999 live ebuild being shadowed by
160 > 2.3_pre20050201 snapshot).
161
162 Solved by both this and the -scm GLEP.
163
164 > - you cannot track what did you install since you don't have a precise
165 > information about it, emerge logs will just provide you the build
166 > date.
167
168 Most SCM eclasses have facilities for storing this data, eg. ESVN_LOG_DIR.
169 Standardizing it could be helpful.
170
171 > - you cannot do exact reemerges and that may break revdep-rebuild
172
173 You can use eclass features that skip the updating phase and just build the
174 current sources (eg. ESVN_OFFLINE). And as I mentioned above, some can
175 build a specific revision.
176
177 > - the package manager isn't aware of the "liveness" condition.
178
179 Solved by both this and the -scm GLEP.
180
181 > - in order to refresh/update the installed package automatically you
182 > need either to rely on script or on sets hand produced or
183 > heuristically defined (e.g "all ebuilds that inherit eclass svn go in
184 > svn set").
185
186 Do people really want live ebuilds updating automatically? It sounds
187 like a recipe for breakage. I don't want live sources updating until
188 i explicitly tell them to, but maybe that's just me. If someone does
189 want this behaviour, I'd suggest using cron. Also, doesn't portage have
190 a @live-rebuild set that makes this trivial?
191
192 > - since you fetch on unpack phase you cannot use emerge --fetch
193 > consistently.
194
195 How does either proposal address this?
196
197 In the end, I don't see anything that datename expansion does that
198 can't be done more easily and less confusingly with other techniques.
199 Is there a specific problem it solves that can't be addressed through
200 other means?
201
202
203 --
204 gcc-porting, by design, by neglect
205 treecleaner, for a fact or just for effect
206 wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies