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

[K. Piche]

On Sun, 2008-01-13 at 19:44 -0600, Dan McGee wrote:
> 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.

Ebuilds.  :)  I'm not fully aware of Frugal's method - wasn't it a
collection of Fblah macros?  The "class" method does hide things from
the packager.

> > 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.

I can't disagree with this - the simplicity of Arch does rule.  So
basically you want a collection of standard build functions.

> -Dan
> 
> _______________________________________________
> pacman-dev mailing list
> pacman-dev at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev
-- 
K. Piche <kpiche at rogers.com>