perl module conflicts

In the process of packaging up the latest Moose and Class::MOP perl modules (and all the other dependencies) I discovered that the build process of some of them is asking for a version of Test::Simple which is more recent than that which is on SL5. Normally this would not be a problem, I would just grab the SRPM for that module, drop in the new source tar.gz and update version/changelog accordingly. There is a problem though with Test::Simple and some other modules as they are included as part of the RHEL/SL core perl package. Building my own package puts the perl modules into different locations but the manpages should go into the same directory /usr/share/man/man3 so we end up with file conflicts. I don’t see an easy way to resolve this issue and with the long lifetime of SL5 we are almost certainly going to be in this situation several times. At the moment this is not an important issue but what happens when we really need a newer version of a core module?

As an aside, it is interesting to contrast this with how Debian handle the problem so much better. The core versions of the modules are put into /usr/share/perl/5.8.8/ and /usr/lib/perl/5.8.8 (replace 5.8.8 with the current version of perl on any Debian system) and non-core modules go into /usr/share/perl5 and /usr/lib/perl5. They use the same manpage directory so file conflicts are avoided by the core versions using a .3perl file name suffix and non-core versions using the .3pm suffix. Why this is not the standard approach everywhere I cannot understand.

2 Responses to perl module conflicts

  1. sxw says:

    Fedora have now split the main perl RPM into a number of sub packages. I think this happened with F7, it’s certainly there in the F8 VM on my desktop. This means that you can replace the upstream version of (for example) Test::Simple with your own one, just by replacing the perl-Test-Simple package.

    Of course, that does require that the new version is API compatible with the old one – but I suspect that the same problem will occur with the Debian solution too, as perl seems to have no mechanism for requiring a particular version of a given module.

  2. cc says:

    Until you get a proper solution, it might be worth mailing the SL users’ list – we surely won’t be the first site to have come up against this, and someone else might have already done the work to solve it.