Re: blaming perl for not using a build policy

I started using F/OSS because it is free. Then, I used it because it is good enough (and more) for what I do. Then, I finally understood why I must use it and that is because I can tailor it to what I want.

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. Installation and maintenance scripts can take a little longer to run, but they have to run successfully.

My highly optimized webapp has very different needs than the OS perl. As such, I shouldn't be screwing with the OS perl by installing additional modules or upgrading stuff. I may break it. So, I ALWAYS compile my own Perl, Apache, and (in some cases) MySQL. I ALWAYS use my own gcc to do these things (largely because I want gcc 4 and the massive improvements over gcc 3.x). And, I ALWAYS put it somewhere else, in its own directory structure and usually in its own jail. And you should, too. Until you've seen an OS fall apart because someone upgraded a CPAN module and you had to fix it at 3am on a Sunday, you haven't lived. :-)

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re: blaming perl for not using a build policy

Replies are listed 'Best First'.
Re^2: blaming perl for not using a build policy by shmem (Chancellor) on Aug 27, 2008 at 14:43 UTC
The version of perl (or apache or mysql) that comes with the OS should be used solely by the OS. There's no distinct line between OS- and non-OS-stuff in RedHat; `/usr/local/bin` is there only because it's supposed to be there; all app stuff is jammed into `/usr` invariably. Is OpenOffice as shipped by RH meant to be used by the system only? Where does a RedHat system need mysql? 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. Mind to provide anything to prove that? If "their scripts" only work with a patched perl and might break with a perl release change, they are poorly written in the first place. But then, their OS related scripts are written in python. It is possible to de-select perl upon install, but it will be installed anyways because of bogus package dependencies. Let's have a look. Where does RH's systems rely on perl? As of a RHEL-4 update 7 default install (which ships 5.8.5, btw) [shmem@rhel4 ~]$ for pkg in `rpm -q --whatrequires perl \| grep -v perl +`; do rpm -ql $pkg \| xargs perl -nle 'exit if -d $ARGV[0];/\bperl\b/ +and print $ARGV and exit' ; done /usr/bin/genkey /usr/bin/foomatic-compiledb /usr/share/foomatic/db/source/printer/NEC-PinWriter_P6_plus.xml /usr/bin/decode-dimms.pl /usr/bin/fileshareset /usr/share/mimelnk/application/x-perl-module.desktop /usr/X11R6/bin/xscreensaver-getimage-file [shmem@rhel4 ~]$ [download] the only script "(C)RedHat" is `/usr/bin/genkey` of `crypto-utils` which is fairly old and doesn't rely on any esoteric perl configure settings or patches, and `[shmem@rhel4 ~]$ rpm -q --whatrequires crypto-utils no package requires crypto-utils [shmem@rhel4 ~]$ su - Password: [root@rhel4 ~]$ rpm -e crypto-utils [root@rhel4 ~]$` [download] not even that one is needed by the system. I have not checked, but I suspect the dependency on perl of any later RH OS to be even less.	[reply] [d/l] [select]
Re^2: blaming perl for not using a build policy by blazar (Canon) on Aug 27, 2008 at 13:36 UTC
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.~~	[reply] [d/l] [select]
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]


"be consistent"
	PerlMonks