>> AFAIK, the distribution isn't "bootstrapped" (rebuilt entirely using itself >> as the build host), I kind of determined this empirically. It doesn't build from itself, therefore, Red Hat is not shipping binaries that is built from the actually shipping copy of all the srpms. This is bad news for any group that needs the ability to rebuild a distribution to prove they have the complete set of source and can re-create it if they ever needed to; or prove there are no 3rd party add-ons/hacks. (There are govt institutions that require this.) >> but instead assembled from packages built all along the development cycle, >> rebuilt only for updates, bug fixes or to pick up new dependencies. I would have hoped that a "release" is built from itself so that *everything* matches. There are programs that are statically linked to glibc/dietlibc/slang/newt that may have bugs fixed in a subsequent release. >> So for now, it's clearly a good idea to try and rebuild the >> test release "on itself" and report any breakage like you've found to the >> list, or better, to bugzilla. >From my own study of the packages, these PR's in bugzilla keep it from building against itself: 127526, 129946, 130717, 131780, 131783, 131841 I think there are more that I haven't filed yet. >In theory we do this automatically, but these "mass rebuild test" runs >seem to be broken at the moment. :-( I am only tracking 200 or so packages that you would use for a console based server distribution. I've submitted over 75 patches to fix just those 200. I would venture to say it would take a lot of work to get anything in the X world to build cleanly. This is mostly due to the shear number of packages involved. It really is important to be able to re-create a distribution from the shipped srpms. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
