Hello all.

> With the RHEL6 beta out, and SL 5.5 released, it's time to really start 
> planning for SL6.
> There are a few idea's that would be good to be discussed before we
> charge forward to implement them.

Since we at CERN also start thinking about, let me share my opinions on this
subject..

> 
> *Sites - Customized SL releases

We have been using sites feature at the very beginning (SL(C) 3) and then
judged it little bit too complicated for us to implement and users to
understand. In SLC 4 we modified (heavily) anaconda installer. In SLC 5
we use unmodified anaconda with addition of updates.img where our
add-on modifications live.

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

> *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.

> *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.

> 
> *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.

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 ...

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

My opinion: Just the base system and updates - enabled (all of them ?
security only ? - I would go for all updates enabled: users requiring
it can easily opt-out, users who 'do not care' or know

Additional repos: EPEL, elrepo, ...  - disabled ?

(commenting on the comment about dag , atrpms and EPEL conflicts:
these conflics are unfortunately introduced by the fact that both
dag and atrpms replace existing system packages, while EPEL has
clear policy to not do so - which, being one of support persons
for a large users community - is very appreciable in the
context of consistent user experience across RH, SL, CentOS and
SLC)

[ My 0.02 CHF -> Why to stick with RH/SL/CentOS at all if you start
changing half of system libraries ... in such case better go for
some recent Fedora / Ubuntu or even Gentoo ... compatibility with
others using 'same' platform is lost anyway ..]


> 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 ?)

> 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.

> *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.

(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).

> 
> *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)

> 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 !

Cheers

Jarek
__
-------------------------------------------------------
_ Jaroslaw_Polok __________________ CERN - IT/OIS/ODS _
_ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _
_____________________________________ +41_78_792_0795 _