[SOLVED] First crack at packaging

Ben9250 · 2011-03-03 22:06:30

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 <benjamin.ward@bathspa.org>
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)

Army · 2011-03-03 22:42:25

Don't put lines into the PKGBUILD which aren't needed. In your case there's license, depends, makedepends and optdepends. But I'm pretty sure there IS a license, also some kind of dependency (I never saw one without a dependency), maybe there's no makedepends and yes it's very possible that there's no optdepends.
Change the pkgname to aquesttoofar, there aren't supposed to be capitals in the pkgname. Instead, add a line after pkgname, e.g. realname=AQuestTooFar and use that e.g. in the source line and in the build function.
In your source line there's this 091010, I guess this is some kind of date format or something. Therefore you could also put a line date=091010 in front of the build function, so you only have to update this one line in case of a newer release of the application.
The arch line is wrong, this PKGBUILD produces binary code! So you'll have to arch=(i686 x86_64) in case those two platforms are supported. If you aren't sure, only put your architecture in it and let other users confirm that the other architecture works as well.
Your ln-s line is wrong as well, it should be ln -s /opt/AQuestTooFar/AQuestTooFar $pkgdir/usr/bin/AQuestTooFar

Those are the first things I see. Your build function looks like a big hack, all this cp -r, chmod, ... stuff doesn't look very nice. Give me a moment, I want to take a look into it.

ewaller · 2011-03-03 22:52:12

My observations:

The License and depend fields are not optional.
You should have a package statement. End the build section right after the make. I have not written one one a while, but I think you need to check that make completed without error or cause the makepkg to die.
I don't know about that soft link. Does that work?
Code tags in posts are a good thing.
When all is said and done, the files that will be copied to the real file system should be in their relative places in the pkgdir.

Maybe I'll try this when I get home.

Army · 2011-03-03 23:00:50

Ok a few things more, your ln -s line doesn't work, because then it expects the Data folder to be in /usr/bin, which of course it isn't (and shouldn't be!). So you'll have to put a little script in /usr/bin which changes into /opt/AQuestTooFar and then executes the binary. Dependencies are sdl and gcc-libs.
You don't need the Build directory in /opt/AQuestTooFar, so don't put it in there.
Here's my quickly updated version of your PKGBUILD

pkgname=aquesttoofar
_realname=AQuestTooFar
pkgver=1.3
_date=091010
pkgrel=1
pkgdesc="A rouge-like dungeon crawling game, using text."
arch=(i686 x86_64)
url="http://www.randomstuff.org.uk/~geoffrey/roguelikes/aquesttoofar.html"
license=(GPL)
depends=('sdl' 'gcc-libs')
source=(http://www.randomstuff.org.uk/~geoffrey/roguelikes/${_realname}${pkgver}-${_date}.zip)
md5sums=('68545729914de7c7549b8d5ece13f061')

build() {
    cd "${srcdir}/${_realname}${pkgver}-${_date}"
    make
}
package() {
    cd "${srcdir}/${_realname}${pkgver}-${_date}"
    install -Dm755 ${_realname} $pkgdir/opt/${_realname}/${_realname}
    install -Dm644 readme.txt ${pkgdir}/usr/share/doc/${_realname}/README
    for i in Data/*;do install -Dm644 "$i" ${pkgdir}/opt/${_realname}/"$i";done
    install -dm755 ${pkgdir}/usr/bin
    echo "#!/bin/sh
cd /opt/${_realname}
./${_realname}" > ${pkgdir}/usr/bin/${_realname}
    chmod +x ${pkgdir}/usr/bin/${_realname}
}

I don't know if it can be done better, but that's how I would put it into the AUR.

edit: improved

Last edited by Army (2011-03-03 23:20:34)

jnguyen · 2011-03-03 23:12:37

Also "realname" and "date" should be changed:

man PKGBUILD wrote:

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.

Army · 2011-03-03 23:18:55

Oh shit, you are right!!

Ben9250 · 2011-03-04 00:33:41

Thanks ever so much for the feedback, I was hoping I'd learn a lot from this - I never thought of the softlink behaving as you pointed out. So I'll go through and make sure I understand how you solved, as you rightly pointed out, the messy parts.

- "The arch line is wrong, this PKGBUILD produces binary code! So you'll have to arch=(i686 x86_64) in case those two platforms are supported. If you aren't sure, only put your architecture in it and let other users confirm that the other architecture works as well." 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?

"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?

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?

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?

Last edited by Ben9250 (2011-03-04 06:01:59)

ngoonee · 2011-03-04 01:47:59

Please, whenever you post code (or PKGBUILDs) use the code tags.....

Army · 2011-03-04 13:17:26

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)

Arch Linux

#1 2011-03-03 22:06:30

[SOLVED] First crack at packaging

#2 2011-03-03 22:42:25

Re: [SOLVED] First crack at packaging

#3 2011-03-03 22:52:12

Re: [SOLVED] First crack at packaging

#4 2011-03-03 23:00:50

Re: [SOLVED] First crack at packaging

#5 2011-03-03 23:12:37

Re: [SOLVED] First crack at packaging

#6 2011-03-03 23:18:55

Re: [SOLVED] First crack at packaging

#7 2011-03-04 00:33:41

Re: [SOLVED] First crack at packaging

#8 2011-03-04 01:47:59

Re: [SOLVED] First crack at packaging

#9 2011-03-04 13:17:26

Re: [SOLVED] First crack at packaging

Board footer