[Beowulf] A press release
tjrc at sanger.ac.uk
Thu Jul 3 07:31:53 PDT 2008
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
> 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
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
> 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.
> 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
> 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
> 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.
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.
More information about the Beowulf