On Fri, 24 Dec 2010, Josh Boyer wrote: >> enough cpu cycle:-) then no package can be missing from the release. > > There is nothing that says all BuildRequires packages have > to be shipped in the release. It's only important to them > that they can build RHEL, not anyone else. True enough -- closed and complete 'self-hosting' has never been a goal upstream in their enterprise product; I understand the wish of those here (and even more strongly in EPEL which this piece was crossposted to as well ...) to have it, however include my stock IAAL disclaimer, and also not sent from a centos email address For those components of the upstream RHEL sources that are GPLv2 licensed (not all of them, by a growing margin) and to the people to whom binary content is distributed, this is possibly not the case GPLv2, section 3 a) Accompany it with the complete corresponding machine-readable source code [later un-numbered para portion] ... For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable Assuming, arguendo that there are 'tweaks' from Release Engineering, or such to make mock stand up and dance, on the offending 'make check' absence of PTY [Clark William's comment on one], or such [or a need to manually 'walk a build through' outside of mock -- I make no such representation, and my approach on distribution buildsystems is not CentOS' present one], ... ... the build system deviations from what is stock 'mock' would appear to constitute either part of the 'complete source code' to attain a binary, or alternatively part of 'the scripts used to control compilation' ... and be part of the releasables in proper and a somewhat narrow set of cases * shrug * and GPLv3 does not have such an argument chain available in it that I can see presently The bugs referenced in this thread here and on the EPEL mailing list, seem to refer to Artistic licensed code, however As to builders, I looked, and upstream released its v 6 product beta in late July, and the gold release drop in early November. This new major release, with the changes I've noted before on one of the mailing lists on the difficulty of doing a yum migration from 5 to 6 should be taken to confirm that it is indeed challenging to solve it all I've privately solved subsets of the upstream's 6 sources, not for CentOS but for other purposes, and it can be tricky ;) I guess it is time to write my annual buildsystems piece. If bugs in this regard are filed in the CentOS tracker, or in the upstream tracker on such problems, and you do no see me 'cc into them, please feel free to send a private email to me at herrold owlriver com and I'll look in on them -- Russ herrold