[pacman-dev] makepkg patch - simple pkg class feature

[Dan McGee]

On Jan 13, 2008 7:23 PM, K. Piche <kpiche at rogers.com> wrote:
> On Wed, 2008-01-09 at 22:33 -0600, Dan McGee wrote:
> > OK, now that the release is out the door (a whole hour ago :P), I'll
> > take a look.
> >
> > I've been thinking of something like this for a while, because this
> > kind of thing would be mucho-handy for SVN/GIT/etc. PKGBUILDs as well.
> >
> > How about something more like this?
> >
> > pkgname=foobar
> > pkgver=1.0
> > pkgrel=1
> > .......
> > buildlib=perl.build
> > install=foobar.install
> >
> > build() {
> >     pre_build()
> >     perl_build()
> >     post_build()
> > }
> >
> >
> > perl.build would be sourced before the build() function is called, so
> > those functions (and variable redefinitions) would be available. Hell,
> > you could probably even define build() in there as long as we set it
> > up right.
> >
> > This would allow a bit more flexibility than what your patch afforded
> > in that you could mix function calls with the ability to still tweak
> > the build in build().
>
>
> I'm not really sure there is a difference.  Your build calls the
> functions to run but that is equivalent to the array
> build_funcs="pre_build perl_build post_build".  It's just syntax.
>
> What I liked about my setup is that I could build a perl module with 6
> or 7 variables and no build() in the PKGBUILD.

And this is what I was trying to stay away from. I hate looking at
Gentoo emerge files (what are they called?), and I've never been a fan
of the huge abstraction that Frugalware uses in their PKGBUILD files.
The whole idea of a PKGBUILD in my eyes is ease of use- if a user
wants to customize it, everything is *right there* in front of them.
They don't have to fight to add or remove a single configure flag, or
get docs installed, etc.

> I also figured that the "optional" build functions would allow for
> interesting possibilities - define a build_funcs="patch configure
> compile install extras".  If a source distribution was standard no
> build() would be required but the parts of a standard build could be
> changed:
>
> pkgname=blah
> ...
> patch() {
>   patch -Np0 -i fixit.patch
> }
> EOF
>
> The local patch func would be used and the standard compile, install,
> etc would come from the class.  If a PKGBUILD had no patch() and there
> wasn't one in the class it would simply be skipped.

People switch to Arch, like what they see, and then attempt to build
their first package. A proficient Linux user can have one written in
10 minutes. I don't want anything to take that ease of use away,
that's all. And I know users wouldn't be required to use this, but I'm
sure they would want to customize a PKGBUILD that did and explaining
to a user why a build function is optional just seems to be too much
for me.

-Dan