I’m here in front of a really difficult dilemma - whether to package Perl, its modules or skip it alltogether.
Packaging Perl itself is okay - I can look how other distributions have done it, but packaging Perl modules is totally another can of worms. Here I’ll bring out major issues what I’ve encountered.
There are so many modules to package!
Oh my god! I’m a package maintainer! I must package, package and only package and…. only package?
How about… automation. This was the day when perl-autopackager project was born. It should create PKGBUILD files for all Perl modules by their distribution names, and soon handle automatic updating and rebuilding (bumping pkgrel in other words).
However… this led me into another issue
There is no easy way to figure if module is packaged with Perl itself or not currently
I borrowed patchprov script from Arch Linux Perl package, but it only lists CPAN modules *bundled* with Perl, not core libraries.
So I need to actually learn how Perl works and:
1) Instead of only adding CPAN modules to
provides array I also need to
2) Add core modules to
provides array or simply exclude them from package build/runtime requirements.
But wait! Not all core modules provide version information. So how could I workaround that…
Build systems are messy
I followed Arch’s “Perl package guidelines”, which is great and I’m going to enforce this on Warm Linux as well.
HOWEVER, there’s no easy way to figure out what kind of a build system of all 4 common ones does given Perl
package use (yes, really).
I can’t use dependency information to figure out if given module actually uses
Module::Build-style build system,
it might still have e.g.
Makefile.PL and require you to use
make instead of using
Build.PL at first place.
Hopefully I can sort this out in this week.