On 06/04/2012 02:23 AM, William Hubbs wrote:
> On Sun, Jun 03, 2012 at 01:38:32PM +0100, Ciaran McCreesh wrote:
>> On Sun, 03 Jun 2012 12:42:45 +0300
>> Samuli Suominen<ssuominen@g.o>  wrote:
>>> When all there is required is dropping some "$@" to the Portage code
>>> and be done with it, and have everything be in consistent format...
>>
>> The question is not about the code, but about the design. Your design
>> doesn't make sense: there's no direct correspondence between functions
>> and phases, so it's not obvious where arguments to "default" get sent.
>>
>> "default" is for the easy cases. If you're wanting to do something
>> different, don't use it.
>
> Also, default can be used as the starting point for a more complex
> install. For example, you can call default, then once that returns,
> modify the image by adding/removing/moving files, adding init scripts,
> etc.

yeah, the default of EAPI=4 is nearly replacement for the src_install() 
provided by base.eclass
except it is missing argument handling

the number of pkgs using it are increasing steadily exactly for the 
reason you described, it is useful already, except when it's not anymore

would be cool to just point src_{configure,compile,install}() to 
`default` in, for example, xfconf.eclass and then do rest like you 
described, like:

xfconf_src_configure() {
[[ ${PV} == *9999* ]] && XFCONF+=( --enable-maintainer-mode )
default "${XFCONF[@]}" "$@"
}

xfconf_src_compile() {
default "$@"
}

xfconf_src_install() {
default "$@"
find "${ED}" -name '*.la' -exec rm -f {} +
validate_desktop_entries
}

we could even let base.eclass go at some point for most packages.
epatch_user and PATCHES=() to own eclass, like "patches.eclass", if you 
have better name idea, speak up.
then when EAPI=5 is released, convert packages using base.eclass from 
EAPI<5 + base.eclass, to EAPI=5 + patches.eclass