Some comments from TRIUMF's perspective.  We use CentOS on servers and 
SL on desktops so my comments are heavily biased towards what our 
desktop users need.

Jaroslaw Polok wrote:
>> *Sites - Customized SL releases

For SL-4 and SL-5 we use standard SL plus our own internal repository of 
rpms that make customisations for use at TRIUMF.  The rpms are written 
to be modular and uninstallable (i.e. if they modify a config file, 
removing the rpm intelligently removes the modification)

> So for us [CERN] the way to go would be rather Fedora-like in the future..

We also like this idea.

  >> *Yum - autoupdate
> 
> For SLC we use a little bit different autoupdate script than
> SL does, but we will be looking at the possibility of using yum-cron
> AND yum-updateonboot together.

We use yum-cron and prefer it over yum-autoupdate for several reasons; 
mainly the flexibility of the yum-shell mechanism but also because 
e-mails are only sent when something fails.

It was me that asked for its inclusion last year.  Thanks Troy for 
including it.  I hope it will remain. At the time, I asked that 
yum-updatesd, yum-autoupdate and yum-cron be handled by the alternatives 
mechanism to avoid having more than one active.  But Troy rejected it as 
too complicated and confusing for ordinary desktop users

>> *Kernel-modules
> 
> Since RH introduced the kABI whitelisting with 5 and is going
> to continue to do so for 6: I believe the kABI tracing modules
> (as ones provided by elrepo) are very nice thing, saving us lots
> of recompilations - and do work very well, so I would definitely
> 'vote' for kmods.

Agreed

>> *Security - Bugs - Enhancement Updates
> 
>> If we had them in one big repository, we would have to label them as
>> security, bugs, enhansements, and them make sure we used the
>> yum-security plugin.

That's a nice idea.

> I believe above would address the issue and make the maintenance
> of repositories easier: also from user perspective we've found that
> having too many repositories is just confusing ...

Agreed

>> *Yum Repositories
>> What should we have for default?

I agree with what Jaroslaw wrote. base and all updates enabled, 
everything else disabled.  But this is something that I suspect most 
sites will customise.  We do and will continue to do so.

>> Should we still have "contrib"?
> 
> Looking at current content for SL 5 .. I think - not - most of things
> in there are available from elsewhere - and these which are not could
> be eventually transferred to these existing repos ... (in total
> contrib contains now a small number of packages ... about ~10-12 ?)

While I agree with this, I think it's good to have some sort of 
"contrib" or "extras" repo.   Packages can be added it to it in future 
without having to issue an update to yum-conf (or similar) which can be 
problematic.


>> Should we add "development"?
> 
> A repo that would contain upcoming updates ? -> yes, that would
> be good idea allowing users to prepare themselves for upcoming
> changes.

Isn't this fastbugs?

>> *JAVA
>> I propose we don't add Sun's (Oracle's) java.
> 
> Hmm.. This one I would actually add -> as long as it is not
> available from another repository: alternative option for users
> is going to Jpackage AND going to Oracle downloading stuff here and
> there and rebuilding by themselves - quite painful for end-user
> IMHO.

I disagree with Jaroslaw here and like the original proposal of _not_ 
adding Oracle/SUN Java.  The SUN rpms are terrible and having unsigned 
packages in the base and updates repos causes updates to fail if gpg-key 
checking is enabled.

I started with the Jpackage nosrc rpms and made several modifications to 
fix things like X11 paths, java-ws and the 64-bit browser plugin in 
alternatives.  I then build and sign SUN-java rpms for 
SL-{4,5}-{i386,x86_64} and put them in our local repos.  Our TRIUMF 
customisations exclude the java rpms from the SL  repos to avoid the 
signing-key issue.

We don't have permission to redistribute Oracle/SUN java so I can't make 
them available from here, but I would be willing to contribute them to 
some SL contribs/extras repo, and keep them up-to-date.

Troy - let mw know if you are interested.

> (without willing to start a religious war on OpenJDK vs Sun/Ora Java:
> I believe many users will just have a 'hard' requirement on this
> -> if it is shipped at the 'top SL level' it will be the same version
> used by all the sites which is good for compatibility - especially
> if it matches the version shipped by RH).

Are you referring to the SUN-java that is available to RH subscribers 
through one of the supplementary channels?

I agree that it would be good to be compatible with this and think that 
the packages I build are.

>> *What should we add to SL6
>> At the last Hepix meeting one of the discussions was that many
>> scientists are adding their packages to EPEL.  They would like it if
>> packages that are in EPEL stay just in EPEL and not go into SL unless
>> there is a good reason for it.
> 
> Sounds reasonable to me: why duplicate what is already there
> (at CERN we are slowly removing from SLC packages we were preparing
> ourselves that are now available from EPEL)

Agreed

>> A good reason would be that it is needed during the install.
>> I like this idea and would like to adopt it.
> 
> +1 ;-)
> 
> 
> Thanks Troy for starting the discussion !

Yep.  Thanks also to Jaroslaw for the thoughtful comments.

Kel Raywood
TRIUMF