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

[Dan McGee]

On Jan 9, 2008 10:10 PM, K. Piche <kpiche at rogers.com> wrote:
>
>
> On Tue, 2008-01-08 at 17:44 -0600, Dan McGee wrote:
> > On Jan 8, 2008 5:28 PM, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> > > 2007/12/27, K. Piche <kpiche at rogers.com>:
> > >
> > > > Hi,
> > > >
> > > > I hope everyone had a great holiday!
> > > >
> > > > Perl module PKGBUILDs tend to be a mess and some build() functions are
> > > > not "standard".  Now with the new upcoming perl policy all of the
> > > > PKGBUILDs need to be "standardized" again.  To help combat this problem
> > > > I hacked up a package class feature where all the functions and package
> > > > defaults are set in a class file and sourced before the package is
> > > > built.  The class file can define a set of build functions to call
> > > > instead of just build().
> > > >
> > > > Some advantages:
> > > > - standardization of package types, even AUR packages could be uniform
> > > > - code in makepkg could be moved to a class so that it could easily be
> > > > override by people doing non-standard things: no man pages, i585 ports
> > > > - anything set in the PKGBUILD takes precedence over the class
> > > > - defined build functions can be optional (see the sample perl class)
> > > >
> > > > The patch is backwards compatible with non-class PKGBUILDs and I have
> > > > been using my classy makepkg for 5 days.
> > > >
> > > > Attached is the patch, a perl class, and sample PKGBUILD for
> > > > Sys::Syslog.  Right now the class file has to be in the same directory
> > > > as the PKGBUILD.
> > > >
> > > > Happy New Year!
> > > >
> > >
> > > Dan, Aaron, is this in your working trees somewhere?
> > > Otherwise it would be better to create a feature request on Flyspray
> > > so it won't get lost.
> >
> > Sorry that I haven't responded. At first glance, I like this idea. I
> > want to queue it up for 3.2 after some discussion and looking at it if
> > no one else objects. I've just been a bit busy worrying about release
> > fixes so I haven't had time to review this.
>
> That's why I didn't ask...  :)

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

Kevin, what do you think? Naming kinks would need to be worked out
(buildlib, a *.build convention, etc) but I think this is a good idea
to run with.

I'd also like to see the ability to have buildlib's be located both
locally and somewhere like /usr/share/makepkg/svn.build.

-Dan