[Centos] Issues/thoughts re CentOS-4

[Michael Jennings]

On Tuesday, 14 December 2004, at 17:22:21 (+1100),
John Newbigin wrote:

> 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

IMHO, 4.0 should represent the final release, and each .? version
afterward should correspond to a RHEL numbered update set.

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

There are two basic philosophies behind rebuilds, and Mezz can do
either one.  You can rebuild all packages from SRPM and point
Mezzanine at the SRPM's (or SCM checkins thereof), or you can supply
source and binary packages for anything you'll not rebuild and only
rebuild what you need to.  For cAos, every single package is an SPM in
the CVS repository (first approach); for Vermillion, I used the second
approach instead.

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

For clarity, I recommend ".centos4.NUM" instead.  And there's really
no reason to have more than one NUM suffix; just increase it each
time.

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

The line should be drawn at anything which would break binary
compatibility.  In other words, anything that changes library sonames,
or moves perl/python modules around, etc.

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

Maintaining binary compatibility is more important than being
self-hosting.  During the beta cycle, any non-self-hosting packages
should be filed as bugs in RH bugzilla.  After that, it's too late; we
have to work around it.

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

I had a tool that looked at the RH update trees and fetched any new
updates automatically.  If mezzanine were driving the CentOS builds,
it would be fairly trivial to do this.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej at kainx.org>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "Can you stay for awhile?  Try to imagine this.  Could you be for
  awhile?  I can't remember it.  Could you fall for awhile?  'Cause
  I can't escape from this." -- Jars of Clay, "Portrait of an Apology"