Re^2: blaming perl for not using a build policy

The version of perl (or apache or mysql) that comes with the OS should be used solely by the OS. The reason RH still ships Perl 5.8.0 (patched heavily) with their OS is because their scripts work with 5.8.0 and upgrading may break that.

This is what quite a lot of people have been claiming in this thread thus far, and you're the last one in order, so I'm replying to you that I may well buy your argument; but then the OS should clearly say so, to the effect that the Perl installation should not be touched in any way, and probably not even be used but possibly as a fallback solution if no other perl is available: its perl executable should not even be in the path, since for installation scripts the precise indication in the shebang line would suffice.

As far as I'm concerned, I think that the System perl should be robust enough not to warrant any major problem, and offer a reliable working environment. But above all, if system initializations scripts depend on it, then they should be written well enough not to break for something as innocent as a module upgrade. Which is what that holds for quite about any other program: if I write one say to use 5.008; then it should be guaranteed to work with any perl version higher or equal than that one, shouldn't it?

--
~~If you can't understand the incipit, then please check the IPB Campaign.~~

Comment on Re^2: blaming perl for not using a build policy Select or Download Code

Replies are listed 'Best First'.
Re^3: blaming perl for not using a build policy by moritz (Cardinal) on Aug 27, 2008 at 13:45 UTC
This is what quite a lot of people have been claiming in this thread thus far, and you're the last one in order, so I'm replying to you that I may well buy your argument; but then the OS should clearly say so, to the effect that the Perl installation should not be touched in any way Which includes not shipping a CPAN.pm and a `cpan` script. Clearly you never need CPAN for a perl that's never used for anything else but for the the operating system itself.	[reply] [d/l]
Re^3: blaming perl for not using a build policy by Anonymous Monk on Aug 27, 2008 at 14:46 UTC
IMHO, placing a binary in /usr/bin is a clear indication that it should be acceptable for general use. If something is there only for the system, it should go somewhere else (like /sbin or /usr/sbin).	[reply]
Re^4: blaming perl for not using a build policy by Argel (Prior) on May 04, 2009 at 21:54 UTC
Use: yes. Modify: no. Thats an important distinction to keep in mind. Elda Taluta; Sarks Sark; Ark Arks	[reply]
Re^3: blaming perl for not using a build policy by Zen (Deacon) on Sep 02, 2008 at 00:09 UTC
"but then the OS should clearly say so, to the effect that the Perl installation should not be touched in any way, and probably not even be used but possibly as a fallback solution if no other perl is available" ++. Please.	[reply]
Re^3: blaming perl for not using a build policy by Argel (Prior) on May 04, 2009 at 22:08 UTC
but then the OS should clearly say so . . . I find it really ironic that on a Linux system people have no problem messing with the system's Perl while they would likely not even think about touching it if they were running a commercial version of UNIX such as Solaris. It shouldn't have to be documented because it should be obvious, but for whatever reason the word "Linux" is justification to trump System Administration Best Practices. My guess is that people are used to playing around with Linux as a hobby and thus forget to go back into Best Practices mode when using it at work. Sorry for the late post. I stumbled upon this thread today and thought I would respond to a few of the comments in it. Elda Taluta; Sarks Sark; Ark Arks	[reply]