Klaus Steinberger wrote:
Hi,
We have asked may times for volunteers to help us put all of those
scientific applications into SL. The only thing we ever get is "please
put in so.and.so". We do not get "Yes, I will help you put in these
scientific applications".
We talked about making a contrib RPM for root, but my colleague who maintains
the root installations at our site is somewhat reluctant to pack root into a
rpm. He says root is too much of a moving target to have it burn into a rpm.
Usually we have 3 installations of root on our systems in parallel (old, new,
prod) to maintain binary compatibility. This would be hard to do with RPM's.
Red Hat did something similar with python 1.5 and python 2.
I don't know what root is or what releases exist, so interpret this to
suit reality.
root's binaries go to
/usr/bin/root-<releaseno> - maybe /usr/bin/root-1.0, /usr/bin/root-1.5,
/usr/bin/root-2.0, Similar for man pages.
root's shared libraries also have the version in their filenames.
root's library-type scripts go to /usr/lib/root-<releaseno>. See perl
for examples.
root's docs go to /usr/share/doc/root-<releaseno>
Use Red Hat's alternatives system to maintain symlinks in /usr/bin that
point to the default root _on this system_. See /etc/alternatives/ for
other packages that use alternatives.
Uses can explicitly choose the version they want, maybe executing root-1.5
Alternatives is a standard way, but one could also use a script in
/etc/root to set users' environment for their prefered version; users
would source the one of choice. A symlink, /etc/profile.d/root.sh, would
point to the default version (but might need to be source explicitly in
some cases, think crontabs.)
What we do: root sits on a shared (NFS) storage, so we don't have to install
it on every desktop, they just use the shared storage.
Of course it would be easier with a rpm to maintain all those notebooks ....
Sincerly,
Klaus
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Please do not reply off-list
