Re: How can Debian accomodate new installation ?
> "Andy" == Andy Dougherty <[EMAIL PROTECTED]> writes: [snip] That's what I hate about you, Andy. You always have such clear and rational explanations for things :) -- 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
Re: How can Debian accomodate new installation ?
On Thu, 8 Oct 1998, Stephen Zander wrote: > It's not clear to me why debian began installing modules in perl_arch > by default. Perhaps Darren knows. Debian (sensibly, in my opinion) puts $sitelib and $sitearch in /usr/local and leaves them for the individual end user to use to install local extensions. The problem arises, then, what to do with modules such as Tk, which Debian supplies in precompiled form. Darren's solution of putting all Debian-supplied extensions (be they part of the perl core, such as POSIX.so or optional extensions, such as Tk.so) in the Debian-controlled /usr/lib/perl5 hierarchy makes good sense to me. The problem then arises what to do when perl undergoes a minor maintenance revision (e.g. 5.004_02 -> 5.004_03). Since these minor maintenance revisions are supposed to maintain binary compatibility, there is no need to recompile all the add-on extensions right away. However, the default perl installation directory would have changed from 5.00402 to 5.00403, and suddenly the modules would have apparently disappeared. Darren neatly solved _that_ problem by omitting the subversion number on maintenance releases so that all of 5.004_0x modules go into the /usr/lib/perl5/i386-linux/5.004/ directory. Upgrades between compatible perl maintenance subversions then don't break other modules. One of the primary purposes of perl's installation directory structure (and recent reorganization) was to allow users to have more than one version of perl installed at a time. Debian users generally don't do that -- perl5.005 will replace 5.004 -- so the installation hierarchy probably doesn't help all that much. Once 5.004 is replaced, all the compiled modules that were built under it will become immediately non-working, and they will need to be replaced too. (I suppose one could draw upon the a.out->ELF or libc5-libc6 experience to try to make a smooth transition, but I'm not sure it'd be worth it.) Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: How can Debian accomodate new installation ?
> "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
