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

Re: Perl 5.005.02



On Sun, Oct 11, 1998 at 11:28:06AM -0400, Roderick Schertler wrote:

> > Andy Dougherty, in an immanent manifestation of deity, wrote:
> >>
> >> After some thought, I think I'd recommend that perl5.005_xx retain the
> >> same directory structure that perl5.00[34]_xx did. (with 5.005 in place of
> >> 5.00[34], of course).

> I don't think Andy is taking into account your plan of allowing both
> threaded and non-threaded Perls present on the system at the same time.

That shouldn't matter, since the threaded version ought to have it's
own $Config{'archname'} and put all the thread-specific files in something
vaguely like /usr/lib/perl5/i386-linux-thread (Configure handles this
automatically).  The threaded and non-threaded versions can share the rest
of the files.  (Well, there can be only one /usr/bin/perl, of course:-).
I don't know how to tell dpkg that such files are shared, however.

If, however, Debian does move towards supporting simultaneous installation
of multiple perl versions, then I think the new 5.005 default directory
structure still won't be rich enough.  In that case, Debian probably ought
to introduce a new set of directories--perhaps call them $vendor_arch and
$vendor_lib--to hold Debian-supplied extensions and modules.  These would
work just like the /usr/local/lib/site* variables (in how they track
changes in perl versions) but they would be in the /usr/lib/ hierarchy for
Debian to use.

> It seems to me that the only real problem we've got with the current
> layout is that the *.pm files for extensions which have XS portions are
> placed in /usr/lib/perl5 rather than in /usr/lib/perl5/<arch>/<version>.

I thought MakeMaker was supposed to do that automatically already.  I'd
consider that a MakeMaker bug.

    Andy Dougherty		doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042




Reply to: