On Fri, 2005-04-08 at 11:24, Peter Elmer wrote:

>   I would actually hope that it is possible to converge on _one_ single
> distribution rather than two (SL3 _and_ SLC3). Having two >very< similar, but
> not identical, SL flavors (in addition to RHEL3) is already and will 
> continue to be a source of confusion in the computing centers, some of which
> are running one and some the other.

Clarification:

SL actually provides a mechanism to derive sub-distributions from it,
the so-called "sites". In a way, SLC3 is such a "site" (with the
exception that we went back to the original Red Hat distribution layout,
which does not affect the final installation result on a machine. To my
understanding, the version installed at Fermi is another "site":
ftp://linux.fnal.gov/linux/scientific/304/i386/sites/Fermi/Fermi.releasenote.latest

SLC3 uses binary RPMs from SL3 for most updates.

>   Given the strong participation of FNAL in CMS (and thus LHC computing), I 
> would hope that we would be able to converge on some mechanism whereby a 
> single distribution (and its updates) can serve the needs of (at least) most 
> of the HEP community. This goal seems _much_ closer than in the past, but we 
> are not quite there. Am I missing something fundamental which prevents us
> from aiming for that?

I believe that with SL(C)3 we have reached a local optimum between
uniformity across sites and adaption to local circumstances, and that
the challenge will rather be in keeping this over time.

SL3 is the de-facto standard in our community, but still site
modifications are (and will be) required, not only for configuration
issues, but also by installing additional software. Example:
OpenAFS is not present in RHE3, it is included in but not a requirement
for running SL3, but a lot of sites (like CERN) rely so much on it that
it has to be part of any "default" installation. Similar for local
interface tools ("phone" at CERN is the first one to come to my mind).

We also believe that pure user-to-service interface programs like mail
clients or web browsers are not required to be compatible across sites.
Nor is the OS kernel, which has primarily to cope with the local
hardware. Building dependencies on exact versions of any of these is
against good software practices anyway, since both these services and
the kernel provide an abstraction layer. But even here, exceptions would
be possible, provided such dependencies are documented explicitly.

In general, the responsibilities on compatibility seem to be well
defined (RHE3 sets the standard for both SL3 and SLC3; whoever breaks
compatibility has to fix it). I would agree that a "core" set of package
versions that should not be touched by local modifications could be
useful to prevent picking up accidental dependencies, but this (until
now) doesn't seem to be a major problem.

A totally uniform distribution would be less attractive than the current
"as close as possible, as different as required" model. It would remove
the possibility to locally fix shortcomings (e.g. hardware support in
the kernel), and would make integration into the site's workflow very
difficult. It would also not address the issue of default package sets
(i.e. which RPM is available *everywhere*), nor the problem of update
delays across sites. Which means that too-strict software dependencies
will continue to break across sites, and will (as is the case now) at
least have to be made explicit (fortunately, RPM is doing a decent job).


I would be happy to discuss such things with all interested sites at the
next HEPiX meeting (DE/Karlsruhe, May 9-13, http://www.fzk.de/hepix), we
have a time slot reserved for this already.

Best regards
jan



>                                  thanks,
>                                    Pete
> 
> > REd Hat Enterprise 3. We have no chance of persuading Red Hat to upgrade
> > versions in a "stable" release like RHE3 without "heavy" arguments, so
> > moving everybody forward is very unlikely. If we simply upgrade on SLC3
> > (and assuming we stay somehow backward compatible, e.g. with "compat-.."
> > libraries), we still risk that code compiled at CERN will not run
> > anywhere else, a major pain for LCG software. So we would need to "hide"
> > the add-on package in a non-default path, accessible only after a
> > conscious choice against this RHE3/SL3-compatibility has been taken. But
> > this is very close to what the LCG SPI installation is (they use AFS, we
> > could provide RPMs, but the actual result would be the same)...
> > 
> > This leaves "pestering" Red Hat with bug reports, until they realize
> > that moving forward is a viable alternative. Which means we would need
> > each individual problem is a format that can be passed on to Red Hat
> > (reproducible, clear indication of the circumstances -- 'proper' bug
> > reports in other words). And initially at least Red Hat would probably
> > be fixing these via backported patches (but perhaps at a slow pace..).
> > But at least the whole RHE3/SL3/SLC3 community would benefit from such
> > fixes.
> > 
> > >  -It looks like XFree86-devel-4.3.0-68.EL.i386.rpm is not installed
> > > by default. This creates a lot of headaches for many users who were
> > > used to a default and solid installation of the X11 suite.
> > > You can find a typical example of complaint at the ROOT Forum;
> > > http://root.cern.ch/phpBB2/viewtopic.php?t=1823
> > 
> > >From what I see, it should get installed by default, at least on SLC3:
> > 
> > XFree86-devel gets installed if the "CERN Recommended Setup"
> > installation is chosen (this is the default for interactive
> > installations), or if any of the following package groups is picked (e.g
> > for kickstart installs):
> >  X Software Development
> >  GNOME Software Development
> >  KDE Software Development
> >  Development (whole category)
> > 
> > I tried searching the ROOT forum for XFree86-devel OR x11-devel OR
> > libX11, but most of the problems seem to be for other distributions
> > (Mandrake/RH8/RH9/Windows :-). If you have pointers for other cases,
> > please let me have a look at them - maybe this is more a problem with
> > SL(not-C)3.
> > 
> > Regards
> > Jan
> > 
> 
> 
> 
> -------------------------------------------------------------------------
> Peter Elmer     E-mail: [log in to unmask]      Phone: +41 (22) 767-4644
> Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
> -------------------------------------------------------------------------