[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Perl modules and perl upgrade



*Richard Braakman wrote:
> I still don't see anything that will keep a system from breaking when
> perl 5.005 is installed, though.  Saying "upgrade everything" is not
> good enough -- we support partial upgrades.  If a user installs one
> package from the new distribution, and this pulls in the new perl, and
> that breaks every other perl module on the system, then there is a
> problem.
	Thats why we could use a debian-perl list.  In the perl thread from
March 12, Z. Hull makes a plan that satisfies some people (Joey H. and Chip
S.) . But I forgot too, and had to dig it out. (Not too hard  because it was
recent).
	The idea was to keep the current perl and perl5.005 at the same
time.  The  perl5.004  does  not use versioned directories.  And the new
modules depend on perl5.005.
	I do see a problem though.  What about scripts ?  Scripts should all
point to /usr/bin/perl, but we need simultaneous versions of perl.  I guess
/etc/alternatives can only point to one perl at a time.  But some scripts
will need different versions depending on which modules they are using. I am
confused, maybe I don't understand something.
	Does it make sense to set the unversioned perl library path to be 
 last in @INC in perl5.005, so any modules that were not 
upgraded will be found there ?
	
 btw. Here is an interesting bit from A. Cox from this week on lsb-discuss
   Im very concerned we don't try and mandate perl too much. Every tiny
   subrelease of perl breaks something different, and there is no formal
   grammar for perl to reference against that I can find.

   Perl is a bigger nightmare than libc variance

	John
-- 
John Lapeyre <lapeyre@physics.arizona.edu>,  lapeyre@debian.org
Tucson,AZ     http://www.physics.arizona.edu/~lapeyre


Reply to: