[21:07] SpanKY: why do you think export_functions isn't needed anymore btw? [21:09] solar: glibc mostly ;p [21:10] Hm. [21:14] ferringb: because (1) someone said so a while back and (2) very few ebuilds use it anymore [21:14] someone is a moron. [21:15] s/ebuilds/eclasses/ [21:15] why did i read that as mormon ? [21:15] that moron was a portage dev :P [21:15] SpanKY: lots of eclasses still use it. [21:15] SpanKY: still 'twas a moron. [21:15] (even if I said it, which I didn't. :) [21:15] well it is kind of stupid [21:15] requiring EXPORT_FUNCTIONS [21:15] considering it's trivial to code it automatically [21:16] err... think that one through. [21:16] i did [21:16] in terms of inheritance, it specifies which phases to override the default with. [21:16] if you're suggesting it be a forced "override them all", that's stupid. [21:16] if you're suggesting they name the func with the exact phase name, again stupid (can't do multiple inherits). [21:17] i'm suggesting the logical step [21:17] holy shit i seem to be getitng more and more unexplicable lagspikes with portage 2.1... [21:17] not saying the forced $ECLASS_$PHASE is a good convention, but the reasoning for it is wise. [21:17] automatically override only the funcs that are defined [21:17] my computer has been rendered unusable... [21:17] and 10% cpu.. .wtf disk i/o? [21:17] SpanKY: forces ebuilds to restore defaults if an eclass bundles a non-default replacement. [21:18] which sucks, also. [21:18] it can and should be done [21:19] take it up with one of the portage maintainers then, and figure out how to do it without breaking existing eclass support. [21:19] it *could* be slipped into g33, but I still posit it's a damn stupid idea :) [21:19] is there a program to check disk i/o? [21:19] g33 is portage-ng/savior/bcportage today? [21:20] SpanKY: yes, it's an extra line in an eclass. it's also a knob eclass maintainers can use for finer granularity in inheritance [21:20] solar: g33 is ebd [21:20] anyone can add it to trunk if they want, or they can grab my rewrite work and go from there. [21:20] right, making maintainers add hacks to eclasses to workaround portage deficiencies is a damn stupid idea [21:20] wtf [21:21] SpanKY: it's not a portage deficiency [21:21] it's an extra knob eclasses can use to change the overrides. [21:21] SpanKY: you do any oop? [21:21] yeah, exactly, it's oop [21:21] shitty form, but yes. [21:22] you may not always want them to override [21:22] why would you define a default function when you wouldnt want them to override [21:22] and if you dont want them to override, give it a different name [21:22] "give it a different name" ? [21:23] wtf does that mean in context of export_functions actions? [21:23] dont name it $ECLASS_$FUNCTION [21:23] ugh. [21:23] gee, that smell like a hack to you? [21:23] SpanKY: you can label it a deficiency if you want, but the alternative I'm labeling a hack _also_ [21:24] there are valid reasons for both changes, the question is which is better, and if the change can be made. [21:24] so you'd push more onto maintainers rather than automating it in the backend [21:24] one of these is prone to errors, the other is not [21:24] SpanKY: it's one fucking line dude. [21:25] and we've illustrated that maintainers constantly get this "one fucking line" wrong [21:25] SpanKY: I've seen 5 bugs or so. [21:25] ive silently fixed eclasses since i joined [21:25] I really don't define that (Especially when the 5 dudes screwing it up are new) as "always getting it wrong" [21:25] well fucking educate them about it [21:26] I already explained why it's not an easy change over [21:26] i have [21:26] people still get it wrong [21:26] would you like me to cronjob e-mail reminders ? [21:26] like some sort of mailing-list subscription reminder ? [21:26] SpanKY: well I guess we should remove the other functionality that folks can remove too, right? [21:27] s:remove:screw up: [21:27] the eclass development docs specifically state how eclass_function works last I checked [21:27] dont twist the discussion [21:27] i'm advocating automating internal aspects [21:28] not twisting the discussion, I'm pointing out that you're trying to streamline this thus removing the underlying useful functionality [21:28] your reasoning is that people fuck it up too much [21:28] the underlying functionality should remain, an automated stomping of the template is a stupid idea (imo)- we can't do it with eclass v1 anyways do to backwards compatibility issues. [21:28] that is one supporting argument [21:29] my main reason is that there's not reason to force people to learn it [21:29] i dont see how it's useful at all for people to have this [21:30] because not every function needs to be a default; it's merging of namespaces, export_function specifies the intersection. [21:30] now that I think about it, the "call it something else" argument goes along with oop languages, where you override by using the same name [21:30] zmedico: oop languages have seperated namespaces typically, you can get at the original method via referencing the class [21:31] anyone know why process "cc1" spawned by emerge needs 50 megs of ram? [21:31] we can't do it in bash; an offset might work but it still is fugly voodoo. [21:31] aaronf0: it's the compiler [21:31] and is swapping like all fuck? [21:31] aaronf0: use less ricer flags [21:31] heh [21:31] ferringb: 50 megs of ram, and completely tooling a system... [21:31] SpanKY: im lacking in ricer flags [21:31] wrong channel either way [21:31] SpanKY: as theres about all of 3 for my box... [21:31] aaronf0: compile some C++ code, you can easily use hundreds and hundreds of megs [21:31] NOTABUG [21:32] its not like im -j200 either [21:32] SpanKY: zmedico: personally I think it's a bad idea doing the change. you're effectively requiring that the function be named mysql_not_default_pkg_prerm (fex), which is fugly in comparison to just mysql_pkg_prerm and leaving pkg_prerm out of export_functions. [21:33] either way, backwards compatibility is one thing that must be addressed if y'all (and the community) think it's wise. [21:33] oh, I see, we don't want a bunch of default phases suddenly being overriden by the ones from eclasses [21:34] ferringb: which is unintuitive to define such a function and *not* have it be the default [21:35] eclipse-ext.eclass:function pkg_postinst() { [21:35] nice [21:35] yeah, that right there is stupid. [21:35] * ferringb shrugs [21:36] SpanKY: currently, eclass funcs are commonly prefixed. you're suggestion is to deviate from that for a bit of ease (ignoring all concerns of making the change) [21:37] either way, y'all decide it. no longer my problem. :) [21:37] * ferringb goes back to work [21:37] i'm suggesting we make the very common usage easier [21:38] especially since it's easy to screw up and devs do screw it up [21:38] if they don't know what export_functions does (those who are fucking up don't), frankly they shouldn't be writing eclasses for the tree. [21:38] it's up there with "don't stick stupid shit in global scope". [21:38] great, feel free to send an e-mail out [21:39] "All you morons, stop writing eclasses, only us smart peeps are qualified to do so" [21:39] make QA do it. [21:39] I'm not even on -dev ml. [21:39] "All you morons who don't understand what export_functions does, read the damn function, kthnx" [21:39] SpanKY: the common usage isn't that difficult, it's just extra work to go and change things that can lead to breakage [21:40] i'm not saying it's difficult [21:40] i'm saying it's pointless extra overhead [21:41] it's one damn line that allows them control over the namespace. [21:41] it's a feature [21:41] * antarus|work notes if eclasses were properly QA'd in the first place we probaly wouldn't have this issue [21:41] I'm not saying make things hard, but christ man it's pretty damn simple- the skeleton eclass should even _state_ how EXPORT_FUNCTION is used [21:41] antarus|work: agreed. [21:42] right, i'll keep waiting for repoman to commit eclasses [21:42] maybe i should buy a bunker too for the coming ice age :p [21:42] Repoman was not what I was referring to [21:42] or just get off your ass and implement it. :) [21:42] less bitching, more coding++ [21:42] or we could remove the need to QA it [21:43] The current policy is that adding an eclass requires mail to -dev, which means someone should be reviewing the code for sanity, especially in cases such as stupid use of this functionality [21:43] SpanKY: removing features cause people sometimes screw up with them is a bad route to go. [21:43] but half the time mail is never sent anyway [21:44] are there any functions for parsing metadata.xml files? [21:44] tcort: Ask solar [21:44] antarus|work: anyone ever port the -svv modifications from ebd to trunk? [21:45] tcort: Jeeves can do it via python scripts [21:45] ferringb: Not to my knowledge [21:45] tcort: your best bet is using an XML DOM, IIRC, marienz knows how, and solar has the scripts ;) [21:46] tcort: ...or grab the functionality from the ebd branch of portage and split a patch for trunk for the portage maintainers [21:46] * antarus|work hasn't done much coding lately, mostly trying to document random things.. [21:46] and apparently get really far behind in school too, heh. [21:46] * zmedico wants a full fleged portage manual [21:47] don't we all...heh [21:52] so the only reason you can give as to why it should remain is so that maintainers have this way to control which functions arent exported [21:52] can you guess how many eclasses utilize said functionality ? [21:53] SpanKY: so, are you saying they should be called $ECLASS_$FUNCNAME still, but they automatically get aliased? [21:53] yes [21:53] tcort: http://dev.gentoo.org/~solar/portage_misc/metadata.py [21:53] if i have eclass foo.eclass, and i create a function "foo_src_compile", it should automatically be the default "src_compile" [21:54] and really, any other behavior is intuitive imho [21:54] SpanKY: sounds like glep material [21:55] no point in writing a GLEP when people in here seem to be opposed to the idea [21:55] solar: thanks :) [21:56] what happens when two eclasses export the src_compile [21:56] tcort: remove the nocolor() [21:56] currently, the last eclass inherited gets the definition [21:56] as it should [21:58] SpanKY: one thing to consider is that the EAPI needs to be known to decide which functions to export [21:58] i dont pay attention to EAPI [21:58] considering nothing uses it [21:59] solar: where do I get cElementTree? [21:59] merge it [21:59] SpanKY: well, EAPI does matter in the long term, so your proposed change requires that the eclass define the EAPI [22:00] * ferringb sighs [22:00] added that fucking var, and it's what will allow people to move forward with the format, but it's amazing the number of folks who just brush the damn thing off. [22:01] can't just add shit to the format without versioning it, it's the same thing in terms of soname versioning [22:01] EAPI is the main show stopper I see with his idea here [22:02] keeping EXPORT_FUNCTIONS means the eapi doesn't really matter, they just export the functions they want to, regardless of EAPI [22:03] late binding of functions is better. [22:03] final eapi, can discern what to do then rather then allowing for eapi to change along the way. [22:19] so should i go ahead and file a bug :P [22:24] so, I guess you can export anything that starts with $ECLASS_ [22:25] nothing else makes sense [22:25] just the standard functions [22:25] [New Bug] http://bugs.gentoo.org/124347 nor, P2, All, vapier@gentoo.org->tools-portage@gentoo.org, NEW, pending, add inject support to emaint to replace loss of feature from emerge [22:25] (pkg|src)_* ebuild functions [22:26] well, to make it EAPI independent, you have to do anythin that starts with $ECLASS_ [22:26] that doesnt make any sense [22:27] what aout when src_config comes along [22:27] i highly doubt anyone who is using EXPORT_FUNCTIONS with something other than a standard (pkg|src)_* does it on purpose [22:27] meaning it's an unintended bug and fixing the bug wouldnt affect anything [22:28] well, (pkg|src)_* is an EAPI dependent thing [22:29] just export everything, and it's independent of EAPI [22:34] zmedico: late binding... [22:35] eg, after everything is done, walk the inherits and start slipping missing functions in from the namespace stack. [22:35] that sounds good