Need newer package version for PKGBUILD. What to do?

skoal · 2004-10-08 05:25:12

I'm making a PKGBUILD, and I need a newer version for "openal" than what is listed in the Arch repo's. The version I need is from their CVS repo's.

* How should I handle this in my PKGBUILD if some other Arch users would want my package?

I already modified the "openal" PKGBUILD from my sync tree (in local), built my custom "openal" package ("openal-20040810-1.pkg.tar.gz"), tested it against my program I'm making a PKGBUILD for, and it works fine.

So, how should I continue? Should I just put in a package request for the latest OpenAL CVS version and wait?

Xentac · 2004-10-08 05:28:34

In this case you probably want an openal-devel package.

skoal · 2004-10-08 05:49:14

Xentac wrote:

In this case you probably want an openal-devel package.

I don't know how you guys handle a "devel" package for a library versus the normal one, and I haven't installed the current OpenAL package from Arch repo's. So, the following OpenAL PKGBUILD below is the one I used.

pkgname=openal
pkgver=20040810
pkgrel=1
pkgdesc="OpenAL audio library for use with opengl"
depends=('glibc' 'libvorbis')

build() {
  cd $startdir/src/
  cvs -d ':pserver:guest:guest@opensource.creative.com:/usr/local/cvs-repository' login
  cvs -z3 -d ':pserver:guest:guest@opensource.creative.com:/usr/local/cvs-repository' co -P openal
  cd openal/linux
  ./autogen.sh
  ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-alsa
  make || return 1
  make DESTDIR=$startdir/pkg/usr/ install
}

Just minor changes to the existing one. But, I added the "--enable-alsa" backend support for this version.

Thanks.

Here's the "diff" in case you're interested:

[root@morpheus openal]# diff PKGBUILD ../../extra/lib/openal/PKGBUILD 
3c3
< # Maintainer: Skoal <skoal@agold.mine.nu>
---
> # Maintainer: dorphell <dorphell@archlinux.org>
6c6
< pkgver=20040810
---
> pkgver=20032409
9a10
> source=($pkgname.patch)
15a17
>   patch -Np2 -i ../../$pkgname.patch
17c19
<   ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-alsa
---
>   ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var

Xentac · 2004-10-08 06:22:15

Well... it's like a regular package... except the package name has a -devel at the end of it...

Look in unstable for many examples of such packages.

sarah31 · 2004-10-08 14:41:24

isn't openal already drawing from CVS? At the time i introduced it to the repos the only way openal was available was via CVS. If thas is still the case just flag it out of date.

EDIT: it is a cvs only package just flag it out of date it has not been upgraded from CVS for a very long time.

skoal · 2004-10-09 03:54:37

Xentac wrote:

Well... it's like a regular package... except the package name has a -devel at the end of it...
Look in unstable for many examples of such packages.

I went to the web CVS interface, looked at "cdrtools-devel" in unstable, and found what I was looking for. My concern was how "-devel" packages are handled with the possibility of an existing package of same name (and non-devel).

A simple "conflicts" section in the PKGBUILD using the root name of the package seems to take care of that aspect. I don't know the importance of using "provides" (in conjunction with "conflicts"), but it would seem I should do this too. I guess the "provides" is necessary if other packages look for "openal", and that person only has "openal-devel" installed. In my case:

[...]
conflicts=('openal')
provides=('openal')
[...]

thx.

sarah31 · 2004-10-10 07:37:34

like i said this package is already drawn from CVS just flag the package out of date through the web page. doing so will ensure that all archer will have the opportunity to have a much newer openal.

since openal is only distributed as CVS and certain stable release packages need it it is in extra and not unstable. there is no need to set up conflict or provides, just flag it out of date and the maintanier should have it ready in a few days or less.

skoal · 2004-10-11 02:46:06

sarah31 wrote:

like i said this package is already drawn from CVS just flag the package out of date through the web page. doing so will ensure that all archer will have the opportunity to have a much newer openal..

Thanks. I went ahead and flagged it as out of date. I'm working on learning how to use the Arch packaging system effectively. Using this particular package gave me insight into some very important concepts while doing so, and I appreciate the help and responses given.

Arch Linux

#1 2004-10-08 05:25:12

Need newer package version for PKGBUILD. What to do?

#2 2004-10-08 05:28:34

Re: Need newer package version for PKGBUILD. What to do?

#3 2004-10-08 05:49:14

Re: Need newer package version for PKGBUILD. What to do?

#4 2004-10-08 06:22:15

Re: Need newer package version for PKGBUILD. What to do?

#5 2004-10-08 14:41:24

Re: Need newer package version for PKGBUILD. What to do?

#6 2004-10-09 03:54:37

Re: Need newer package version for PKGBUILD. What to do?

#7 2004-10-10 07:37:34

Re: Need newer package version for PKGBUILD. What to do?

#8 2004-10-11 02:46:06

Re: Need newer package version for PKGBUILD. What to do?

Board footer