On Thu, Oct 1, 2009 at 9:58 AM, Xavier wrote:

On Wed, Sep 30, 2009 at 9:07 PM, Aaron Griffin 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