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

Aaron Griffin aaronmgriffin at gmail.com
Thu Oct 1 13:08:12 EDT 2009

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
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

More information about the arch-dev-public mailing list