Dan Nicholson wrote these words on 12/11/05 19:23 CST: > My opinion: Making the build alphabetical is silly. It's a purely > cosmetic change that doesn't do anything for getting a better final > result.
Exactly my sentiments. I'm glad that at least one person has agreed with me. Not that it makes me feel better, it just sort of reaffirms that fact that nothing is gained, and there could be breakage down the road. It is a lose-lose situation. There is nothing to be gained. > Jeremy, I think that a better goal would be to resurrect the purity > tests and see how current LFS stacks up. I'll be glad to help on > this. I have slow hardware, so doing a complete LFS is an all day > affair, and I can't completely devote my one box to this purpose. I would be willing to offer CPU cycles for this as well. I'm all for testing the purity of the build, and doing what is necessary to ensure that purity, build after build. > I think that if the current LFS passes, then we should look into > documenting the build order and changing it if it's possible. You're > right that we should get to the bottom of the build order and see if > it causes bugs. Me too. And I'm not a me-too poster. I do feel strongly though, that if the current build process is reliable, builds consistently with the same end-result and is completely reproduceable, then it should stay until a newer version is proven to do the same thing. So, that means we need to test the current version first, then try and migrate to a new build order. Which means we need to develop a reliable QC program *before* we need to change the build order. Right? -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 19:25:01 up 78 days, 4:49, 3 users, load average: 0.26, 0.80, 0.81 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
