export.log

export.log (text/plain), 13.88 KB, created by SpanKY on 2006-02-27 22:33:07 UTC

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