Dag Wieers wrote:
On Mon, 15 Sep 2008, Scott Silva wrote:
on 9-14-2008 10:33 AM Dag Wieers spake the following:
On Sun, 14 Sep 2008, Hugo van der Kooij wrote:
I noticed in the past some perl conflicts. But it seems the issue runs
much deeper.
Multiple perl packages are in effect uninstallable due to conflits with
perl itself.
I have included one example below but I feel a lot of packages are
affected and the whole set of perl packages needs to be checked.
We know this, these are always manpages. We could remove the manpages for
the modules that are included with perl. But until now we decided it is a
good thing to not replace a 'base' perl module (given the complexity to
debug it).
So the only "solution" would be to not offer them.
I really don't see this as a problem.
Or set man pages as separate rpm's.
No, that could become very ugly. We could create a new macro that is set
for RHEL5 which forces the man-pages to not be installed when the module
also ships with RHEL's perl.
But then the manpages would be describing the wrong module versions.
Would it not be better to put them somewhere separate and then let
people use man -M or set their MANPATH accordingly?
Adjusting the MANPATH automatically is unfortunately not so easy since
that would mean scripting a change to /etc/man.config.
However I fear people are going to accidentally update their base perl
modules by RPMforge modules without knowing/understanding...
Intentionally breaking the packages to avoid this is a bad solution and
IMHO it has a negative impact on the perceived quality of rpmforge. It
sends the wrong signal and leads to misunderstandings (rpmforge is broken).
Even if I know I want these modules I can't get them without alot of
pain since yum/apt-get will refuse to install them because they're broken.
IMO the correct solution would be a separate repository accompanied by
information on how to adjust the MANPATH to get at the updated manpages
installed outside the normal man search-path.
Also more generally there should be some information on the issue with
@INC and perhaps a note on how setting PERL5LIB can be used to override
the bad @INC.
-tgc
_______________________________________________
users mailing list
[email protected]
http://lists.rpmforge.net/mailman/listinfo/users