You are not logged in.

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

skoal
Member
From: Frequent Flyer Underworld
Registered: 2004-03-23
Posts: 612
Website

Need newer package version for PKGBUILD. What to do?

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?

Offline

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

Xentac
Forum Fellow
From: Victoria, BC
Registered: 2003-01-17
Posts: 1,797
Website

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

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


I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal

Offline

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

skoal
Member
From: Frequent Flyer Underworld
Registered: 2004-03-23
Posts: 612
Website

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

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

Offline

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

Xentac
Forum Fellow
From: Victoria, BC
Registered: 2003-01-17
Posts: 1,797
Website

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

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 have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal

Offline

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

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

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

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.


AKA uknowme

I am not your friend

Offline

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

skoal
Member
From: Frequent Flyer Underworld
Registered: 2004-03-23
Posts: 612
Website

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

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.

Offline

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

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

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

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.


AKA uknowme

I am not your friend

Offline

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

skoal
Member
From: Frequent Flyer Underworld
Registered: 2004-03-23
Posts: 612
Website

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

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.

Offline

Board footer

Powered by FluxBB