LANG="en_US"
SUPPORTED="en_US:en_US.UTF-8:en"
SYSFONT="latarcyrheb-sun16"
[download]

I used to feel the same way about CPAN, but either it's gotten much better, or I have a bigger pile of hammers to apply to things when they break. These days, I'm well below the threshold of frustration.

In your particular case -- are you sure you've exhausted the standard set of Fedora RPMs? I don't have a Fedora handy, but in my pile of standard RH9 RPMs, I have both perl-DBD-MySQL and mod_perl RPMs.

The module compiling problems due to Unicode implementation in RH9 were pretty much solved in FC1. That is, I have not had to mess with $LANG under FC1 to install modules, while this was necessary under RH9. There are still issues when reading SMB file systems, but Perl modules compile fine (as the poster already noted, his problem was in passing the tests, and the documentation actually provides a solution to that problem, which is due to file permissions).

As to solving the problem in the module's test suite, is there any reason not to move the files that have to be modified/written to /tmp, so that "nobody" can do this? Or have the test script change the permissions on the files? I suppose there's a portability issue here, since Windows essentially has no permissions, and the temp directory can be in various places on various systems. It seems silly to have a test suite that is doomed to failure on all 'nix systems and then put a "how to fix it" note in the docs...

Mandrake is not a server OS. It is a bleeding edge version of Red Hat with lots of pretty GUI stuff. Although RedHat is probably the dominent Linux server OS I find that a minimal install, rpm -e <widget> and then source installs of perl, apache, openssl, ssh etc remove almost all issues. When you do a binary install of anything you are typically linking here there and everywhere. It all works seemlessly if things are *where they are supposed to be* On RedHat/Mandrake they are not. By building your server essentially on top of a fairly naked kernel you get two benefits - stuff works and you have the latest secure versions of your server widgets. We use RH7.3, gcc 2.9x, and perl 5.6.2 and have very few issues.

One interesting misfeature of RH7.3 is the fact that many of the man dirs are missing. Here is an excerpt from our standard server setup docs:

man1 .. man9


Now because tripwire (amongst other programs tries to install into non
+-existent man directories ie man5 and man8 and redhat only has man1) 
+run this command to make sure these dirs exist.

mkdir /usr/man
perl -e 'mkdir "/usr/man/man$_" for 1..9'
ls /usr/man
man1 man2 man3 man4 man5 man6 man7 man8 man9
$

odd that some programs simply assume that manX will exist and don't do
+ a -p but.....they do.

If you don't do this now a whole lot of the software we are about to i
+ntall will partially choke. By partially choke I mean they will insta
+ll but the man pages won't. So when you man widget it won't bloody we
+ll work. Do it now. I'll wait ;-)
[download]

cheers

tachyon

I'd suggest doing a direct install of Debian.

Knoppix is a great demo. But when you do install-to-disk and then the Debian upgrade, you'll find that Knoppix has rearranged several packages to its own taste, resulting in package management issues to sort out. A straight Debian install takes a little more work, but the upgrade path is a lot cleaner.

I'd also suggest making sure that you have some old Debian hands available for your inevitable questions about why things are the way that they are. (IRC works.)

You may be frustrated by Debian too - you'd have to choose between using Debian's very out of date packages and installing everything from source. If you end up taking the second option then you're better off with Gentoo or Slackware.