First PKGBUILD assist

diamondmind · 2008-01-21 05:52:15

Just started using Arch a few weeks ago and love it (already wrote a Wiki for my laptop model .. heh) but noticed there were a couple of obscure but useful utils missing from all of the repos .. so I decided to try rolling my own packages and see what happened.

I've pored over the documentation here on the forums and the Wiki and I've got something that works on my machines but I'm sure I'm missing something. These packages are really niche software for programming FX2 boards, so I don't really expect much broad interest, though that's probably as good a place as any to start.

Anyway, here's what I've come up with for my PKGBUILDs:

# Contributor: Nate Rhodes  <nate.rhodes at gmail.com>
# Created:     January 2008

pkgname=fx2_programmer
pkgver=2.0.2
pkgrel=1
pkgdesc="A small utility to access the Cypress Semiconductor CY7C68013 chip."
arch=('i686')
url="http://volodya-project.sourceforge.net/fx2_programmer.php"
license=('LGPL')
depends=('glut' 'fftw' 'libusb')
source=("http://downloads.sourceforge.net/volodya-project/$pkgname-$pkgver.tgz")
md5sums=('ff2878e900b6cbae427320e54e94f28d')

build() {
  # Go to source dir
  cd "$startdir/src/$pkgname"

  # Set up the "install" directories
  mkdir "$startdir/pkg/usr"
  mkdir "$startdir/pkg/usr/bin"

  # Update 'install' rule to put binaries in right place
  sed -i.orig "s|\${PREFIX}/bin/|$startdir/pkg/usr/bin|g" Makefile 

  # Build the binaries
  make || return 1
  make DESTDIR="$startdir/pkg/usr/bin" install || return 1
}

# Contributor: Nate Rhodes  <nate.rhodes at gmail.com>
# Created:     January 2008

pkgname=cycfx2prog
pkgver=0.41
pkgrel=1
pkgdesc="A small tool to program the FX2 and do basic endpoint communication for testing."
arch=('i686')
url="http://www.cip.physik.uni-muenchen.de/~wwieser/elec/periph/USB-FX2/software/"
license=('GPL')
depends=('libusb')
source=("http://www.cip.physik.uni-muenchen.de/~wwieser/elec/periph/USB-FX2/software/$pkgname-$pkgver.tar.gz")
md5sums=('618207b113ed364a7a09c16ae881b945')

build() {
  # Go to source dir
  cd "$startdir/src/$pkgname-$pkgver"

  # Build the binaries
  make || return 1

  # Move binaries around to proper place
  install -D "$startdir/src/$pkgname-$pkgver/$pkgname" "$startdir/pkg/usr/bin/$pkgname" || return 1
}

namcap gives me the missing Maintainer Tag and Missing CVS ID Tag warnings for both. How can I fix those? I either looked over or missed documentation on both of those.

Last edited by diamondmind (2008-01-21 05:54:43)

brebs · 2008-01-21 06:25:10

Ignore them - they are appropriate for packages in the official tree, but not for personal use or the AUR.

byte · 2008-01-21 07:02:56

Looks fine (small hint for the 1st one: mkdir -p). Also run namcap on the generated packages, that's usually more important than the simple PKGBUILD syntax check.

diamondmind · 2008-01-21 15:58:03

byte wrote:

Looks fine (small hint for the 1st one: mkdir -p). Also run namcap on the generated packages, that's usually more important than the simple PKGBUILD syntax check.

I never thought to look for a switch for that.

Thanks for the suggestions .. couple questions:

1) Should pkgrel be bumped for changes like that that don't really change the functionality of the package? And should I be bumping it every time I make changes in my "provisional" testing?
2) Is it better to use something like sed to manipulate the install rule (if it has one) of the Makefile or to try to use 'install' to move the binaries around manually? Is it just whatever is easier?

diamondmind · 2008-01-21 18:03:55

Added to AUR this morning. Hopefully they'll save someone a little work down the line. Thanks for the help.

Zer0 · 2008-01-21 18:09:49

1) When you make changes to your PKGBUILD or any other included files (eg .installs) then you should up the pkgrel. Only bump by one when you make the changes public and they are different from your last public release. When a new version of the software comes out and you change your PKGBUILD, start at 1 for your pkgrel again.

2) Using sed is fine but to me it seems like a dirty hack. If it's the only way you can make it work though I guess you have no choice. Use install if it's easier, but you wouldn't want your PKGBUILD to have 20+ install lines or similar..

looking at the "\${PREFIX}/bin/" portion though it would seem that the install script supports PREFIX option.. I would use this option and set it as $startdir/pkg then move the files where you want...

   # move /bin to /usr/bin
  cp -rf $startdir/pkg/bin $startdir/pkg/usr/bin
  rm -r $startdir/pkg/usr/local

Much cleaner and easier to read then a sed command. I guess you could use mv instead of cp also

brebs · 2008-01-21 18:16:41

"cp" is not safe - use "install" instead.

diamondmind · 2008-01-22 00:12:00

Zer0 wrote:

2) Using sed is fine but to me it seems like a dirty hack. If it's the only way you can make it work though I guess you have no choice.

That's pretty much how I felt about it too .. heh.

Zer0 wrote:

looking at the "\${PREFIX}/bin/" portion though it would seem that the install script supports PREFIX option.. I would use this option and set it as $startdir/pkg then move the files where you want...

Using ./configure --prefix=xxx? Neither of these apps had configure scripts. Trying to use ${PREFIX} would require setting some environment variable then wouldn't it? I thought doing that was a no-no in PKGBUILDs?

Zer0 wrote:

   # move /bin to /usr/bin
  cp -rf $startdir/pkg/bin $startdir/pkg/usr/bin
  rm -r $startdir/pkg/usr/local
Much cleaner and easier to read then a sed command. I guess you could use mv instead of cp also

I read somewhere that you should use install not cp for moving files. I think it has to do with inheriting permissions correctly?

brebs · 2008-01-22 00:25:19

A little example:

make PREFIX=$startdir/pkg/usr BINDIR=$startdir/pkg/usr/bin install || return 1

See lots more examples with:

find /var/abs/ -name PKGBUILD | xargs grep PREFIX

After running "abs", of course.

Last edited by brebs (2008-01-22 00:26:07)

diamondmind · 2008-01-22 03:59:33

brebs wrote:

A little example:
make PREFIX=$startdir/pkg/usr BINDIR=$startdir/pkg/usr/bin install || return 1
See lots more examples with:
find /var/abs/ -name PKGBUILD | xargs grep PREFIX
After running "abs", of course.

Ah .. OK .. thanks. I've never done much with Makefiles so I didn't realize you could do that kinda stuff. (Although after reading through a lot of PKGBUILDs you would think I'd catch on .. heh.)

Zer0 · 2008-01-22 21:31:04

brebs wrote:

"cp" is not safe - use "install" instead.

I read that post but I'm having a bit of trouble following it..
I thought that a cp of $startdir/pkg/bin to $startdir/pkg/usr/bin would be fine as the contents of pkg/bin are created by the make install script and so the permissions should be set correctly.

I always use install instead of copy if there's no setup/make script because of permission issues..
So using cp isn't right in any situation related to PKGBUILDs?

brebs · 2008-01-22 23:18:19

Use "install -m644", and we *know* that the permissions will be 644.

Use "cp", and the permissions will be whatever they already are. Which might or might not be correct. Usually they will be correct, but *sometimes* they will be wrong.

byte · 2008-01-23 01:08:18

http://bugs.archlinux.org/task/9242 is another reason to choose 'install' over 'cp'.

Arch Linux

#1 2008-01-21 05:52:15

First PKGBUILD assist

#2 2008-01-21 06:25:10

Re: First PKGBUILD assist

#3 2008-01-21 07:02:56

Re: First PKGBUILD assist

#4 2008-01-21 15:58:03

Re: First PKGBUILD assist

#5 2008-01-21 18:03:55

Re: First PKGBUILD assist

#6 2008-01-21 18:09:49

Re: First PKGBUILD assist

#7 2008-01-21 18:16:41

Re: First PKGBUILD assist

#8 2008-01-22 00:12:00

Re: First PKGBUILD assist

#9 2008-01-22 00:25:19

Re: First PKGBUILD assist

#10 2008-01-22 03:59:33

Re: First PKGBUILD assist

#11 2008-01-22 21:31:04

Re: First PKGBUILD assist

#12 2008-01-22 23:18:19

Re: First PKGBUILD assist

#13 2008-01-23 01:08:18

Re: First PKGBUILD assist

Board footer