I was just reading a post by rafael and it got me thinking about something that I've been wondering about a for a long time.
Mainly, installing Perl modules from a vendor vs. installing via CPAN.
For myself, I usually install almost everything via CPAN... because they don't get updated during normal system updates. That way I've got a chance to run updates on a dev server (and my test scripts) before they make it into production.
In some cases I actually recompile a custom Apache and (mod)Perl specifically so that system updates don't fubar what I've written. (OSX is one such case. The vendor version(s) don't like Mason that well. Panther is better, but I've had problems that were resolved by compiling custom versions.)
Now, one obvious downside is when there might be a serious data damaging (or security) issue... and I haven't kept things up to date.
So... how do others handle module installs? Do you do everything one way... like always use the vendor version unless there isn't one.... a mixture, like installing everthing that requires a compiler using the vendor modules and the rest from CPAN... or is it less "planned" than that?
TIA
I do it like this. The vendor perl is for vendor-supplied software.
Re:My "best practices"
phillup on 2004-09-29T18:40:15
Wow!
That is a very nice write-up... and, even tho I've installed Perl quite a few times... I definitely picked up a pointer or two.
Thanks!
The vendor perl is for vendor-supplied software.
After I got a Mac, with OSX... I started feeling just this way.
I had not had much problems on my linux boxes, but I've still started doing some of them with custom installs of Apache and Perl (similar to your instructions) just so that I could fiddle more with the OS without having to worry about not being able to get some work done because I messed something up with a vendor upgrade.Re:My "best practices"
jdavidb on 2004-09-29T19:04:46
Thank you! Your expression of appreciation made my day!
I have in the past done custom installs of Perl/Apache for specific applications. For example, when I installed RT a couple of years back, I created an rt user and compiled everything (Perl, MySQL, Apache) as that user, keeping it separate from whatever else was on the system.
Re:My "best practices"
phillup on 2004-09-29T20:40:13
Well, RT uses Mason... and, that is what got me started on compiling custom versions.
I pretty much do Mason stuff all day long. (Writing an application used by a school district.)
And, there are a suprising number of vendors that ship an Apache/Perl combo that Mason is not totally happy about.
Generally I'll install Perl and any updates to it that the vendor releases (in this case, Red Hat) via their up2date/yum package management system. Any additional modules I want installed and/or updated I do via CPAN and track them on a daily basis with a cronjob using my modulereport script.
0 11 * * */root/bin/modulereport -rs
Drops a nice summary of updated/changed modules in my mailbox every morning at 11am (which gives the authors time to get their updates in for the day, and gives me some time to work on things before getting around to the perl updates).
This has also helped me track interesting module conflicts such as this morning when I noticed that yesterday's update of CPANPLUS installed some modules as part of Tk that conflict with similarly-named modules by other authors that have wildly different version numbers.
Admittedly it gets a bit confusing when there's a Perl update to the core that is not reflected by updates to the vendor's release of Perl (*sigh*), so the report lists a few modules that merely show a new Perl version instead of a new Module version, but at least this report makes it easier for me to see when this is the case so I don't accidentally try to start installing Perl instead of just a Module. =8)
Re:ancillary modules
phillup on 2004-09-29T18:42:01
Oh great, now I need another 'tuit.
;-)
Nice program.
Thanks!
