[suggest] perl modules with conflicting man pages
dag at wieers.com
Mon Jun 30 18:45:56 CEST 2008
On Mon, 30 Jun 2008, Peter Willis wrote:
> Dag Wieers wrote:
>> On Mon, 30 Jun 2008, Peter Willis wrote:
>>> Hi, there are a couple perl modules in rpmforge which upgrade older
>>> versions in perl core, but the perl modules have man pages which exist in
>>> perl core and prevent them from being installed. These seem to be
>>> requirements for other perl modules so it is preventing yum from
>>> installing other modules. Here are some example errors from yum:
>>> file /usr/share/man/man3/IO::Socket::UNIX.3pm.gz from install of
>>> perl-IO-1.2301-1.el5.rf conflicts with file from package
>>> file /usr/bin/enc2xs from install of perl-Encode-2.25-1.el5.rf conflicts
>>> with file from package perl-5.8.8-10.el5_0.2
>>> file /usr/share/man/man3/Encode.3pm.gz from install of
>>> perl-Encode-2.25-1.el5.rf conflicts with file from package
>>> file /usr/share/man/man3/Getopt::Long.3pm.gz from install of
>>> perl-Getopt-Long-2.37-1.el5.rf conflicts with file from package
>>> file /usr/share/man/man3/Test::Harness.3pm.gz from install of
>>> perl-Test-Harness-3.11-1.el5.rf conflicts with file from package
>> The solution is to disable building those packages on RHEL5, rather then to
>> remove the manpage.
> I haven't yet researched the exact requirements of the dependent modules but
> I think they are built because newer versions are required to obtain new
> functionality/support for other 3rd-party modules. I think if they aren't
> built the other modules will not build/install, which if true would simply
> block support for those 3rd-party modules.
Correct. The message to anyone using perl modules is:
If you want your product to work on RHEL4, or RHEL5, then do not
require any newer versions of those perl modules.
We do not want to replace perl modules that come with RHEL because that
would invalidate that RHEL release.
The application should be written to work on RHEL, RHEL should not be
modified to assist an application. The main reason would be that otherwise
applications would not be able to coexist on a single RHEL. Maybe needing
incompatible versions of the same perl module.
And if you *do* want a certain application to run on a RHEL release, then
it should ship its own perl modules in its own perl-module path to not
affect the system itself.
The same is true for PHP, python and other languages. You build the
application to work on an OS and not the other way around.
> Would changing the mandir to /usr/local/share/man be an acceptable fix? If
> it's not already in the default MANPATH you could add an
> /etc/profile.d/manpath.[c]sh which added it. For bindir files you could
> rename those files (for the few perl modules that install files into bindir)
> with a ".new" extension and add a %post section that for each non-symlink
> file on a system which matched the original file name, mv the file to
> file.bak and symlink the file.new to the base file name.
> I'll first find out if upgrading these modules is required for any 3rd-party
> modules already in rpmforge and reply to the list with the results.
Changing the manpath will not make a difference to the reason why we would
not like those perl modules in the first place. We are lucky they could
not be installed.
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
More information about the users