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 |