Randall Hansen wrote: > This all started so simply - I just wanted the mysql DBI module. So I > fired up CPAN for the first time (perl -MCPAN -e shell)
It's generally a much better idea to install the debian package if it is available. Is this it? [EMAIL PROTECTED]:~>apt-cache search mysql dbi libdbd-mysql-perl - mySQL database interface for Perl If the module is not packaged (about 270 are), the next best thing is to use the dh-make-perl, which can build debian packages on the fly out of CPAN. I don't reccommend using CPAN for installing stuff on Debian systems. It's too smart for its own good. > , went through > the configuration, and then watched as it downloaded and installed > Perl 5.6.1. Oops. Debian.org doesn't even list a Perl 5.6.1; the most > recent they have is 5.6 (in unstable). Erm, unstable has had perl 5.6.1 in it since May 21st. > I *think* that Perl still works (although 90 minutes into this, I > still haven't gotten to the mysql driver), but here's my question: is > my Debian package system hosed? This isn't a production machine, so > I'm not worried about the odd bit of breakage, but I'd really like to > know what the implications are. It seems that CPAN is its own > mini-package manager, and it's conflicted with Debian's. Do apt-get > et. al. still think that Perl 5.005 is my current version? How would I > convince them otherwise? Well, if CPAN is building a new version of perl for you, it will not be installed in FHS compliant locations, and it will not look in those locations for perl modules. So if it ends up on your path before Debian's perl, things will begin to break all over the place. Luckily, it shouldn't be too difficult to find out where it was installed to and delete it. You might find `cruft' useful in doing so. -- see shy jo