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
right.
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: