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