[arch-dev-public] [aur-general] I need some help with nexuiz-data

[Aaron Griffin]

On Wed, Sep 30, 2009 at 2:11 AM, Xavier <shiningxc at gmail.com> wrote:
> On Wed, Sep 30, 2009 at 7:10 AM, Evangelos Foutras <foutrelis at gmail.com> wrote:
>> Xyne wrote:
>>>
>>> I sent a message to this list about this yesterday but it seems to have
>>> been lost. It seems that things like to stop working all at once.
>>>
>>>
>>> I can't get nexuiz-data into the database. I keep getting the following
>>> error:
>>>
>>> [xyne at sigurd ~]$ /arch/db-community ==> Processing 1 new/updated
>>> arch-independent packages for
>>> 'community'... Checked out revision 3198.
>>>    Validating package arch (any) nexuiz-data
>>>    Checking SVN for nexuiz-data
>>>    WARNING: nexuiz-data-2.5.1-3-any.pkg.tar.gz does not match PKGBUILD
>>> in community-any Updating DB for community-i686
>>> ==> Copying DB file from 'community'...
>>> ==> Processing 1 new/updated packages for repository 'community'...
>>> D         checkout/nexuiz-data
>>> Checked out revision 3198.
>>> Errors found when adding packages
>>> Updating DB for community-x86_64
>>> ==> Copying DB file from 'community'...
>>> ==> Processing 1 new/updated packages for repository 'community'...
>>> Checked out revision 3198.
>>> Errors found when adding packages
>>>
>>>
>>>
>>> I've tried removing (svn rm) the PKGBUILD in nexuiz-data/repos/,
>>> commiting the changes and re-releasing the trunk. I've double-checked
>>> that I've followed all the steps for adding and updating the package
>>> against the wiki and my own working scripts. I've even tried bumping
>>> the pkgrel and rebuilding the package.
>>>
>>> I've also removed the local svn copy of nexuiz-data, checked it out
>>> again to make sure that I have the same version of the PKGBUILD, and
>>> used that to rebuild the package.
>>>
>>> I have no idea what to do now and would appreciate any help.
>>>
>>> The package is in ~/staging/community on Sigurd. I also have a copy of
>>> the current PKGBUILD along with the Nexuiz source code in ~/build for
>>> quick rebuilds (all it does is unzip the sources, move them to $pkgdir,
>>> remove some unnecessary Windows and Mac files, then recompress).
>>>
>>> Thanks,
>>> Xyne
>>
>> It looks like _pkgname in the PKGBUILD overrides a variable which is
>> internal to db-update and happens to have the same name.
>>
>> Here are the relevant lines in /arch/db-update: http://pastebin.com/f2b478ad
>> - see my comments on each highlighted line for what I believe is going on
>> and causes it to fail.
>>
>> I would suggest losing the _pkgname in the PKGBUILD, but there may be a
>> better and more universal solution.
>>
>
> 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.