[arch-dev-public] perl modules in archlinux
Hi all, I've been busy modifying all perl packages today to follow the same installation method. I think I'm past halfway now, only 20-25 packages to go. I added some dependencies for modules which I retrieved from the META.yml and/or Makefile.PL files. Things I did: - make all build() functions the same - add !emptydirs to options to get rid of empty perl directories - add md5sums - update to newest versions - add licenses (used PerlArtistic for anything that doesn't have an official license) Please watch out carefully when adding new perl packages to the repository, we don't want these things to become bad again.
great job! Sunday 02 September 2007, Jan de Groot wrote: | - make all build() functions the same by the way: can we not have a predefined function that is defined somewhere central and makepkg knows about? something like buildperl() that you can just run in PKGBUILD if it is the same for a lot of pkgs. - D
On Sun, 2007-09-02 at 01:00 +0200, Damir Perisa wrote:
great job!
Sunday 02 September 2007, Jan de Groot wrote: | - make all build() functions the same
by the way: can we not have a predefined function that is defined somewhere central and makepkg knows about? something like buildperl() that you can just run in PKGBUILD if it is the same for a lot of pkgs.
- D
Besides the directory to go to for the build, there's not much difference. Some packages are a bit harder to do because they need customization (some of them have interactivity which you must disable...). I see we have several things going on in our distribution: - universal installed binaries, like gconfpkg in the gconf package to handle postinstall/preremove of gconf schemas - copy&paste like we always do - one stupid file that is copied into many directories because our packages should be able to build on its own (goodconf, badconf, uglyconf in gstreamer). I would love to see this one solved the same way as GConf BTW, a scriptlet in the Gstreamer0.10 package. We should have a unified way of doing these things. Frugalware can do it with their F* macros, Debian can do it with dh_*, Gentoo has their Eclasses, why can't we do this?
On 9/1/07, Jan de Groot <jan@jgc.homeip.net> wrote:
We should have a unified way of doing these things. Frugalware can do it with their F* macros, Debian can do it with dh_*, Gentoo has their Eclasses, why can't we do this?
Because everyone passes the buck and wants everyone else to implement their ideas? Go ahead and do it. Make a script, I'm sure we could figure out some way to get it into things elegantly... like say: /etc/makepkg.d/perl Then have makepkg load that somehow. /me shrugs I disagree with this sort of stuff, so I would never do it, and I'm sure a handful of other people feel the same - but if you do it, and it breaks nothing, I see no reason why we couldn't integrate it. You can send patches to Dan or I
Doesn't xterminus have a perl build system chugging along pretty well for a while now? Automated and everything? Wonder what he is up to lately....
On Sat, 2007-09-01 at 17:31 -0700, eliott wrote:
Doesn't xterminus have a perl build system chugging along pretty well for a while now? Automated and everything?
Wonder what he is up to lately....
His scripts autogenerate PKGBUILDs for perl packages. Though most things are included there, the removal of packlist and perllocal.pod files is not completely correct and empty directories aren't cleaned up.
2007/9/2, Aaron Griffin <aaronmgriffin@gmail.com>:
On 9/1/07, Jan de Groot <jan@jgc.homeip.net> wrote:
We should have a unified way of doing these things. Frugalware can do it with their F* macros, Debian can do it with dh_*, Gentoo has their Eclasses, why can't we do this?
Because everyone passes the buck and wants everyone else to implement their ideas?
Go ahead and do it. Make a script, I'm sure we could figure out some way to get it into things elegantly... like say: /etc/makepkg.d/perl Then have makepkg load that somehow.
/me shrugs
I disagree with this sort of stuff, so I would never do it, and I'm sure a handful of other people feel the same - but if you do it, and it breaks nothing, I see no reason why we couldn't integrate it.
You can send patches to Dan or I
I do like gconfpkg. It greatly simplifies creation of PKGBUILDs for Gnome applications. It is included in gconf package for 2 months already, so I think AUR packages can start using it. The good thing is that solution like gconfpkg doesn't require any changes to Pacman. The bad thing is that this solution can be used only for packages that depend on a package which include such script. -- Roman Kyrylych (Роман Кирилич)
participants (5)
-
Aaron Griffin
-
Damir Perisa
-
eliott
-
Jan de Groot
-
Roman Kyrylych