[arch-dev-public] Bad behavior of dbscripts for custom variables

[Aaron Griffin]

On Thu, Oct 1, 2009 at 9:58 AM, Xavier <shiningxc at gmail.com> wrote:
> On Wed, Sep 30, 2009 at 9:07 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
>>>
>>> What, dbscripts use _foo variables ?
>>> Doesn't that completely defeat the guideline we have in PKGBUILD man page :
>>>
>>>       If you need to create any custom variables for use in your build
>>>       process, it is recommended to name your custom variables with an _
>>>       (underscore) prefix. This will prevent any possible name clashes with
>>>       internal makepkg variables. For example, to store the base kernel
>>>       version in a variable, use something similar to $_basekernver.
>>>
>>> It is the PKGBUILD who should use _foo syntax to avoid clashes.
>>> If dbscripts does it also, it's not avoiding clashes, it's asking for clashes :)
>>>
>>> However, if dbscripts used things like $realpkgname $pkgbuild_pkgname
>>> or whatever, it would be fine. If a pkgbuild also defined these, it
>>> would be pkgbuild's fault of not following the guidelines.
>>>
>>> This should definitely be fixed.
>>
>> Patches welcome.
>>
>
> Should this be fixed by someone not even using dbscripts ? :)
>
> If you do think this an issue that should be addressed, and no one
> else can fix it, I will see what I can do.

Well, no, I was just put off a bit by the "OMG THIS IS TERRIBLE, IT
SHOULD NEVER EVER HAVE BEEN DONE THIS WAY, HOLY CRAP FIX IT NOW"
attitude, so I decided to be snarky.

Actually, to do this properly, we should do away with the sourcing of
PKGBUILDs the way we do it, and do something like:

function pkgfile_from_pkgbuild () {
   ( . PKGBUILD; echo "$pkgname-$pkgver-$pkgrel" )
}

or something of the sort. Sourcing the PKGBUILD in a subshell will
prevent us from polluting the script-level variables