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"