Fred Reimer <[EMAIL PROTECTED]> writes: > I don't understand myself why Debian has to make custom deb packages > for CPAN modules.
Because anything else is *impossible* to reliably integrate, debug or otherwise claim to be demonstrably working in what is suppsed to be a internally consistent, largely plug-and-play distribution. Please note: there is _nothing_ that prevents people from installing perl-5.6 on their Debian boxes and using it. I think you'll find that a number of prominent Perl developers---Chip Salzenberg and Graham Barr, perhaps Andy Dougherty and others that don't come to mind right now---are able to use Debian as their platform for development with no problems. However, and here's the thing that I wish Michael Koehne would take some time to understand: Debian is a distribution. The whole point is that we present a pre-packaged, working set of packages that are all intended to function together. Sure, you can add things on---hell, you can use CPAN with our perl-5.005 packages, if you want, you don't _have_ to use debs of other-than-core modules at all---but replacing a core tool upon which a large part of the distrbution depends with an arbitrary hunk of user-compiled code is a guaranteed way to cuase ourselves no end of bug reports about which we will be able to do *absolutely nothing*. Hell, Michael himself admitted that Perl 5.6.0 wasn't stable enough to use as the default perl on Debian in a message to this list.[1] > 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'" Taken to its logical absurdity, why are you using a distribution anyway? Why don't you just self-compile everything using little shell scripts that download them things for you. I used to maintain Solaris boxes like that. The answer is "it's not appropriate for a distribution". It means you have to have a whole host of tools you might not otherwise have, just to install Digest::MD5 or HTML::Parser, and heaven help you if you have to do some of it on the old 386 that's sitting in the corner being used as a RAS server. But, as I said before, if you want to go this route, fine, use CPAN, not our pre-compiled packages. It'll work. > Part of the strength of Perl is that you can relatively easily > install and remove packages. Mixing this ability with binary > packages, in either a deb or rpm type system, just makes it harder > to maintain two different "systems." Learn to create the debs yourself, then. It's not hard---in fact, you can do most of them using a template where only about five lines change, and it only takes about five minutes a shot. Of course, some would suggest that the nigh-mechanical nature of the process suggests it should be automated,---to them I say that I did a totally clean install 5.005 on a Solaris box, and when I installed Bundle::CPAN using CPAN (my first action) the perl installation promptly rendered itself unusable because certain things didn't build because the Solaris box wasn't set up for it, and it didn't detect failures adequately, etc. I reinstalled perl and decided to deal with dependencies and such by hand, installing each module individually. That has _never_ happened on my Debian box, in part because _there's a human in the loop_. Anyone who doesn't understand the value of that in keeping a working system needs their head examined. Mike. 1. www.debian.org/Lists-Archives/debian-perl-0005/msg00001.html
