[CentOS-devel] Considering repo re-structuring

[Karanbir Singh]

Hi Guys,

Some micro-conversations have taken place around this issue on various 
venues and its worth bringing all that together into one place.

With EL6, the rpmlist has grown quite a bit, also there are components 
that Red Hat ship out in their 'optional' repo. Which are not available 
on the main isos. Or so I've been told - if you can verify that, please do.

The other thing to keep in mind is that we have always merged in all 
packages from various variants that upstream ship - making all packages 
available to everyone was always the aim.

So traditionally, CentOS has maintained the distro repositories in 2 url's:

[os]
[updates]

with [os] reflecting whats on the isos/; as close to exactly as possible.

With CentOS-6, we might need to reconsider that - there is way too much 
content to fit onto a single DVD. And having the main distro on multiple 
DVD's might be an option, but is that the best option ?

to expand on that option, we could merge in all packages, built a DVD 
iso set ( 2 or 3 disks, whatever is needed ), stick with the [os] and 
[updates] repo's on mirror.c.o - and then potentially consider doing 
some 'slimmer' options. eg: CentOS-6-Minimal, or CentOS-6-SMB-Server etc.

The other option is to split the repos into
[os]
[updates]
[optional] {1}
[optional-updates] {2}

{1} or use a better / different name
{2}  do we even need the second -updates, we could go with what the 
present policy w.r.t centosplus/extras is - and drop updates into the 
same repo

Then stick with what we have done in the past, use the isos to reflect 
whats in [os], create the ability for people to use the [optional] repo 
at install time and go with that. The iso content would be dictated by 
the merged iso contents from upstream, so we retain the CentOS <= 5 
process in that regard.

Continuing on the same idea, one thing that came up was reporpose the 
Extras/ repo and use that to host these 'additional/optional' packages. 
Given that it changes a massive user expectation - unless there is very 
good reasoning to do this, lets try and avoid this.

- KB