Arch Linux User Repository

@trya: Yes, I did realize from looking at the PKGBUILD that I would need to place the game archive in the PKGBUILD dir, but when I was confronted by this error message that *didn't* complain about not finding the file, but instead about not even knowing the protocol, I didn't even try any further. I assumed it was something that maybe worked with older makepkg versions but not anymore, or only with certain AUR helpers, and hence needed fixing. I undestand your comments below now, although I guess I disagree about the usage of the term "elegant" for a solution that confronts the user with a completely misleading error message. Don't get me wrong, I too think that the solution *would* be really elegant - if makepkg would explicitly support it.

@smls: did you read the PKGBUILD? Did you read the discussion? You have to put the game tarball in the PKGBUILD directory.

Installation fails with "==> ERROR: There is no agent set up to handle file URLs. Check /etc/makepkg.conf."

@Kppqju77: I don't the idea that much. Compare this PKGBUILD with those handling the Humble Bundle keys, you'll probably understand. Then, I'd like to prevent HB servers from clogging. One download is enough, make copies or links if necessary.

Can you do an installer with the _humblebundleandroidkey defined to grab it on humble bundle website (like bittriprunner,jamestown,cogs... with _humblebundle4key) ?

Please disable compression of the package in the next release... PKGEXT='.pkg.tar'

Found an elegant solution to circumvent the "makepkg --source" issue by using an uncommon protocol for the tarball. It could be useful for "non-redistributable" software packages in the AUR. If you want to push the integration a little more, you can add 'file::/bin/true' in the DLAGENTS array of makepkg.conf.

I'm not sure everyone will agree with you. In an ideal world, that's actually how all PKGBUILDs should look like, without any kind of interactivity. But this isn't a usual PKGBUILD: we're not trying to package a free (as in beer or as in speech) software, but a commercial game whose tarball is not freely available. Try "makepkg --source" with the PKGBUILD you suggested, you'll see what I'm talking about. However, I have an idea to get around this situation (which could involve switching from a local tarball to a distant location in the PKGBUILD source array). Please wait.

There is really no need for all that complexity in handling the source tarball. http://paste.pocoo.org/show/481725/ If for some reason you don't want to have the actual data in $SRCDEST, just put a symlink there and it'll work, but don't hack the pkgbuild.

@Ideka: the problem lies in the included libvorbisfile library. For an unknown reason (maybe glibc related), libvorbisfile is not able to load Ogg Vorbis files anymore... The glibc has been updated on June 26th, you posted on June 27th, that's why I think it's related. Still, I didn't got any error output from libvorbisfile, so I'm clueless. Better use system libraries for now, even if we're not safe from a soname bump some day, but it's manageable. Updated PKGBUILD.