perl module conflicts

February 1, 2008

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.