zerohero has asked for the wisdom of the Perl Monks concerning the following question:

I previously asked a question about packaging up perl modules as (Fedora) RPMs and got a lot of answers as to this being very hard and scary, and you wouldn't want to do this. However, after looking about there seem to be several different tools to do just this (although I haven't yet tried).

The most intriguing of these seems to be cpan2dist, which relies on the CPANPLUS code to create Fedora style RPMs.

I'd imagine that one problem is "mixing distro packages" (i.e. RPM hell), which results when mixing Fedora RPMs installed via YUM with CPAN modules. However, does cpan2dist solve these problems?

Does anyone understand the various types of problems that can arise and how to lessen them? Are there some huge outstanding issues to the way Fedora builds their packages (not sure why they don't just suck them out of CPAN and do some sort of autobuild procedure)?

Replies are listed 'Best First'.
Re: CPAN Modules, RPMs, CPAN++ (cpan2dist)
by perrin (Chancellor) on Feb 24, 2009 at 20:35 UTC

    I can tell you that we're using cpan2rpm, with some success. Here are a few of the pitfalls:

    • Some modules ask interactive questions when you try to build them. Very irritating when you want to script the RPM-ing of a set of modules. I asked for suggestions recently on how to deal with this. The only 100% solution is Expect.
    • The cpan2rpm script turns a lot of optional modules into RPM requires. This is bad. Hopefully cpan2dist doesn't do that.
    • Some modules won't build at all without other modules installed, e.g. DBD drivers that want DBI just to run their Makefile.PL. This sucks because we don't want to install DBI on our build box, but we have to.
    • Some modules are set to die when you run Makefile.PL if their pre-reqs are not installed, even though they aren't needed to build. This is totally wrong, but they still do it. Again, don't want to install the pre-reqs on the build box.

    As for mixing with distro packages, my advice is that you should build your own perl if it's an important piece of your software stack. The one that comes with Red Hat is built with threads support (read: performance penalty) and their own selection of patches. It's better to run the official version, IMO.

    You will also be at their mercy on which CPAN modules and version you can get if you stick with theirs. Want the lastest Devel::NYTProf? Forget it.