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

[Xavier]

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.