> To quote: > "FEATURES is a portage specific package manager configuration > variable not specified in PMS and cannot reliably be used in ebuilds > or eclasses."
For distcc & ccache, let me quote ebuild.sh code:
if hasq distcc $FEATURES ; then
export PATH="/usr/lib/distcc/bin:$PATH"
[[ -n $DISTCC_LOG ]] && addwrite "${DISTCC_LOG%/*}"
fi
if hasq ccache $FEATURES ; then
export PATH="/usr/lib/ccache/bin:$PATH"
[...]
Do you want an example how to mimic this with portage without having
neither distcc nor ccache in FEATURES?
Even with portage, checking the FEATURES variable isn't reliable. If
you do not want to fix the real bugs and check/disable distcc/ccache
for any reason, then check PATH.
If you want to keep this simple, write an eclass providing functions
for disabling/checking these features.
> Well then, I suggest we finally start documenting reality and fix
> PMS. The use of the FEATURES variable, while it has been there
> for ... uhm ... as long as I can think back, actually :), should not
> be randomly suppressed.
If you want to fix PMS, then send a patch rephrasing it to explain why
it isn't correct to check FEATURES in some cases. On the other hand, as
its name implies, PMS is a spec, not a documentation on why every
single choice has been made.
> So ... what's your opinion? Should we do things as they are correct,
> or as they are specified in PMS?
PMS may have some flaws, but not these, sorry.
> ( /me points at bash 3.0 )
Ever thought about backward compatibility and keeping a sane upgrade
path? Because that's exactly what this EAPI & PMS debate is all about
IMHO.
Regards,
Alexis.
signature.asc
Description: PGP signature
