Just my tuppence worth...

On Mon, 7 Jun 2010, Troy Dawson wrote:

> Hello,
> 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.
>
> *Sites - Customized SL releases
> In the past, we have always put patches into anaconda (the installer) so
> that people and groups can more easily create a custom release.
> We were thinking of not changing the installer at all, but instead
> implement revisor, and it's friends, to create custom sites, in the same
> way that Fedora creates their custom spins.
> - This would be less work on our part
> - Documentation should be better since we would mainly be using Fedora's
> - The technique could be transfered to CentOS based distributions.

In versions before sl5 we generated our own trees which were much like the 
ones which could be put on the install media though in fact we only ever 
used them for network/kickstart installs.  I believe that this was much 
like the sites stuff but we were actually using different scripts.

Since sl5 we only need to point the installer at additional (local) repos 
containing the extra stuff we want adding which is much simpler (for us).

I know that this isn't enough for those who need to distribute media etc 
but it is very simple - and the same repos can be used in both anaconda 
and with yum...

> *Yum - autoupdate
> How do we want to do that?
> - Continue with my script ?
> - Use yum-cron ?
> - have several things available ?

I use a local script which calls yum and a yum plugin which implements 
some restrictions - so we can mark that an update needs a reboot and/or 
that it shouldn't be installed until some particular date.  Our 
plugin-code probably isn't flexible enough for everyone but it was 
sufficient for us to be able to drop a much harder to read script we had 
before...

> *Kernel-modules
> They are a necessary evil.  How should we handle them on SL6
>
> *Security - Bugs - Enhancement Updates
> Do we want everything separate still?
> Do we want everything in one big yum repository with them labeled
> correctly as Security, Bugs, and Enhancements?
> 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'd like to be able to distinguish updates which will affect users, e.g. 
needing a reboot or restart of X (for example), but other than that I 
don't particularly care how the repos are structured.

> *Yum Repositories
> What should we have for default?
> Should we still have "contrib"?
> Should we add "development"?
> Should we have yum-conf-epel?  Or should that be a default repository?
>
> *JAVA
> I propose we don't add Sun's (Oracle's) java.
>
> *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.
> A good reason would be that it is needed during the install.
> I like this idea and would like to adopt it.
> This would mean that we would take out several packages that have
> traditionally been in earlier SL releases, but I think it will make
> things better and more consistent in the long run.
> This way scientists would be able to know they are getting the same
> packages whether they are running SL, RHEL or CentOS.
> Thoughts on this proposal?

Maybe I'm mis-remembering or mixing it up with a different repo but I have 
a memory of trying to install an epel package with:

   yum --enablerepo=... install ...

and it wanting to update a huge number of core sl packages; presumably 
because the package I'd asked to install had been built on a system where 
those packages had been updated.

I currently have a preference for dag/rpmforge packages (where I have a 
choice) simply because I've had fewer surprises over the years.

In fact we do have some packages "from epel" but those have mostly been 
rebuilt from the srpms to ensure that we don't get dependency issues 
(maybe I'm wasting my time with that)...  Mind you sometimes I rebuild 
(with minor tweaks) the dag/rpmforge (or even core sl ones) too...

Currently we take packages that are locally built or added from 3rd party 
repos and stick them in one or more local repos so we don't need to enable 
those repos (and risk pulling in updates we didn't expect), but it does 
mean that we have to have a different way to check for updates for the 
packages we copy over (so it isn't ideal either)...

-- 
/--------------------------------------------------------------------\
| "Computers are different from telephones.  Computers do not ring." |
|       -- A. Tanenbaum, "Computer Networks", p. 32                  |
---------------------------------------------------------------------|
| Jon Peatfield, _Computer_ Officer, DAMTP,  University of Cambridge |
| Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/ |
\--------------------------------------------------------------------/