Matt Burgess wrote: > On Fri, 2013-03-29 at 15:06 -0500, Bruce Dubbs wrote: > >> I agree that we shouldn't go out of the way to disable unneeded portions >> of builds, but I do not think we should be fixing them if they are >> broken either. If they cause a problem, then disable them in Chapter 5. >> The only time they need fixing is in Chapter 6. > > But then we're causing ourselves more work, surely? We've got to figure > out 2 'solutions'; 1 to disable the problematic component in chapter 5, > and one to provide the real 'fix' in chapter 6. As we *have* to fix > things in chapter 6, we may as well just reuse the fix in chapter 5 as > well, no?
In this case, we already know both methods. From an educational point of view, saying that there is a problem, but we'll fix it later seems to me a better way to go. For future packages, the fix will probably be incorporated and both methods will be removed. I'd still prefer something along the line of "Hey, this package builds something we really don't need here, but breaks the build because it has not caught up with newer tools. We'll just skip that here and fix it properly in Chapter 6." -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
