Anyone know the answer to the first question?
----- Forwarded message from kynn@panix.com -----
From: kynn@panix.com
Date: Sun, 15 Feb 2004 21:22:22 -0500 (EST)
To: debian-user@lists.debian.org
Subject: Debian's Perl installation
[ I already sent this in many hours ago, but for some reason it hasn't
been posted to the list, so I'm sending it in again. My apologies
for any repeats. ]
Here are a couple of posts that I recently found while reading Usenet
news. I have myself run into similar problems/questions as the author
describes, so I thought I'd re-post them here. (BTW, the few replies
the OP received are not helpful.)
kj
P.S. please cc me in your replies.
======================================================================
( posted by "bill" in linux.debian.user)
bill => I'm doing a re-installation of Perl 5.8.2-2, because the
bill => currently installed version has threads enabled, which I
bill => don't want. When I do make test, 2 tests fail...
bill =>
bill => The first failing test (run/fresh_perl.t) fails with the
bill => error:
bill =>
bill => /home/knight/build/perl-5.8.2/perl: relocation error:
bill => /usr/lib/perl/5.8.2/auto/NDBM_File/NDBM_File.so: undefined symbol:
bill => Perl_Gthr_key_pt
ben => Whomever installed your previous version of perl should be
ben => shot :).
bill => I guess that'd be me. My only defense is that I used
bill => Debian's apt-get installation utility, which is entirely
bill => hands-off (at least in my hands). As far as I can tell,
bill => all the decisions as to where to put things are built
bill => into the downloaded package.
ben => Shared objects (indeed, anything arch-specific) should go
ben => in
ben =>
ben => /usr/lib/perl/5.8.2/arch-os-thread-multi/auto/whatever
ben =>
ben => which would stop the new perl from finding the old modules
ben => that are not compatible (as it would be looking for them in
ben =>
ben => /usr/lib/perl/5.8.2/arch-os/auto/whatever
ben =>
ben => , because it wasn't build with threads).
Is this a bug in the Debian testing perl-5.8.2 distribution?
ben => I'd suggest moving the whole auto directory into an
ben => arch-specific subdirectory
This sounds like good advice to me. Is there any good reason why
the Debian installation doesn't do it this way?
Thanks!
bill
======================================================================
( posted by "bill" in comp.lang.perl.misc)
I have three questions for anyone knowledgeable about Linux Debian's
Perl installation.
The first question is, how can I change the Configure parameters
that apt-get or dpkg -i use? The default installation (at least for
the testing distribution) has these values, which I don't entirely
agree with:
-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8.2 -Darchlib=/usr/lib/perl/5.8.2 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.2 -Dsitearch=/usr/local/lib/perl/5.8.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.2 -Dd_dosuid -des
My second question has to do with the default installation's library
directory structure. Mine (again, testing distribution) has library
files in
/usr/lib/perl/5.8.2/
/usr/lib/perl5
/usr/local/lib/perl/5.8.2/
/usr/share/perl/5.8.2/
/usr/local/share/perl/5.8.2/
/usr/share/perl5
What's up with lib vs. share? And perl/5.8.2 vs. perl5? What's the
rationale for breaking things up this way? Why not just a single
perl/5.8.2 directory, or at most /usr/lib/perl/5.8.2 and
/usr/local/lib/perl/5.8.2 (with corresponding arch-dependent
directories)?
My third question has to do with the location of auto subdirectories
and other architecture-dependent stuff. It appears that Debian's
default is to put this stuff directly in /usr/lib/perl/5.8.2/ and
/usr/local/lib/perl/5.8.2/, instead of segregating in directories
like /usr/lib/perl/5.8.2/some-architecture-string/ and
/usr/local/lib/perl/5.8.2/some-architecture-string/.
This can lead to installation bugs (as I've posted in another clpm
thread). What's Debian's rationale from deviating from Perl's
standard here? Will apt-get and dpkg get hopelessly confused if I
manually create these arch-dependent directories and move the auto
subdirectories to them?
Thanks!
bill
======================================================================
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
----- End forwarded message -----
--
see shy jo
Attachment:
signature.asc
Description: Digital signature