On Thu, Sep 27, 2012 at 10:30:21AM -0700, Zac Medico wrote:
> On 09/27/2012 10:16 AM, Ian Stakenvicius wrote:
> > On 27/09/12 01:07 PM, Zac Medico wrote:
> >> On 09/27/2012 09:49 AM, Ulrich Mueller wrote:
> >>> As far as I can see, only the definition of the usex function
> >>> must be disabled. Please review the patch included below.
> >>>
> >>> Ulrich
> >>>
> >>> --- eutils.eclass 15 Sep 2012 16:16:53 -0000 1.403 +++
> >>> eutils.eclass 27 Sep 2012 16:45:14 -0000 @@ -1373,7 +1373,9 @@ #
> >>> @DESCRIPTION: # If USE flag is set, echo [true output][true
> >>> suffix] (defaults to "yes"), # otherwise echo [false
> >>> output][false suffix] (defaults to "no"). +if has "${EAPI:-0}" 0
> >>> 1 2 3 4; then usex() { use "$1" && echo "${2-yes}$4" || echo
> >>> "${3-no}$5" ; } #382963 +fi
> >>>
> >>> # @FUNCTION: prune_libtool_files # @USAGE: [--all]
> >>>
> >
> >> Looks good to me.
> >
> >> It may not work for unofficial EAPIs that don't include usex, but
> >> I guess there's nothing we can do for those, and they can just be
> >> replaced with newer EAPIs that include usex.
> >
> > ....i actually just committed the fix discussed in #gentoo-dev , using
> > 'declare -F' instead (similar to the eqawarn conditional declaration
> > already in eutils.eclass)
> >
> >
> > Sorry..
>
> It's fine with me, but some of the other package manager devs might
> object, since it makes assumptions about implementation details.
PMS isn't particular clear on the metadata sourcing env for EAPIs-
especially after the requirement that we pull the EAPI out of the file
on the fly was aded.
Point is, if it's EAPI5 the env should already export usex- even if
it's disabled- so case/esac is better imo.
~harring
