[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cern software



Christian Holm Christensen <cholm@nbi.dk> writes:

> Scientific Linux comes it to variants - the FermiLab variant and the
> CERN variant.  

One can install vanilla SL which is just RHEL.  But, that doesn't
negate all the other problems with SL that were brought up.  Besides
them, SL doesn't support upgrading in place between major releases.

> ROOT was close to hitting `main' for etch, but some unfortunate license
> problems prevented that.  The upload to Debian is postponed till that
> situation is remedied (upstream and I are working on it :)

I thought this was a solved problem as of 5.04/00.

>>  It uses its own package
>> manager, CMT (www.cmtsite.org) 
>
> CMT is an unfortunate mix of a build system and a package manager - very
> much geared to SL.  

I don't think it is SL or any OS specific.  One of its features is to
be cross platform.  CMT is actually pretty nice for what it does.  We
use it on another experiement (Daya Bay reactor neutrinos) to build
our code so I can attest that it works fine on Debian.  My only gripe
is its documentation.  It has a detailed manual but it is very hard,
for me at least, to find solutions to problems with it.

> Hopefully that's true.  However, be aware of RPM hooks in CMT, and other
> ill-conceived hacks that could distribut the system. 

I don't know of any RPM related anything in CMT. 

> I'd suggest setting up a test machine before you plunge into the big
> install.  If you package CMT for Debian, perhaps that would minimise
> your problem. 

Probably it's easiest to install CMT from source and share the
installation disk throughout the cluster.  Likewise with CMT built
packages.  CMT allows the concept of a base software release and
additionally one or more user-modified packages overriding base ones.

> Sounds good.   Don't you start up PROOF servers too? 

No, I haven't ever looked in to PROOF.

-Brett.



Reply to: