[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 
purpose

* 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 
versions?

* 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.

-- 
John Newbigin
Computer Systems Officer
Faculty of Information and Communication Technologies
Swinburne University of Technology
Melbourne, Australia
http://www.it.swin.edu.au/staff/jnewbigin




More information about the CentOS mailing list