Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
I don't want to be the guy that kicks people off lists; but I will do it; so keep the thread on topic[0] and be nice[1]. I know everyone here is capable of that. Feel free to sling the personal crap comments somewhere more appropriate (such as a personal diary, blog, or in verbal complaints to a spouse or drinking buddy.) Remember that text is hard to communicate through and regardless of any intentions, people are judged by how they are perceived and 'helpful' intentions may not come off quite as helpful as some would like; chose your words carefully. Consider this your first and last warning from Userrel. -Alec [0] Subject: Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses [1] http://www.gentoo.org/proj/en/council/coc.xml
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Alec Warner [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 10 Oct 2008 00:17:14 -0700: Consider this your first and last warning from Userrel. FWIW... at least on gmane, that appears as a response to aballier (gentoo dev), with references headers indicating the same thing, but given that (1) there was no attribution or quote so it's not possible to say who it was intended for directly, (2) I didn't see what was offensive in his post, and (3) that the warning was from userrel not devrel, I believe the warning was intended for someone other than the direct parent (my grandparent) poster. IOW, aballier may be very confused right about now... I know I was but at least it's not my posts in the balance like his appear to be, while someone else (my public attempt at a guess who wouldn't help) may be missing a warning they need to see (tho hopefully they got the message in any case). -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
On Fri, Oct 10, 2008 at 5:41 AM, Duncan [EMAIL PROTECTED] wrote: Alec Warner [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 10 Oct 2008 00:17:14 -0700: Consider this your first and last warning from Userrel. FWIW... at least on gmane, that appears as a response to aballier (gentoo dev), with references headers indicating the same thing, but given that (1) there was no attribution or quote so it's not possible to say who it was intended for directly, (2) I didn't see what was offensive in his post, and (3) that the warning was from userrel not devrel, I believe the warning was intended for someone other than the direct parent (my grandparent) poster. IOW, aballier may be very confused right about now... I know I was but at least it's not my posts in the balance like his appear to be, while someone else (my public attempt at a guess who wouldn't help) may be missing a warning they need to see (tho hopefully they got the message in any case). Assume the warning was for the whole list; I just replied to the last message in the thread; blame gmail ;) -Alec -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
I don't quite see how that deals with an eclass calling econf in its exported src_compile? Seems like EAPI versioning for eclasses (with implicit 0 only) is more what you're after for that issue (so the PM could suppress src_configure if src_compile is going to resolve to an EAPI-0 eclass function, although the inheritance stack might prove problematic.) I don't know of any way for the pm to detect if the eclass supports given eapi or not, and even less if exported src_compile will be eapi-2 aware or not. Having to die for an unsupported EAPI seems like the wrong approach; if it's not going to work the PM shouldn't source it. If it can be made to work by filtering certain functions, that's doable. I tend to see dying for an unsupported eapi as eclass versioning for the poor people but that's the only thing we can do atm afaik. For now, all eapi are backward compatible wrt to sourcing so that's not really an issue to source an eapi-0 eclass withing an eapi-2 ebuild. I think there has been a discussion on eclasses vs eapi before and the outcome was that eclasses should add hacky checks for eapi; which means to me we'll have to adjust those hacky checks for each new eapi. However, for now, not dying allows workarounds like: http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/ogmrip/ogmrip-0.12.2.ebuild?view=markup but I don't consider it very pretty. In the worst case, an ebuild switching to EAPI will require eclass maintenance; this is where the separation of elibs (useful code) and eclasses (template ebuilds) would be useful, although that needs versioning too. The problem will remain for this new definition of eclasses; glad to see you're volunteering to fix every single eclass that exports a src_compile/unpack function for eapi-2 :) If by template ebuilds you mean the EXPORT_FUNCTIONS line and some deps, then I dont see the difference between eapi versioning for eclasses and a switch/case for each eapi in the unversioned eclass. Note that useful code can differ upon eapi (I'm thinking about has_version checks). Regards, Alexis. signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Alexis Ballier wrote: Indeed; different names could be given to different implementations of the same thing, but that might completely kill the point of abstracting it. Maybe eclasses should die on unknown eapi; the fact is I really hate the current way it's done when switching an ebuild to EAPI-2 which uses an eclass that exports src_compile; most eclasses don't special case eapi-2 yet and we end up running econf twice at best. I fear that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll support src_configure too) An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi would help too. Ciaran McCreesh [EMAIL PROTECTED] wrote: An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place checking for eclass screwups... yes; that's just a matter of choice though, but for eclasses it's probably not luxury. Well it's simple enough to check (and give a QA warning) for unknown functions; adding a check for a specific string prefix (or to exclude a certain subset) in EXPORT_FUNCTIONS (based on current EAPI) is simple enough too. Is that what you mean? The behaviour to trigger could change eg for debug mode, or a repoman check. I don't quite see how that deals with an eclass calling econf in its exported src_compile? Seems like EAPI versioning for eclasses (with implicit 0 only) is more what you're after for that issue (so the PM could suppress src_configure if src_compile is going to resolve to an EAPI-0 eclass function, although the inheritance stack might prove problematic.) Having to die for an unsupported EAPI seems like the wrong approach; if it's not going to work the PM shouldn't source it. If it can be made to work by filtering certain functions, that's doable. In the worst case, an ebuild switching to EAPI will require eclass maintenance; this is where the separation of elibs (useful code) and eclasses (template ebuilds) would be useful, although that needs versioning too.
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
On Tue, 07 Oct 2008 17:07:21 +0100 Steve Long [EMAIL PROTECTED] wrote: It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). That seems a bit implementation-specific; how one alternative package manager generates that metadata isn't important (though it does seem odd that you think it has to be done at that point) nor should it get in the way. The whole point of PMS is that it provides a way to avoid relying upon implementation specific things. There are currently no packages that rely upon calling phase functions in the wrong place, and there are good reasons a package manager might want to avoid implementing things in a way such that doing so is legal, so we don't allow it. Also, I don't think it has to be done at that point. I think it's convenient to do it at that point, and when combined with several other reasons doing it that way is the best option. Strange how you repeatedly seem to pop up in favour of doing whatever you think will cause most inconvenience to Paludis, though... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Ciaran McCreesh wrote: On Sun, 5 Oct 2008 17:38:11 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells has my eapi foo support but that sort of bites its tail that way. Hm, what about: [ $(type -t src_configure) == function ] EXPORT_FUNCTIONS src_configure Or is this too fragile or trying to be too clever? It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). That seems a bit implementation-specific; how one alternative package manager generates that metadata isn't important (though it does seem odd that you think it has to be done at that point) nor should it get in the way.
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
On Tue, Oct 07, 2008 at 05:07:21PM +0100, Steve Long wrote: Ciaran McCreesh wrote: On Sun, 5 Oct 2008 17:38:11 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells has my eapi foo support but that sort of bites its tail that way. Hm, what about: [ $(type -t src_configure) == function ] EXPORT_FUNCTIONS src_configure Or is this too fragile or trying to be too clever? It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). That seems a bit implementation-specific; how one alternative package manager generates that metadata isn't important (though it does seem odd that you think it has to be done at that point) nor should it get in the way. Actually both alternative PM's do this now (=pkgcore-0.4.7.9), although in pkgcore's case the default phase functions are installed after sourcing rather then at the time of invocation. Long term, this is the correct way to go imo- the downside to it is that a common sourcing env needs be defined at some point (newdepend, newrdepend, etc) to avoid any question of what's available. ~brian pgplTnmKBbhpJ.pgp Description: PGP signature
