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
