On 03/10/2011 05:50 PM, Johnny Hughes wrote: [de-branding] > There is nothing magic ... if you have the .centos SRPM and the upstream > SRPM, then you have everything I use. Of course there is no magic, but there is a lot of work already invested. Ready patches for example. Anyone who has those patches could already be testing them on the next release, instead of starting off from scratch by making them. [dependencies] > It has been made public: > http://lists.centos.org/pipermail/centos/2011-February/106570.html Thank you, that's yet another posting I had missed. > But, you need to understand that the list is fluid. If a package does > not build because of a hidden build requirement, that is a bug. You > have to figure it out to get it to build, but the next time you build > that package you will likely NOT need to change the build root as they > will likely have fixed the issue by then. Over the years I have reported a number of these myself upstream and my experience is varied. Sometimes they fix things, sometimes not. Having a summary of all quirks that were needed to build a release makes building the next one so much easier. >> That last part, "easily accessible", is just as important as "public". >> There might be lots of tidbits of information on this list, but finding >> them is a drag. > Why is that important. Red Hat did not tell me how to build it. The > purpose of the CentOS Project is to produce an operating system that you > can choose to use or not to use. It is not to tell someone else how to > produce an operating system. Why should I tell someone how to build a > replacement OS to CentOS. That makes no sense at all. I'm not telling you to tell someone how to build a replacement of CentOS. I'm saying that you should tell everyone how to build CentOS itself. That would guarantee an influx of developers and CentOS' long-term survival, also past the point when you decide to swap your keyboard for a hammock in some tropical island. Z