1 |
gentoofan23 09/03/30 12:31:41 |
2 |
|
3 |
Added: 20090326-summary.txt 20090326.txt |
4 |
Log: |
5 |
Add council log and summary from meeting on 03/26/09 |
6 |
|
7 |
Revision Changes Path |
8 |
1.1 xml/htdocs/proj/en/council/meeting-logs/20090326-summary.txt |
9 |
|
10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090326-summary.txt?rev=1.1&view=markup |
11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090326-summary.txt?rev=1.1&content-type=text/plain |
12 |
|
13 |
Index: 20090326-summary.txt |
14 |
=================================================================== |
15 |
Roll Call: |
16 |
=========== |
17 |
Betelgeuse: here |
18 |
Cardoe: absent |
19 |
dberkholz: here |
20 |
dertobi123: here |
21 |
dev-zero: here |
22 |
leio: here |
23 |
lu_zero: here |
24 |
tanderson(secretary): here |
25 |
|
26 |
Topics: |
27 |
=========== |
28 |
|
29 |
GLEP 55: |
30 |
Petteri noted that portage had recently gotten support for both GLEP |
31 |
55 and the parse-eapi proposal. Petteri will have benchmarks done by |
32 |
the next meeting. |
33 |
|
34 |
EAPI-3 Proposals: |
35 |
A call for objections to/questions about any of the various proposals |
36 |
was asked for. What follows is a list of proposals to which objections were |
37 |
raised or for which there are open questions as well as who raised the |
38 |
points. |
39 |
|
40 |
slot operator support: |
41 |
leio, open questions, position pending on answers |
42 |
default_src_install: |
43 |
leio, open questions |
44 |
dberkholz |
45 |
dertobi123 |
46 |
doinclude: |
47 |
dberkholz |
48 |
leio |
49 |
dosed: |
50 |
dberkholz |
51 |
unpack failing on unknown types: |
52 |
dberkholz |
53 |
docompress: |
54 |
leio, needs to review proposal and prepalldocs |
55 |
dev-zero, thinks it's useless |
56 |
doexample: |
57 |
dev-zero, thinks it should have -r if we have it at all |
58 |
dohard being deprecated: |
59 |
leio, thinks it should remain and have its bugs fixed. |
60 |
disable-dependency-tracking: |
61 |
lu_zero, possible breakage of configure scripts(mplayer & ffmpeg mentioned) |
62 |
utility commands should die by default: |
63 |
leio, open questions |
64 |
ban || ( foo? ( . ) . ): |
65 |
leio, sees no reason to ban something that might have some valid use cases |
66 |
|
67 |
One part of the EAPI-3 discussion is whether to have variables that |
68 |
behind-the-scenes control the default functions. The DOCS variable was |
69 |
created so that a list of documentation to install can be passed to |
70 |
default_src_install. A 4-2 vote approved the DOCS variable for use in |
71 |
src_install. Specific details have not yet been worked out. |
72 |
|
73 |
Open Floor: |
74 |
=========== |
75 |
|
76 |
Ned Ludd(solar) requested that the council discuss a migration of KEYWORDS out |
77 |
of ebuilds to be discussed at the next meeting. |
78 |
|
79 |
|
80 |
|
81 |
1.1 xml/htdocs/proj/en/council/meeting-logs/20090326.txt |
82 |
|
83 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090326.txt?rev=1.1&view=markup |
84 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090326.txt?rev=1.1&content-type=text/plain |
85 |
|
86 |
Index: 20090326.txt |
87 |
=================================================================== |
88 |
16:01 <@Betelgeuse> so are we starting |
89 |
16:01 <@dberkholz> yep |
90 |
16:01 <@leio> where does that assumption come from |
91 |
16:01 <@dertobi123> heya |
92 |
16:01 <@lu_zero> apparently |
93 |
16:01 <@leio> ok, nevermind for now |
94 |
16:01 <@dberkholz> i was typing and was interrupted by a salad dish =P |
95 |
16:01 <@dev-zero> leio: what assumption? |
96 |
16:01 <+tanderson> mmmm, yummy |
97 |
16:01 <@dberkholz> council folks, speak up please |
98 |
16:01 < ciaranm> leio: if the assumption doesn't hold, you're into "stuff that doesn't work with existing EAPIs anyway" territory, and slot operator deps don't affect it |
99 |
16:01 <@leio> that >=foo/bar-2:= means 2, 3 or 4, but not 1 |
100 |
16:01 <@dev-zero> dberkholz: another desert for me please |
101 |
16:02 <@dberkholz> tanderson: can you list anyone on council who hasn't spoken since 2000 |
102 |
16:02 -!- psychoschlumpf [i=lars@unaffiliated/psychoschlumpf] has joined #gentoo-council |
103 |
16:02 <@dev-zero> leio: read what ciaran said completely :) |
104 |
16:02 < ciaranm> leio: if it doesn't, you can't use existing deps correctly anyway |
105 |
16:02 <@leio> There are two parts in there |
106 |
16:02 <@leio> >=foo/bar-2 |
107 |
16:02 <@leio> and := |
108 |
16:02 <@leio> Some foo/bar-2.0.1 might be SLOT=1 |
109 |
16:02 <@dev-zero> leio, ciaranm: I guess we should do that discussion later |
110 |
16:03 <@leio> exactly, nevermind for now |
111 |
16:03 < ciaranm> leio: ...in which case you're in "doesn't work with existing deps anyway, so unrelated to the proposal" territory |
112 |
16:03 <+tanderson> dberkholz: Cardoe |
113 |
16:03 <+tanderson> I knew I was missing someone... |
114 |
16:04 <@leio> Cardoe had asked dang to proxy on #gentoo-desktop the other day |
115 |
16:04 <+tanderson> well, dang isn't here either... |
116 |
16:04 <@dberkholz> neither of them are on freenode |
117 |
16:04 <@lu_zero> hmm |
118 |
16:04 <+tanderson> dang it :P |
119 |
16:04 <@dberkholz> if anyone's got im handy, please ping |
120 |
16:05 <@dev-zero> is there a way we can store that info on a voluntary basis in the ldap? |
121 |
16:05 <@dberkholz> we already do |
122 |
16:05 <@dev-zero> ah, ok |
123 |
16:05 <@dberkholz> gentooIM or so |
124 |
16:05 <@dev-zero> then I have to go updating my info there :) |
125 |
16:05 <@dberkholz> so let's get rolling |
126 |
16:06 <@dberkholz> EAPI=3. i'd like to see people mention any specific features they've got questions for or want to reject entirely |
127 |
16:06 <@dberkholz> i think only dev-zero and i have done this on the list |
128 |
16:06 <@leio> the SLOT operator stuff is hazy for me. A nice concrete user facing documentation blurb would be appreciated |
129 |
16:06 < ciaranm> dberkholz: Betelgeuse did too 15m or so ago |
130 |
16:07 <@dberkholz> ah, thanks. been eating dinner and all that. |
131 |
16:07 * solar requests that you start at the top of the draft vs the middle of it |
132 |
16:08 * dev-zero agrees with solar |
133 |
16:08 <@lu_zero> there is a quick link with the up to date list? |
134 |
16:08 <@dev-zero> see topic |
135 |
16:08 <+tanderson> solar: yep, nice for summaries as well |
136 |
16:08 <@dberkholz> ok, sure. |
137 |
16:08 <@leio> what, we are going to go through all of them again in a meeting? |
138 |
16:09 <+tanderson> dleverton had PMS copies available as well, since my computer is still struggling to compile texlive |
139 |
16:09 <@dev-zero> we can group them by priority |
140 |
16:09 <@dberkholz> i've got an idea |
141 |
16:09 <@Betelgeuse> The only thing I see useful to do here is to assign people to take care of getting them implemented |
142 |
16:09 <@Betelgeuse> I can take a couple |
143 |
16:09 <@dev-zero> I already started :) |
144 |
16:10 <@dberkholz> does anyone who hasn't posted on the list have questions or problems with specific features that they want to say here? |
145 |
16:10 <@lu_zero> ... |
146 |
16:10 < solar> yes |
147 |
16:10 < solar> but towards the end |
148 |
16:10 < hwoarang> not right now :) |
149 |
16:11 <@dev-zero> ok, pkg_pretend and the USe dep modifiers have already been accepted |
150 |
16:11 <@leio> yes, but details on list after meeting would be best, sorry for not doing it before-hand. |
151 |
16:11 <@dev-zero> slot operator support as implemented in kdebuild ... leio has a question there |
152 |
16:12 <@dertobi123> well, probably yeah ... but i wasn't able to do so on-list before the meetingt |
153 |
16:12 <@dertobi123> meeting* |
154 |
16:12 <@dberkholz> hmm |
155 |
16:12 <@dev-zero> leio: your question is about certain use cases, right? |
156 |
16:12 <@dberkholz> can we collect a specific list of features that people have questions/problems with now, and not actually discuss the questions? |
157 |
16:12 <@leio> yes, and actual examples and user documentation |
158 |
16:12 <@dberkholz> that way we at least know what's blocking |
159 |
16:13 <@dev-zero> dberkholz: ok, let's first do that and then discuss the concrete questions right afterwards |
160 |
16:13 <@lu_zero> or that there are enough features worth an eapi bump |
161 |
16:13 <@dev-zero> lu_zero: do you doubt that? |
162 |
16:13 < ciaranm> user documentation for slot operator deps is easy. just tell people that if they build+run dep on something that has multiple slots, they should append either :* or :=. |
163 |
16:13 <@leio> regarding dohard deprecation I'm reserved about. It should be handled when possible and the portage bug needs to be fixed anyhow (actual packages are getting lots of copies of the same file because hard links are lost, irrelevant to dohard) |
164 |
16:13 <+tanderson> I could do devmanual patches easily for docs |
165 |
16:14 <@dberkholz> whoever has a feature they have a question/problem with, just say to me (dberkholz: $feature) what the feature is, so tanderson can collect a list of what feature and who |
166 |
16:14 <@lu_zero> dev-zero after discussion we can either wait or go on with what is already accepted |
167 |
16:14 <@dev-zero> tanderson: that'd be great because I don't want to touch that thing |
168 |
16:14 <@dev-zero> leio: I don't think there's a good way to handle it properly |
169 |
16:14 <+tanderson> dberkholz: it's easier to prefix that with tanderson since then I'll just look for highlights :) |
170 |
16:15 <@dberkholz> either way. already one false positive |
171 |
16:15 <@dberkholz> you've got 5 minutes =P |
172 |
16:15 <+tanderson> *cricket* :P |
173 |
16:15 < hwoarang> dberkholz: doinclude seems useless to me |
174 |
16:15 <@leio> Are we talking about open questions about a feature, or rejections too? ;p |
175 |
16:16 <@dev-zero> leio: both |
176 |
16:16 <@leio> like I'm clear on some of them but definitely rejecting |
177 |
16:16 <@lu_zero> which ones? |
178 |
16:16 <@dev-zero> dberkholz: mind posting yours too? |
179 |
16:16 <@leio> tanderson: slot operator support (open questions, might be against depending on the answer to those) |
180 |
16:17 <@leio> tanderson: default src_install (there are already open questions still there per dev-zero's summary - same thing) |
181 |
16:17 <@Betelgeuse> I wonder if the slot operator stuff would better be postponed to go in with labels. |
182 |
16:17 <@Betelgeuse> ciaranm: Does that make sense^? |
183 |
16:17 < ciaranm> Betelgeuse: labels solve a different problem |
184 |
16:17 <@lu_zero> tanderson I'm against disable-dependency-tracking in econf by default |
185 |
16:17 <@dberkholz> tanderson: default src_install; doinclude; dosed |
186 |
16:18 < ciaranm> Betelgeuse: you *could* co-opt it into labels, but it's messy, because labels work on groups, and operators work on individual things |
187 |
16:18 <@dberkholz> tanderson: unpack should fail on unknown types |
188 |
16:18 <@dberkholz> i think that's it off dev-zero's list |
189 |
16:19 < ciaranm> lu_zero: what's wrong with disable-dependency-tracking? not heard any objections to that before |
190 |
16:19 <@leio> tanderson: docompress (I need to review what prepalldocs does and compare it closer to the proposed thing, so not open question, just needing more time to be sure) |
191 |
16:19 <@lu_zero> ciaranm there are configure script rejecting it |
192 |
16:19 <@dberkholz> remember, we're not discussing yet... hold off till we're done |
193 |
16:19 <+tanderson> leio: not sure what to classify that one as then |
194 |
16:19 <@lu_zero> (sadly) |
195 |
16:19 < ciaranm> lu_zero: which ones, and why? |
196 |
16:19 <@lu_zero> hand made ones |
197 |
16:19 <@leio> tanderson: ignore I guess unless I bring up on ml |
198 |
16:19 <@Betelgeuse> lu_zero: Well just have a way to disable the behaviour |
199 |
16:20 <@dev-zero> tanderson: docompress ... I still think it's useless |
200 |
16:20 <+tanderson> leio: ok |
201 |
16:20 <@dev-zero> tanderson: doexample must have -r if at all |
202 |
16:20 <@lu_zero> Betelgeuse ok |
203 |
16:20 <@dertobi123> tanderson: default src_install; doexample |
204 |
16:21 < dleverton_> Are hand-made configuration scripts going to accept the arguments that econf already passes? |
205 |
16:21 <@lu_zero> dleverton_ yes |
206 |
16:21 <@leio> tanderson: regarding "Limit values in $USE to the ones in $IUSE" I need to just educate the developers about what LINGUAS is and isn't better. |
207 |
16:21 <@dberkholz> not all of them. i've got examples |
208 |
16:21 < ciaranm> lu_zero: there're hand-made configure scripts that take everything econf passes but not disable-dependency-tracking? examples please |
209 |
16:21 <@lu_zero> ffmpeg ? |
210 |
16:21 <@lu_zero> mplayer ? |
211 |
16:23 < ciaranm> they take weird stuff we already pass like --host and --localstatedir, but barf on --disable-dependency-tracking? |
212 |
16:23 <@dberkholz> anyone still got things to list to me / tanderson ? |
213 |
16:23 <@lu_zero> anyway if econf is tailed to work with autotool generated configure |
214 |
16:23 <@leio> tanderson: Deprecate "|| ( foo? ( . ) . )" in depend -- should not need an EAPI rule to ban it completely to avoid mis-use, and I see no reason to start banning various specific DEPEND constructs and be required to parse for all the EAPI rejected stuff and so on, while there might be 1-10% valid use cases |
215 |
16:23 <@lu_zero> and is stated |
216 |
16:23 <@lu_zero> I'm fine with adding them |
217 |
16:23 < ciaranm> econf already passes autotools-specific weirdness |
218 |
16:23 <@leio> tanderson: dohard - should remain and bugs fixed instead imho |
219 |
16:23 < ciaranm> leio: banning it across EAPIs is a clean way of getting rid of it. and there are no valid use cases. |
220 |
16:24 < ciaranm> dohard is probably unfixable |
221 |
16:24 <@dev-zero> ciaranm: it is |
222 |
16:24 <+tanderson> leio: as far as I'm aware there have been no correct usecases for || ( foo? ( . ) . ) |
223 |
16:24 <@leio> tanderson: doinclude - mostly unnecessary . Might be interesting for the potential +x removing bit, but build systems should install them properly really |
224 |
16:25 <@leio> tanderson: .xz support - never heard of what it is and it doesn't appear to be a mature packing format yet. Does it mean portage will have to rdepend on the unpacking tool of it? |
225 |
16:25 <@dev-zero> leio: no, it doesn't mean that |
226 |
16:25 <@leio> tanderson: --disable-dependency-tracking and --enable-fast-install -- would be nice, but some scripts don't take them and fail |
227 |
16:25 < ciaranm> leio: deps for .xz things are like deps for .rar, which unpack already does |
228 |
16:26 <@dev-zero> btw, it has been requested that .xpi gets added to the new extensions unpack supports |
229 |
16:26 <@leio> package needs to DEPEND on the unpacker? Fine. |
230 |
16:26 <@lu_zero> and xpi is stable and widespread |
231 |
16:26 < ciaranm> what unpacks xpi, and how horrid is its interface? |
232 |
16:26 <@leio> tanderson: utility commands should die -- documented open questions |
233 |
16:26 < psychoschlumpf> isnt --enable-fast-install enabled per default for autoconf configure scripts |
234 |
16:26 <@lu_zero> ciaranm zip |
235 |
16:26 <@dberkholz> can anyone speak up now if they haven't yet said they have issues with EAPI=3 features? |
236 |
16:27 < ciaranm> xpi's easy enough then, so i have no opinion on it |
237 |
16:27 <@leio> tanderson: "provide ebuilds a way to differentiate between updates and removals" -- seems to duplicate REPLACING_VERSIONS |
238 |
16:27 <@dberkholz> tanderson: you have a list of features now? |
239 |
16:27 < ciaranm> leio: uh, that *is* REPLACING_VERSIONS |
240 |
16:27 <@dev-zero> jup, my bad, sorry |
241 |
16:27 <@lu_zero> then it's a dupe |
242 |
16:27 <@leio> sorry, I'm going by dev-zero list |
243 |
16:27 <@dev-zero> leio: no problem, my fault |
244 |
16:27 <@dberkholz> the description needs changing, i guess |
245 |
16:28 <@dev-zero> I'll do that after the discussion to not even confuse people even further ;-) |
246 |
16:28 <@leio> lots of the stuff at the end seems to have unclear things |
247 |
16:29 <@dev-zero> leio: which ones= |
248 |
16:29 <@lu_zero> leio you mean "Non-fast Features" |
249 |
16:29 <@dev-zero> ? |
250 |
16:29 < ciaranm> leio: go by the pms draft for clear specifics |
251 |
16:29 < solar> If you are at the end. Then Non-fast Features -> src_test() listed is a no go. |
252 |
16:29 <@leio> nah, I think just one or two of the stuff before non-fast features had mentioned open questions too. |
253 |
16:30 <@leio> as for non-fast features |
254 |
16:30 <@dev-zero> solar: that's why it's non-fast, not considered for eapi-3 unless someone explicitly asks for it |
255 |
16:30 <@dev-zero> (should have chosen a better title though) |
256 |
16:30 <@leio> most of them have no description in dev-zero summary |
257 |
16:30 * ciaranm asked for it, on the grounds that src_test is useless without it |
258 |
16:30 <@leio> regarding |
259 |
16:30 <@leio> src_test run unless RESTRICTed or explicitly disabled by the user |
260 |
16:30 <@leio> completely against it, in any form |
261 |
16:30 <@lu_zero> ciaranm src_test should be triggered by repoman |
262 |
16:30 <@Betelgeuse> ciaranm: well I do have arch teams using src_test to catch stuff so it's not useless |
263 |
16:31 < solar> well as stated. The core problem there is if $CBUILD != $CHOST |
264 |
16:31 <@dberkholz> ok, let's skip non-fast things in the interest of getting this in the tree by the end of april |
265 |
16:31 <@Betelgeuse> ciaranm: probably could be more useful of course |
266 |
16:31 < ciaranm> lu_zero: yes, because that works *brilliantly* for detecting failures on user systems. |
267 |
16:31 < ciaranm> solar: ebuilds don't support cross compiling, so it's not an issue |
268 |
16:31 <@dberkholz> sarcasm not necessary... |
269 |
16:31 <@lu_zero> ciaranm user system having src_test enable is a failure by itself |
270 |
16:31 <@lu_zero> since the time and resources needed by certain testsuites |
271 |
16:31 < ciaranm> lu_zero: no, it's a basic sanity feature. for those certain test suites you can override it. |
272 |
16:31 <@Betelgeuse> If we were to enable to now, my bet would be that most users would just disable it. |
273 |
16:31 <@dev-zero> lu_zero: that's a different issue |
274 |
16:31 <@leio> ok, now what? |
275 |
16:32 <@lu_zero> ciaranm do you really use src_test on your systems? |
276 |
16:32 <@Betelgeuse> Then they won't enable it when it's actually good to enable. |
277 |
16:32 < ciaranm> lu_zero: yup |
278 |
16:32 <+tanderson> lu_zero: I use it on my system, works fine |
279 |
16:32 < ciaranm> lu_zero: as does everyone else running paludis |
280 |
16:32 < dleverton_> lu_zero: in the same way that having cmake installed or using live ebuilds is a failure? |
281 |
16:32 <@leio> lets not discuss src_test further please. It is not feasible to enable it by default this year |
282 |
16:32 <@lu_zero> ciaranm and you do not have failures? |
283 |
16:32 < ciaranm> lu_zero: i do. EAPI 3 would fix this. |
284 |
16:32 <@lu_zero> dleverton_ ciaranm said there are so... |
285 |
16:32 <@dev-zero> hehe, touché :) |
286 |
16:33 <@lu_zero> ciaranm I don't see why |
287 |
16:33 <@dberkholz> tanderson: i'm still waiting for you to tell us that you have a list of features with people who have questions etc |
288 |
16:33 < ciaranm> lu_zero: if it were on for EAPI 3, any src_test failure that made it to the user would be a genuine failure. right now, half of test failures are just caused by lazy developers. |
289 |
16:33 < dleverton_> lu_zero: ciaranm said there are what so what? |
290 |
16:33 <@lu_zero> make test is used by upstream |
291 |
16:33 < solar> ok well the real world includes things like cross compiles. So in the case of $CBUILD != $CHOST src_test() can and should not be run. |
292 |
16:33 <@lu_zero> dleverton_ not just me apparently |
293 |
16:33 <+tanderson> dberkholz: I can't write that up while the meeting's going on...too many people and too many proposals |
294 |
16:33 < dleverton_> lu_zero: I can't understand a word you're saying now. |
295 |
16:33 <@dev-zero> tanderson: how much off-time you need? |
296 |
16:34 <+tanderson> dev-zero: ~5-10 minutes maybe |
297 |
16:34 <@dberkholz> tanderson: now you understand the challenge when i was trying to be secretary too =) |
298 |
16:34 < ciaranm> solar: so users who do cross-compiling can turn it off, along with all the other things they need to do to get cross-compiling to sort of work |
299 |
16:34 <+tanderson> dberkholz: heh, indeed |
300 |
16:34 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council |
301 |
16:34 <+tanderson> dberkholz: for now I can give you a list of things that need discussing so it can be done one at a time though |
302 |
16:34 < solar> ciaranm: no reason to break stuff that works now for people |
303 |
16:34 <@leio> ciaranm: for cross-compiling to work they just cross-compile, there's nothing else to do beside fix bugs... |
304 |
16:35 <@dberkholz> tanderson: ok. all in one line, please, so it doesn't get broken up. then i'll start at the beginning |
305 |
16:35 < solar> if people want and have the spare cpu and are the type to fix stuff. They can enable what they want. |
306 |
16:35 < ciaranm> solar: it's an easy change for people who've already made large changes for cross-compiling to make one more small change |
307 |
16:35 < solar> vs us being broken by default |
308 |
16:35 < ciaranm> leio: ebuilds don't support it, though, except by fluke |
309 |
16:35 <@leio> FEATURES=test on by default is completely unfeasible |
310 |
16:35 < dleverton_> If it would really make people happy, portage could easily disable tests automatically in that case. PMS already doesn't cover cross compiling, so no need to mention it there. |
311 |
16:35 <@leio> and as far as I'm concerned not a thing for an EAPI point |
312 |
16:36 <@dertobi123> leio: fully-agreed |
313 |
16:36 < ciaranm> leio: explain why please, avoiding any issue that has previously been shown to be false |
314 |
16:36 < solar> our users are not an excuse for upstreams often buggy test suites. but that is a diff story. |
315 |
16:36 <@dev-zero> ok, can we stop src_test discussion _now_ ? |
316 |
16:36 <@leio> if a package manager wants to give users pleasures of uninteresting subtle failures due to bugs in the tests themselves, and increase the compile time from minutes to days for some stuff, that's their business |
317 |
16:37 < ciaranm> leio: sorry, already debunked as being utter nonsense. please at least read the discussion we had. |
318 |
16:37 <@leio> it's not an EAPI feature what a package manager or profiles considers a default FEATURES |
319 |
16:37 < ciaranm> leio: also already debunked |
320 |
16:37 < solar> I read it and in no way did you debunk it. you dismissed it |
321 |
16:37 <@leio> I'm done with src_test for today. |
322 |
16:37 <@Betelgeuse> stop |
323 |
16:37 <@Betelgeuse> I don't see this going anywhere useful atm |
324 |
16:38 <@dev-zero> me neither |
325 |
16:38 <+tanderson> slot operator support(leio questions), default src_install(leio, open questions), disable-dependency-tracking(lu_zero), unpack fail on unknown types(dberkholz), doinclude( dberkholz ), doesed( dberkholz ), docompress(dev-zero+leio), doexample(dev-zero), limit values in $use to $iuse(leio), deprecate || ( foo? ( . ) . )(leio), dohard(leio), doinclude(leio), fast-install(leio) |
326 |
16:38 <@Betelgeuse> There's nothing new here. |
327 |
16:38 <@dertobi123> Betelgeuse: exactly |
328 |
16:38 < ciaranm> it's not going to go anywhere useful until people read the frickin' discussion |
329 |
16:38 <@dberkholz> aha, there we go |
330 |
16:38 < solar> so drop it from the draft plz then |
331 |
16:38 <@dev-zero> solar: will do |
332 |
16:38 < ciaranm> solar: it's not in the draft |
333 |
16:38 < solar> thanks. have a nice day * |
334 |
16:38 <@dertobi123> tanderson: hrm, you missed my comment? ;) |
335 |
16:38 <@dberkholz> the first thing on the list is slot ops. leio, you said you'll post to the list about that? |
336 |
16:38 < solar> ciaranm: see the end of it. It was. |
337 |
16:38 <@Betelgeuse> solar: read pms |
338 |
16:38 < ciaranm> solar: no, it's in dev-zero's summary. it's not in the draft. |
339 |
16:38 <+tanderson> dertobi123: I skimmed over, probably missed a few people's objections |
340 |
16:39 < solar> Betelgeuse: PMS is the final spec. We are talking about a draft here at listed in the topic |
341 |
16:39 <@leio> dberkholz: I guess. It would be nice to have explanations from an ebuild developer point of view for things like that point |
342 |
16:39 <@dev-zero> list seems small enough to be discussed here, no? |
343 |
16:39 < ciaranm> solar: uh. no. we're talking about a pms draft branch. |
344 |
16:39 < solar> if you are putting things into before they are approved, then something is really wrong |
345 |
16:39 < solar> ok |
346 |
16:39 <@dertobi123> tanderson: anyways, my topics are listed |
347 |
16:39 <@Betelgeuse> solar: The topic should have been made to point to PMS draft branch |
348 |
16:40 <+tanderson> dertobi123: yeah, when we get to those you can just chip in that you also have questions |
349 |
16:41 <@dev-zero> leio: from an ebuild developer pov: DEPEND="dev-lang/python" in a python package spans up to 4 slots |
350 |
16:42 <@dev-zero> leio: DEPEND="dev-lang/python:=" will tell the pm that a package built using a specific python version needs that specific python version as long as that package is installed |
351 |
16:42 <@leio> dev-zero: I think my point is to have such an explanation available to anyone evaluating the features. Your summary page or mailing list or whatever that goes beyond council members :) |
352 |
16:42 < ciaranm> leio: *all* the changes will need user-facing documentation |
353 |
16:42 <@dev-zero> yes, but creating them before actually having stuff implemented is a lot of work |
354 |
16:43 <@leio> yeah, I don't mean all. Just things that are not well understood otherwise. Like this one. |
355 |
16:43 <@dberkholz> leio: anythong you want to bring up now on default src_install? |
356 |
16:43 <@leio> Ah! I think I found the right place in PMS. the hyperlinks on the bottom to up are going to weird places |
357 |
16:44 <@dev-zero> leio: and the result? :) |
358 |
16:44 <@leio> as for default src_install, I understand it covers what docs should be installed by default |
359 |
16:44 -!- kickar [n=didkoddd@unaffiliated/kickar] has joined #gentoo-council |
360 |
16:44 < ciaranm> the default src_install has "TODO: what goes here?" |
361 |
16:45 <@leio> I think that this should be done by the maintainer always |
362 |
16:45 <@dev-zero> leio: so, no default src_install? |
363 |
16:45 <@dberkholz> yeah, there are many cases when the default GNU files are totally useless |
364 |
16:45 < ciaranm> because some people think ebuilds shouldn't use DOCS="blah", despite writing lots of code themselves that does exactly that... |
365 |
16:45 <@leio> this is in regards to the docs part of it |
366 |
16:45 <@dev-zero> dberkholz: but for those a src_install is already written |
367 |
16:45 <@leio> dodoc seems to already ignore files listed that are empty |
368 |
16:46 <@leio> but in some cases NEWS says |
369 |
16:46 <@leio> "See ChangeLog" and nothing else, crap like that doesn't need to get installed |
370 |
16:46 <@leio> DOCS sounds good. Many eclasses do it. |
371 |
16:46 <@dev-zero> dberkholz: and don't understand the argumentationn, sorry |
372 |
16:46 < ciaranm> leio: in some cases, you override it. it's only a default. |
373 |
16:47 * dertobi123 likes to see a useful default DOCS |
374 |
16:47 <@leio> but I want the default src_install to handle the actual installation |
375 |
16:47 <@leio> not decide for me what docs get installed |
376 |
16:47 < ciaranm> then if the default's not good enough, don't use it |
377 |
16:47 < ciaranm> the idea of defaults is to cover a lot of cases, not all cases |
378 |
16:47 <@dertobi123> have a sane default, if you want to decide what docs get installed set DOCS |
379 |
16:48 <@dev-zero> yes, you can still override it if you see that the docs installed by default are crap |
380 |
16:48 <@leio> yeah, just please with a way that doesn't mean I can't call default in src_install for stuff like getting make install run by the default |
381 |
16:49 <@leio> DOCS="" |
382 |
16:49 <@leio> src_install() { |
383 |
16:49 < ciaranm> leio: that'd need DOCS then, which some people object to |
384 |
16:49 <@leio> some_extra_stuff |
385 |
16:49 <@leio> default |
386 |
16:49 <@leio> } |
387 |
16:49 <@leio> sounds good |
388 |
16:49 <@leio> right, so there's more discussion to do on list :( |
389 |
16:49 < ciaranm> unfortunately the objection to DOCS is purely ideological |
390 |
16:49 <@dev-zero> no, I don't think so |
391 |
16:49 -!- spitf1r3 is now known as spitfire_ |
392 |
16:49 < ciaranm> which means voting on it and seeing which ideology is in the majority... |
393 |
16:50 <@dev-zero> dberkholz: I remember you being the one objection DOCS, right? |
394 |
16:50 <@dberkholz> yes |
395 |
16:51 <@dberkholz> if you want docs defaults, i'd prefer a function argument instead |
396 |
16:51 <@dev-zero> example? |
397 |
16:52 <@dberkholz> i haven't thought about the interface |
398 |
16:52 <@dberkholz> but you're all familiar with the concept of arguments to functions |
399 |
16:52 <+tanderson> why not just vote on it? |
400 |
16:53 <@dev-zero> yes, who objects a default src_install which calls "emake DESTDIR=${D} install ... ; dodoc ${DOCS}" ? |
401 |
16:53 <@dev-zero> and from those who don't: who objects DOCS having a sane default like README NEWS etc. if not specified otherwise? |
402 |
16:53 < solar> will it die if they don't exist? |
403 |
16:54 <@dberkholz> i object to the whole philosophy of moving important parts of all ebuild functions (not global metadata) into variables |
404 |
16:54 <@Betelgeuse> I want the contrary |
405 |
16:54 <@Betelgeuse> In Java ebuilds having as much in variables has showed to be much better |
406 |
16:54 <@dberkholz> i don't think it's useful enough with the changes in new EAPIs |
407 |
16:54 < solar> and will the ebuild be forced to set DOCS="" ? |
408 |
16:54 <@dberkholz> although when i wrote eclasses years ago, it was nice |
409 |
16:54 < ulm> solar: some eclasses die if files from DOCS don't exist. so a general default may be problematic |
410 |
16:55 < ciaranm> solar: the DOCS-based proposals i've seen only die if you explicitly set docs and stuff doesn't exist |
411 |
16:55 < solar> seems sane |
412 |
16:55 < ciaranm> solar: they silently ignore any defaults that don't exist |
413 |
16:55 <@dev-zero> that seems useful |
414 |
16:55 <@dev-zero> vote? |
415 |
16:55 <@dberkholz> making people know all these variables associated with ebuild functions adds a whole new dimension to what they have to learn |
416 |
16:56 <+tanderson> so people learn a bit more...big deal. |
417 |
16:56 <+tanderson> Learning ebuilds isn't terribly difficult |
418 |
16:56 < solar> tanderson: it will become harder over time as each eapi will have it's own rules. |
419 |
16:56 < hwoarang> imho it's better to learn a couple of new ebuild than writting functions |
420 |
16:56 <@dev-zero> nothing more than they have to learn when writing an ebuild using one of 13 or 14 eclasses which already recognise DOCS |
421 |
16:56 <@dertobi123> and DOCS shouldn't be that hard to "learn" *cough* |
422 |
16:56 < hwoarang> *s/ebuilds/variables |
423 |
16:57 <@lu_zero> since is already in use |
424 |
16:57 < ciaranm> solar: you only have to learn the EAPIs for things you're writing. which should just mean new EAPIs. older stuff you just look up. |
425 |
16:57 <@lu_zero> have it standardized would be good |
426 |
16:57 <@dev-zero> solar: there's usually only one eapi to learn, the most recent one |
427 |
16:57 < solar> no |
428 |
16:58 <@dberkholz> editing an ebuild that's e.g. part of kde or X or whatever is a whole different story from having *all* ebuilds doing something |
429 |
16:58 <@dev-zero> dberkholz: not all, only those being EAPI=3 and from those only the ones with no src_install |
430 |
16:58 < ciaranm> this isn't going to get decided by anything except a vote |
431 |
16:58 <@dberkholz> you can learn levels of complexity in steps instead of needing it all at once for a basic ebuild |
432 |
16:58 <@lu_zero> I'd just think if it would make us spare time or not |
433 |
16:58 < ciaranm> both sides already know the arguments each way |
434 |
16:58 <+tanderson> hint: if a substantial amount of eclasses do something, there might be a point to it |
435 |
16:59 <@dev-zero> tanderson: my point |
436 |
16:59 <@dev-zero> and I would like to see a vote |
437 |
16:59 <@Betelgeuse> DOCS++ |
438 |
16:59 <@dev-zero> DOCS++ |
439 |
17:00 <@dberkholz> ---------------------- |
440 |
17:00 <@dertobi123> DOCS++ |
441 |
17:00 <@dberkholz> sorry, bad wifi. |
442 |
17:00 <@lu_zero> too many - ^^ |
443 |
17:00 <+tanderson> unfortunately, we could have a tie vote... |
444 |
17:00 <+tanderson> lu_zero: is that a DOCS-- for you? |
445 |
17:00 <@leio> sorry, I got pre-occupied |
446 |
17:00 <+tanderson> ok |
447 |
17:01 <@lu_zero> tanderson I'm not so fond of having too many automagic vars |
448 |
17:01 <@lu_zero> so I can agree on the idea of dberkholz |
449 |
17:02 <@lu_zero> in itself shouldn't change much since common docs aren't that common (sadly) |
450 |
17:02 <@Betelgeuse> lu_zero: woot? |
451 |
17:02 <@Betelgeuse> lu_zero: I see it in almost every ebuild I write |
452 |
17:03 <@lu_zero> Betelgeuse and you touch which kind of ebuilds? |
453 |
17:03 <@dev-zero> lu_zero: and you can still set it manually |
454 |
17:03 <@Betelgeuse> lu_zero: Java and autotools |
455 |
17:03 <@dberkholz> we need to wrap it up |
456 |
17:03 < ciaranm> need to finish the vote! |
457 |
17:03 <+tanderson> is that a positive vote for DOCS? 3 ++, 2 -- |
458 |
17:03 <@dberkholz> looks like we're waiting on another vote from leio, and we'll catch cardoe later |
459 |
17:04 <@dberkholz> if necessary |
460 |
17:04 <@dberkholz> then we'll close up |
461 |
17:04 <@leio> sorry, was on phone with landlord, gimme a minute please |
462 |
17:05 <@lu_zero> Betelgeuse do they have a common intersection that is bigger than 2? |
463 |
17:05 <@Betelgeuse> betelgeuse@pena /usr/portage $ find -name "*.ebuild" | xargs grep -l dodoc | wc -l |
464 |
17:05 <@Betelgeuse> 12457 |
465 |
17:05 <@Betelgeuse> betelgeuse@pena /usr/portage $ find -name "*.ebuild" | xargs grep -vl dodoc | wc -l |
466 |
17:05 <@Betelgeuse> 26204 |
467 |
17:05 <@Betelgeuse> and then there's the DOCS using stuff etc |
468 |
17:05 <@dberkholz> leio: from 20:53 on will catch you up on this, if you aren't yet |
469 |
17:06 <@leio> yeah, got markerline, reading |
470 |
17:06 <@lu_zero> Betelgeuse so you are positive that would make us spare time |
471 |
17:06 < solar> it sounds like you don't have to vote right now as cardoe is not here anyway |
472 |
17:06 <@Betelgeuse> solar: if leio votes yes we have a majority any way |
473 |
17:06 < ciaranm> doesn't really matter if leio votes in favour |
474 |
17:06 <@dberkholz> you could do a grep for exactly how dodoc is called |
475 |
17:06 <@dberkholz> indeed |
476 |
17:07 <@leio> DOCS++ |
477 |
17:07 <@Betelgeuse> lu_zero: We used to have lots of stuff in functions in Java ebuidls. I migrated to using variables and it has been a lot better. |
478 |
17:07 <@Betelgeuse> lu_zero: At least for me personally |
479 |
17:07 <+tanderson> fine, DOCS is in |
480 |
17:07 <@dberkholz> k, that's it for tonight |
481 |
17:07 < solar> guys done? |
482 |
17:07 <@dev-zero> yes |
483 |
17:07 <@Betelgeuse> I will note that zac told me that GLEP 55 support is in Portage. |
484 |
17:07 <@Betelgeuse> So I can finally do the numbers. |
485 |
17:07 <@lu_zero> its 10.12 for me |
486 |
17:08 <@dberkholz> meeting's over, tanderson please be sure to post the nice list of features with people blocking them |