Re: State of the Art wrt XML/XSL.
Fred Reimer wrote:
> Well, I wouldn't use quite so strong words, but I don't understand
> myself why Debian has to make custom deb packages for CPAN modules.
There are several reasons. The most important two are:
* everyone makes mistakes
* TIMTOWTDI (really)
Everyone makes mistakes -- so CPAN authors can make mistakes. Therefore,
Debian has to have a way to correct those mistakes (and make mistakes of
our own!). If we pulled directly from CPAN, we would have no way to
insert fixes.
There Is More Than One Way To Do It -- not just in in perl coding, but in
filesystem layout and system integration as well. Debian's filesystem
layout for perl is not idential to the default perl layout. We did this
for valid and good reasons, and perl demigods have looked at it and said
it makes sense -- but modules have to be modified to fit in this layout.
Debian's dependancy system is a superset of the dependancy information
in CPAN, since it includes dependancies on C libraries and standalone
programs. Therefore, we need to be able to manually add such dependancy
information to perl module packages to ensure the high degree of
integration that gives Debian its good name.
> Wouldn't it be workable to create deb "packages" that were more like
> installation helper scripts instead of the binaries themselves? So you
> select a package and when it was installed your system would run
> something like "perl -MCPAN -e 'install XML::XPath'"
And what do you do if your system is not on the net?
Or if the perl module is an XS module and has to be compiled on the fly?
And you don't have space for a compiler or do not want it on this system
for administrative reasons?
Or if the module on CPAN has been renamed since the last release of
Debian, and the command fails?
Or if the module on CPAN has been upgraded since the last realse of
Debian, and a newer version is retreived, which breaks other software on
the Debian system?
--
see shy jo
Reply to: