[PKGBUILD] new rulez for the creation

baptux · 2005-06-29 15:49:42

Hi,

I'll be perhaps a new users.

I was looking for a new linux distrib, I come from slackware then freebsd, tried Gentoo for a long, but not satisfied
I'm want sources+packages, and find out that Arch could the one

I've looked to pacman, abs, etc., I've looked to some PKGBUILD, and notice there wasn't any (perhaps wrong) options that could be pass in order to modify a bit the way packages are build from sources, as it's done in FreeBSD.

I don't want something like gentoo USE flags, too much options I think, and some are not really usefull.

I've read the rules for the creating PKGBUILD, and here is my idea (sur not the only one, don't blame me if it was already discuss and rejected).
I think we can put some predefined variables within the packages, those variables are independant from the installed packages, except if they need the installation of an extra package for dependencies. (for FreeBSD users, it's exactly what is done in the ports). By default the behaviour is the one define by the maintainer.

To illustrate I've modify a bit the vim PKGBUILD :
Original :

# $Id: PKGBUILD,v 1.19 2005/06/22 02:37:09 judd Exp $
# Maintainer: judd <jvinet@zeroflux.org>
pkgname=vim
pkgver=6.3
pkgrel=5
pkgdesc="VIM - Vi IMproved console"
url="http://www.vim.org"
depends=('glibc' 'ncurses')
backup=(etc/vimrc)
source=(ftp://ftp.vim.org/pub/vim/unix/$pkgname-$pkgver.tar.bz2 
        vim.patch filetype.patch)
md5sums=('821fda8f14d674346b87e3ef9cb96389' '386938c7bd7890b7d1900615f40ee9a7'
         '916fd94f2546007c637ad08e88400d1a')

build() {
  cd $startdir/src/vim63
  patch -Np1 -i ../vim.patch || return 1
  patch -Np1 -i ../filetype.patch || return 1
  cd src
  ./configure --prefix=/usr --localstatedir=/var/lib/$pkgname 
    --disable-gpm --with-x=no --enable-gui=no --enable-multibyte 
    --enable-cscope
#    --enable-perlinterp --enable-pythoninterp --enable-rubyinterp   
  make CPPFLAGS=-DSYS_VIMRC_FILE="/etc/vimrc" VIMRTDIR=  auto/pathdef.c
  make CPPFLAGS=-DSYS_VIMRC_FILE=\"/etc/vimrc\" VIMRTDIR=  || return 1
  make DESTDIR=$startdir/pkg VIMRTDIR= install
  cd $startdir/pkg/usr/bin
  ln -sf vim vi
  mkdir -p $startdir/pkg/etc
  cp $startdir/pkg/usr/share/vim/vimrc_example.vim $startdir/pkg/etc/vimrc
}

My proposal :

# $Id: PKGBUILD,v 1.19 2005/06/22 02:37:09 judd Exp $
# Maintainer: judd <jvinet@zeroflux.org>
pkgname=vim
pkgver=6.3
pkgrel=5
pkgdesc="VIM - Vi IMproved console"
url="http://www.vim.org"
depends=('glibc' 'ncurses')
if [ ! -z $WITH_PERL ];then
    depends=($depends 'perl')
fi
if [ ! -z $WITH_PYTHON ];then
    depends=($depends 'python')
fi
if [ ! -z $WITH_RUGBY ];then
    depends=($depends 'ruby')
fi
backup=(etc/vimrc)
source=(ftp://ftp.vim.org/pub/vim/unix/$pkgname-$pkgver.tar.bz2 
vim.patch filetype.patch)
md5sums=('821fda8f14d674346b87e3ef9cb96389' '386938c7bd7890b7d1900615f40ee9a7'
'916fd94f2546007c637ad08e88400d1a')

build() {
    cd $startdir/src/vim63
    patch -Np1 -i ../vim.patch || return 1
    patch -Np1 -i ../filetype.patch || return 1
    cd src
    PKGBUILDOPTIONS=""
    if [ ! -z $WITH_PERL ];then
        PKGBUILDOPTIONS="$PKGBUILDOPTIONS --enable-perlinterp"
    fi
    if [ ! -z $WITH_PYTHON ];then
        PKGBUILDOPTIONS="$PKGBUILDOPTIONS --enable-pythoninterp"
    fi
    if [ ! -z $WITH_RUGBY ];then
        PKGBUILDOPTIONS="$PKGBUILDOPTIONS --enable-pythoninterp"
    fi
    ./configure --prefix=/usr --localstatedir=/var/lib/$pkgname 
    --disable-gpm --with-x=no --enable-gui=no --enable-multibyte 
    --enable-cscope $PKGBUILDOPTIONS
    #    --enable-perlinterp --enable-pythoninterp --enable-rubyinterp   
    make CPPFLAGS=-DSYS_VIMRC_FILE="/etc/vimrc" VIMRTDIR=  auto/pathdef.c
    make CPPFLAGS=-DSYS_VIMRC_FILE=\"/etc/vimrc\" VIMRTDIR=  || return 1
    make DESTDIR=$startdir/pkg VIMRTDIR= install
    cd $startdir/pkg/usr/bin
    ln -sf vim vi
    mkdir -p $startdir/pkg/etc
    cp $startdir/pkg/usr/share/vim/vimrc_example.vim $startdir/pkg/etc/vimrc
}

No modification needed to abs or pacman or anything else.
no more need, create our own PKGBUILD in order to get some usefull options, the default behaviour is still the same.
Are we allowed to do that (I've seen that the less we use vars the better it is)
I think there could be a rule to define the use of such can of vars, in order to prevent getting to much options like gentoo.

I hope I was clear, waiting for your suggestion

phrakture · 2005-06-29 16:02:35

I think you've missed a key point in arch - it's simplicty... gentoo is based on "here's a million options and you'll never know what's correct" - arch is based on "here's the common case, want something more? recompile it"

that said - even with that PKGBUILD file, you're still going to have to build, what, 6 binaries to satisfy all cases to the end user... and srcpac can do this entire thing on a case by case basis anyway...

if you're dead set on doing something this way, I highly suggest making different PKGBUILDs for each and not cluttering the primary one up with additional logic that doesn't need to be there.

let's think about this part to: let's say user1 want's python and perl enabled... what's it going to hurt to enable ruby then? user2 want's none of those enabled? disable them all...

I personally just enable all of them along with --enable-features=huge in my vim build (though it's a 7.0 build)

I think that what you're trying to emulate is gentoo use flags (to a small extent) - the example I *always* bring up in this case is X.org - the arch PKGBUILD for X.org is about 150-250 lines... the gentoo ebuild is over 3000! Why? Use flags... sure your vim PKGBUILD is only adding 3, but if something like this becomes the norm, another user may step in and add 3 more and so on and so on...

"The Arch Way" of doing something like this is through srcpac (pacman -S srcpac).. you configure it with sed expressions on a base PKGBUILD... it's that simple.

The way Arch packages are made, they are there to suit the majority of users... if there is something missing, a large chunk of the others can just deal with the missing feature (what if vim was compiled without "signs" enabled... would you care? I know I wouldn't). It's only a handful of users that would want the package made differently, and in that case, it's not hard to recompile the package with your own modifications.

Hope this helps.

baptux · 2005-06-29 16:18:51

I think I wasn't clear enough, I've tested gentoo and don't at all something like USE flags.
I don't know if you ever had a look to FreeBSD port system, but there is small option for some packages (a few) if the maintainer think it is important, to provide some. usually it doesn't break any dependency with other package because you haven't choose one option when compiling.

Another important thing, in gentoo you must have a look too useflags to get a usable system, in that case, the default behaviour is the actual, no more, no less. I think a few packages need options, and perhaps vim wasn't a good example, but simple one

The packages for pacman should be build using the default behaviour. the options shouldn't be detected automatically like in gentoo : because perl is installed you always have WITH_PERL, not in this case. The acceptance of option in a PKGBUILD should be discuss and the less there is the better it is. An option should break any dependency with other packages.

I think if it's written as a rule, and every maintainer follow this rule, there won't be any problem nor a hudge number of options

phrakture · 2005-06-29 17:17:26

baptux wrote:

I think if it's written as a rule, and every maintainer follow this rule, there won't be any problem nor a hudge number of options

it's just that simple! ok everyone, get to work!
...

baptux, this isn't going to happen. it doesn't make sense in Arch. I think this happens about twice a month "Hey, I found this neat feature in distro X and want to shoe-horn it into Arch!!" and then a few weeks later, that user is never heard from again.

PKGBUILDs are made to be simple and straightforward. Can you imagine a package with, say, 20 of your "arch-flags" (you seem offended when I call them use flags, which is exactly what they are)? And what about, say, adding an "arch-flag" to vim which also requires a recompile of, say, cscope? now you get into the realm of cyclic recompiles... ok, so I want to "use" feature "Z" with vim, which requires cscope to be recompiled to support feature "Y", but feature "Y" requires perl to be installed, and also compiled with feature "Z"... it's just too complicated...

The Arch Way wrote:

If you try to hide the complexity of the system, you'll end up with more complex system.

You're trying to extrapolate configuration options made by developers to a system which anyone can use like switches without knowing the full impact (i.e. USE=gtk emerge vim, ENABLE_GTK=y makepkg, etc). This is how you get from 150 lines (xorg PKGBUILD) to 3000+ lines (xorg ebuild).

It's too impractical and goes against the standard arch mantra of simplicity and the KISS philosophy.

I'll use a real example based on the PKGBUILD you've changed: in my entire time I've been with arch, no one has ever complained "why isn't vim compiled with option X??" people who cared (like myself) simply used abs to get the PKGBUILD, added "--enable-pythoninterp" at the right place and ran "makepkg -i" - problem solved... no wacky "arch-flags", no excess work on the package maintainers... it's simple, and simplicity rules here

baptux · 2005-06-29 17:42:32

Perhaps you're right, but, I'll give a try to Arch linux and see.

I'm sure I could be done to use this kind of use flags (as you call them ), FreeBSD does it and it's not as important as it is in gentoo.

I'll see if it's so important to get this options after trying Arch linux, but if I miss it and love Arch, I'll be back to find out a good way to use it .

dtw · 2005-09-26 07:29:37

And baptux was never heard from again...

phrakture · 2005-09-26 15:56:32

dibblethewrecker wrote:

And baptux was never heard from again...

Thread revivals are the new black now? heh

Arch Linux

#1 2005-06-29 15:49:42

[PKGBUILD] new rulez for the creation

#2 2005-06-29 16:02:35

Re: [PKGBUILD] new rulez for the creation

#3 2005-06-29 16:18:51

Re: [PKGBUILD] new rulez for the creation

#4 2005-06-29 17:17:26

Re: [PKGBUILD] new rulez for the creation

#5 2005-06-29 17:42:32

Re: [PKGBUILD] new rulez for the creation

#6 2005-09-26 07:29:37

Re: [PKGBUILD] new rulez for the creation

#7 2005-09-26 15:56:32

Re: [PKGBUILD] new rulez for the creation

Board footer