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

FWD: Debian's Perl installation

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.)


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?



  ( 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


  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

  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

  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?



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

Reply to: