[Centos] Issues/thoughts re CentOS-4

John Newbigin jn at it.swin.edu.au
Tue Dec 14 06:22:21 UTC 2004

This is a list of issues for discussion for CentOS-4.  Most of it is 
based on my experience from building/maintaining CentOS-2 and observing 
CentOS-3.  I have not seen the CentOS-4 beta yet so I don't know if any 
of this is already done.  If these have been discussed on IRC then 
perhaps someone could produce a shot summary of the outcomes....?

* Just call it CentOS-4 not 4.1 etc.  Too confusing and serves no real 

* All modified rpm should use mezzanine or equiv.  This makes it easier 
to track changes, build updates and generate a report on what has changed.

* Modified rpm should have .c4.n added to the release
- c4 = centos 4.  (works well once the 4.1 is dropped)
- .n = a number starting at 1.  The spec only 0 does not scale if you 
need to make another spec only change.  The changelog will tell you what 
has changed.

* Mission: To stay as close to RedHat as possible
Issues: some things need to be modified to support this.  For example 
the cpu/memory restrictions will be removed(like in CentOS-3).  Given 
that we are doing this, should we also lift other artificial constraints 
like installing on i386?

If we start making changes, where do we draw the line?  In CentOS-2 I 
have fixed some small 1 line bugs (mostly packaging issues) but this 
might be a contentious issue.  What about a CentOS+ repo. for enhanced 

* Issue: should the distro be self hosting?  I think as long as the 
requirements are available from the addon/extras repos. then I don't 
think this is needed out of the box.  Obviously the build environment 
needs to be well documented and reproducible.

* Mission: Remove RedHat trademarks.
Issues: should we replace all rh logos/icons or just the ones required 
by RedHat?  I think if the file/words can be replaced then yes, but 
package names etc. should be left alone.

* Issue: yum
Don't ever auto-modify yum.conf.  Too confusing.
Invent a system for selecting/allocating a mirror.  Users should always 
use a 3rd party mirror and not the main caosity mirrors.
Issue: every mirror has different paths.  We need to clean up all the 
symlinks and multi versions on the mirrors.  (We need someone in change 
of the mirrors)

* Issue: gpg key.
This should be installed by default so the user does not have to find & 
import it.  At a minimum it should be in /usr/share/doc/centos-release 
and work like a RedHat box.

* Issue: release QA
Before public release, a QA procedure should make sure that there are no 
obvious problems (like the comps issue of 3.3).

* Idea: automatic patch building.
It should be possible to build most patches without intervention.  I 
don't know what the current systems in place are but if there were 
autobuilt unsigned patches available it would allow
- testing of patches before they are 'officially' released
- checking the progress if a patch

Using an automatic system to apply CentOS specific modifications means 
that in some cases, the CentOS specific changes can also be autoapplied 
and the package build.

Obviously before a package is officially released, someone needs to 
check that it is correct and works etc.


John Newbigin
Computer Systems Officer
Faculty of Information and Communication Technologies
Swinburne University of Technology
Melbourne, Australia

More information about the CentOS mailing list