[Beowulf] A press release

[Tim Cutts]

On 3 Jul 2008, at 2:38 pm, Prentice Bisbal wrote:

> Here's another reason to use tarballs: I have /usr/local shared to all
> my systems with with NFS.

Heh.  Your view of local is different from mine.  On my systems /usr/ 
local is local to the individual system.  We do have NFS mounted  
software of the kind you describe, but we stopped putting it in /usr/ 
local because users got confused thinking it was really local to the  
machine.  We now have a separate automounted /software directory for  
all that stuff.

> With RPM, deb, or whatever, I'd have to use func or ssh and a shell
> script w/ a loop to install on all systems (assuming nightly 'yum
> update' cron job won't work in this case)

Well, you don't, actually.  You can maintain a local repository of  
your custom packages, and then use something like cfengine or puppet  
to make sure everything is kept up to date.  I need the cfengine stuff  
anyway to keep various configuration files in sync, so extending it to  
package management was a no-brainer.

>
> This is incredibly helpful with Python, Perl, R, and other languages
> which have additional modules or libraries. Installing additional
> modules can be very easy (CPAN module for perl, for example). These
> modules aren't included in RPM format (that I know of), and when you
> upgrade, perl or python, the RPMs clobber whatever modules you  
> installed
> in /usr.

Yes, I agree, and that's what we do here /software/bin/perl is our  
supported perl version.  But you're not correct about the CPAN modules  
being clobbered, at least on Debian.  Debian's perl packages are  
configured such that locally installed CPAN modules go into a  
different tree from the package's own versions of the modules, so  
yours don't get clobbered on upgrade.  And if you really do insist on  
changing a file which belongs to a package, you can still tell Debian  
to leave it alone on package upgrade by marking it as diverted with  
'dpkg-divert'.

The debian guys really did put a lot of thought into how dpkg works.

>
> Compiling Perl can be time consuming vs. just installing the RPM, but
> once installed, if I run '/usr/local/bin/perl -MCPAN -e shell' as  
> root,
> I can install all the perl modules needed just once, and they won't be
> clobbered by an RPM update. In the end, this is much more efficient.  
> And
> CPAN manages dependencies automatically, too.

I agree.  In the case of perl, you're absolutely right.

>
> We use RT where I work, which requires a few Perl modules. On Friday,
> June 13 (Yes, Friday the 13! - it figures. ). I had to stop and  
> restart
> our web server that provides RT. The perl packages had recently been
> updated. When apache restarted, it couldn't find the necessary perl
> modules, and RT wouldn't function. It took me HOURS to track the  
> problem
> down to a couple missing perl modules.

*shrug*  I use RT as well, but it's pre-packaged for Debian, so I just  
use their version and don't have to worry about the dependencies.

Tim



-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.