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
