Fernando J. Pereda wrote:
>> > Why can't it be in the file but readable without sourcing?
>> >
>> There's _no_ need to source, nor constrain like that, for a simple
>> one-line variable, eg:
>> $ sed -nr '/^[[:space:]]*DESCRIPTION="([^"]*)".*/ { s//\1/p;q; }' \
>> app-portage/autounmask/autounmask-0.21.ebuild
>> autounmask - Unmasking packages the easy way
>>
>> eapi=$(sed -nr '/^[[:space:]]*EAPI="([^"]*)".*/ { s//\1/p;q; }'
>> foo.ebuild)
>> [[ $eapi ]] && checkAPI "$eapi"
>> ..would do it in bash (empty if unset in ebuild) assuming the
>> conventional EAPI="xx" format is used. Other languages can call system()
>> easily enough.
>
> This is just *brillant*. Lets see how useful your solution is:
>
> --- 8< ---
> # EAPI has to be set differently based upon tests on PV
Er, why exactly? Why not just have the new version of the ebuild declare a
new EAPI?
> if [[ -z ${PV/?.?/} ]] ; then
> EAPI="bar-1"
> elif [[ -z ${PV/?.?.?/} ]] ; then
> EAPI="0"
> else
> EAPI="1"
> fi
> --- 8< ---
>
> So please, no hacks.
>
Are you really telling me you are going to write _one_ ebuild with /that/
god-awful hackery in it?
If a new version of an ebuild uses a different EAPI, one would have thought
the changes to it-- to use that EAPI-- would mean a single EAPI declaration
is enough.
Sticking to a single EAPI="xx" format in the ebuild means we don't have the
*hack* of duplicating information in the filename (and the whole
{pre,post}src issue, QA checks for human error since this is redundant
info) simply to avoid parsing a config file.
--
[EMAIL PROTECTED] mailing list
