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

Re: Perl 5.6.0 Is Here!

Moin Chip Salzenberg,

> I never did like perllocal.pod.  Debian tends to use directories for
> that sort of thing.  I suggest we have a directory whose contents are
> used to build perllocal.pod after module install/remove.  Something
> modelled on /etc/modutils should serve us well, and it might even get
> pushed back upstream.

  perllocal.pod is a good way to look whats installed. I normaly use
  this to produce a bundle file, instead of using the normal autobundle.

> > Perhaps a good way solve this would be to use PPM from the
> > ActiveState Perl.
> What would that gain us over a modutils-like approach?  (Serious
> question -- I'm not that familiar with PPM.)

  I'm also not familar with PPM. But as far as I know, the way ActiveState
  handles modules, could also offer a solution to Debian.

  My first idea (some month ago) was to pack the !original! tar.gz
  files from CPAN and to run the complete "perl Makefile.PL && make &&
  make test && make install" on them during postinst. But this would
  require a CC for installing modules.

  ActiveState has the same problem (even worse as their Perl is based
  on M$ CC, which is deprecicated buyware for folks like me) so they
  just pack the things in blib in a tgz together with an XML file into
  a zip file. Now the installation process does not need to call CC
  if installing some XS, as only the "make test && make install" is
  necessary on the client, and the "perl Makefile.PL && make" already
  done while building the PPM.

  I think that a 'scan CPAN' -> 'build debian' could be done automaticaly ;-)

  Debian Perl 5.6 may also come with a ExtUtils::MM_Debian, to update the
  dpgk database, to tell Debian that some module was installed by CPAN.
> I'm not getting that.  Which db libraries do you have installed?  I'm
> using the one in glibc:

  If you only have the file from libc, your Perl wont support DB_File.
  You also need the libdb2-dev, which will cause the known error.

[from t/lib/anydbm.t]
# anydbm.t test 12 will fail when AnyDBM_File uses the combination of
# DB_File and Berkeley DB 2.4.10 (or greater).
# You are using DB_File $DB_File::VERSION and Berkeley DB $compact
# Berkeley DB 2 from version 2.4.10 onwards does not allow null keys.
# This feature will be reenabled in a future version of Berkeley DB.
> Well, I think the version scheme can support it.  So I suppose it's
> possible.  At the very least we can build and publicize unofficial
> debs that are intended to work with potato.

  For Potato we have only the inofficial way, as Potato is frozen
  now to become stable.  I've done a test build available at 
  	deb ftp://ftp.copyleft.de/pub/project/debian potato/
  but its 5.005-63, so I should upgrade this to Perl 5.6 ;-)

> > But I think that building a Perl 5.6 that is replacing Perl 5.005
> > wont be trivial, as any .deb that is depending on Perl has to be
> > rebuild.
> You win the "Understatement Of The Month" award.  :-)

  I thought about building my own /usr/lib/perl as a .deb, that has
  to raise conflict with the original perl, but after nightmares of
  headaches, I deceided to use an /opt/perl and to ignore the Debian
  /usr/bin/perl completely. This also meant that have to ignore Debian's
  Apache, SGML-tools, and many other things.

> Good point!  I suggest you file bug reports to that effect against all
> such packages.

  Well this is not a bug in implementation, but in concept. But I filed
  the bug-report anyway.

> A properly installed Perl system should allow CPAN updates.

  nope - Debian does not integrate CPAN. There is no way to delete
  some module using dselect, and to install it using CPAN. Dpkg
  dependencies wont know about the hand installed module, and wants
  the Debian one on next dselect.

  I'm not claiming that Debian's Perl does not work, but that Debian
  Perl is bad integrated.

  Those bugs are not implementation bugs, that can easy solved
  after a bug is known, but conceptual bugs, that would need some
  work inside and !outside! the Debian domain. And probately lots
  of discussion between der Perl and the Debian comunity to do it

Bye Michael
  mailto:kraehe@copyleft.de             UNA:+.? 'CED+2+:::Linux:2.2:14'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO MSDOS ESSE DELENDAM

Reply to: