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
John Newbigin wrote:> perhaps someone could produce a shot summary of the outcomes....?or even a short one. -- 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
>From: John Newbigin <jn at it.swin.edu.au> >To: CentOS Users <centos at caosity.org> >Subject: [Centos] Issues/thoughts re CentOS-4 >Date: Tue, 14 Dec 2004 17:22:21 +1100 > >* 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).Could you please share more information about this? What cpu/memory restrictions are in Centos 3 which are not present in RHEL3 ? This is what I am trying to discover which RHEL version like AS, ES or WS is Centos based on. I was under impression after reading Centros website documents that Centos is designed to be an almost 100% RHEL clone minus the copyrighted Redhat logos.>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?Yes please! Please keep Centos changes to RHEL SRPMS separate from RHEL clone packages.>* 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.Do you get best RHEL clone packages from building on RHEL AS computer itself? If so then I believe that is what should be used to build Centos RPMS. Opinions?>* 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.A nice mission would be to remain 100% RHEL compatible with just no Redhat copyright logos + references.>* 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.This will be convenient!>* 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).Ah also an good idea. Less bugs = more fun =)>* 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 patchWhat patches are added to RHEL SRPMS besides logo removals? This is the main reason why I am browsing Centos documents. I would like to use RHEL clone on which to install RHEL compatible certified software and hardware. If HP server is certified for RHEL AS then can I use with CEntos without headaches? Same with software also like from Veritas or Oracle. I am just giving examples ........ I dont use Oracle but just in case someone else does. Many thanks to all. Max. _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft? SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN? Premium right now and get the first two months FREE*.
> * 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) >Why not to point "default" yum.conf to 3rd partymirrors Something like below. I let mirror.centos.org there because of statistics ... :-), but this setup makes it 1/10th of all downloads .... If you add more mirrors it will be less ... (I forced failovermethod=roundrobin, but it is not necessary <http://slovnik.seznam.cz/sl.fcgi?src_trg=en_cz&len=30&word=necessary%20steps> it is default) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release installonlypkgs=kernel kernel-smp kernel-hugemem kernel-enterprise kernel-debug kernel-unsupported kernel-smp-unsupported kernel-hugemem-unsupported tolerant=1 exactarch=1 [base] name=CentOS-$releasever - Base baseurl=http://mirror.centos.org/centos-3/$releasever/os/$basearch/ http://ftp.upce.cz/caos/centos-3/$releasever/os/$basearch/ http://caos.oregonstate.edu/centos-3/$releasever/os/$basearch/ ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/os/$basearch/ http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever/os/$basearch/ ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/os/$basearch/ http://download.centos.ru/centos-3/$releasever/os/$basearch/ ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/os/$basearch/ http://public.planetmirror.com/pub/caosity/centos-3/$releasever/os/$basearch/ ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/os/$basearch/ gpgcheck=1 failovermethod=roundrobin #released updates [update] name=CentOS-$releasever - Updates baseurl=http://mirror.centos.org/centos-3/$releasever/updates/$basearch/ http://ftp.upce.cz/caos/centos-3/$releasever/updates/$basearch/ http://caos.oregonstate.edu/centos-3/$releasever/updates/$basearch/ ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/updates/$basearch/ http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever/updates/$basearch/ ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/updates/$basearch/ http://download.centos.ru/centos-3/$releasever/updates/$basearch/ ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/updates/$basearch/ http://public.planetmirror.com/pub/caosity/centos-3/$releasever/updates/$basearch/ ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/updates/$basearch/ gpgcheck=1 failovermethod=roundrobin #packages used/produced in the build but not released [addons] name=CentOS-$releasever - Addons baseurl=http://mirror.centos.org/centos-3/$releasever/addons/$basearch/ http://ftp.upce.cz/caos/centos-3/$releasever/addons/$basearch/ http://caos.oregonstate.edu/centos-3/$releasever/addons/$basearch/ ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/addons/$basearch/ http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever/addons/$basearch/ ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/addons/$basearch/ http://download.centos.ru/centos-3/$releasever/addons/$basearch/ ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/addons/$basearch/ http://public.planetmirror.com/pub/caosity/centos-3/$releasever/addons/$basearch/ ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/addons/$basearch/ gpgcheck=1 failovermethod=roundrobin #additional packages that may be useful [extras] name=CentOS-$releasever - Extras baseurl=http://mirror.centos.org/centos-3/$releasever/extras/$basearch/ http://ftp.upce.cz/caos/centos-3/$releasever/extras/$basearch/ http://caos.oregonstate.edu/centos-3/$releasever/extras/$basearch/ ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/extras/$basearch/ http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever/extras/$basearch/ ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/extras/$basearch/ http://download.centos.ru/centos-3/$releasever/extras/$basearch/ ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/extras/$basearch/ http://public.planetmirror.com/pub/caosity/centos-3/$releasever/extras/$basearch/ ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/extras/$basearch/ gpgcheck=1 failovermethod=roundrobin #packages in testing #[testing] #name=CentOS-$releasever - Testing #baseurl=http://mirror.centos.org/centos-3/$releasever/testing/$basearch/ # http://ftp.upce.cz/caos/centos-3/$releasever/testing/$basearch/ # http://caos.oregonstate.edu/centos-3/$releasever/testing/$basearch/ # ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/testing/$basearch/ # http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever/testing/$basearch/ # ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/testing/$basearch/ # http://download.centos.ru/centos-3/$releasever/testing/$basearch/ # ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/testing/$basearch/ # http://public.planetmirror.com/pub/caosity/centos-3/$releasever/testing/$basearch/ # ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/testing/$basearch/ #gpgcheck=1 #failovermethod=roundrobin ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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 > purposeIMHO, 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"