Re: How can Debian accomodate new installation ?
>>>>> "John" == John Lapeyre <lapeyre@physics.Arizona.EDU> writes:
John> Hi, I have packaged several modules for Debian Linux.
John> We are currently discussing how to handle your new
John> installation hierarchy. I'd appreciate comments. We
John> currently have about 80 packages that would need to be
John> recompiled or repackaged every time the x in 5.00x changes.
John> We are also considered installing everything in, for
John> instance, /usr/lib/perl5/debian and making a symlink to the
John> current perl version number.
Here's one debian developer on both lists. :)
The site_arch component of @INC was specifically designed for this, to
save recompiling perl modules everytime there's a new perl version.
Site_arch does require, however, that binary compatibility be
maintained between perl releases and 5.005 broke that compatibility.
So no matter what you do, any XS module will need re-compiling (and if
you start altering the contents of @INC, non-XS modules will need
reinstalling too). Should 5.006 again break binary compatibility, you
will again face this problem. Generally, though, p5p and the pumpking
in particular do not break binary compatibility without an incredibly
good reason (for 5.005 that reasons was threads, PERL_OBJECT and the
move to ansi-ness).
It's not clear to me why debian began installing modules in perl_arch
by default. Perhaps Darren knows.
One other thing. None of perl's paths are cast in stone, they are all
changable at build time. Darren could simply choose to build perl
with a debian specific set of paths, rather than following the
possibly changeable perl default paths.
--
Stephen
---
Perl is really designed more for the guys that will hack Perl at least
20 minutes a day for the rest of their career. TCL/Python is more a
"20 minutes a week", and VB is probably in that "20 minutes a month"
group. :) -- Randal Schwartz
Reply to: