[SOLVED] First crack at packaging

Question

After the first instance ever on Arch where a (admittedly very new) program has to be done by source, and not on the AUR. It got me wanting to know how to package things, although nothing so complex as the program I'm after yet, I want to crawl before walking.
I decided to have a crack at a smaller program - so chose a rouge like game I hadn't yet seen in the AUR - not that it matters even if it was.
I paste the PKGBUILD I made for it below - it's not finished, but the instructions to make and build the package are there:
I took a lot of "inspiration" from the ASCIIPortal PKGBUILD because, like this game "AQuestTooFar", in the source, there is no "make install" part of the process, only a "make" and then an executable is made that you run straight from wherever the source and everything was downloaded to. Theres also no Package() part. But it works and makes a package nonetheless. However after intallation with pacman, I get an error when I try and launch it from terminal, about not being able to load one of the files in the "Data" folder, which I've checked it included and is present in my package.
Hopefully some of you would be able to offer any feedback and advice, and any thoughts on this error. I'm a complete newb to doing things from source and then packaging them - Oh package managers, how you spoil us =].
Cheers,
Ben.
# Maintainer: Ben Ward <[email protected]>
pkgname=AQuestTooFar
pkgver=1.3
pkgrel=1
pkgdesc="A rouge-like dungeon crawling game, using text."
arch=(any)
url="http://www.randomstuff.org.uk/~geoffrey/roguelikes/aquesttoofar.html"
license=()
depends=()
makedepends=('')
optdepends=('')
source=(http://www.randomstuff.org.uk/~geoffrey/roguelikes/AQuestTooFar1.3-091010.zip)
md5sums=('68545729914de7c7549b8d5ece13f061') #generate with 'makepkg -g'
build() {
cd "${srcdir}/AQuestTooFar1.3-091010"
make
install -d $pkgdir/opt/AQuestTooFar
install -D AQuestTooFar $pkgdir/opt/AQuestTooFar/
install -D readme.txt $pkgdir/usr/share/doc/AQuestTooFar/README
cp -r Build Data $pkgdir/opt/AQuestTooFar
mkdir $pkgdir/usr/bin
ln -s $pkgdir/opt/AQuestTooFar/AQuestTooFar $pkgdir/usr/bin/AQuestTooFar
chmod -x $pkgdir/opt/AQuestTooFar/*/*
Last edited by Ben9250 (2011-03-06 15:09:44)

Answer 1

Ben9250 wrote:Is there a certain situation then when ('any') is ok to be used or should one always try to put either i686 or x86_64 or both?
Yes, for example if your build only contains python code, then it runs on every platform which python runs on. That's when you can put arch=(any) into the PKGBUILD, because it runs everywhere.
Ben9250 wrote:
"install -Dm755 ${_realname} $pkgdir/opt/${_realname}/${_realname}"
"install -Dm644 readme.txt ${pkgdir}/usr/share/doc/${_realname}/README"
With these such lines, the -Dm755 part for example, it looks to me as though this is setting permissions, rather in a chmod kindof manner?
It's always good to set the permissions directly. Only that way you can be sure that the permissions will be right.
Ben9250 wrote:
for i in Data/*;do install -Dm644 "$i" ${pkgdir}/opt/${_realname}/"$i";done
This line is a loop, which loops around for every file in the Data folder, and copies them to the opt directory, essentially getting rid of the cp line?
Unfortunately something like install -Dm644 Data/* ${pkgdir}/opt/${_realname}/ doesn't work, so I solved it with a loop. But this line is basically doing the same as
cp -r Data/* ${pkgdir}/opt/${_realname}/
chmod 644 ${pkgdir}/opt/${_realname}/Data/*
but as I wrote before, the PKGBUILD I posted is how I would do it and I don't like to use cp in a build function, it's a matter of personal taste I guess.
Ben9250 wrote:
echo "#!/bin/sh  - forgive me but I don't know about this line, echo is something to do with printing things, and theres someting going on with a shebang and sh, so something to do with bash?
"cd /opt/${_realname}"
"./${_realname}" > ${pkgdir}/usr/bin/${_realname}"
"chmod +x ${pkgdir}/usr/bin/${_realname}"
This looks to me like the answer to the softlinking?
Yes. If you use a softlink in /usr/bin which directs to /opt/${_realname}, it's kind of like the binary file is in /usr/bin. The binary expects the data directory in the same directory, but it's in /opt/${_realname}. That's why the ln -s method doesn't work. The shell script however first does cd into /opt/${_realname} and then executes the binary. That way everything's fine, because the data directory is in the same directory.
Last edited by Army (2011-03-04 13:18:30)