Hi,

so, if my understanding is correct, the idea would be to go on with a
sort of "mixed" responsibility between experiment software managers and
local site managers. If the experiment needs something very specific it
asks the sites to install it, so that the experiment software itself is
in some way guaranteed to work.

But, since experiments in general come with all the pieces into their
rpms (CMS puts also the gcc compiler, just in case...), and since sites
are supposed to be binary compatible with with RHEL (or SL), I don't see
the need for something like that. If the esperiment doesn't trust the
local gcc, it installs its own gcc, like CMS does. So that the
experiment software is almost "autoconsistent"...

Furthermore the procedure of software installation would become more
complicated. The number of sites supporting, for example, CMS is growing
up and, as the ESM, I'm driving crazy to install sw remotely with grid
jobs. My idea would be to have an almost authomatic procedure to start
deploying software as soon as a new release is ready.

In the view you propose, I should make a list of requirements, send it
to all site managers whose site I would like to "exploit", wait for the
"green light" and then start installing. Did I understand correctly?

Then, maybe, the specific rpms conflict with the standard configuration...

To me, at this point, would be better to leave to site managers also the
experiment software installation, as it was before, then mix the
responsibility.

Cheers

Marco

owen maroney wrote:
> Hi,
>
> I think this problem is more-or-less exactly what Kostas had in mind in
> his contribution to the OS Name debate:
>
>  > So if understand you correctly you should not even have to care about
>  > the tag. Because something is called RHEL3 or FC3 it doesn't mean that
>  > it has the version of glibc/limxml or whatever else that you need.
>  >
>  > I think it will be much better if you can provide a list of requirements
>  > that your experiment needs and we can make sure that if we support your
>  > experiment the requirements are there.
>  >
>  > Since we are all supposed to have binary compatibility with RHEL there
>  > are many ways that you can provide such a list. For example an rpm
>  > with requires for your software:
>  >
>  > rpm -q experiment-system-support --requires
>  > libc.so.6()
>  > libc.so.6(GLIBC_2.2.5)
>  > libperl.so()
>  > libpthread.so.0(GLIBC_2.2.5)
>  > perl >= 1:5.8.0
>  > perl(Getopt::Std)
>  > /bin/bash
>  > libqt-mt.so.3()
>  > libstdc++.so.6(CXXABI_1.3)
>  > beecrypt >= 3.0.1
>  >
>  > With something like that me as a sysadmin i can easilly check and
> install
>  > automatically everything from the base system that you need and
> publish that
>  > as a tag. If the tag is there you *know* that the software that you
> require
>  > is available and you only have to worry about binary compatibility
> which in
>  > theory *is* there.
>  >
>  > Cheers,
>  > Kostas
>
> This doesn't require sysadmins to have preinstalled specific packages as
> a baseline, but if these packages are required by an experiment, then
> such a missing package can be specified and installed in this way.  And
> VO's won't have to install missing packages in their own software area!
>
> There didn't seem to be any response Kostas suggestion: to me it sounds
> like a very good idea...
>
>
> Burke, S (Stephen) wrote:
>
>  > Hi *,
>  >
>  > I'd like to extend the discussion about OS names to the question of what
>  > packages are assumed to be installed. Yesterday I was a bit surprised to
>  > find that the RAL installation of SL does not come with a C++ compiler
>  > installed by default; also atlas apparently found that some other
>  > gcc-related packages were installed in some places and not others. Steve
>  > Traylen tells me that sites decide individually what to install, and
>  > that if VOs need particular packages they need to ask sites to do it. It
>  > seems to me that this is not a very scalable solution, at least for
>  > something as basic as a compiler, and that there should be some
>  > agreement on what should be there by default. If we don't get agreement
>  > I suspect we'll be back to the situation where VOs have to install
>  > pretty much everything in their own software area because they won't be
>  > able to rely on anything ...
>  >
>  > Stephen
>  >
>
> --
> =======================================================
> Dr O J E Maroney # London Tier 2 Technical Co-ordinator
>
> Tel. (+44)20 759 47802
>
> Imperial College London
> High Energy Physics Department
> The Blackett Laboratory
> Prince Consort Road, London, SW7 2BW
> ====================================
>


--
Marco Corvo
Cern/Infn Ph-Cmc  CH-1211 Geneva 23
Phone: +41 22 7671692   office: 40 3A-15
Email: marco.corvo @ cern.ch
        marco.corvo @ cnaf.infn.it