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
perl-5.8.8-10.el5_0.2
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
perl-5.8.8-10.el5_0.2
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
perl-5.8.8-10.el5_0.2
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
perl-5.8.8-10.el5_0.2
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, [EMAIL PROTECTED], http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest
