[CentOS-devel] Release processs for CentOS 5

Rodrigo Barbosa rodrigob at darkover.org
Wed Nov 22 17:49:49 UTC 2006

Hash: SHA1

Ok, this kind of crazy stunt reminds me (a lot) from my time at 
Conectiva. So I might be able to contribute something, even if only
some anedoctal facts.

On Wed, Nov 22, 2006 at 07:38:46AM -0600, Johnny Hughes wrote:
> > >> Somebody knows if exists some roadmap about release beta process for CentOS
> > >> 5 in parallell with RedHat ?? Or we need ot wait until RedHat 5 will be
> > >> released??
> > > 
> > > I'm also curious if there's plans to do a separate Desktop and Server
> > > release. From what I saw in RHEL5 beta1, there's apparently a slightly
> > > different set of packages in each....
> > 
> > There is going to be a bit of a discussion on this soon, also howto 
> > manage the various repos within each tree.
> There are differences in the upstream release for Client and Server
> (much like the difference between AS, ES, WS, Red Hat Desktop, etc).  We
> handled this in CentOS-3 and CentOS-4 by just releasing the AS package
> set and it contains all the other subsets.
> It is slightly different now, however, as there are separate yum
> repositories (and directories) for Server, Client, VM, Cluster*, etc. on
> the EL5 Beta2 CDs (much like CentOS has extras, centosplus, etc. :P).

Once uppon a time ...

Conectiva loved to have everything splited. And I mean everything
(glibc was like 50 packages, total). So we used to have some number
of repositories. This eventually started reflecting the CD number too.
Do CD1 was "main", CD2 was "extras". But "gnome" and "kde" were also on
separate repositories.

This turned out to be a nightmare to maintain. I mean, some softwares
would have a core package on the main (or extra) repositories, and 
one on the "kde" repository for the kde-ui, and one on the "gnome"
repository for the gnome-ui.

Granularity is all very nice, but it can (and will) turn into a maintenance

> In a yum tree on the server this is not too hard, links can be created
> to connect the packages that are the same and all can co-exist in one
> tree.
> (that might also work OK for the Binary DVD too ... we might be able to
> fit all the packages on the DVD in separate repos/dirs and keep it under
> 4.3gb)
> As far as I know, ln -s or hardlinks will not translate to size savings
> (or even work) on an iso9660 CD ... therefore it seems that we may have
> to either:
> 1.  Combine all the packages into a single repository (CentOS or Release
> or Server, etc.)  This is similar to what we currently do on 3 and 4
> now, with all the AS packages included.

Which is the best idea, as far as I'm concerned. We already have enough
granunarity using yum groups.

> 2. Release a CD set with Server and Client (and all the other repos on
> it ... showing everything) ... no idea how much space that takes yet or
> if it is doable.  I would think (if we can't use links) that this set
> would be 6-9 discs in size.

Unless you can make sure people can do an install (easily) with just
a subset of those CDs, this is going to give you headaches, IMHO.

> 3. Release a Client and Server CD, and a Client and Server DVD ... but
> put everything in one yum tree with a Client and Server and all the
> other dirs/repos under that tree. (I would imagine that each set would
> be 4-5 discs in size)

This could work. The main advantage, the way I see it, is to keep it
closer to the original upstram methodology.

> I think 3 is the way that makes the most sense ... it also requires the
> most disk space and bandwidth ... and requires the most maintenance.

Actually, 2 will eventually require more maintenance.

> Option 1 is less disk space, in keeping with what we currently do, BUT
> creates an install that is not much like upstream.

I don't think a problem there. The important thing is that it be
"functionaly" identical to upstream. We are already using "yum", after

It might cause problem for people migrating from upstream to CentOS, thou.

> Once installed, either of these methods becomes the same as all yum
> repos should be enabled by default, unless we have a centOS-release-
> client and centOS-release-server ... so that if you install client, you
> get only client repos by default and for server, only server repos by
> default .... and you could enable the others too manually on each if you
> want.

Maybe a yum plugin that reads /etc/sysconfig/install-mode, and so decide
if we are running a server or client install (or custom, with everything
enabled). Should be relatively easy to create, I suppose.

> The developers need to play with all these ideas and test several things
> before we can even smartly discuss these options.
> Once we have a better idea what this entails, we can discuss it further.

I also suggest the developers go and talk to people who worked on other
distributions (talking old and current employees here). It might also
give a nice perspective and the kind of maintenance traps you might find.

I'm pretty sure Acme and Cavassin(*) would be willing to help.

* - Both are former Conectiva owners and development directors, and were
deeply involved on all these packaging decisions in the past. Johnny, if you
want, contact me offlist and I'll give you their e-mail addresses. They
both work at Mandriva now.

Best Regards,

- -- 
Rodrigo Barbosa
"Quid quid Latine dictum sit, altum viditur"
"Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

Version: GnuPG v1.4.5 (GNU/Linux)


More information about the CentOS-devel mailing list