1 |
gentoofan23 09/05/04 00:43:20 |
2 |
|
3 |
Added: 20090423-summary.txt 20090423.txt |
4 |
Log: |
5 |
Add log and summary for meeting on April 23, 2009 |
6 |
|
7 |
Revision Changes Path |
8 |
1.1 xml/htdocs/proj/en/council/meeting-logs/20090423-summary.txt |
9 |
|
10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090423-summary.txt?rev=1.1&view=markup |
11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090423-summary.txt?rev=1.1&content-type=text/plain |
12 |
|
13 |
Index: 20090423-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 |
Technical Issues: |
30 |
|
31 |
- Portage changing behaviour without EAPI bumps: |
32 |
David Leverton(dleverton) requested that the council mandate that portage |
33 |
is not allowed to change behaviour that is specified in PMS, as has |
34 |
occurred a few times in the past. |
35 |
|
36 |
Conclusion: |
37 |
The council decided that if PMS-conflicting changes occur in |
38 |
package managers then the council can mandate that versions that |
39 |
conflict will be masked. The council may take into account |
40 |
extenuating circumstances. |
41 |
|
42 |
- EAPI 3: |
43 |
EAPI 3's features have been finalized and its final approval is |
44 |
pending portage support for the most important features. Some less |
45 |
critical features may be removed if they cannot be accomplished in |
46 |
a reasonable timeframe and are holding up the introduction of the |
47 |
critical features. This summary of features lists only those features |
48 |
discussed on the April 23 meeting of the Gentoo Council. |
49 |
|
50 |
- New utility functions: 'Doexample'/'Doinclude' |
51 |
Some council members believed that adding these utility functions |
52 |
would complicate things for new ebuild authors while not providing |
53 |
any especially needed features. |
54 |
|
55 |
Conclusion: |
56 |
Voted to not be included in EAPI 3. |
57 |
|
58 |
- Ban || ( use? ( ... ) ... ) |
59 |
Mart Raudsepp(leio) argued that banning such constructs is |
60 |
strictly a QA issue and shouldn't be covered by PMS, while others |
61 |
argued that there are no valid use cases for the construct and |
62 |
that you need appropriate rules to parse RDEPEND/DEPEND. |
63 |
|
64 |
Conclusion: |
65 |
It was decided that a repoman warning would be most |
66 |
appropriate for this case and that the topic of banning it in |
67 |
an EAPI can be revisited for EAPI 4. |
68 |
|
69 |
- Ban 'dohard' |
70 |
Currently dohard cannot be guaranteed to work across filesystems |
71 |
and few packages use it. |
72 |
|
73 |
Conclusion: |
74 |
Voted to be banned in EAPI 3. |
75 |
|
76 |
- New econf options, |
77 |
'--disable-dependency-tracking'/'--enable-fast-install' |
78 |
The addition of '--enable-fast-install' was opposed because it is |
79 |
already a libtool default and as such is useless. No arguments |
80 |
were made against '--disable-dependency-tracking'. |
81 |
|
82 |
Conclusion: |
83 |
'--disable-dependency-tracking' was voted in, while |
84 |
'--enable-fast-install' was voted out. |
85 |
|
86 |
- Add --if-compressed option to unpack(). |
87 |
|
88 |
Conclusion: |
89 |
Voted to be not included in EAPI 3. |
90 |
|
91 |
- Slot Operator Dependencies(:= and :*) |
92 |
|
93 |
Conclusion: |
94 |
Voted to be included in EAPI 3. Mart Raudsepp has remaining |
95 |
queries about the final syntax. |
96 |
|
97 |
|
98 |
|
99 |
|
100 |
1.1 xml/htdocs/proj/en/council/meeting-logs/20090423.txt |
101 |
|
102 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090423.txt?rev=1.1&view=markup |
103 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20090423.txt?rev=1.1&content-type=text/plain |
104 |
|
105 |
Index: 20090423.txt |
106 |
=================================================================== |
107 |
20:00 <@dberkholz> ok, let's get started |
108 |
20:00 <@dberkholz> who's here |
109 |
20:00 <@dertobi123> <- |
110 |
20:00 <@dev-zero> here |
111 |
20:00 <@leio-dl> here |
112 |
20:01 * lu_zero is here |
113 |
20:02 <@dberkholz> Betelgeuse, Cardoe: check in post-2000 please |
114 |
20:02 <@Betelgeuse> \o/ |
115 |
20:02 <@dberkholz> tanderson: here? |
116 |
20:03 <+tanderson> yeup |
117 |
20:03 <@dberkholz> ok, that's everyone but cardoe |
118 |
20:03 -!- ferringb [n=ferringb@67.164.75.74] has joined #gentoo-council |
119 |
20:04 <@dberkholz> seems people really want to cover the "Portage changing behavior in ebuild-visible ways |
120 |
20:04 <@dberkholz> " |
121 |
20:04 <@dberkholz> topic, and we heard positively back from zmedico, so my feeling is that we can do something worthwhile with it quickly |
122 |
20:04 <@dberkholz> the proposal is that we vote that this isn't allowed to happen in the future and will be reverted if so |
123 |
20:05 <@dberkholz> are people ready to vote on that? |
124 |
20:05 <@dev-zero> yes |
125 |
20:05 <@dertobi123> yes and yes |
126 |
20:05 <@lu_zero> yes^2 |
127 |
20:05 <@dev-zero> and yes for the vote |
128 |
20:05 <@leio-dl> what is really "this" is the vague thing here imho. Pretty subjective matter at times |
129 |
20:06 <@Betelgeuse> zmedico: has changed things on ways that are on no way subjective |
130 |
20:06 <@Betelgeuse> like changing order of phaes |
131 |
20:06 <@Betelgeuse> phases |
132 |
20:06 <@leio-dl> sure, those should get communication |
133 |
20:06 <@Betelgeuse> they should not be done at all |
134 |
20:06 < ciaranm> uhm. not "communication". "reverted". |
135 |
20:06 <@Betelgeuse> that's why we have EAPI |
136 |
20:07 <@dev-zero> it's not a one-man show anymore |
137 |
20:07 <@leio-dl> but lets make sure we aren't going to end up having to discuss everything done or have everything done be an EAPI feature, you see where I'm going maybe. Otherwise, yes |
138 |
20:07 < jmbsvicetto> Are you guys ready to "forbid" portage to have new features? |
139 |
20:07 <@leio-dl> No |
140 |
20:07 <@dberkholz> as far as i can tell, ebuild-visible features is pretty much the definition of an EAPI |
141 |
20:07 < ciaranm> jmbsvicetto: uh, no-one said anything about that |
142 |
20:08 <@Betelgeuse> Portage should not change behaviour in EAPI 0. |
143 |
20:08 < jmbsvicetto> ciaranm: well, restrict the above sentence to "if those features happen to have ebuild-visible effect" |
144 |
20:08 <@leio-dl> for example phase order default isn't really ebuild-visilbe |
145 |
20:08 <@dberkholz> not counting optionally handled stuff etc. |
146 |
20:08 < ferringb> hate to point out the obvious, but why not just have it such that the next time this occurs it's brought to the council, instead of trying to forbid portage from doing a vaguely defined thing |
147 |
20:08 <@Betelgeuse> leio-dl: what? |
148 |
20:08 < ciaranm> jmbsvicetto: read dleverton's proposal. |
149 |
20:09 < jmbsvicetto> ciaranm: was it sent today? |
150 |
20:09 <@Betelgeuse> leio-dl: ebuilds wont' break if src_install comes before src_compile? |
151 |
20:09 < ferringb> changing the mtime preservation (which is ebuild visible but not eapi mandated) is a good example of why this vagueness will be problematic |
152 |
20:09 < ciaranm> jmbsvicetto: no. long before that. |
153 |
20:09 <@leio-dl> Betelgeuse: nevermind, I was thinking completely different thing |
154 |
20:09 <@leio-dl> phase order change is ebuild visible. What was the change exactly btw? |
155 |
20:09 < Ford_Prefect> ++ on what ferringb said. Rather than stifle changes we don't even know yet, let's talk about them when they actually (need to) happen. |
156 |
20:09 <@Betelgeuse> leio-dl: he changed the order while updating |
157 |
20:09 <@dberkholz> the wording might be a touch off. |
158 |
20:10 < ciaranm> ferringb: we're looking to get assurances that when it happens, we can get it reverted quickly, rather than having to wait months for a decision by which point there's an even bigger mess to fix |
159 |
20:10 <@dberkholz> we could clarify it to ebuild-visible things that are specified by an EAPI or conflict with something specified by an EAPI |
160 |
20:10 < jmbsvicetto> ciaranm: I understand the concern about package.mask.d changes and agree about that, but I'm worried this might end up in preventing portage development |
161 |
20:10 < ferringb> ciaranm: I've been there for each of those scenarios; going to the council (which has a two week cycle roughly) is fast enough |
162 |
20:10 -!- codejunky [i=jan@××××××.org] has left #gentoo-council [] |
163 |
20:10 < ciaranm> jmbsvicetto: and if it ends up doing so in such a way that's causing problems, we can revisit it for those issues. but given that we have EAPIs, there's very likely not a problem. |
164 |
20:11 < ciaranm> ferringb: that hasn't worked. |
165 |
20:11 <@leio-dl> I think the important bit is to simply not have that unwarranted change end up in a stable version portage upgrade |
166 |
20:11 <@leio-dl> more or less |
167 |
20:11 < ferringb> ciaranm: if it fails next time around, fine, going for the heavy handed ruleset. this is keeping in mind I agree with your point, but not your solution here. |
168 |
20:11 <@lu_zero> ciaranm your concern is just for stable portage and api or every portage released? |
169 |
20:11 < ciaranm> lu_zero: my concern is when portage makes arbitrary, ebuild-visible, PMS-contradicting changes because zmedico thinks it's a good idea |
170 |
20:11 <@dberkholz> ok, here's an idea that might satisfy people |
171 |
20:11 < darkside_> man, give zac a break. he didn't brick everyone's gentoo system. i didn't even notice this change that is causing so much concern |
172 |
20:11 <@dberkholz> the change has to be reverted until the next council meeting |
173 |
20:11 < ciaranm> such as, say, phase order changes. |
174 |
20:12 < ciaranm> darkside_: you didn't have to go around tidying up after him |
175 |
20:12 < ferringb> that change was also near a year back |
176 |
20:12 <+tanderson> darkside_: yeah, I'd agree. but it still shouldn't have happened and things like that have the possibility to brick things |
177 |
20:12 < Ford_Prefect> Why does it need to wait for a council meeting for a decision? Can the discussion and decision not be made on-list? |
178 |
20:13 <@Betelgeuse> darkside_: We shouldn't gamble with users systems. |
179 |
20:13 < ferringb> dberkholz: s:reverted:unreleased: |
180 |
20:13 < jmbsvicetto> ciaranm: I think the real problem is for portage to introduce new features that cause issues for established EAPIs and that people start relying on |
181 |
20:13 < ferringb> dberkholz: and that I personally could live with, suspect zac also. |
182 |
20:13 < jmbsvicetto> ciaranm: The problem isn't the feature in itself but that people start relying in it |
183 |
20:13 <@dberkholz> ferringb: i guess reverted from the user perspective. you can't unrelease things, but you can release a bump that reverts the change. |
184 |
20:14 < ciaranm> what we need is a "this won't happen, and if it does it will get reverted quickly, and if something really needs to break that rule then it'll do so after careful discussion and planning", not "well the council might eventually step in, but not if by that point the mess has already happened, in which case everyone else has to catch up" |
185 |
20:14 <@dberkholz> can someone propose a single wording that we can just vote on? |
186 |
20:14 <@dberkholz> this is turning into a long discussion |
187 |
20:14 < solar> don't be afraid to talk |
188 |
20:15 <@Betelgeuse> solar: if there was something to talk about |
189 |
20:15 < ciaranm> "If ebuild-visible, PMS-conflicting changes occur in Portage, the Council will make sure they get reverted quickly. If special circumstances come along, they will be dealt with specially." |
190 |
20:15 < ferringb> dberkholz: you can pull it from the tree actually; also note that people are watching the changes occuring in svn, so it may not even hit the point of a release. |
191 |
20:15 <@Betelgeuse> or does some council feel that he doesn't understand the issue? |
192 |
20:15 <@Betelgeuse> +member |
193 |
20:15 < solar> there is clearly if people are talking about it and don't see eye to eye |
194 |
20:15 < ferringb> ciaranm: drop ebuild visible |
195 |
20:15 <@lu_zero> I'd specify portage version |
196 |
20:16 < ciaranm> "If PMS-conflicting changes occur in Portage, the Council will make sure they get reverted quickly. If special circumstances come along, they will be dealt with specially." |
197 |
20:16 < Ford_Prefect> ciaranm's wording sounds reasonable. The second sentence seems redundant, really, since that is implicitly the council's job. |
198 |
20:16 < ferringb> mostly suffices, even if I think this seriously heavy handed for issues mostly gone these days. |
199 |
20:16 < tove> s/Portage/PM/ |
200 |
20:16 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has joined #gentoo-council |
201 |
20:16 < ferringb> tove: ++ |
202 |
20:17 <@Betelgeuse> council has no control over other PMs |
203 |
20:17 < ciaranm> for issues that're already gone we've already tidied up the mess |
204 |
20:17 < ferringb> Betelgeuse: council implicitly does via punting the versions out of gentoo-x86 |
205 |
20:17 < ciaranm> things like phase order changes are a lost cause now |
206 |
20:17 <@leio-dl> we could have control of what version and stuff is in gentoo-x86 |
207 |
20:17 < ferringb> Betelgeuse: that's the same control the council has over portage realistically |
208 |
20:17 < ferringb> nail *all* PM's with that rule and I'll be very happy |
209 |
20:17 <@leio-dl> you break it in pkgcore new version, we p.mask it |
210 |
20:17 < ferringb> exactly |
211 |
20:17 <@Betelgeuse> ferringb: well we control who has access to Portage svn etc |
212 |
20:17 <@Betelgeuse> ferringb: or Gentoo does in general |
213 |
20:18 <@lu_zero> so we can control what's in portage |
214 |
20:18 < jmbsvicetto> Betelgeuse: And we don't control gentoo-x86? |
215 |
20:18 <@dertobi123> yep |
216 |
20:18 < ferringb> Betelgeuse: all that truly matters here is if it gets released and used- meaning gentoo-x86. |
217 |
20:19 <@dertobi123> so, make it "in any Package Manager"Ã? can we agree on that? |
218 |
20:20 <@Betelgeuse> fine to me if ferringb and ciaranm don't oppose |
219 |
20:20 <@dev-zero> ++ |
220 |
20:20 < ciaranm> wfm |
221 |
20:21 <@leio-dl> "If PMS-conflicting changes occur in a package manager, the council will make sure the affected versions will be package.masked in gentoo-x86 at the very least". Something like that? |
222 |
20:21 < ciaranm> although i think it's silly. the whole problem is only there because portage's influence means if portage changes everyone else has to. |
223 |
20:21 <@dberkholz> so how's this "If PMS-conflicting changes occur in a package manager, the council will ensure that conflicting versions are not generally available in Gentoo, excepting extenuating circumstances." |
224 |
20:21 < ferringb> dberkholz: masked please, although preferably not even in gentoo-x86 |
225 |
20:21 < jmbsvicetto> ciaranm: If someone were to rely on changes done on another PM in the tree, we would get the same issue |
226 |
20:21 < ferringb> dberkholz: extenuating is fine also. frankly sorting it out when it occurs works for me also |
227 |
20:22 < ciaranm> jmbsvicetto: yeah, but that's never happened and realistically won't happen |
228 |
20:22 < jmbsvicetto> Cardoe: The problem is people relying on "incompatible changes" |
229 |
20:22 < ferringb> it's happened w/ paludis |
230 |
20:22 < ferringb> version comparison differences come to mind |
231 |
20:22 < jmbsvicetto> Cardoe: sorry |
232 |
20:22 < ferringb> pretty sure I've triggered it at least once unintentionally in the past for pkgcore also |
233 |
20:22 < jmbsvicetto> ciaranm: ^^ |
234 |
20:22 < jmbsvicetto> The -r0 stuff, right? |
235 |
20:23 <@dberkholz> happy with this, then? "If PMS-conflicting changes occur in a package manager, the council will ensure that conflicting versions are masked, excepting extenuating circumstances." |
236 |
20:23 < ferringb> no, actual version comparison, how '0' was dealt with |
237 |
20:23 < ciaranm> -r0 was a pkgcore bug, and paludis behaved exactly as pms specified |
238 |
20:23 < Ford_Prefect> dberkholz, ++ |
239 |
20:23 < ciaranm> the '0' thing varied between portage releases at that point |
240 |
20:23 < ciaranm> dberkholz: fine by me |
241 |
20:23 <@dertobi123> dberkholz: happy with that |
242 |
20:23 <@dev-zero> dberkholz: ++ |
243 |
20:23 <@dberkholz> other council members? |
244 |
20:23 <@lu_zero> I'm fine |
245 |
20:23 <@leio-dl> zmedico: how do you feel about that? |
246 |
20:24 < ferringb> dberkholz: wfm. |
247 |
20:24 <@Betelgeuse> sure |
248 |
20:24 < zmedico> leio-dl: sounds reasonable |
249 |
20:24 <@dberkholz> i'm good with that. |
250 |
20:24 <@leio-dl> then fine by me |
251 |
20:24 <@dberkholz> ok, let's get on with it |
252 |
20:24 <@dberkholz> EAPI=3 proposal |
253 |
20:24 <@dberkholz> you saw all the features with "no" votes |
254 |
20:25 -!- EvaSDK [n=eva@gentoo/developer/evasdk] has joined #gentoo-council |
255 |
20:25 <@dev-zero> you can change my "no" for docompress to a "whatever" |
256 |
20:25 <@dberkholz> i propose that any features with a "no" get dropped, unless people voting no are willing to change their votes |
257 |
20:25 < ciaranm> dberkholz: some features are considered both "no" and "critical" |
258 |
20:25 <@dberkholz> yeah, i'm looking forward to that one. |
259 |
20:26 <@dberkholz> ciaranm: some meaning more than just the compression one? |
260 |
20:26 <@dberkholz> because that's now a whatever |
261 |
20:26 < ciaranm> mm, the rest are mostly one no with a bunch of yesses |
262 |
20:27 < ciaranm> dropping all of those would be rather crippling |
263 |
20:27 <@Betelgeuse> I don't see why one no should get a feature dropped. |
264 |
20:27 < Arfrever> You could vote separately for every feature. |
265 |
20:27 <@dberkholz> the others i see are ANY-USE, DOEXAMPLE/DOINCLUDE, BANNED-COMMANDS (dohard/dosed), UNPACK-IF-COMPRESSED |
266 |
20:27 < ciaranm> for most of the features there's a clear majority |
267 |
20:27 <+tanderson> Betelgeuse++ |
268 |
20:28 <@leio-dl> I explained why that majority is not that meaningful in my e-mail |
269 |
20:28 <@dberkholz> Betelgeuse: yeah, i guess my real intention is to make sure everyone knows *why* someone is voting no |
270 |
20:28 <@leio-dl> many of the features with no's are not features but banning, tolo |
271 |
20:28 <@leio-dl> too* |
272 |
20:28 <@dberkholz> if they take that into account and still choose to vote for it, that's fine |
273 |
20:28 < ciaranm> dropping anything with a single "no" is going to cripple EAPI 3, and postponing's a really bad idea |
274 |
20:29 < bonsaikitten> so let's drop eapi3 and wait until people can agree. |
275 |
20:29 <@dberkholz> a la src_install DOCS, i explained my opinion and most people just didn't agree |
276 |
20:29 < bonsaikitten> I like that idea |
277 |
20:29 <@dev-zero> I agree there, and I could have argued the same way as leio for controllable-compress, but seeing that people really seem to want it led me decide to accept it |
278 |
20:29 < ciaranm> bonsaikitten: please troll somewhere else, we're trying to get this settled |
279 |
20:30 < ciaranm> the two 'controversial' ones seem to be doexample and doinclude |
280 |
20:30 < bonsaikitten> ciaranm: so am I. Stop throwing mud. |
281 |
20:30 < ciaranm> which fortunately no-one really seems to care overly much about |
282 |
20:30 < Ford_Prefect> dberkholz, why not assign 5 minutes per feature for discussion. If there is consensus at the end, go ahead, else drop for further discussion. |
283 |
20:30 <@dberkholz> so, let's run through the "no's" quick now that everyone is definitely listening |
284 |
20:30 < peper> 5x24 - gl with that ;] |
285 |
20:30 <@leio-dl> maybe we all can find some dozen more minutes for the meeting if necessary |
286 |
20:30 < peper> 25 even |
287 |
20:31 <@Betelgeuse> peper: just nos |
288 |
20:31 <@leio-dl> the ones with any 'no's is considerably smaller |
289 |
20:31 <@dberkholz> let's start with doexample/doinclude |
290 |
20:31 <@Betelgeuse> we use doexample quite often with java |
291 |
20:31 <@dberkholz> my feeling is that these don't do anything interesting that insinto+doins can't do easily |
292 |
20:32 < ciaranm> i get the impression that opinions on doexample and doinclude are either "sure, why not, there'd be a use for that" or "meh, i think it's pointless" |
293 |
20:32 <@dberkholz> same permissions as any other arbitrary normal file |
294 |
20:32 <@leio-dl> my feeling is the same, especially for doinclude |
295 |
20:32 < Arfrever> dberkholz++ |
296 |
20:32 <@leio-dl> (on top of that with doinclude you really shouldn't need to use it but have the build system fixed imho) |
297 |
20:32 <@Betelgeuse> dberkholz: insinto+doins can do that but it's much easier for newbies to write a single call |
298 |
20:32 <@dberkholz> it's more material to learn that doesn't really simplify anything complex |
299 |
20:32 <@dertobi123> indeed |
300 |
20:33 <@Betelgeuse> dberkholz: you need a subshell if you don't want insinto sticking to exampels dir |
301 |
20:33 <@leio-dl> dberkholz++ |
302 |
20:33 < ferringb> random suggestion.... why not set aside a meeting for *just* eapi3 if y'all are low on time. dislike the notion it needs to go through now, and nothing can be dropped. |
303 |
20:33 < ciaranm> unless anyone has an opinion other than "mildly useful" or "mildly pointless", how about just having a vote right now and going on majority? |
304 |
20:33 <@dev-zero> ferringb: please, there isn't much left we have to discuss |
305 |
20:33 <@Betelgeuse> How about doinstall <dir> <stuff> ? |
306 |
20:33 * leio-dl has time for 2-3 more hours :) |
307 |
20:34 <@dberkholz> if i thought it was mildly pointless, i would've said whatever instead of no |
308 |
20:34 <@Betelgeuse> well food for later eapis |
309 |
20:34 < ferringb> Betelgeuse: exactly. |
310 |
20:34 <@dberkholz> other council members got a useful, new opinion on doexample/doinclude? |
311 |
20:35 <@dberkholz> otherwise let's take a vote and go with majority, since the idea is that we've spoken our minds |
312 |
20:35 <@Betelgeuse> I vote yes |
313 |
20:35 <@dev-zero> yes |
314 |
20:35 <@dberkholz> no |
315 |
20:35 <@leio-dl> maybe they should be taken separately |
316 |
20:35 <@leio-dl> I vote no |
317 |
20:35 <@leio-dl> for both |
318 |
20:35 <@dertobi123> no for both |
319 |
20:35 <@dberkholz> sure, if anyone has a split vote, feel free to say so. |
320 |
20:35 <@lu_zero> I'd no both since Betelgeuse suggested something that could replace them |
321 |
20:36 <@dberkholz> that's all 6 of us who are around, 2 yes 4 no |
322 |
20:36 <@dberkholz> so it's in |
323 |
20:36 <@dberkholz> let's move on to ANY-USE |
324 |
20:36 <@leio-dl> I think you mean it's out? |
325 |
20:36 <@dberkholz> errr, yes. |
326 |
20:37 <@dertobi123> heh |
327 |
20:37 <@leio-dl> ANY-USE I think is me |
328 |
20:37 < ciaranm> both out? lemme update the spreadsheet |
329 |
20:37 <@dberkholz> leio-dl: your reason for voting "no" once more, please? |
330 |
20:37 <@dberkholz> tanderson: just to be perfectly clear when you're making the summary, doexample/doinclude will not be in EAPI=3. |
331 |
20:37 <@leio-dl> I strongly believe this is not something that an EAPI should be dictating. It's a QA issue if used for the purpose as described, not something that must be completely forbidden hard with an EAPI rule |
332 |
20:38 <@Betelgeuse> ciaranm: is || ( foo? ( a ) b ) valid btw? |
333 |
20:38 < ciaranm> Betelgeuse: currently yes, but it shouldn't be, and won't be with ANY-USE |
334 |
20:38 <@leio-dl> Make a repoman check, what is the reason to have this an EAPI item |
335 |
20:38 <+tanderson> dberkholz: k |
336 |
20:38 < ciaranm> leio-dl: the reason is that it's already special-cased in PMS, and we want to remove that special case |
337 |
20:39 <@dev-zero> since there is no use case you could solve with it |
338 |
20:39 <@dev-zero> but you generate problems by using it |
339 |
20:39 <@leio-dl> how are you sure about that? |
340 |
20:39 <@leio-dl> that there is no use case. Why should it be said in PMS |
341 |
20:39 <@leio-dl> there is no use case for other constructs as well conceptually |
342 |
20:39 <@Betelgeuse> leio-dl: because Portage supports it in EAPI 0 |
343 |
20:39 <@dberkholz> maybe to rephrase, nobody has thought of a use case for it and devs do create real problems when trying to use it |
344 |
20:39 < ciaranm> other constructs aren't special-cased in PMS currently |
345 |
20:39 <@Betelgeuse> leio-dl: so if you are making a diff against EAPI 0 you must ban it |
346 |
20:39 <@leio-dl> so it should be a repoman warning or error |
347 |
20:40 < ciaranm> dberkholz: it's not just that there's no use case thought of. it's that there's no way you can use it correctly. |
348 |
20:40 <@leio-dl> why should we set a precendence that EAPI's can say what kind of RDEPEND combinations are valid or not |
349 |
20:40 < ciaranm> leio-dl: it's already something mandated by PMS |
350 |
20:40 <@leio-dl> if you give me a bit, I can come up with many more nonsensical constructs there |
351 |
20:40 < ciaranm> leio-dl: you can't cope up with any nonsensical constructs that have special wording in PMS to deal with them |
352 |
20:40 <@Betelgeuse> You need rules to be able to parse RDEPEND. |
353 |
20:41 <@dberkholz> does that mean we should be changing the meaning of || instead of banning a syntax? |
354 |
20:41 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Nick collision from services.] |
355 |
20:41 * ferringb strongly suspects that via appropriate checks in the ebuild it is possible to use it properly. not saying people do that however. |
356 |
20:41 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council |
357 |
20:41 < ciaranm> dberkholz: all we're doing, in effect, is moving part of ||'s meaning from being a convoluted mess to just making some of it explicitly illegal |
358 |
20:41 <@leio-dl> exactly, there can be cases where it _could_ be used fine |
359 |
20:41 < ferringb> hence error/warning being my preference, and banning if it proves to be a non issue by the time of the next eapi. |
360 |
20:42 < ciaranm> leio-dl: no there aren't |
361 |
20:42 <@lu_zero> anybody checked how widely it is used? |
362 |
20:42 <@leio-dl> I believe zmedico agrees with ferringb? |
363 |
20:42 <@Betelgeuse> ciaranm: Is there a valid syntax for use? inside || ( ) ? |
364 |
20:42 < ciaranm> lu_zero: three or four places in the tree last time i looked, all wrong, and one example in the docs, which is wrong |
365 |
20:42 <@dberkholz> my understanding is that because of the difference between || preferring first-installed and use flags preferring what USE is, you can never deterministically pull in the right deps |
366 |
20:42 < zmedico> leio-dl: yeah, I'd prefer warning |
367 |
20:42 < ciaranm> Betelgeuse: as a direct child, it's syntactically legal at present but can't be used correctly |
368 |
20:43 < darkside_> bug 168179 |
369 |
20:43 < Willikins> darkside_: https://bugs.gentoo.org/168179 "Packages misusing || ( use? ( ) ) constructs"; Gentoo Linux, Applications; NEW; ciaran.mccreesh@××××××××××.com:qa@g.o |
370 |
20:43 < ferringb> dberkholz: has_version... like I said, via appropriate ebuild voodoo... |
371 |
20:43 <@dberkholz> ferringb: how can you use has_version in DEPEND? |
372 |
20:43 < ciaranm> you can't even has_version it correctly because there can be multiple matches |
373 |
20:43 <@leio-dl> yes, you prefer one of them |
374 |
20:43 < ferringb> dberkholz: has_version checking w/in the ebuild as to which actually was used. for hard linkages (gcc and friends) he's right |
375 |
20:43 < ferringb> dberkholz: for dynamic imports, it's a different story imo |
376 |
20:43 <@leio-dl> you can do that in python |
377 |
20:44 <@dberkholz> by the time you know which was used, you've already pulled in an irrelevant package in DEPEND that you had a USE flag for but didn't get used in the || |
378 |
20:44 <@leio-dl> they actually use code |
379 |
20:44 <@leio-dl> try: |
380 |
20:44 < ferringb> or at least a muddier story that makes this grey |
381 |
20:44 <@leio-dl> import foo |
382 |
20:44 <@leio-dl> except: |
383 |
20:44 <@leio-dl> import bar |
384 |
20:44 < darkside_> looks like 6 ebuilds are still in violation? really a reason to be arguing about this? |
385 |
20:44 < ferringb> elementtree/celementtree/python:2.6 is an example |
386 |
20:44 < ciaranm> darkside_: we want to remove a whole load of messy special-casing, so yes |
387 |
20:44 < ferringb> pkgcore would have such a dep if it weren't for the fact we bundle a fallback ;) |
388 |
20:44 <@leio-dl> that special casing isn't going to go anywhere |
389 |
20:44 <@dberkholz> any council members still unclear on the implications of this? |
390 |
20:45 <@dberkholz> if not, we might as well vote |
391 |
20:45 <@dev-zero> leio-dl: wrong, in general an ebuild should remove the option which hasn't been selected, even if changeable at runtime |
392 |
20:45 <@leio-dl> so to reiterate, there are valid use cases for this |
393 |
20:45 <@Betelgeuse> Well could someone tell me why flatten use and then do || ( ) norma doesn't work if there are multiple children |
394 |
20:45 <@Betelgeuse> I was only thinking with a single use? children |
395 |
20:45 < ciaranm> Betelgeuse: did you see the example i posted to the list when this first came up? |
396 |
20:46 <@Betelgeuse> ciaranm: that's probably some time ago and I have already forgotten |
397 |
20:46 <@Betelgeuse> ciaranm: do you have an archive link? |
398 |
20:46 < ciaranm> Betelgeuse: http://archives.gentoo.org/gentoo-dev/msg_4b2d8e11cb80aba847b8ab687ab5af47.xml |
399 |
20:46 <@leio-dl> you have a dynamic language. You allow something to be preferred by a USE flag (possibly an extra dep). The package itself can work dynamically with either anyway. Hence that syntax is exactly what is proper to express all of that |
400 |
20:47 <@dev-zero> leio-dl: no, it's not. example: blueman |
401 |
20:47 < ciaranm> leio-dl: no, it's not. |
402 |
20:47 <@leio-dl> blueman? |
403 |
20:47 < ciaranm> leio-dl: either you use a simple || ( ) dep, or you use a set of use? deps so you know which you're getting |
404 |
20:47 <@leio-dl> you don't need to know that |
405 |
20:48 <@leio-dl> it is irrelevant |
406 |
20:48 <@dev-zero> leio-dl: check the ebuild, reason why even for dynamic languages such switching may be harmful |
407 |
20:48 <@leio-dl> it works with both |
408 |
20:48 < ciaranm> leio-dl: if you don't need to know it, you use || ( ) on its own |
409 |
20:48 < ciaranm> leio-dl: if you do need to know, you use the use construct expanded to what you really mean |
410 |
20:48 <@dev-zero> vote please? |
411 |
20:48 <@leio-dl> dev-zero: what category is that? |
412 |
20:48 <@dev-zero> leio-dl: net-wireless |
413 |
20:49 <@dev-zero> leio-dl: but that doesn't really belong in this meeting |
414 |
20:49 * ferringb notes again, pkgcore's xml usage is a valid counter example to this |
415 |
20:49 < Arfrever> There's only: network? ( || ( net-dns/dnsmasq =net-misc/dhcp-3* ) ) |
416 |
20:49 < ciaranm> ferringb: || ( ) with no use? is the correct way of doing that |
417 |
20:50 < ciaranm> ferringb: if you add in the use?, all you do is break up-front repeatability |
418 |
20:50 < ferringb> ciaranm: obviously folk disagree on the 'correct' there. |
419 |
20:50 <@Betelgeuse> I vote no and make this go to repoman then. |
420 |
20:50 < ciaranm> ferringb: those people are missing the implications of lack of up-front repeatability |
421 |
20:50 < Arfrever> dev-zero: What is exactly wrong in blueman? |
422 |
20:51 <@Cardoe> tanderson: mark me as basically missing it. |
423 |
20:51 < ferringb> ciaranm: up front repeatability isn't there to begin with unless the vdb is in the exact same state, resolver algo hasn't changed, etc. |
424 |
20:51 <@dev-zero> Arfrever: not now |
425 |
20:51 <@leio-dl> the settings are stored in different place depending on which |
426 |
20:51 <@Betelgeuse> But I am not strongly opionated either way. |
427 |
20:51 < ciaranm> ferringb: if a user has USE=-foo, but has libfoo installed, does pkgcore still use libfoo if it's available? |
428 |
20:51 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has quit [Connection timed out] |
429 |
20:52 < ciaranm> ferringb: assuming libfoo is the first choice, of course |
430 |
20:52 < ferringb> ciaranm: in cases of this sort, ||() constructs basically become ordered preference |
431 |
20:52 <+tanderson> Cardoe: yep, you were more than 15 minutes late anyway I /think/ |
432 |
20:52 < ciaranm> ferringb: simple question. simple answer please? |
433 |
20:53 <@Cardoe> tanderson: I was. |
434 |
20:53 <+tanderson> goodie, my clock's not off then |
435 |
20:53 <@leio-dl> the USE is in there something that allows the user to opt out or in of a provider. An ordered preferences, yes |
436 |
20:53 < ferringb> ciaranm: the underlying code is still going to do an ordered set of imports till it finds one that works- via ||() w/ conditionals it's specifying the preference. yes, because of ||() behaviour it's possible for it to choose something other then leftmost- that's more a resolver choice however |
437 |
20:54 <@dberkholz> i've gotta step away for a few, anyone feel free to bring it to a vote |
438 |
20:54 < ciaranm> so basically if we're using this construct for dynamic things as leio-dl and ferringb have suggested, the user specifying USE=-foo but having foo installed may result in foo being used anyway, and the package manager thinking it's not used. so, again, no right way of using it. |
439 |
20:54 < loki_val> Please ban this feature. It makes my head hurt trying to figure it out. |
440 |
20:54 < ferringb> loki_val: heh |
441 |
20:54 <@leio-dl> it doesn't matter |
442 |
20:54 <@leio-dl> if the package manager thinks its used or not |
443 |
20:55 < ferringb> ciaranm: if you'd really like the import list to be pruned down to exactly what the ||() was at the time of merging, it can be done. reason it isn't is because that's generally pointless to do |
444 |
20:55 <@leio-dl> the package itself works with either one, as long as one of them is available, which is what a ||() construct is about |
445 |
20:55 <+tanderson> loki_val: hehe, :) |
446 |
20:55 < ciaranm> leio-dl: uh, i don't think you've thought that through |
447 |
20:55 < ferringb> warn/error it, presuming no real world screaming after an eapi cycle, punt it. |
448 |
20:55 < ferringb> for eapi deprecation of most stuff I kind of prefer that approach anyways |
449 |
20:55 < ferringb> (where viable of course) |
450 |
20:56 < ciaranm> leio-dl: you're saying, in effect, that it's fine for packages to list utterly incorrect dependencies, when listing them correctly instead is even easier |
451 |
20:56 <@leio-dl> ciaranm: except they are not incorrect |
452 |
20:56 <@Betelgeuse> add a warning now and let's drop it in EAPI 4 if not valid usage comes up |
453 |
20:56 < ciaranm> leio-dl: read what i just said. they are. |
454 |
20:56 <@leio-dl> read what I said, they are not? This goes nowhere like that. |
455 |
20:57 < ciaranm> leio-dl: your "try to import foo, then bar" example is expressed as || ( foo bar ), not || ( foo? ( foo ) bar? ( bar ) ) |
456 |
20:57 <@leio-dl> My vote is that we make it a repoman warning instead, and see for EAPI-4 |
457 |
20:57 < ferringb> ciaranm: you're pointing at all fault w/ ||() in general btw, consider multiple satisfiers available... |
458 |
20:57 < ciaranm> ferringb: || ( ) in general is at least well defined |
459 |
20:57 < ferringb> Eh. |
460 |
20:57 <@leio-dl> the USE check adds a preference |
461 |
20:57 < ferringb> weak counterarg, that one. |
462 |
20:57 < ciaranm> if a package does "try to import foo, then bar", that maps exactly onto what || ( foo bar ) does |
463 |
20:57 <@leio-dl> it can be useful in certain embedded scenarios, for example |
464 |
20:58 < ferringb> either way |
465 |
20:58 <@dertobi123> ok, dito for repoman warning now and let's take another look for eapi-4 |
466 |
20:58 < ciaranm> leio-dl: er, the preference is ignored, though |
467 |
20:58 <@leio-dl> but foo is something that needs a python library that has a global USE flag for it |
468 |
20:58 < ferringb> ciaranm: suspect you've made your point, know I've made my point. might as well leave it to them to decide. |
469 |
20:58 <@lu_zero> I agree with leio-dl first have a repoman check then bring it back to eapi-4 |
470 |
20:59 <@dev-zero> well, I'd vote for ban in eapi-3, but since that doesn't get a majority I'm fine with first repoman check and then ban (to get at least something) |
471 |
20:59 <+tanderson> I gotta run to a college seminar(trying to steal my money.) I'll work(hopefully get out) on the summary tomorrow |
472 |
20:59 <@dev-zero> tanderson: ok, thanks |
473 |
21:00 <@leio-dl> ok, so I think we have leio, lu_zero, dertobi123 and Betelgeuse for repoman warning and revisit EAPI enforcement in EAPI-4 |
474 |
21:00 <@dertobi123> right |
475 |
21:00 * ciaranm marks that on the spreadsheet |
476 |
21:00 <@Betelgeuse> I would like to see us finishing the list today so let's continue? |
477 |
21:00 <+tanderson> dev-zero: np |
478 |
21:00 <@dev-zero> Betelgeuse: jup |
479 |
21:01 <@dev-zero> next: banned-commands? |
480 |
21:01 <@leio-dl> Betelgeuse: too late, the day just changed for me ;p |
481 |
21:01 <+tanderson> hah |
482 |
21:01 <@Betelgeuse> leio-dl: same here |
483 |
21:01 <@leio-dl> ok, so we have 24 hours. |
484 |
21:01 <@dertobi123> Betelgeuse: uhrm, i need to get up again in a few hours ... |
485 |
21:02 <@dberkholz> alright |
486 |
21:02 <@Betelgeuse> Well if there's 4 of use around we can vote on what's left :) |
487 |
21:02 <@leio-dl> for banned commands the only "no" is for dohard specifically I believe |
488 |
21:02 <@dberkholz> i'm back now |
489 |
21:02 <@Cardoe> leio: you can add me to the list for enforcement for EAPI=4 |
490 |
21:02 <@dberkholz> next question is part ofBANNED-COMMANDS dohard |
491 |
21:02 < jmbsvicetto> Cardoe: You may want to direct that to tanderson |
492 |
21:03 <@dberkholz> quick on the trigger there. leio objected to dropping dohard, people didn't seem to care about dosed one way or the other. |
493 |
21:03 <@leio-dl> dohard is useful, it just doesn't guarantee a hard link if they are across partitions. Portage is now fixed to deal with the situation when it is temporarily in different partitions like PORTAGE_TMPDIR or $D |
494 |
21:03 <@leio-dl> which was a bug that simply needed fixing, for other reasons mainly |
495 |
21:03 <@Cardoe> jmbsvicetto: he already left |
496 |
21:04 <@leio-dl> so dohard should now behave quite good, with probably a guarantee to work fine if it's a link to the same directory. Don't see why we should ban a useful function that has no alternative |
497 |
21:05 <@leio-dl> (other than calling ln directly, but the PM can deal better with any portability concerns) |
498 |
21:05 <@Betelgeuse> leio-dl: in a single dir use ln directly |
499 |
21:05 < ciaranm> there's no guarantee it'll work even for the same directory. not all filesystems do hardlinks at all. |
500 |
21:05 <@lu_zero> in that case it fallsback to symlink? |
501 |
21:05 < ferringb> ick |
502 |
21:05 < jmbsvicetto> Isn't a "best effort" better than nothing at all? |
503 |
21:05 < ferringb> usual fallback for hardlink is a seperate copy |
504 |
21:05 <@Cardoe> not all filesystems support symlinks as well |
505 |
21:05 < ciaranm> lu_zero: no, there's a fallback to a copy |
506 |
21:05 <@leio-dl> yes, the documentation implying that there is a guarantee should be changed then |
507 |
21:06 < ciaranm> Cardoe: if there's no symlink support you can't install gentoo onto it |
508 |
21:06 <@Betelgeuse> Do we support file systems with no hardlinks on system partitions? |
509 |
21:06 <@Cardoe> ciaranm: I'll make Gentoo on vfat a reality someday ;) |
510 |
21:06 < ciaranm> Betelgeuse: yes |
511 |
21:06 <@lu_zero> which ones? |
512 |
21:07 <@leio-dl> if it's not technically possible, it'll make a copy. But if a hard link is useful instead of a copy when it's possible to have on the partitions involved... |
513 |
21:07 <@Betelgeuse> I wonder how much upstream software relies on hardl inks. |
514 |
21:08 <@leio-dl> well, probably not much that would fall over if it's a copy instead |
515 |
21:08 <@lu_zero> is dohard used widely? |
516 |
21:08 <@leio-dl> but a copy takes space |
517 |
21:08 <@dev-zero> lu_zero: no |
518 |
21:08 < ciaranm> dohard's not used widely and mostly used incorrectly |
519 |
21:08 < ferringb> hardlinks have other issues anyways... they're not really represented in the vdb at all |
520 |
21:09 < ferringb> treated as a seperate copy there (chksums and all) |
521 |
21:09 <@dberkholz> dohard is used by 6 packages |
522 |
21:10 <@dberkholz> streamixer, nbsmtp, w3mimgfb, mailwrapper, pipes, cdecl |
523 |
21:10 <@dev-zero> and one of them does a hardlink across directories |
524 |
21:10 <@leio-dl> that's orthogonal - proper hard link support is necessary either way. Some packages standard install scripts can do hard links (see dev-util/git) |
525 |
21:10 <@dberkholz> all of them stay within /usr/{bin,lib,sbin} |
526 |
21:11 < ciaranm> proper hard link support can't be guaranteed. having a dohard's just encouraging people to use something that might not work. |
527 |
21:11 <@leio-dl> so in a common scenario of that being mounted on / or /usr, the hard link is technically working |
528 |
21:11 <@leio-dl> (not guaranteed) |
529 |
21:11 <@dev-zero> dberkholz: nope, nbsmtp doesn't |
530 |
21:12 <@Betelgeuse> well dohard would become fatal in EAPI 3 so if there's no hard link support it would not succeed |
531 |
21:12 < ciaranm> there was one filesystem a while back (coda? i forget) that only allowed hardlinks that were in the same directory, regardless of cross-fs |
532 |
21:12 <@lu_zero> hmm |
533 |
21:12 <@Betelgeuse> so you would not end up in an unwanted state |
534 |
21:12 <@dberkholz> dev-zero: what does nbsmtp do outside of /usr/bin, /usr/lib, and /usr/sbin? is my grep broken? |
535 |
21:12 <@leio-dl> I don't think it should become fatal. So I guess we need some changes anyway in what it does |
536 |
21:13 < ferringb> unionfs likely allows for inter-directory hardlink failure btw |
537 |
21:13 <@lu_zero> I'd keep it for now and try to overhaul it a bit |
538 |
21:13 <@Betelgeuse> Is it useful enough to keep a complicated spec? |
539 |
21:13 <@Betelgeuse> Just use ln || die for current usage? |
540 |
21:13 <@dev-zero> dberkholz: it links from /usr/bin to /usr/lib and with split-debug info in /usr/lib some user might get the idea to put that one on a separate volume |
541 |
21:14 <@dev-zero> dberkholz: probability is low, the case probably doesn't exist, but... |
542 |
21:14 <@dberkholz> i think that is a good point from Betelgeuse. we should focus on the core things that get done often as ebuild-specific features, and let people do rare things by hand |
543 |
21:14 < ferringb> Betelgeuse: || die doesn't do jack though since when it would fail is during merge |
544 |
21:14 <@Betelgeuse> If people want to shape it up, it can come back later. |
545 |
21:15 <@Betelgeuse> ferringb: true |
546 |
21:15 < ciaranm> ln can fail at build time |
547 |
21:15 < ciaranm> the || die is still useful |
548 |
21:16 < ferringb> eh, only in build |
549 |
21:16 < ferringb> binpkg is completely exempted there, so it's not a good gurantee |
550 |
21:16 < ferringb> can only check in preinst, which would suck |
551 |
21:16 <@Betelgeuse> ferringb: but dohard suffers the same thing any way |
552 |
21:16 <@Betelgeuse> so ot |
553 |
21:17 < ciaranm> just tell people to use symlinks. far easier. |
554 |
21:17 <@leio-dl> dohard - Create a hardlink to the first argument from the second argument, when possible on the system. Otherwise copies first argument to second argument. |
555 |
21:17 <@leio-dl> is what I would propose as an alternative then |
556 |
21:17 < ciaranm> leio-dl: bleh. that's not what it does. |
557 |
21:17 < ferringb> that's what it should do however |
558 |
21:17 < ciaranm> leio-dl: dohard can't even know whether it'll work later on |
559 |
21:17 <@leio-dl> that's what I propose it to do in EAPI-3 instead of banning. We need to change something as the stuff would die by default otherwise |
560 |
21:18 < ferringb> ciaranm: dohard is enough of a hook that the pm can track that request and try to honor it at merge time |
561 |
21:18 < ciaranm> ferringb: but it can't provide that information up-front, which is what leio-dl's saying it has to do |
562 |
21:18 <@leio-dl> it doesn't need to provide anything up front |
563 |
21:19 <@leio-dl> with that alternative description the package manager at merge time does what it can |
564 |
21:19 < ferringb> ciaranm: different reading there. I interpret most of that as merge time rather then just build. |
565 |
21:19 <@dberkholz> we're running over and i need to get going. |
566 |
21:19 < ciaranm> leio-dl: the way you have it worded, ebuilds are allowed to dohard, then check whether it did a copy or a link, and do something different depending upon the two as a result |
567 |
21:19 < ferringb> ciaranm: my standpoint, once it goes into ${D}, the ebuild shouldn't be screwing with it. |
568 |
21:19 <@dberkholz> do you want to continue the discussion about this and --if-compressed? |
569 |
21:19 < ciaranm> and the econf options stuff, that has a no |
570 |
21:19 <@dberkholz> oh yeah, missed that one. |
571 |
21:19 < ferringb> although yes that can make perms slightly tricky (did the hardlink succeed? if not, I need to chmod it... etc). |
572 |
21:20 -!- maekke [n=maekke@gentoo/developer/maekke] has quit [Client Quit] |
573 |
21:20 <@dertobi123> can we make it another meeting then, next week or so? |
574 |
21:20 * ciaranm cries |
575 |
21:20 < ciaranm> can we just go with the majority for the sake of finally getting this done? |
576 |
21:20 <@dev-zero> jup |
577 |
21:20 <@dertobi123> if we're not going to discuss everything for another 30 minutes each? |
578 |
21:20 <@leio-dl> I need to go afk for 3 minutes |
579 |
21:20 < ferringb> next meeting. I dislike rushing stuff that folks don't fully agree on... |
580 |
21:20 -!- spitfire__ [n=none@×××××××××××××××××××××××××.pl] has joined #gentoo-council |
581 |
21:21 <@dev-zero> ahem, we had a couple of weeks time to think it through, there was the list request |
582 |
21:21 <@dev-zero> no running anymore, please |
583 |
21:21 <@dberkholz> and yet people continue to have things to discuss, as evidenced by this meeting |
584 |
21:22 < ciaranm> this should have been over weeks ago. unfortunately some people want to be council members for one hour a week. |
585 |
21:22 < ferringb> dev-zero: mean it nicely, but there are two options there- 1) folks don't give a damn, 2) consensus ain't there. if it's #1, hey, force it through. #2 however... |
586 |
21:22 < ferringb> dev-zero: so find out who truly gives a damn ;) |
587 |
21:22 < bonsaikitten> grumble. |
588 |
21:22 < NeddySeagoon> reconviene another day, it need not be next meeting |
589 |
21:23 <@Betelgeuse> Let's just put the yesses here: 1. yes |
590 |
21:23 <@dev-zero> yes, yes from me |
591 |
21:23 <@dertobi123> and yes from me |
592 |
21:23 <@Betelgeuse> one more and we are done |
593 |
21:24 <@dberkholz> what are we even voting on here, dohard or everything left on the list |
594 |
21:24 <@leio-dl> I just hope everyone understands the implications here. |
595 |
21:24 <@Betelgeuse> dberkholz: banning dohard/dosed |
596 |
21:24 <@dev-zero> both of it |
597 |
21:24 <@Betelgeuse> I don't see the complexity being worth it |
598 |
21:24 <@leio-dl> dohard was discussed by me long ago. No-one ever replied to me |
599 |
21:25 <@dberkholz> i don't care about dohard |
600 |
21:25 <@Betelgeuse> leio-dl: you mean a couple packages just use symlinks? |
601 |
21:25 <@dberkholz> i am fine with removing it. not like EAPI=2 is going to disappear tomorrow |
602 |
21:25 <@Betelgeuse> leio-dl: they don't even have to migrate to EAPI 3 |
603 |
21:25 <@leio-dl> until you need to use both dohard and a EAPI=3 feature |
604 |
21:26 <@Betelgeuse> leio-dl: there's nothing in the tree that needs dohard |
605 |
21:26 * lu_zero doesn't care about dohard that much as well |
606 |
21:26 <@leio-dl> maybe that's because portage hard link handling was quite broken until January this year |
607 |
21:26 <@dertobi123> so we have 4,5 yes for now, right? |
608 |
21:27 <@dberkholz> doesn't that just prove it wasn't needed? |
609 |
21:27 <@dertobi123> can we move on then, please? |
610 |
21:27 <@leio-dl> I don't care about dohard very hard(sic) either, but I am making myself care as one of the representatives of the electorate. Lets put it that way. |
611 |
21:27 <@Betelgeuse> I see dosym as better than falling back on copies |
612 |
21:27 <@leio-dl> fine, lets ban it and move on. |
613 |
21:27 <@leio-dl> there are technical reasons to use hard links instead of symlinks |
614 |
21:27 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has joined #gentoo-council |
615 |
21:27 <@leio-dl> where a copy is better than a symlink |
616 |
21:28 <@Betelgeuse> sure but doesn't see a big need for stuff ebuidls manually install |
617 |
21:28 < ciaranm> econf options! |
618 |
21:28 < ciaranm> four yes, one no from leio-dl |
619 |
21:28 <@dberkholz> ok, we've pretty much finished up with removing dohard. |
620 |
21:28 <@leio-dl> I am fine with --disable-dependency-tracking |
621 |
21:28 <@leio-dl> --enable-fast-install is just irrelevant. There is even no reasoning of why that should be passed |
622 |
21:29 <@leio-dl> The bug just had the bug subject changed to include --enable-fast-install with not even a mention in comments of why the change of title |
623 |
21:29 <@leio-dl> --enable-fast-install is a libtool specific option, which is already the default |
624 |
21:30 <@Betelgeuse> so no harm in including it? |
625 |
21:30 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)] |
626 |
21:30 <@leio-dl> there is the same harm as --disable-dependency-tracking, instead in this case there is no gain either |
627 |
21:30 <@leio-dl> hand-made configure scripts might very well implement all the other options, because they are standard in autoconf |
628 |
21:30 <@dberkholz> ebuilds would be a lot longer if we respecified every default configure option |
629 |
21:31 <@leio-dl> but no-one will want to implement all these libtool configure arguments when they aren't even using libtool |
630 |
21:31 <@Betelgeuse> I foudn ciaranm's argument about ignoring unknown options valid |
631 |
21:31 <@leio-dl> and those that do use libtool, already have --enable-fast-install as the default unless the upstream package maintainer has specifically requested it to not be (which I have never seen |
632 |
21:31 < ciaranm> the hand-made thing is a straw man |
633 |
21:31 <@Betelgeuse> libtool might change default |
634 |
21:32 <@dberkholz> so might everything else, and yet we don't specify every single option |
635 |
21:32 < ciaranm> we still haven't found a hand-made configure script that works with all the mess we already pass but not with the two new ones |
636 |
21:32 <@Betelgeuse> vote: |
637 |
21:32 <@Betelgeuse> 1.yes |
638 |
21:32 <@dberkholz> i'm for dep tracking, against fast-install |
639 |
21:32 <@leio-dl> also, there is not even any word from the one who has "requested" it |
640 |
21:32 <@leio-dl> not sure why this is even considered as part of EAPI-3 (--enable-fast-install) |
641 |
21:33 <@leio-dl> a bug title was changed with no explanation. That's it. |
642 |
21:33 < ferringb> ciaranm: about the only one I'd expect is mplayer, due to them mangling the crap out of their script. still would be rather unlikely to be affected... |
643 |
21:33 <@lu_zero> I'm for dep tracking, not fast install |
644 |
21:33 <@dev-zero> I'm for both |
645 |
21:33 <@leio-dl> bug 211529 is the one in question |
646 |
21:33 < Willikins> leio-dl: https://bugs.gentoo.org/211529 "[Future EAPI] have econf run ./configure with --disable-dependency-tracking and --enable-fast-install"; Gentoo Hosted Projects, PMS/EAPI; NEW; nyhm@g.o:pms-bugs@g.o |
647 |
21:33 <@leio-dl> you will note that the title was changed with no comment, and there is no mention of fast-install anywhere in the content. |
648 |
21:33 <@dertobi123> i'm with lu_zero and dberkholz on that |
649 |
21:33 <@lu_zero> ferringb mplayer and ffmpeg are better left w/out econf |
650 |
21:34 <@leio-dl> I'm against --enable-fast-install, whatever with --disable-dependency-tracking |
651 |
21:34 <@leio-dl> so we have 4 no's |
652 |
21:34 <@dberkholz> ok, that's enough folks |
653 |
21:34 * ciaranm updates |
654 |
21:34 <@dberkholz> plus on --disable-dependency-tracking, minus on --enable-fast-install |
655 |
21:34 < ferringb> lu_zero: tend to agree. either way, only potential I could think of |
656 |
21:35 <@leio-dl> when libtool changes default, we can reconsider |
657 |
21:35 <@dberkholz> last topic is unpack --if-compressed only allowing known suffixes |
658 |
21:35 < ciaranm> unpack --if-compressed. two yes, one no from dberkholz, one query from leio-dl which i think was just about messed up wording in pms |
659 |
21:35 -!- spitfire_ [n=none@××××××××××××××××××××××××××.pl] has quit [Read error: 110 (Connection timed out)] |
660 |
21:36 <@dberkholz> i think it's annoying to need --if-compressed for all unknown formats even though they may not be compressed at all |
661 |
21:37 <@leio-dl> no, it was uncertainty of the same thing dberkholz is against |
662 |
21:37 < ciaranm> what it means is that unpack foo.txt will now die, unless you do unpack --if-compressed foo.txt |
663 |
21:37 <@dev-zero> I think it's easy for people to specify --if-compressed in case they have an A mixed of compressed and uncompressed stuff |
664 |
21:37 <@leio-dl> why have to pass it at all |
665 |
21:38 < ciaranm> well, we could just make unpack foo.txt utterly fatal, but there are times it's convenient when foo.txt is part of something else |
666 |
21:38 <@leio-dl> PM already has a list of extensions it needs to unpack. We make things hard for ebuild developers because we think they don't know if the extension they write in SRC_URI is not a common pack format? |
667 |
21:39 <@dberkholz> perhaps adding a few of the most common uncompressed suffixes would help |
668 |
21:39 < ciaranm> it's not making things for ebuild developers at all. it's making it easier for them. |
669 |
21:39 < ferringb> seems like a rather zealous safety feature more annoying then useful |
670 |
21:39 <@dberkholz> my main annoyances are .txt files and scripts |
671 |
21:39 <@dberkholz> .sh, .py, .pl |
672 |
21:40 <@leio-dl> how is it easier if they have to now pass --if-compressed to places when there is no reason right now and it works fine that way |
673 |
21:40 < ciaranm> dberkholz: and how often do you pass those to unpack? |
674 |
21:40 <@dberkholz> every time i don't define a custom src_unpack... |
675 |
21:40 < ferringb> ciaranm: how does it make it easier? For the vast majority they won't even need it- for those that do, unpack just doing a cp if it's an unknown format seems way simpler |
676 |
21:40 < ciaranm> dberkholz: uh, no. check the default src_unpack in eapi 3 |
677 |
21:40 <@dev-zero> c |
678 |
21:41 < ferringb> it's not like this is an error that'll silently slip by also ;) |
679 |
21:41 <@dev-zero> dberkholz: meaning that default src_unpack is passing --if-compressed |
680 |
21:41 < ciaranm> ferringb: it's highly unobvious when people do unpack foo.xz and foo.xz silently gets passed through ununpacked |
681 |
21:41 <@dertobi123> i'm merely "whatever" on that, but we do specify a list of extensions to unpack - therefore it implicitly is defined how to act on extensions not-specified-for-compression. no need to define that again. |
682 |
21:41 < ferringb> ciaranm: not really. the build blows the hell up shortly there after |
683 |
21:42 < ciaranm> ferringb: and people wonder why, especially with some extensions being eapi dependent |
684 |
21:42 < ferringb> personally, I consider it a daft feature- it'd be less annoying if it was inverted (--all-compressed) |
685 |
21:42 < ciaranm> experience has shown that you very rarely have to specify it |
686 |
21:43 <@dberkholz> so, if it's in the default to ignore them, then how is it even a useful thing to add? |
687 |
21:43 < ferringb> raising the question of it's usefulness in light of the build blowing up if they screw up anyways |
688 |
21:43 < ciaranm> dberkholz: stick 'unpack foo.xz' in an ebuild right now. it will silently do nothing. |
689 |
21:44 <@dertobi123> as expected |
690 |
21:44 <@dberkholz> same as would happen if i stuck foo.cx in SRC_URI and didn't have src_unpack |
691 |
21:44 <@leio-dl> adding --if-compressed also means all eclasses that export src_unpack need to make yet another EAPI conditional in there (unless they call default too) |
692 |
21:44 < ciaranm> try 'gunzip foo.txt' |
693 |
21:44 <@dberkholz> now, i'll get different behavior in those two scenarios because default_src_unpack is passing extra nondefault options |
694 |
21:44 < ciaranm> dberkholz: no you wouldn't, because you'd just call 'default' |
695 |
21:45 < ciaranm> the *only* thing this alters is where people explicitly call 'unpack' |
696 |
21:45 < ferringb> eclasses... |
697 |
21:46 < ciaranm> eclasses are already conditionaling that lot because of src_prepare, and usually don't need to mess with src_unpack at all in EAPI 2+ |
698 |
21:47 < ciaranm> there really aren't that many unix apps that silently do nothing if you give them a file parameter that they don't support |
699 |
21:47 <@leio-dl> they do |
700 |
21:47 <@leio-dl> a common src_unpack in an eclass is |
701 |
21:48 <@leio-dl> eclass_src_unpack() { |
702 |
21:48 <@leio-dl> unpack ${A} |
703 |
21:48 <@leio-dl> cd "${S}" |
704 |
21:48 <@leio-dl> has ${EAPI:-0} 0 1 && gnome2_src_prepare |
705 |
21:48 <@leio-dl> } |
706 |
21:48 <@leio-dl> I guess maybe it shouldn't export src_unpack with EAPI-2+ then |
707 |
21:48 < ciaranm> that should be rewritten the clean way |
708 |
21:48 <@leio-dl> but we must do that export |
709 |
21:49 <@leio-dl> and we can't call default unless there is an additional check in there. unpack ${A} cd "${S}" if EAPI<2, otherwise default |
710 |
21:49 <@dberkholz> ciaranm: so in what cases would people be calling unpack in EAPI=3? |
711 |
21:49 < ciaranm> dberkholz: in fancy cases like having to unpack one tarball in one place, then cd to a subdirectory and unpack a second tarball |
712 |
21:50 <@dberkholz> this seems like a lot of special casing for unlikely scenarios |
713 |
21:51 < ciaranm> by that argument, you could say that giving people explicit access to 'unpack' is unlikely |
714 |
21:51 <@dberkholz> yep, you could. |
715 |
21:51 < ciaranm> it still happens often enough that unpack is useful, and that it should behave sanely on error |
716 |
21:51 * ferringb still says invert the bugger... preserves the common case without detriment while covering the potential ciaran is worried about |
717 |
21:52 < ferringb> or nuke the proposal. ;) |
718 |
21:52 < ciaranm> if you invert it no-one will remember to use it. also, i can't think of any unix apps that work that way around. |
719 |
21:53 < ciaranm> silently ignoring failures is highly weird |
720 |
21:53 < ferringb> I'd rather it just cp it over if it's not a supported extension |
721 |
21:53 <@dberkholz> i feel like parameters should get added in the special cases, not by default |
722 |
21:53 < ciaranm> that'd change existing behaviour |
723 |
21:54 < ferringb> re: unixy, if we were talking about -stupid-mplayer-options vs --stupid-mplayer-options, sure, applicable; this is core logic of our own defined func, so... unix traditions apply only so far. |
724 |
21:54 < ciaranm> dberkholz: the special case *is* "i want this argument i'm explicitly specifying to be ignored" |
725 |
21:54 < ferringb> dberkholz: you nailed my view. |
726 |
21:55 <@dberkholz> except that special case happens every time you do SRC_URI="foo.tgz bar.txt" and don't define src_unpack |
727 |
21:55 < ciaranm> but then you're not dealing with unpack yourself, so it's irrelevant |
728 |
21:56 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has quit [Read error: 60 (Operation timed out)] |
729 |
21:56 <@dberkholz> i don't think i'll ever be calling unpack again either way, so i'm not really going to spend any more time on this |
730 |
21:57 <@dberkholz> any other council members want to say something, or ready to vote? |
731 |
21:57 <@dev-zero> I vote yes |
732 |
21:57 <@dertobi123> ready to vote and no |
733 |
21:57 <@lu_zero> no as well |
734 |
21:58 < ciaranm> Cardoe and Betelgeuse were yes before the meeting, dunno about now |
735 |
21:58 <@leio-dl> some points were brought up that when thinking more about I _might_ change my mind, but a no right now |
736 |
21:59 <@Cardoe> ciaranm: hmm? |
737 |
21:59 <@dberkholz> Cardoe: on --if-compressed |
738 |
22:00 <@Cardoe> oh |
739 |
22:00 <@Cardoe> Did we extend the meeting length? |
740 |
22:01 -!- Netsplit hubbard.freenode.net <-> irc.freenode.net quits: kallamej, GrantN05, dleverton, wrona |
741 |
22:01 <@dberkholz> felt like actually getting through EAPI=3 today |
742 |
22:01 <@dertobi123> Cardoe: obviously yes :P |
743 |
22:01 -!- billie80 [n=billie@×××××××××××××××××××××××××××××××××××.net] has joined #gentoo-council |
744 |
22:01 <@dberkholz> and this is the last bit |
745 |
22:01 <@Cardoe> wish that had gone out in the e-mail |
746 |
22:01 <@leio-dl> there was also SLOT-OPERATOR-DEPS |
747 |
22:02 <@dberkholz> well, it didn't get extended till we were about out of time and decided we wanted to extend |
748 |
22:02 <@dberkholz> it's not an advance notice thing |
749 |
22:02 -!- Netsplit over, joins: dleverton, wrona, kallamej, GrantN05 |
750 |
22:02 * ferringb still wants mtime (in one form or another) yayed nayed, although unlikely considering folks ignoring it :P |
751 |
22:02 <@dberkholz> i can finish this, then i'm done |
752 |
22:02 <@dertobi123> so can we finish --if-compressed, please? |
753 |
22:02 <@dberkholz> i cannot take any more time out of work |
754 |
22:02 <@Cardoe> sure |
755 |
22:02 <@Cardoe> I was a yes on it |
756 |
22:03 <@leio-dl> the point was to understand the no-sayers view and then perhaps that changes |
757 |
22:03 <@leio-dl> but I think we have 4 no's anyway, don't we? |
758 |
22:03 < ciaranm> leio-dl: only if you're voting no |
759 |
22:03 <@dberkholz> i haven't changed my opinion |
760 |
22:04 < ciaranm> dberkholz, dertobi123 and lu_zero said no, Cardoe and dev-zero said yes, Betelgeuse isn't here but said yes in his email |
761 |
22:04 <@Betelgeuse> People oppose --if-compressed by default in src_unpack I presume? It will still be added to unpack as an option? |
762 |
22:04 < ciaranm> Betelgeuse: no, they're opposing it entirely |
763 |
22:04 <@leio-dl> it's about the option I believe. |
764 |
22:04 < ciaranm> the option and the src_unpack pretty much have to go together |
765 |
22:04 <@leio-dl> If the option is voted to happen, most will want that option passed in default_src_unpack I bet |
766 |
22:04 <@dberkholz> if it's on by default so often, it's not really a useful validation |
767 |
22:05 <@Betelgeuse> leio-dl: eclass authors can still decided on way or the other |
768 |
22:05 <@dev-zero> leio-dl: that's already the case in eapi-3 |
769 |
22:05 < ciaranm> --if-compressed without the default src_unpack is a very bad idea and if anyone calls for that i'll yell lots and lots |
770 |
22:05 <@leio-dl> yes, the change of src_unpack seems to be the same item in the consideration list. |
771 |
22:06 <@leio-dl> I vote no |
772 |
22:06 < ciaranm> lame! |
773 |
22:06 <@Betelgeuse> do we still have something left? |
774 |
22:06 <@leio-dl> I would vote yes for a --all-compressed option |
775 |
22:06 < ciaranm> looks like it's out :( |
776 |
22:06 <@dertobi123> it is |
777 |
22:06 <@leio-dl> I have reservations about :* syntax that I didn't manage to think through today |
778 |
22:07 <@dberkholz> i need to leave now |
779 |
22:07 < ciaranm> slot-operator-deps is down as two critical, three yes and a query from leio-dl |
780 |
22:07 <@leio-dl> I am not opposed to the feature by concept. A query means something is missing from making a yes or no decision I think. |
781 |
22:08 <@Cardoe> ciaranm: so are you saying you're opposed to --if-compressed? Wasn't it your proposal? |
782 |
22:08 <@dberkholz> leio-dl: can you post your query by monday so we can nail that down by next thursday? |
783 |
22:08 < ciaranm> Cardoe: no, i'm saying i want --if-compressed, and i think you all suck for not going for it |
784 |
22:08 <@dberkholz> other than that, EAPI=3 is good to go |
785 |
22:08 <@leio-dl> I have a visitor till Monday |
786 |
22:08 < ferringb> heh |
787 |
22:08 <@Cardoe> ciaranm: oh. I agree |
788 |
22:08 <@leio-dl> so I'm not sure I can do Monday. I can promise Tuesday |
789 |
22:09 <@Betelgeuse> dberkholz was talking about Thursday |
790 |
22:09 <@leio-dl> I think the implementation can start for portage |
791 |
22:09 <@dberkholz> ok, we've made a decision, and this is the part where you guys support the council even though you disagreed with it, because you got to speak up =) |
792 |
22:09 < ciaranm> quick! four people vote yes to slot-operator-deps so we can just approve the frickin' thing right now |
793 |
22:09 <@Cardoe> Can someone ensure the FULL log is posted somewhere so I can read it on my next plane flight? |
794 |
22:09 <@Cardoe> ciaranm: didn't I already say yes? |
795 |
22:09 <@dberkholz> Cardoe: you were on irc the whole time, don't you log? |
796 |
22:09 < ciaranm> Cardoe: yes, but you need to say so now for it to count as not being deferred |
797 |
22:09 <@Cardoe> ciaranm: well then yes |
798 |
22:09 <@Cardoe> dberkholz: not on this client |
799 |
22:10 <@dev-zero> ahem, what's the point of waiting for slot-op-deps if most people aren't going to change their minds? |
800 |
22:10 <@leio-dl> please by all means start implementing slot-op-deps |
801 |
22:10 <@dev-zero> and why did we extend the meeting time to bring through the issues when we wait again? |
802 |
22:10 <@leio-dl> I do not want to see it not be part of EAPI-3 |
803 |
22:11 <@dev-zero> so, then lets vote |
804 |
22:11 < ciaranm> we're deferring because leio-dl has unspecified objections to slot-operator-deps that he hasn't brought to the list yet |
805 |
22:11 <@Betelgeuse> yes |
806 |
22:11 <@Cardoe> if you guys marked me as deferred on any items I already commented on in my e-mail then you can simply change my vote to what I put in my e-mail |
807 |
22:11 <@dev-zero> and nail that thing done for once |
808 |
22:11 <@Cardoe> leio-dl: ok so change to yes |
809 |
22:11 < ciaranm> that's yes from dev-zero, Betelgeuse and Cardoe. please one more. make my life easier! |
810 |
22:11 <@dertobi123> yes and good night |
811 |
22:12 < ciaranm> \o/ |
812 |
22:12 * dertobi123 gotta go to bed |
813 |
22:12 <@dev-zero> yes from me |