DeLi(cate) Forum

Full Version: PKGBUILD files
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
This thread is dedicated to discussion about PKGBUILD files ....

Here's the PKGBUILD howto ...
https://wiki.archlinux.org/index.php/PKGBUILD
Since I accidently deleted the whole thread related to snownews and irssi, the very first PKGBUILD's gonna be the irssi one ...

Here's the reviewed version ...

Code:
# Maintainer: Theo - nl2stk

pkgname=irssi
pkgver=0.8.15
pkgrel=1
pkgdesc="Modular text mode IRC client with Perl scripting"
url="http://irssi.org/"
license=('GPL')
depends=('glib2' 'openssl' 'perl')
source=(http://irssi.org/files/${pkgname}-${pkgver}.tar.bz2)
md5sums=('1dcb3f511b88df94b0c996f36668c7da')

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"

  ./configure --prefix=/usr \
              --enable-ipv6 \
              --with-proxy \
              --sysconfdir=/etc \
              --enable-static=no \
              --host=$CHOST \
              --build=$CHOST

  make || return 1
  make DESTDIR="${pkgdir}" install || return 1

  # Remove the libtool stuff
  find ${pkgdir} -depth | grep "\.la" | while read libtool_file ;do
    rm -f $libtool_file
  done
}

--with-perl-lib=vendor didn't work well in our case ... it created the perl stuff in the top level directory and we don't want to have any mess there

--enable-static=no ... since we don't like any static libraries, it's always better to disable them if they are not needed.

Libtool files are useless in our case and it's better to remove them to save a disc space.
And here's the snownews PKGBUILD ...

Code:
# Maintainer: Theo - nl2stk

pkgname=snownews
pkgver=1.5.12
pkgrel=1
pkgdesc='CLI based RSS-reader'
url='http://kiza.kcore.de/software/snownews/'
licence=('GPL')
depends=('uclibc'
         'ncurses'
         'libxml2'
         'gettext'
         'libiconv'
         'openssl')
source=(http://kiza.kcore.de/media/software/snownews/${pkgname}-${pkgver}.tar.gz)
md5sums=('80da8943fc5aa96571924aec0087d4c0')

build() {
    cd $startdir/src/$pkgname-$pkgver
    ./configure --prefix=/usr
    sed -i 's/gcc/gcc -march=i386/g' Makefile
    sed -i 's/LDFLAGS)/LDFLAGS) -lintl/g' Makefile
    make || return 1
    make DESTDIR=${pkgdir}/ install || return 1
}

The right architecture had to be forced by patching the Makefile since the configure script doesn't support --build / --host parameters (the first sed call).

The second sed call solves the following errors appearing during the build:
undefined reference to `libintl_gettext'
One of the most populair classic videogames couldn't be left out.
So here it is, myman - a pacman-clone for the terminal with ncurses.

Code:
# Contributor: chochem <chochem@gmail.com>
# Original for Arch, a bit changed for Delicate Linux
pkgname=myman
pkgver=0.7.0
pkgrel=1
pkgdesc="A Pacman clone with an ncurses and a 'graphic' interface"
url="http://myman.sourceforge.net/"
license=('BSD')
depends=('ncurses' )
source=(http://xent.com/~bsittler/${pkgname}-${pkgver}.tar.gz)
md5sums=('ca34d3f12c973558dc52516144b64530')

build() {
  cd $srcdir/$pkgname-$pkgver
  ./configure --with-xterm --prefix=${pkgdir}/usr
  make || return 1
  make install
  mkdir -p $pkgdir/usr/share/licenses/$pkgname
  cp ./LICENSE $pkgdir/usr/share/licenses/$pkgname/COPYING
  rm $pkgdir/usr/bin/$pkgname-$pkgver
}
I'll check and build it this evening ... :]

But .... I have a big dilema if the Arch maintainers/contributors should stay in the PKGBUILD comments or not ....

Since the DeLi(cate) packages can differ a lot and those people might be not interrested in contributing to DeLi(cate), somebody could consider them as DeLi(cate) maintainers by mistake and then request changes/updates from them.
On the other hand ... We would steal their credits for the work they've done by removing their names :|
Unfortunately I've already removed all the comments in PKGBUILD files I've taken over and still thinking if that was a good idea.
What do You think?
Mark them as former Arch contributors in the future PKGBUILDs?

I prepare a source repository too ... but that would be better with newer makepkg version .... it's able to create source packages
Well it was my mistake, I would changed it in 'Original created by... for Arch (remove the email-adress)' and on the second line ' patched by... for Delicate'. With that changed the original maintainer can not be asked for whatsoever and still gets the credits for his work. But on the other hand, Delicate isn't Arch, so I understand the dilema. I didn't know what to do, so that why the original maintainer is in the PKGBUILD.
It's a bit like .deb files. If someone created them on Debian, it can be useable for Ubuntu or AntiX. I know that they're closer to Debian compared with Delicate and Arch. But it's a bit of the same question.

I think it depends on what is copied from the Arch PKGBUILD, sometimes only the links, dependencies and md5 is useable. Stuff that otherwise can be found with google, and I have never put them in the credits :]

Personally, if I made a PKGBUILD I wouldn't care if they would remove my name. After all I didn't make the software, just a few lines to create a package.
And most of things, is just mandatory stuff.
Oooooouuuu .... now I remember ..... I tried to build the myman one month ago, but I stopped the build because of the compilation time .... it took ages! It seems to be a bug in the make utility, because it eats the whole CPU ...
And now the history repeats :] I have only 2 hours for the build .... soooo ..... we'll see.
(09-09-2011 08:16 PM)tavvva Wrote: [ -> ]Oooooouuuu .... now I remember ..... I tried to build the myman one month ago, but I stopped the build because of the compilation time .... it took ages! It seems to be a bug in the make utility, because it eats the whole CPU ...
And now the history repeats :] I have only 2 hours for the build .... soooo ..... we'll see.

Yes, it takes some time. CenterIM is the same story.
I can place the package on a a free filehoster.
I don't know if it is an idea?

EDIT: I saw it was in the repo's.
But maybe it's an idea for the future, for packages like this.
You know ... as I'm still responsible for the final sanity of the product, I should always check the builds from contributors. All of them have to be 100% reproducible and without visible issues. It's a kind of review process that's well known in companies developing the most famous distros Smile And it really has sense! More than 10% of issues are found during tne review. So ... don't be affraid and paste the PKGBUILD here ... and if the build takes too long, just make a note about that and I'll reserve more time for the build.
I know, but it was an idea for a helping hand. I know the responsable issues and it was not meant for normal use.

But making a note with some info would help too.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
Reference URL's