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 _