Randy McMurchy wrote: > > It is a lose-lose situation. There is nothing to be gained.
Explain how it is a lose-lose. You don't *know* there will be breakage and I've already agreed that more testing needs to be done before any merge is considered. What is lost? I'll give you what is gained: 1) We'll know exactly what package depends on which others. 2) Because we want to establish purity, we'll know just how the build stacks up. 3) The book will be more technically accurate because it will list the dependencies of all packages built. Frankly, I don't see what there is to lose. And once more, nothing is going to be blindly merged without fully testing. I'll do the ICA. > 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. I agree that a QA process is in order and there is a great need to test purity. But there is also a need to rationalize the build order. You can't see that? Why spend the time to verify the purity of a system that we can't rationalize now? We should get at the root of the problem by starting with the build order and verifying purity from there. If it's shown to be faulty, we adjust and tweak until it is pure and we document as we go. At the end we'll have the answer to every question with LFS and we can defend our decsions by the data we glean. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
