More patches, this time to makepkg.

Question

Makepkg needs extensibility.
What sort of extensibility, you ask?
Anything that automates a common task when building packages.
Examples:
Checking sources out of CVS
Applying patches
Doing build activites that are common to a particular set of software (example: the necessary environment initialization which must precede any GNUstep builds)
Should we keep adding stuff to makepkg, and bloat it up?  No.
Makepkg needs a pre-build stage.
I see more and more PKGBUILDs where a lot of what goes on in build() has nothing to do with building.  Or installing, for that matter.  Patching files... checking files out of CVS, etc.  "makepkg -o" (another patch of mine) is useless for a lot of packages if the files are being obtained by some method other than ftp or http.  Likewise, it's useless if they're going to be heavily patched before they're useable.  A packager should be able to type "makepkg -o" and be presented with the source tree exactly as it will be before actual configuration/building begins.
Certain makepkg functions need to be separated from makepkg itself.
The specific examples I have in mind are warn, msg, and error.  Why those three?  Well, I see plenty of postinstall scripts that kludgily do something like the following:
echo "==> You now need to GNU your linux"
echo "==> Knock on Stallman's door three times"
echo "==> Yell 'freedom'"
Likewise, some packages install an installer that can be used later.
Having functions like warn, msg, and error in a separate file means that a script can simply source that file and, as a result, be able to display messages in the same manner as makepkg does during a build, thus resulting in consistency and saved time.
Now I could sit and whine, but that's pointless..
Here is how my system looks right now:
/etc/makepkg.d
->  functions  <-- Contains warn, error, msg, and strip_url
->  patch <-- Contains routines to automate patching
->  cvs <-- Contains routines to automate CVS checkouts
And here's an example PKGBUILD that takes advantage of all this new loveliness:
pkgname=libxentac-cvs
pkgver=20040806
pkgrel=2
pkgdesc="A library which turns any computer into Canada"
depends=(libbritain libfrance)
source=(make-the-tragically-hip-sound-good.diff.gz international-relevance.patch.bz2)
md5sums=('e117f30d93856e0517ef0b2a5dcea383' 'e7169ccd28f81dbfca44add973d7d7eb')
patch=(make-the-tragically-hip-sound-good.diff international-relevance.patch)
cvsroot=":ext:[email protected]:/cvsroot/xentac"
cvsmod="libxentac"
cvsrsh="ssh"
prebuild() {
include cvs
include patch
sed -i s/foo/bar/ $startdir/src/$cvsmod/Makefile.in
build() {
cd $startdir/src/$cvsmod
./configure --enable-lots-of-wheat --density=minimal
make || return 1
make DESTDIR=$startdir/pkg || return 1
And here's what running 'makepkg -o' might look like:
==> Entering fakeroot environment
==> Making package: libxentac-cvs (Mon Sep 6 03:36:56 CDT 2004)
==> Checking Runtime Dependencies...
==> Checking Buildtime Dependencies...
==> Retrieving Sources...
==> Validating source files with MD5sums
==> Extracting Sources...
==> Preparing for checkout over SSH...
==> Fetching sources from CVS...
==> Applying make-the-tragically-hip-sound-good.diff at level 2...
patching file libxentac/src/hearing.c
patching file libxentac/src/taste.c
==> Applying international-relevance.patch at level 0...
patching file libxentac/src/telling-the-us-where-to-shove-it.c
==> Sources are ready.
Now I kid, I kid 
I like Canada, the Tragically Hip, and Herr Doktor Chustick.
But the point remains.  Those are some cool features, no?
I'm going to do some touch-up work on these, make a nice big diff, and post it up somewhere.  Stay tuned  :!:

Answer 1

Sarah, I know we are frequently at odds but I will try to explain myself on this.
I think you misunderstand the main purposes of these additions to makepkg, as well as the nature of the additions itself.
First of all, the biggest change is making makepkg extensible.  This can only be a good thing.  There is lots of code duplication between PKGBUILDs, and having the ability to consolidate certain tasks into a single makepkg addition is good.  My inspiration for this particular change was Portage which allows packagers to create "classes" and have ebuilds inherit from them; I think that's a bit much, but just extensibility as a feature in itself is a good goal.
Second, you need to look beyond whether something is good for packages that go  in current/extra.  One of the beauties of ABS is that it makes the package building process so simple that the average user is encouraged to package everything they install, instead of just installing it willy-nilly over their file system.  ABS is not just a way for people to produce publically-distributable or core-repository-worthy packages; it is a way for them to make sure that their customization of their own system results in something maintainable for years to come.  Adding things like a prebuild stage, and a "--pkg-only" target let users be lazier with PKGBUILDs that they make for themselves, and thus can only be a good thing for the casual packager-for-one's-own-system.  As of right now, makepkg basically requires that a PKGBUILD be perfect before you can build a proper package; if something messes up during the build stage of a particularly messy build, you're forced to start over from scratch.  When this involves CVS checkouts (once again, something many people will want to package for themselves, regardless of whether they belong in current/extra), you are not only wasting time but the bandwidth of the cvs server if you must check out again as you keep improving your PKGBUILD.  That is a bad thing.  Likewise with -pkg-only, the user doesn't even need his PKGBUILD to be correct at all... he can configure and build the software himself, then stage it into the destroot himself, and then have makepkg package it up into an installable package.  I would hope nobody who makes packages for inclusion in any Arch repository does this, but I am lazy, most people are lazy, and I see no reason why makepkg shouldn't accomodate laziness.  One of the biggest mistakes of overly-complicated systems like RPM or dpkg is that they make package building a voodoo art, since they focus on packages as solely a distributable thing.  I think the pragmatist realizes that most packaging, at least with a simple as system as abs, is for one's own self, and why not make it simpler for them?  What flies for my own system obviously doesn't fly for [current], but it should fly nonetheless
Praise Bob.
@@@@@@@^^~~~~~~~~~~~~~~~~~~~~^^@@@@@@@@
@@@@@@^ ~^ @ @@ @ @ @ I ~^@@@@@@
@@@@@ ~ ~~ ~I @@@@@
@@@@' ' _,w@< @@@@
@@@@ @@@@@@@@w___,w@@@@@@@@ @ @@@
@@@@ @@@@@@@@@@@@@@@@@@@@@@ I @@@
@@@@ @@@@@@@@@@@@@@@@@@@@*@[ i @@@
@@@@ @@@@@@@@@@@@@@@@@@@@[][ | ]@@@
@@@@ ~_,,_ ~@@@@@@@~ ____~ @ @@@
@@@@ _~ , , `@@@~ _ _`@ ]L J@@@
@@@@ , @@w@ww+ @@@ww``,,@w@ ][ @@@@
@@@@, @@@@www@@@ @@@@@@@ww@@@@@[ @@@@
@@@@@_|| @@@@@@P' @@P@@@@@@@@@@@[|c@@@@
@@@@@@w| '@@P~ P]@@@-~, ~Y@@^'],@@@@@@
@@@@@@@[ _ _J@@Tk ]]@@@@@@
@@@@@@@@,@ @@, c,,,,,,,y ,w@@[ ,@@@@@@@
@@@@@@@@@ i @w ====--_@@@@@ @@@@@@@@
@@@@@@@@@@`,P~ _ ~^^^^Y@@@@@ @@@@@@@@@
@@@@^^=^@@^ ^' ,ww,w@@@@@ _@@@@@@@@@@
@@@_xJ~ ~ , @@@@@@@P~_@@@@@@@@@@@@
@@ @, ,@@@,_____ _,J@@@@@@@@@@@@@
@@L `' ,@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@