Re: State of the Art wrt XML/XSL.
Moin Joey Hess,
to be a bit back to topic - state of the art XML/XSL means :
use utf8;
This line will require Perl 5.6. Actual Perl/XML development without
this pragma is looking often like a 'shoot yourself in the foot'. UTF8
is the main reason /usr/bin/perl should be upgraded to asap. The current
Debian Perl is ignoring the fact that Linux is the main 'legal' OS in
China, and that therefore China is the becoming larges Linux user base.
If I add korea, japan and europe, people who can live without Perl 5.6
to process their XML are a minority.
> Debconf is a bad example here;
debconf is a very bad example indeed ;-( Its on of 4 bad examples !
I call the following packages badly broken :
debconf - because of Debian::DebConf
debhelper - because of Debian::Debhelper
netbase - because of DebianNet
dpkg-perl - because of Dpkg::Archive and Dpkg::Package
Those 4 modules are standing in a the way of a Debian/CPAN integration.
Without a Debian/CPAN integration, update-alternative wont work for Perl.
Debian/CPAN integration should start at MakeMaker! It should be trivial
to extract Debian dependencies from the XML files provided by 'make ppd'.
We may wrap a generic install script around blib/ - and generate
libfoobaa-perl on the fly. This could be done every night. The other
part that should go into MakeMaker, is to tell Debian about Perl
modules that have been installed by hand. As now any module installs
from blib/ regardless whether it was installed by apt-get or by hand,
a seamless 'update-alternative perl' should be possible using CPAN
autobundle.
> You're not thinking about perl in the debian way, and that is your whole
> problem. What is the point of making a bundle on a debian system?
ok lets think about Perl in a Debian way - I'm the author of XML::Edifact
and several other modules. Actual versions of this modules need 'use utf8;',
so the last XML::Edifact that worked was 0.40. What if some debian maintainer
think's its a good think, to provide a United Nation EDIFACT parser for
Debian. He'll provide a Debian package. But wait - this Debian package is
out of date as actual version is 0.44. The same can be most likely said
about the next Sablotron unstable major likely going the C++ SAX 2.0 way.
The point of running autobundle is to have a 'state of the art Perl'
if you need it for 'state of the art XML/XSL' development. You may
of course say that 'state of the art Java' is a requirement also.
Here debian also badly fails - but Debian is not guilty in this case, Sun is.
So my hole problem is still : Critical Debian Perl Modules !IGNORE CPAN!
making it impossible to do any actual XML work with Debian's /usr/bin/perl.
> > - its impossible to query those critical Perl modules for documentation
> > using e.g. 'perldoc Debian::DebConf' shows me 'No documentation found'.
>
> That is because debconf does not include a module by that name (duh),
bakunin:~ $ fgrep /usr/lib/perl5/ /var/lib/dpkg/info/debconf.list | wc
74 74 3645
bakunin:~ $
I dont know, but my Debian has a Debian::DebCon tree containing 74
modules. Those 74 modules and the others in /usr/lib/perl5/{Debian,Dpkg}
should be coded in a Perl way, and uploaded to CPAN. The Debian source
of those packages may be processed by 'perl Makefile.PL', to satisfy
the Debian constrain, that the package should build from a plain old
Makefile. But the Perl module on CPAN should be the original, while the
Debian source package should only be a derivate.
> the pod docs are in the source package
If I want to !use! some Perl module, I query 'perldoc'. If I want to !use!
some GNU stuff, I query 'info'. I only unpack the source by hand, if I want
to !hack! on some things. So modules in the 4 mentioned packages are, not
only the reason why Debian Perl is allways some versions behind, but they
are effective 'useless' as there is no perldoc, of how to use them.
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: