hi... thanks for the reply... your comments are reasonable. but you have to understand.. this is for a project... to simply gain additional/further information.. i'm not looking to replace Centos/RH... i was simply looking for docs/instructions on how to build Centos from source in both the regular/debug mode... no more.. no less... in all honesty, it should be rather simple, as i should be able to essentually use the same cmnds that are used to build the source rpms.. the difficulty/lack of information is coming as i can't find anything that appears to relate to the 'debug-kernel' issue... thanks -----Original Message----- From: centos-bounces at centos.org [mailto:centos-bounces at centos.org]On Behalf Of R P Herrold Sent: Saturday, August 19, 2006 2:08 PM To: CentOS mailing list Subject: [CentOS] build Centos source/rpms from scratch... On Sat, 19 Aug 2006, Jim Perrin wrote: > It's been stated a couple times on the list that there's no > interest in helping people rebuild the entire distribution > from scratch. ... > beyond that, I'd say you're on your own. Too much > rebuilding dilutes the gene pool. Jim states it humorously, but a whole swarm of issues with emerge during a rebuild effort: - Will package building be done in an 'as found' build environment, or in a chroot - As non-root, or as root - Will the build of the packages be done in a minimal build chroot, a defined chroot, a fully populated build chroot - Will the build chroot be pristine every time, or are shortcuts tolerated - How will non-explicit BuildReq's to be handled - What arches are targets - What installation methods will be supported - Is it a goal to maintain ABI interop with the upstream PNAEVL, or is drift tolerated - What workarounds will be used to solve reaching a ABI identicality when the upstream has build with a tool (such as a GCC variant) not released - What post-testing processes will be used to measure confirmance - Is it going to solve the trademark issues, or ignore them - Will all package versions match the upstream identically, or will 'creep' of later versions and fixes be accepted - How will updates be handled We have not even touched on issues surrounding binary and source code distribution, support, documentation, mailing lists, bug trackers, community building, and the like. Thinking of material alternative efforts similar to CentOS', David Parsley worked and published his solution first, has as to RHAS21; John Morris later with his writeup as to RHEL 3; and many others as well within the context of the 'rebuilds' of RH Enterprise sources derived distributions. Each has made differing choices, and to greater and lesser extents, documented their efforts. David has retired Tao into CentOS recently, as it was so demanding; others as well have flagged in their 'freshness' over time. A strong aspect of CentOS is the ability to attract and retain committed volunteers, and really become the 'community' solution for the whole range of 'being an Enterprise-grade Distribution' -- it is far more than just compiling packages so that they can be wedged into an installable format. Here, as with the IRC channel's guidelines, well asked questions may draw a meaningful response from a CentOS 'insider'; general ones will (and I argue, _should_) not. Solve about the Cost/Benefit equation from the standpoint of a CentOS volunteer: Asking how to make CentOS weaker (as by a random call not showing the slightest bit of advance research and being a distractor from more pressing tasks) is a question thoughtlessly asked. Within the range of proper replies: devnull it and move on. Another couple approaches from the core group also have been offered. Thanks, CentOS core group. You know who you are. - Russ Herrold _______________________________________________ CentOS mailing list CentOS at centos.org http://lists.centos.org/mailman/listinfo/centos