[arch-dev-public] Updated perl 5.10.0

[K. Piche]

On Tue, 2008-01-08 at 14:43 +0200, Roman Kyrylych wrote:
> 2008/1/3, K. Piche <kpiche at rogers.com>:
> > Another thing to note is that additional modules were added to the
> > default perl library so some official packages are not needed once
> > 5.10.0 is installed.  However the packages can be used to "update" parts
> > of the perl library.  I'm not sure how we're going to deal with this
> > situation yet.  For example perl 5.10.0 now comes with
> > IO::Compress::Base version 2.008, perl-io-compress-base is 2.006.  The
> > package is not required until 2.009 is released and before the perl
> > package gets updated.
> 
> I'm confused. If perl-io-compress-base will be at 2.009 and perl
> package will still have 2.008 - user cannot install
> perl-io-compress-base because pacman will complain about file
> conflicts.
> Either perl package should be rebuilt to include the newer IO::Compress::Base
> or all those base modules can be deps (or cannot because of tech limitations?).
> Did I get this right? (I'm not a perl user, never got to writing
> anything in it after reading some book long ago :-P)

It's magic grasshopper!  The new perl policy allows for perl module
packages to take precedence over the standard modules included in the
perl package.  The standard perl modules live
in /usr/{lib,share}/perl5/core_perl and the module packages live
in /usr/{lib,share}/perl5/vendor_perl.  Also the user can install
modules using the CPAN tool and those go
in /usr/{lib,share}/perl5/site_perl.

There can be three different versions of a perl module co-existing
without file conflicts (well except for man pages, shh!).  It's
basically like the $PATH variable but in perl it's called @INC.  So when
I say "updated" I mean that a package or CPAN-installed module are in
the PATH before the perl package's modules.

Hope that made sense.

k




-- 
K. Piche <kpiche at rogers.com>