2007/12/27, K. Piche :

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. -- Roman Kyrylych (Роман Кирилич)

On Tue, 2008-01-08 at 17:44 -0600, Dan McGee wrote:

On Jan 8, 2008 5:28 PM, Roman Kyrylych wrote:

...

2007/12/27, K. Piche :

...

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

-Dan

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev -- K. Piche

On Wed, 2008-01-09 at 22:33 -0600, Dan McGee wrote:

On Jan 9, 2008 10:10 PM, K. Piche wrote:

...

On Tue, 2008-01-08 at 17:44 -0600, Dan McGee wrote:

...

On Jan 8, 2008 5:28 PM, Roman Kyrylych wrote:

...

2007/12/27, K. Piche :

...

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

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

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

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev -- K. Piche

I just wanted to throw this out there - this feature in general is straying away from the simplicity of PKGBUILDs. Can anyone give me a compelling reason why Dan's suggested implementation of this feature is any better than just doing the following: build () { source $startdir/src/perl.build; pre_build(); perl_build(); post_build(); } Which, to me, is a ton clearer about what exactly is going on than some seemingly random variable in the sea of PKGBUILD options called 'buildlib=perl.build'. It feels too much like featuritis, and hiding stuff from the users, in any of the implementations suggested.

On Sun, 2008-01-13 at 19:44 -0600, Dan McGee wrote:

On Jan 13, 2008 7:23 PM, K. Piche 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@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev -- K. Piche

On Jan 13, 2008 8:51 PM, Travis Willard wrote:

I just wanted to throw this out there - this feature in general is straying away from the simplicity of PKGBUILDs.

Can anyone give me a compelling reason why Dan's suggested implementation of this feature is any better than just doing the following:

build () { source $startdir/src/perl.build;

pre_build(); perl_build(); post_build(); }

Which, to me, is a ton clearer about what exactly is going on than some seemingly random variable in the sea of PKGBUILD options called 'buildlib=perl.build'.

It feels too much like featuritis, and hiding stuff from the users, in any of the implementations suggested.

Nicely done, nicely done. I always said that "source" is our equivalent of an "eclass". This is the best implementation I've see, so props.