[PKGBUILD] new rulez for the creation

Question

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 <[email protected]>
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 <[email protected]>
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

Answer 1

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