On 02/24/2011 10:47 AM, Johnny Hughes wrote: > On 02/24/2011 08:59 AM, Lamar Owen wrote: >> On Wednesday, February 23, 2011 11:11:57 am Les Mikesell wrote: >>> Aren't there some tools that are designed to find binary similarities >>> (think anti-virus or things that try to detect copied code sections)? >> >>> Can't whatever they are comparing here be used directly in some clever >>> test to predict what would be needed instead of a trial and error approach? >> >>> Even if no one can come up with a way to extrapolate the dependencies >>> from the RHEL binary, the task seems like something that would scale >>> with more build machines and more people to stage the trial-and-error >>> builds. >> >> Please see if what you're talking about is found in http://mirror.centos.org/centos/build/ (and note the dates). >> >> Note that the built results of some of those SRPMs will be needed for later SRPM builds, and those may need to be done in a deterministic order. IOW, not something easily parallelized. >> >> And do note that some of the packages take a very long time to build; things like KDE, for instance. So if multiple iterations have to happen on a package that takes a long time to build..... >> >> Here's you some homework, Les: build a 'builddep solver' that will tell you in what order the packages need to be built, starting from the bare minimum buildroot. Of course, you don't necessarily know the bare minimum buildroot, and the upstream isn't telling you. >> >> And make it match the released upstream at the binary dependency level. It's not enough to just get the packages to build; the goal is binary and bug-for-bug compatibility. >> >> Now for an arch that upstream doesn't ship you could probably get away without that strict binary level compatibility (say SPARC, for instance, since there is an outside chance an EL6 for SPARC could actually be done, since F12 for SPARC exists in beta form). And, yeah, I'm going to spend some cycles this spring working on that for my own use here, and I'm not planning to hurry with it. Given entitlement syndrome I may not even release it; but may just release instructions on how I did it and let people do it themselves. >> >> But for x86 and x86_64 strict binary-level compatibility seems to be rather elusive. >> >> I haven't run any verification scripts on the SL RC; and even if I were to do that I'd post about it on the SL list, not here.... > > > I also want to throw out "thetango", which was used to bootstrap an ia64 > distro for Fedora. The code and the project seem dead now. This > suggests a build order based on a group of SRPMS. It is very hard to > setup and use, but I have used it when working on C5 sparc in the past: > > https://fedorahosted.org/thetango/browser > > (Read the README) > > And Les ... no, this is NOT easy to do. > I Found this ... so someone else seems to have the same idea to use it for CentOS: https://bitbucket.org/neeraj/python-thetango/overview -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20110224/95521592/attachment-0007.sig>