>>>>> "John" == John Lapeyre <[EMAIL PROTECTED]> 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