[packagers] [Fwd: Re: [users] perl-Test-Inline and perl-Test-Expect]

[Dag Wieers]

On Mon, 6 Aug 2007, Who Knows wrote:

> Dag Wieers wrote:
> > On Mon, 6 Aug 2007, Who Knows wrote:
> > > Dag Wieers wrote: ( on the users lis
> > >     
> > > >  The problem with older modules being shipped within the perl package is
> > > >  something that dates back to Red Hat 5 and possibly earlier. Only since
> > > >  recently, driven by Fedora, is Red Hat slowly releasing these modules.
> > >       
> > > Well this explains some of the issues I have been dealing with since the
> > > recent additions of perl-Module spec files.
> > >
> > > Do we want to standardize a way to deal with it such as the ExcludeDist
> > > and ExclusiveDist tags? Or is it an endeavor best left to each packager?
> >
> > What kind of problems do you see exactly ? If they block yum or apt from
> > properly working, then yes we should use ExclusiveDist/ExcludeDist.
> >
> > Missing perl module dependencies is something we are working on and is much
> > a work in progress. In fact I have started to run repoclosure to get rid of
> > the remaining missing perl modules. Some of them cannot be done though.
>   
> Perhaps then I am misunderstanding your comments about perl modules as part of
> the base distribution.
> 
> For example I ran into an issue today on a fc4 build that required a newer
> version
> of Getopt::Long. I was able to build the latest module perl-Getopt-Long, and
> successfully installed it without yum conflict, but now the system has two
> versions.
> 
> [mochbuild at server lib]$ find /usr/lib/perl5 -name 'Long.pm' | grep Getopt
> /usr/lib/perl5/5.8.6/Getopt/Long.pm
> /usr/lib/perl5/vendor_perl/5.8.6/Getopt/Long.pm
> 
> The original being version 2.34
> The vender_perl from the new module is version 2.35
> 
> After reading your comments I thought I had erred in installing a vendor_perl
> module
> when and existing base module was present?
> 
> Am I to assume if their are no yum conflicts ( there were not in the above
> case ) then
> I am okay?

There are no conflicts because the files are located in different 
directories and because you were lucky that there was no manual page.

You are okay in the sense that both packages are installed and you have 
both modules.

You are not okay in the sense that Red Hat ships perl modified so that 
perl_vendor directory (and others) come after its own directory. Which 
makes it impossible to replace a 'core' perl module.

This is different than what perl does by default or how it behaves on 
other distributions afaik. And is not how it ws intended.

The reason why Red Hat does this is probably that they don't want a broken 
system if someone replaces one of the perl modules they consider 'core'.

But compare it to other packages, if you manually replace your glibc to 
something you build, you can break your system as well. There should be no 
difference when I replace a 'base' perl module (if it was packages 
seperately).

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]