On Mon, 28 Jul 2008, John Summerfield wrote:

<snip>
> Where are the equivalent documents for SL{3,4}? I'm not sure I understand the 
> question, and "site" is awfully vague.

I believe that the anaconda installer in sl5 is the first version which 
supports multiple installation repositories.  ie on earlier versions you 
need to build a single tree containing everything you want to *install* 
with.  Of course that doesn't stop you installing from different places 
*after* the install...

> _I_ don't like adding different versions of packages than the vendor provides 
> as it instantly increases the maintenance burden; RH does a fairly good job 
> of maintaining the packages it offers, and the cloners such as SL mostly do a 
> good job of tracking that maintenance and of maintaining their own additions.
>
> As soon as one uses a different version of a package, to a greater or lesser 
> extent that support is negated.
<snip>

We have 2 types of extra rpms in our local repos:

   additional packages that sl/tuv don't support

   updated versions of existing packages (or with our extra bugfixes)

we think long and hard about adding the latter type, and will usually only 
do it if there is a clear problem (for us) with the shipped version.  We 
will usually try to report any bugs upstream but if there is no sign of a 
fix we may have to bite that particular bullet and build extras ourselves.

Sometimes we will just pinch the relevant package from DAG/ATRPMS if there 
is a suitable one, but there isn't always.

e.g. in recent times for sl5 we have kept patched versions of kernels to 
fix various NFS client performance issues, updated to a rather newer cups 
and have a patched am-utils with different startup scripts, our own build 
of pine and that is about it.

Back in SL3/4 we needed far more locally hacked packages than we have for 
sl5.

  -- Jon