My two cents: Using the system (?:perl|gcc|libc|rpm|deb|python|wx|jvm|libaio|libpcre|ruby|gnumake|cmake|libogg|mesa|bind|postfix|hal|xinetd|gettext|kernel|kernel source|cron) (just as a random sampling) and expecting it to work should be a given. There is no excuse for this stuff to be crap - just because "users" don't use them directly, but the system does, doesn't mean that they should be crap. This throws the entire distro into a tailspin: you'll report a performance problem to the upstream maintainer of some software that relies on one of these things, and they'll have no hope of reproducing and fixing because the problem is actually with your system rather than the other application. The fact that YOU are the "upstream" for some apps should have no bearing on this.
This is a different stand than I take on trying to use a *different* version of perl (or whatever - I'm not repeating the list) on the system than what comes with the distro. For that, I suggest putting the new version in a new path and not overwriting the old version at all, because the distro likely hasn't been tested with the new version, and especially with some core things like libc, perl, bash, rpm, deb, etc., you can really end up with an unusable system afterwards if you screw it up (either by building wrong, or by replacing with a binary-incompatible version or whatever).
If the version on the system is the correct level for you, why should you need to compile a private version? That just really makes everything more difficult for what should be no real reason. Down this path lies madness: instead of relying on the system libc, every application comes with its own... just because the system is unreliable? Fix the system, not the app.
In reply to Re: blaming perl for not using a build policy
by Tanktalus
in thread blaming perl for not using a build policy
by trwww
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |