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@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx]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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
