20:00 <@dberkholz> ok, let's get started
20:00 <@dberkholz> who's here
20:00 <@dertobi123> <-
20:00 <@dev-zero> here
20:00 <@leio-dl> here
20:01  * lu_zero is here
20:02 <@dberkholz> Betelgeuse, Cardoe: check in post-2000 please
20:02 <@Betelgeuse> \o/
20:02 <@dberkholz> tanderson: here?
20:03 <+tanderson> yeup
20:03 <@dberkholz> ok, that's everyone but cardoe
20:03 -!- ferringb [n=ferringb@67.164.75.74] has joined #gentoo-council
20:04 <@dberkholz> seems people really want to cover the "Portage changing behavior in ebuild-visible ways
20:04 <@dberkholz> "
20:04 <@dberkholz> topic, and we heard positively back from zmedico, so my feeling is that we can do something worthwhile with it quickly
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
20:05 <@dberkholz> are people ready to vote on that?
20:05 <@dev-zero> yes
20:05 <@dertobi123> yes and yes
20:05 <@lu_zero> yes^2
20:05 <@dev-zero> and yes for the vote
20:05 <@leio-dl> what is really "this" is the vague thing here imho. Pretty subjective matter at times
20:06 <@Betelgeuse> zmedico: has changed things on ways that are on no way subjective
20:06 <@Betelgeuse> like changing order of phaes
20:06 <@Betelgeuse> phases
20:06 <@leio-dl> sure, those should get communication
20:06 <@Betelgeuse> they should not be done at all
20:06 < ciaranm> uhm. not "communication". "reverted".
20:06 <@Betelgeuse> that's why we have EAPI
20:07 <@dev-zero> it's not a one-man show anymore
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
20:07 < jmbsvicetto> Are you guys ready to "forbid" portage to have new features?
20:07 <@leio-dl> No
20:07 <@dberkholz> as far as i can tell, ebuild-visible features is pretty much the definition of an EAPI
20:07 < ciaranm> jmbsvicetto: uh, no-one said anything about that
20:08 <@Betelgeuse> Portage should not change behaviour in EAPI 0.
20:08 < jmbsvicetto> ciaranm: well, restrict the above sentence to "if those features happen to have ebuild-visible effect"
20:08 <@leio-dl> for example phase order default isn't really ebuild-visilbe
20:08 <@dberkholz> not counting optionally handled stuff etc.
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
20:08 <@Betelgeuse> leio-dl: what?
20:08 < ciaranm> jmbsvicetto: read dleverton's proposal.
20:09 < jmbsvicetto> ciaranm: was it sent today?
20:09 <@Betelgeuse> leio-dl: ebuilds wont' break if src_install comes before src_compile?
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
20:09 < ciaranm> jmbsvicetto: no. long before that.
20:09 <@leio-dl> Betelgeuse: nevermind, I was thinking completely different thing
20:09 <@leio-dl> phase order change is ebuild visible. What was the change exactly btw?
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.
20:09 <@Betelgeuse> leio-dl: he changed the order while updating
20:09 <@dberkholz> the wording might be a touch off.
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
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
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
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
20:10 -!- codejunky [i=jan@nerdig.org] has left #gentoo-council []
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.
20:11 < ciaranm> ferringb: that hasn't worked.
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
20:11 <@leio-dl> more or less
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.
20:11 <@lu_zero> ciaranm your concern is just for stable portage and api or every portage released?
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
20:11 <@dberkholz> ok, here's an idea that might satisfy people
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
20:11 <@dberkholz> the change has to be reverted until the next council meeting
20:11 < ciaranm> such as, say, phase order changes.
20:12 < ciaranm> darkside_: you didn't have to go around tidying up after him
20:12 < ferringb> that change was also near a year back
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
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?
20:13 <@Betelgeuse> darkside_: We shouldn't gamble with users systems.
20:13 < ferringb> dberkholz: s:reverted:unreleased:
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
20:13 < ferringb> dberkholz: and that I personally could live with, suspect zac also.
20:13 < jmbsvicetto> ciaranm: The problem isn't the feature in itself but that people start relying in it
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.
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"
20:14 <@dberkholz> can someone propose a single wording that we can just vote on?
20:14 <@dberkholz> this is turning into a long discussion
20:14 < solar> don't be afraid to talk
20:15 <@Betelgeuse> solar: if there was something to talk about
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."
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.
20:15 <@Betelgeuse> or does some council feel that he doesn't understand the issue?
20:15 <@Betelgeuse> +member
20:15 < solar> there is clearly if people are talking about it and don't see eye to eye
20:15 < ferringb> ciaranm: drop ebuild visible
20:15 <@lu_zero> I'd specify portage version
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."
20:16 < Ford_Prefect> ciaranm's wording sounds reasonable. The second sentence seems redundant, really, since that is implicitly the council's job.
20:16 < ferringb> mostly suffices, even if I think this seriously heavy handed for issues mostly gone these days.
20:16 < tove> s/Portage/PM/
20:16 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has joined #gentoo-council
20:16 < ferringb> tove: ++
20:17 <@Betelgeuse> council has no control over other PMs
20:17 < ciaranm> for issues that're already gone we've already tidied up the mess
20:17 < ferringb> Betelgeuse: council implicitly does via punting the versions out of gentoo-x86
20:17 < ciaranm> things like phase order changes are a lost cause now
20:17 <@leio-dl> we could have control of what version and stuff is in gentoo-x86
20:17 < ferringb> Betelgeuse: that's the same control the council has over portage realistically
20:17 < ferringb> nail *all* PM's with that rule and I'll be very happy
20:17 <@leio-dl> you break it in pkgcore new version, we p.mask it
20:17 < ferringb> exactly
20:17 <@Betelgeuse> ferringb: well we control who has access to Portage svn etc
20:17 <@Betelgeuse> ferringb: or Gentoo does in general
20:18 <@lu_zero> so we can control what's in portage
20:18 < jmbsvicetto> Betelgeuse: And we don't control gentoo-x86?
20:18 <@dertobi123> yep
20:18 < ferringb> Betelgeuse: all that truly matters here is if it gets released and used- meaning gentoo-x86.
20:19 <@dertobi123> so, make it "in any Package Manager"Ã? can we agree on that?
20:20 <@Betelgeuse> fine to me if ferringb and ciaranm don't oppose
20:20 <@dev-zero> ++
20:20 < ciaranm> wfm
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?
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.
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."
20:21 < ferringb> dberkholz: masked please, although preferably not even in gentoo-x86
20:21 < jmbsvicetto> ciaranm: If someone were to rely on changes done on another PM in the tree, we would get the same issue
20:21 < ferringb> dberkholz: extenuating is fine also.  frankly sorting it out when it occurs works for me also
20:22 < ciaranm> jmbsvicetto: yeah, but that's never happened and realistically won't happen
20:22 < jmbsvicetto> Cardoe: The problem is people relying on "incompatible changes"
20:22 < ferringb> it's happened w/ paludis
20:22 < ferringb> version comparison differences come to mind
20:22 < jmbsvicetto> Cardoe: sorry
20:22 < ferringb> pretty sure I've triggered it at least once unintentionally in the past for pkgcore also
20:22 < jmbsvicetto> ciaranm: ^^
20:22 < jmbsvicetto> The -r0 stuff, right?
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."
20:23 < ferringb> no, actual version comparison, how '0' was dealt with
20:23 < ciaranm> -r0 was a pkgcore bug, and paludis behaved exactly as pms specified
20:23 < Ford_Prefect> dberkholz, ++
20:23 < ciaranm> the '0' thing varied between portage releases at that point
20:23 < ciaranm> dberkholz: fine by me
20:23 <@dertobi123> dberkholz: happy with that
20:23 <@dev-zero> dberkholz: ++
20:23 <@dberkholz> other council members?
20:23 <@lu_zero> I'm fine
20:23 <@leio-dl> zmedico: how do you feel about that?
20:24 < ferringb> dberkholz: wfm.
20:24 <@Betelgeuse> sure
20:24 < zmedico> leio-dl: sounds reasonable
20:24 <@dberkholz> i'm good with that.
20:24 <@leio-dl> then fine by me
20:24 <@dberkholz> ok, let's get on with it
20:24 <@dberkholz> EAPI=3 proposal
20:24 <@dberkholz> you saw all the features with "no" votes
20:25 -!- EvaSDK [n=eva@gentoo/developer/evasdk] has joined #gentoo-council
20:25 <@dev-zero> you can change my "no" for docompress to a "whatever"
20:25 <@dberkholz> i propose that any features with a "no" get dropped, unless people voting no are willing to change their votes
20:25 < ciaranm> dberkholz: some features are considered both "no" and "critical"
20:25 <@dberkholz> yeah, i'm looking forward to that one.
20:26 <@dberkholz> ciaranm: some meaning more than just the compression one?
20:26 <@dberkholz> because that's now a whatever
20:26 < ciaranm> mm, the rest are mostly one no with a bunch of yesses
20:27 < ciaranm> dropping all of those would be rather crippling
20:27 <@Betelgeuse> I don't see why one no should get a feature dropped.
20:27 < Arfrever> You could vote separately for every feature.
20:27 <@dberkholz> the others i see are ANY-USE, DOEXAMPLE/DOINCLUDE, BANNED-COMMANDS (dohard/dosed), UNPACK-IF-COMPRESSED
20:27 < ciaranm> for most of the features there's a clear majority
20:27 <+tanderson> Betelgeuse++
20:28 <@leio-dl> I explained why that majority is not that meaningful in my e-mail
20:28 <@dberkholz> Betelgeuse: yeah, i guess my real intention is to make sure everyone knows *why* someone is voting no
20:28 <@leio-dl> many of the features with no's are not features but banning, tolo
20:28 <@leio-dl> too*
20:28 <@dberkholz> if they take that into account and still choose to vote for it, that's fine
20:28 < ciaranm> dropping anything with a single "no" is going to cripple EAPI 3, and postponing's a really bad idea
20:29 < bonsaikitten> so let's drop eapi3 and wait until people can agree.
20:29 <@dberkholz> a la src_install DOCS, i explained my opinion and most people just didn't agree
20:29 < bonsaikitten> I like that idea
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
20:29 < ciaranm> bonsaikitten: please troll somewhere else, we're trying to get this settled
20:30 < ciaranm> the two 'controversial' ones seem to be doexample and doinclude
20:30 < bonsaikitten> ciaranm: so am I. Stop throwing mud.
20:30 < ciaranm> which fortunately no-one really seems to care overly much about
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.
20:30 <@dberkholz> so, let's run through the "no's" quick now that everyone is definitely listening
20:30 < peper> 5x24 - gl with that ;]
20:30 <@leio-dl> maybe we all can find some dozen more minutes for the meeting if necessary
20:30 < peper> 25 even
20:31 <@Betelgeuse> peper: just nos
20:31 <@leio-dl> the ones with any 'no's is considerably smaller
20:31 <@dberkholz> let's start with doexample/doinclude
20:31 <@Betelgeuse> we use doexample quite often with java
20:31 <@dberkholz> my feeling is that these don't do anything interesting that insinto+doins can't do easily
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"
20:32 <@dberkholz> same permissions as any other arbitrary normal file
20:32 <@leio-dl> my feeling is the same, especially for doinclude
20:32 < Arfrever> dberkholz++
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)
20:32 <@Betelgeuse> dberkholz: insinto+doins can do that but it's much easier for newbies to write a single call
20:32 <@dberkholz> it's more material to learn that doesn't really simplify anything complex
20:32 <@dertobi123> indeed
20:33 <@Betelgeuse> dberkholz: you need a subshell if you don't want insinto sticking to exampels dir
20:33 <@leio-dl> dberkholz++
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.
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?
20:33 <@dev-zero> ferringb: please, there isn't much left we have to discuss
20:33 <@Betelgeuse> How about doinstall <dir> <stuff> ?
20:33  * leio-dl has time for 2-3 more hours :)
20:34 <@dberkholz> if i thought it was mildly pointless, i would've said whatever instead of no
20:34 <@Betelgeuse> well food for later eapis
20:34 < ferringb> Betelgeuse: exactly.
20:34 <@dberkholz> other council members got a useful, new opinion on doexample/doinclude?
20:35 <@dberkholz> otherwise let's take a vote and go with majority, since the idea is that we've spoken our minds
20:35 <@Betelgeuse> I vote yes
20:35 <@dev-zero> yes
20:35 <@dberkholz> no
20:35 <@leio-dl> maybe they should be taken separately
20:35 <@leio-dl> I vote no
20:35 <@leio-dl> for both
20:35 <@dertobi123> no for both
20:35 <@dberkholz> sure, if anyone has a split vote, feel free to say so.
20:35 <@lu_zero> I'd no both since Betelgeuse suggested something that could replace them
20:36 <@dberkholz> that's all 6 of us who are around, 2 yes 4 no
20:36 <@dberkholz> so it's in
20:36 <@dberkholz> let's move on to ANY-USE
20:36 <@leio-dl> I think you mean it's out?
20:36 <@dberkholz> errr, yes.
20:37 <@dertobi123> heh
20:37 <@leio-dl> ANY-USE I think is me
20:37 < ciaranm> both out? lemme update the spreadsheet
20:37 <@dberkholz> leio-dl: your reason for voting "no" once more, please?
20:37 <@dberkholz> tanderson: just to be perfectly clear when you're making the summary, doexample/doinclude will not be in EAPI=3.
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
20:38 <@Betelgeuse> ciaranm: is || ( foo? ( a ) b ) valid btw?
20:38 < ciaranm> Betelgeuse: currently yes, but it shouldn't be, and won't be with ANY-USE
20:38 <@leio-dl> Make a repoman check, what is the reason to have this an EAPI item
20:38 <+tanderson> dberkholz: k
20:38 < ciaranm> leio-dl: the reason is that it's already special-cased in PMS, and we want to remove that special case
20:39 <@dev-zero> since there is no use case you could solve with it
20:39 <@dev-zero> but you generate problems by using it
20:39 <@leio-dl> how are you sure about that?
20:39 <@leio-dl> that there is no use case. Why should it be said in PMS
20:39 <@leio-dl> there is no use case for other constructs as well conceptually
20:39 <@Betelgeuse> leio-dl: because Portage supports it in EAPI 0
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
20:39 < ciaranm> other constructs aren't special-cased in PMS currently
20:39 <@Betelgeuse> leio-dl: so if you are making a diff against EAPI 0 you must ban it
20:39 <@leio-dl> so it should be a repoman warning or error
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.
20:40 <@leio-dl> why should we set a precendence that EAPI's can say what kind of RDEPEND combinations are valid or not
20:40 < ciaranm> leio-dl: it's already something mandated by PMS
20:40 <@leio-dl> if you give me a bit, I can come up with many more nonsensical constructs there
20:40 < ciaranm> leio-dl: you can't cope up with any nonsensical constructs that have special wording in PMS to deal with them
20:40 <@Betelgeuse> You need rules to be able to parse RDEPEND.
20:41 <@dberkholz> does that mean we should be changing the meaning of || instead of banning a syntax?
20:41 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Nick collision from services.]
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.
20:41 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
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
20:41 <@leio-dl> exactly, there can be cases where it _could_ be used fine
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.
20:42 < ciaranm> leio-dl: no there aren't
20:42 <@lu_zero> anybody checked how widely it is used?
20:42 <@leio-dl> I believe zmedico agrees with ferringb?
20:42 <@Betelgeuse> ciaranm: Is there a valid syntax for use? inside || ( ) ?
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
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
20:42 < zmedico> leio-dl: yeah, I'd prefer warning
20:42 < ciaranm> Betelgeuse: as a direct child, it's syntactically legal at present but can't be used correctly
20:43 < darkside_> bug 168179
20:43 < Willikins> darkside_: https://bugs.gentoo.org/168179 "Packages misusing || ( use? ( ) ) constructs"; Gentoo Linux, Applications; NEW; ciaran.mccreesh@googlemail.com:qa@g.o
20:43 < ferringb> dberkholz: has_version... like I said, via appropriate ebuild voodoo...
20:43 <@dberkholz> ferringb: how can you use has_version in DEPEND?
20:43 < ciaranm> you can't even has_version it correctly because there can be multiple matches
20:43 <@leio-dl> yes, you prefer one of them
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
20:43 < ferringb> dberkholz: for dynamic imports, it's a different story imo
20:43 <@leio-dl> you can do that in python
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 ||
20:44 <@leio-dl> they actually use code
20:44 <@leio-dl> try:
20:44 < ferringb> or at least a muddier story that makes this grey
20:44 <@leio-dl>   import foo
20:44 <@leio-dl> except:
20:44 <@leio-dl>   import bar
20:44 < darkside_> looks like 6 ebuilds are still in violation? really a reason to be arguing about this?
20:44 < ferringb> elementtree/celementtree/python:2.6 is an example
20:44 < ciaranm> darkside_: we want to remove a whole load of messy special-casing, so yes
20:44 < ferringb> pkgcore would have such a dep if it weren't for the fact we bundle a fallback ;)
20:44 <@leio-dl> that special casing isn't going to go anywhere
20:44 <@dberkholz> any council members still unclear on the implications of this?
20:45 <@dberkholz> if not, we might as well vote
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
20:45 <@leio-dl> so to reiterate, there are valid use cases for this
20:45 <@Betelgeuse> Well could someone tell me why flatten use and then do || ( ) norma doesn't work if there are multiple children
20:45 <@Betelgeuse> I was only thinking with a single use? children
20:45 < ciaranm> Betelgeuse: did you see the example i posted to the list when this first came up?
20:46 <@Betelgeuse> ciaranm: that's probably some time ago and I have already forgotten
20:46 <@Betelgeuse> ciaranm: do you have an archive link?
20:46 < ciaranm> Betelgeuse: http://archives.gentoo.org/gentoo-dev/msg_4b2d8e11cb80aba847b8ab687ab5af47.xml
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
20:47 <@dev-zero> leio-dl: no, it's not. example: blueman
20:47 < ciaranm> leio-dl: no, it's not.
20:47 <@leio-dl> blueman?
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
20:47 <@leio-dl> you don't need to know that
20:48 <@leio-dl> it is irrelevant
20:48 <@dev-zero> leio-dl: check the ebuild, reason why even for dynamic languages such switching may be harmful
20:48 <@leio-dl> it works with both
20:48 < ciaranm> leio-dl: if you don't need to know it, you use || ( ) on its own
20:48 < ciaranm> leio-dl: if you do need to know, you use the use construct expanded to what you really mean
20:48 <@dev-zero> vote please?
20:48 <@leio-dl> dev-zero: what category is that?
20:48 <@dev-zero> leio-dl: net-wireless
20:49 <@dev-zero> leio-dl: but that doesn't really belong in this meeting
20:49  * ferringb notes again, pkgcore's xml usage is a valid counter example to this
20:49 < Arfrever> There's only: network? ( || ( net-dns/dnsmasq =net-misc/dhcp-3* ) )
20:49 < ciaranm> ferringb: || ( ) with no use? is the correct way of doing that
20:50 < ciaranm> ferringb: if you add in the use?, all you do is break up-front repeatability
20:50 < ferringb> ciaranm: obviously folk disagree on the 'correct' there.
20:50 <@Betelgeuse> I vote no and make this go to repoman then.
20:50 < ciaranm> ferringb: those people are missing the implications of lack of up-front repeatability
20:50 < Arfrever> dev-zero: What is exactly wrong in blueman?
20:51 <@Cardoe> tanderson: mark me as basically missing it.
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.
20:51 <@dev-zero> Arfrever: not now
20:51 <@leio-dl> the settings are stored in different place depending on which
20:51 <@Betelgeuse> But I am not strongly opionated either way.
20:51 < ciaranm> ferringb: if a user has USE=-foo, but has libfoo installed, does pkgcore still use libfoo if it's available?
20:51 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has quit [Connection timed out]
20:52 < ciaranm> ferringb: assuming libfoo is the first choice, of course
20:52 < ferringb> ciaranm: in cases of this sort, ||() constructs basically become ordered preference
20:52 <+tanderson> Cardoe: yep, you were more than 15 minutes late anyway I /think/
20:52 < ciaranm> ferringb: simple question. simple answer please?
20:53 <@Cardoe> tanderson: I was.
20:53 <+tanderson> goodie, my clock's not off then
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
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
20:54 <@dberkholz> i've gotta step away for a few, anyone feel free to bring it to a vote
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.
20:54 < loki_val> Please ban this feature. It makes my head hurt trying to figure it out.
20:54 < ferringb> loki_val: heh
20:54 <@leio-dl> it doesn't matter
20:54 <@leio-dl> if the package manager thinks its used or not
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
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
20:55 <+tanderson> loki_val: hehe, :)
20:55 < ciaranm> leio-dl: uh, i don't think you've thought that through
20:55 < ferringb> warn/error it, presuming no real world screaming after an eapi cycle, punt it.
20:55 < ferringb> for eapi deprecation of most stuff I kind of prefer that approach anyways
20:55 < ferringb> (where viable of course)
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
20:56 <@leio-dl> ciaranm: except they are not incorrect
20:56 <@Betelgeuse> add a warning now and let's drop it in EAPI 4 if not valid usage comes up
20:56 < ciaranm> leio-dl: read what i just said. they are.
20:56 <@leio-dl> read what I said, they are not? This goes nowhere like that.
20:57 < ciaranm> leio-dl: your "try to import foo, then bar" example is expressed as || ( foo bar ), not || ( foo? ( foo ) bar? ( bar ) )
20:57 <@leio-dl> My vote is that we make it a repoman warning instead, and see for EAPI-4
20:57 < ferringb> ciaranm: you're pointing at all fault w/ ||() in general btw, consider multiple satisfiers available...
20:57 < ciaranm> ferringb: || ( ) in general is at least well defined
20:57 < ferringb> Eh.
20:57 <@leio-dl> the USE check adds a preference
20:57 < ferringb> weak counterarg, that one.
20:57 < ciaranm> if a package does "try to import foo, then bar", that maps exactly onto what || ( foo bar ) does
20:57 <@leio-dl> it can be useful in certain embedded scenarios, for example
20:58 < ferringb> either way
20:58 <@dertobi123> ok, dito for repoman warning now and let's take another look for eapi-4
20:58 < ciaranm> leio-dl: er, the preference is ignored, though
20:58 <@leio-dl> but foo is something that needs a python library that has a global USE flag for it
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.
20:58 <@lu_zero> I agree with leio-dl first have a repoman check then bring it back to eapi-4
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)
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
20:59 <@dev-zero> tanderson: ok, thanks
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
21:00 <@dertobi123> right
21:00  * ciaranm marks that on the spreadsheet
21:00 <@Betelgeuse> I would like to see us finishing the list today so let's continue?
21:00 <+tanderson> dev-zero: np
21:00 <@dev-zero> Betelgeuse: jup
21:01 <@dev-zero> next: banned-commands?
21:01 <@leio-dl> Betelgeuse: too late, the day just changed for me ;p
21:01 <+tanderson> hah
21:01 <@Betelgeuse> leio-dl: same here
21:01 <@leio-dl> ok, so we have 24 hours.
21:01 <@dertobi123> Betelgeuse: uhrm, i need to get up again in a few hours ...
21:02 <@dberkholz> alright
21:02 <@Betelgeuse> Well if there's 4 of use around we can vote on what's left :)
21:02 <@leio-dl> for banned commands the only "no" is for dohard specifically I believe
21:02 <@dberkholz> i'm back now
21:02 <@Cardoe> leio: you can add me to the list for enforcement for EAPI=4
21:02 <@dberkholz> next question is part ofBANNED-COMMANDS dohard
21:02 < jmbsvicetto> Cardoe: You may want to direct that to tanderson
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.
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
21:03 <@leio-dl> which was a bug that simply needed fixing, for other reasons mainly
21:03 <@Cardoe> jmbsvicetto: he already left
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
21:05 <@leio-dl> (other than calling ln directly, but the PM can deal better with any portability concerns)
21:05 <@Betelgeuse> leio-dl: in a single dir use ln directly
21:05 < ciaranm> there's no guarantee it'll work even for the same directory. not all filesystems do hardlinks at all.
21:05 <@lu_zero> in that case it fallsback to symlink?
21:05 < ferringb> ick
21:05 < jmbsvicetto> Isn't a "best effort" better than nothing at all?
21:05 < ferringb> usual fallback for hardlink is a seperate copy
21:05 <@Cardoe> not all filesystems support symlinks as well
21:05 < ciaranm> lu_zero: no, there's a fallback to a copy
21:05 <@leio-dl> yes, the documentation implying that there is a guarantee should be changed then
21:06 < ciaranm> Cardoe: if there's no symlink support you can't install gentoo onto it
21:06 <@Betelgeuse> Do we support file systems with no hardlinks on system partitions?
21:06 <@Cardoe> ciaranm: I'll make Gentoo on vfat a reality someday ;)
21:06 < ciaranm> Betelgeuse: yes
21:06 <@lu_zero> which ones?
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...
21:07 <@Betelgeuse> I wonder how much upstream software relies on hardl inks.
21:08 <@leio-dl> well, probably not much that would fall over if it's a copy instead
21:08 <@lu_zero> is dohard used widely?
21:08 <@leio-dl> but a copy takes space
21:08 <@dev-zero> lu_zero: no
21:08 < ciaranm> dohard's not used widely and mostly used incorrectly
21:08 < ferringb> hardlinks have other issues anyways... they're not really represented in the vdb at all
21:09 < ferringb> treated as a seperate copy there (chksums and all)
21:09 <@dberkholz> dohard is used by 6 packages
21:10 <@dberkholz> streamixer, nbsmtp, w3mimgfb, mailwrapper, pipes, cdecl
21:10 <@dev-zero> and one of them does a hardlink across directories
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)
21:10 <@dberkholz> all of them stay within /usr/{bin,lib,sbin}
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.
21:11 <@leio-dl> so in a common scenario of that being mounted on / or /usr, the hard link is technically working
21:11 <@leio-dl> (not guaranteed)
21:11 <@dev-zero> dberkholz: nope, nbsmtp doesn't
21:12 <@Betelgeuse> well dohard would become fatal in EAPI 3 so if there's no hard link support it would not succeed
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
21:12 <@lu_zero> hmm
21:12 <@Betelgeuse> so you would not end up in an unwanted state
21:12 <@dberkholz> dev-zero: what does nbsmtp do outside of /usr/bin, /usr/lib, and /usr/sbin? is my grep broken?
21:12 <@leio-dl> I don't think it should become fatal. So I guess we need some changes anyway in what it does
21:13 < ferringb> unionfs likely allows for inter-directory hardlink failure btw
21:13 <@lu_zero> I'd keep it for now and try to overhaul it a bit
21:13 <@Betelgeuse> Is it useful enough to keep a complicated spec?
21:13 <@Betelgeuse> Just use ln || die for current usage?
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
21:14 <@dev-zero> dberkholz: probability is low, the case probably doesn't exist, but...
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
21:14 < ferringb> Betelgeuse: || die doesn't do jack though since when it would fail is during merge
21:14 <@Betelgeuse> If people want to shape it up, it can come back later.
21:15 <@Betelgeuse> ferringb: true
21:15 < ciaranm> ln can fail at build time
21:15 < ciaranm> the || die is still useful
21:16 < ferringb> eh, only in build
21:16 < ferringb> binpkg is completely exempted there, so it's not a good gurantee
21:16 < ferringb> can only check in preinst, which would suck
21:16 <@Betelgeuse> ferringb: but dohard suffers the same thing any way
21:16 <@Betelgeuse> so ot
21:17 < ciaranm> just tell people to use symlinks. far easier.
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.
21:17 <@leio-dl> is what I would propose as an alternative then
21:17 < ciaranm> leio-dl: bleh. that's not what it does.
21:17 < ferringb> that's what it should do however
21:17 < ciaranm> leio-dl: dohard can't even know whether it'll work later on
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
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
21:18 < ciaranm> ferringb: but it can't provide that information up-front, which is what leio-dl's saying it has to do
21:18 <@leio-dl> it doesn't need to provide anything up front
21:19 <@leio-dl> with that alternative description the package manager at merge time does what it can
21:19 < ferringb> ciaranm: different reading there.  I interpret most of that as merge time rather then just build.
21:19 <@dberkholz> we're running over and i need to get going.
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
21:19 < ferringb> ciaranm: my standpoint, once it goes into ${D}, the ebuild shouldn't be screwing with it.
21:19 <@dberkholz> do you want to continue the discussion about this and --if-compressed?
21:19 < ciaranm> and the econf options stuff, that has a no
21:19 <@dberkholz> oh yeah, missed that one.
21:19 < ferringb> although yes that can make perms slightly tricky (did the hardlink succeed?  if not, I need to chmod it... etc).
21:20 -!- maekke [n=maekke@gentoo/developer/maekke] has quit [Client Quit]
21:20 <@dertobi123> can we make it another meeting then, next week or so?
21:20  * ciaranm cries
21:20 < ciaranm> can we just go with the majority for the sake of finally getting this done?
21:20 <@dev-zero> jup
21:20 <@dertobi123> if we're not going to discuss everything for another 30 minutes each?
21:20 <@leio-dl> I need to go afk for 3 minutes
21:20 < ferringb> next meeting.  I dislike rushing stuff that folks don't fully agree on...
21:20 -!- spitfire__ [n=none@abja91.neoplus.adsl.tpnet.pl] has joined #gentoo-council
21:21 <@dev-zero> ahem, we had a couple of weeks time to think it through, there was the list request
21:21 <@dev-zero> no running anymore, please
21:21 <@dberkholz> and yet people continue to have things to discuss, as evidenced by this meeting
21:22 < ciaranm> this should have been over weeks ago. unfortunately some people want to be council members for one hour a week.
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...
21:22 < ferringb> dev-zero: so find out who truly gives a damn ;)
21:22 < bonsaikitten> grumble.
21:22 < NeddySeagoon> reconviene another day, it need not be next meeting
21:23 <@Betelgeuse> Let's just put the yesses here: 1. yes
21:23 <@dev-zero> yes, yes from me
21:23 <@dertobi123> and yes from me
21:23 <@Betelgeuse> one more and we are done
21:24 <@dberkholz> what are we even voting on here, dohard or everything left on the list
21:24 <@leio-dl> I just hope everyone understands the implications here.
21:24 <@Betelgeuse> dberkholz: banning dohard/dosed
21:24 <@dev-zero> both of it
21:24 <@Betelgeuse> I don't see the complexity being worth it
21:24 <@leio-dl> dohard was discussed by me long ago. No-one ever replied to me
21:25 <@dberkholz> i don't care about dohard
21:25 <@Betelgeuse> leio-dl: you mean a couple packages just use symlinks?
21:25 <@dberkholz> i am fine with removing it. not like EAPI=2 is going to disappear tomorrow
21:25 <@Betelgeuse> leio-dl: they don't even have to migrate to EAPI 3
21:25 <@leio-dl> until you need to use both dohard and a EAPI=3 feature
21:26 <@Betelgeuse> leio-dl: there's nothing in the tree that needs dohard
21:26  * lu_zero doesn't care about dohard that much as well
21:26 <@leio-dl> maybe that's because portage hard link handling was quite broken until January this year
21:26 <@dertobi123> so we have 4,5 yes for now, right?
21:27 <@dberkholz> doesn't that just prove it wasn't needed?
21:27 <@dertobi123> can we move on then, please?
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.
21:27 <@Betelgeuse> I see dosym as better than falling back on copies
21:27 <@leio-dl> fine, lets ban it and move on.
21:27 <@leio-dl> there are technical reasons to use hard links instead of symlinks
21:27 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has joined #gentoo-council
21:27 <@leio-dl> where a copy is better than a symlink
21:28 <@Betelgeuse> sure but doesn't see a big need for stuff ebuidls manually install
21:28 < ciaranm> econf options!
21:28 < ciaranm> four yes, one no from leio-dl
21:28 <@dberkholz> ok, we've pretty much finished up with removing dohard.
21:28 <@leio-dl> I am fine with --disable-dependency-tracking
21:28 <@leio-dl> --enable-fast-install is just irrelevant. There is even no reasoning of why that should be passed
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
21:29 <@leio-dl> --enable-fast-install is a libtool specific option, which is already the default
21:30 <@Betelgeuse> so no harm in including it?
21:30 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)]
21:30 <@leio-dl> there is the same harm as --disable-dependency-tracking, instead in this case there is no gain either
21:30 <@leio-dl> hand-made configure scripts might very well implement all the other options, because they are standard in autoconf
21:30 <@dberkholz> ebuilds would be a lot longer if we respecified every default configure option
21:31 <@leio-dl> but no-one will want to implement all these libtool configure arguments when they aren't even using libtool
21:31 <@Betelgeuse> I foudn ciaranm's argument about ignoring unknown options valid
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
21:31 < ciaranm> the hand-made thing is a straw man
21:31 <@Betelgeuse> libtool might change default
21:32 <@dberkholz> so might everything else, and yet we don't specify every single option
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
21:32 <@Betelgeuse> vote:
21:32 <@Betelgeuse> 1.yes
21:32 <@dberkholz> i'm for dep tracking, against fast-install
21:32 <@leio-dl> also, there is not even any word from the one who has "requested" it
21:32 <@leio-dl> not sure why this is even considered as part of EAPI-3 (--enable-fast-install)
21:33 <@leio-dl> a bug title was changed with no explanation. That's it.
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...
21:33 <@lu_zero> I'm for dep tracking, not fast install
21:33 <@dev-zero> I'm for both
21:33 <@leio-dl> bug 211529 is the one in question
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
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.
21:33 <@dertobi123> i'm with lu_zero and dberkholz on that
21:33 <@lu_zero> ferringb mplayer and ffmpeg are better left w/out econf
21:34 <@leio-dl> I'm against --enable-fast-install, whatever with --disable-dependency-tracking
21:34 <@leio-dl> so we have 4 no's
21:34 <@dberkholz> ok, that's enough folks
21:34  * ciaranm updates
21:34 <@dberkholz> plus on --disable-dependency-tracking, minus on --enable-fast-install
21:34 < ferringb> lu_zero: tend to agree.  either way, only potential I could think of
21:35 <@leio-dl> when libtool changes default, we can reconsider
21:35 <@dberkholz> last topic is unpack --if-compressed only allowing known suffixes
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
21:35 -!- spitfire_ [n=none@abjg217.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
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
21:37 <@leio-dl> no, it was uncertainty of the same thing dberkholz is against
21:37 < ciaranm> what it means is that unpack foo.txt will now die, unless you do unpack --if-compressed foo.txt
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
21:37 <@leio-dl> why have to pass it at all
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
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?
21:39 <@dberkholz> perhaps adding a few of the most common uncompressed suffixes would help
21:39 < ciaranm> it's not making things for ebuild developers at all. it's making it easier for them.
21:39 < ferringb> seems like a rather zealous safety feature more annoying then useful
21:39 <@dberkholz> my main annoyances are .txt files and scripts
21:39 <@dberkholz> .sh, .py, .pl
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
21:40 < ciaranm> dberkholz: and how often do you pass those to unpack?
21:40 <@dberkholz> every time i don't define a custom src_unpack...
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
21:40 < ciaranm> dberkholz: uh, no. check the default src_unpack in eapi 3
21:40 <@dev-zero> c
21:41 < ferringb> it's not like this is an error that'll silently slip by also ;)
21:41 <@dev-zero> dberkholz: meaning that default src_unpack is passing --if-compressed
21:41 < ciaranm> ferringb: it's highly unobvious when people do unpack foo.xz and foo.xz silently gets passed through ununpacked
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.
21:41 < ferringb> ciaranm: not really.  the build blows the hell up shortly there after
21:42 < ciaranm> ferringb: and people wonder why, especially with some extensions being eapi dependent
21:42 < ferringb> personally, I consider it a daft feature- it'd be less annoying if it was inverted (--all-compressed)
21:42 < ciaranm> experience has shown that you very rarely have to specify it
21:43 <@dberkholz> so, if it's in the default to ignore them, then how is it even a useful thing to add?
21:43 < ferringb> raising the question of it's usefulness in light of the build blowing up if they screw up anyways
21:43 < ciaranm> dberkholz: stick 'unpack foo.xz' in an ebuild right now. it will silently do nothing.
21:44 <@dertobi123> as expected
21:44 <@dberkholz> same as would happen if i stuck foo.cx in SRC_URI and didn't have src_unpack
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)
21:44 < ciaranm> try 'gunzip foo.txt'
21:44 <@dberkholz> now, i'll get different behavior in those two scenarios because default_src_unpack is passing extra nondefault options
21:44 < ciaranm> dberkholz: no you wouldn't, because you'd just call 'default'
21:45 < ciaranm> the *only* thing this alters is where people explicitly call 'unpack'
21:45 < ferringb> eclasses...
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+
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
21:47 <@leio-dl> they do
21:47 <@leio-dl> a common src_unpack in an eclass is
21:48 <@leio-dl> eclass_src_unpack() {
21:48 <@leio-dl>         unpack ${A}
21:48 <@leio-dl>         cd "${S}"
21:48 <@leio-dl>         has ${EAPI:-0} 0 1 && gnome2_src_prepare
21:48 <@leio-dl> }
21:48 <@leio-dl> I guess maybe it shouldn't export src_unpack with EAPI-2+ then
21:48 < ciaranm> that should be rewritten the clean way
21:48 <@leio-dl> but we must do that export
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
21:49 <@dberkholz> ciaranm: so in what cases would people be calling unpack in EAPI=3?
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
21:50 <@dberkholz> this seems like a lot of special casing for unlikely scenarios
21:51 < ciaranm> by that argument, you could say that giving people explicit access to 'unpack' is unlikely
21:51 <@dberkholz> yep, you could.
21:51 < ciaranm> it still happens often enough that unpack is useful, and that it should behave sanely on error
21:51  * ferringb still says invert the bugger... preserves the common case without detriment while covering the potential ciaran is worried about
21:52 < ferringb> or nuke the proposal. ;)
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.
21:53 < ciaranm> silently ignoring failures is highly weird
21:53 < ferringb> I'd rather it just cp it over if it's not a supported extension
21:53 <@dberkholz> i feel like parameters should get added in the special cases, not by default
21:53 < ciaranm> that'd change existing behaviour
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.
21:54 < ciaranm> dberkholz: the special case *is* "i want this argument i'm explicitly specifying to be ignored"
21:54 < ferringb> dberkholz: you nailed my view.
21:55 <@dberkholz> except that special case happens every time you do SRC_URI="foo.tgz bar.txt" and don't define src_unpack
21:55 < ciaranm> but then you're not dealing with unpack yourself, so it's irrelevant
21:56 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has quit [Read error: 60 (Operation timed out)]
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
21:57 <@dberkholz> any other council members want to say something, or ready to vote?
21:57 <@dev-zero> I vote yes
21:57 <@dertobi123> ready to vote and no
21:57 <@lu_zero> no as well
21:58 < ciaranm> Cardoe and Betelgeuse were yes before the meeting, dunno about now
21:58 <@leio-dl> some points were brought up that when thinking more about I _might_ change my mind, but a no right now
21:59 <@Cardoe> ciaranm: hmm?
21:59 <@dberkholz> Cardoe: on --if-compressed
22:00 <@Cardoe> oh
22:00 <@Cardoe> Did we extend the meeting length?
22:01 -!- Netsplit hubbard.freenode.net <-> irc.freenode.net quits: kallamej, GrantN05, dleverton, wrona
22:01 <@dberkholz> felt like actually getting through EAPI=3 today
22:01 <@dertobi123> Cardoe: obviously yes :P
22:01 -!- billie80 [n=billie@dslb-094-218-009-031.pools.arcor-ip.net] has joined #gentoo-council
22:01 <@dberkholz> and this is the last bit
22:01 <@Cardoe> wish that had gone out in the e-mail
22:01 <@leio-dl> there was also SLOT-OPERATOR-DEPS
22:02 <@dberkholz> well, it didn't get extended till we were about out of time and decided we wanted to extend
22:02 <@dberkholz> it's not an advance notice thing
22:02 -!- Netsplit over, joins: dleverton, wrona, kallamej, GrantN05
22:02  * ferringb still wants mtime (in one form or another) yayed nayed, although unlikely considering folks ignoring it :P
22:02 <@dberkholz> i can finish this, then i'm done
22:02 <@dertobi123> so can we finish --if-compressed, please?
22:02 <@dberkholz> i cannot take any more time out of work
22:02 <@Cardoe> sure
22:02 <@Cardoe> I was a yes on it
22:03 <@leio-dl> the point was to understand the no-sayers view and then perhaps that changes
22:03 <@leio-dl> but I think we have 4 no's anyway, don't we?
22:03 < ciaranm> leio-dl: only if you're voting no
22:03 <@dberkholz> i haven't changed my opinion
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
22:04 <@Betelgeuse> People oppose --if-compressed by default in src_unpack I presume? It will still be added to unpack as an option?
22:04 < ciaranm> Betelgeuse: no, they're opposing it entirely
22:04 <@leio-dl> it's about the option I believe.
22:04 < ciaranm> the option and the src_unpack pretty much have to go together
22:04 <@leio-dl> If the option is voted to happen, most will want that option passed in default_src_unpack I bet
22:04 <@dberkholz> if it's on by default so often, it's not really a useful validation
22:05 <@Betelgeuse> leio-dl: eclass authors can still decided on way or the other
22:05 <@dev-zero> leio-dl: that's already the case in eapi-3
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
22:05 <@leio-dl> yes, the change of src_unpack seems to be the same item in the consideration list.
22:06 <@leio-dl> I vote no
22:06 < ciaranm> lame!
22:06 <@Betelgeuse> do we still have something left?
22:06 <@leio-dl> I would vote yes for a --all-compressed option
22:06 < ciaranm> looks like it's out :(
22:06 <@dertobi123> it is
22:06 <@leio-dl> I have reservations about :* syntax that I didn't manage to think through today
22:07 <@dberkholz> i need to leave now
22:07 < ciaranm> slot-operator-deps is down as two critical, three yes and a query from leio-dl
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.
22:08 <@Cardoe> ciaranm: so are you saying you're opposed to --if-compressed? Wasn't it your proposal?
22:08 <@dberkholz> leio-dl: can you post your query by monday so we can nail that down by next thursday?
22:08 < ciaranm> Cardoe: no, i'm saying i want --if-compressed, and i think you all suck for not going for it
22:08 <@dberkholz> other than that, EAPI=3 is good to go
22:08 <@leio-dl> I have a visitor till Monday
22:08 < ferringb> heh
22:08 <@Cardoe> ciaranm: oh. I agree
22:08 <@leio-dl> so I'm not sure I can do Monday. I can promise Tuesday
22:09 <@Betelgeuse> dberkholz was talking about Thursday
22:09 <@leio-dl> I think the implementation can start for portage
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 =)
22:09 < ciaranm> quick! four people vote yes to slot-operator-deps so we can just approve the frickin' thing right now
22:09 <@Cardoe> Can someone ensure the FULL log is posted somewhere so I can read it on my next plane flight?
22:09 <@Cardoe> ciaranm: didn't I already say yes?
22:09 <@dberkholz> Cardoe: you were on irc the whole time, don't you log?
22:09 < ciaranm> Cardoe: yes, but you need to say so now for it to count as not being deferred
22:09 <@Cardoe> ciaranm: well then yes
22:09 <@Cardoe> dberkholz: not on this client
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?
22:10 <@leio-dl> please by all means start implementing slot-op-deps
22:10 <@dev-zero> and why did we extend the meeting time to bring through the issues when we wait again?
22:10 <@leio-dl> I do not want to see it not be part of EAPI-3
22:11 <@dev-zero> so, then lets vote
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
22:11 <@Betelgeuse> yes
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
22:11 <@dev-zero> and nail that thing done for once
22:11 <@Cardoe> leio-dl: ok so change to yes
22:11 < ciaranm> that's yes from dev-zero, Betelgeuse and Cardoe. please one more. make my life easier!
22:11 <@dertobi123> yes and good night
22:12 < ciaranm> \o/
22:12  * dertobi123 gotta go to bed
22:12 <@dev-zero> yes from me