On 3/1/12 2:30 PM, Qrux wrote: > You seem to be saying: "Okay...We break the not-fixable stuff--BUT, > HEY--that's the only thing that prevents this from being the right thing to > do."
No, that's not what I am saying. I'm saying everything is fixable and the unknown issues this will bring up are few. Those that do come up would be covered by xLFS's current testing/review/release process. That's it, nothing more. > You're point seems to boil down to: "Don't overreact. 95% of stuff will > work." And, you seem to be implying: "Meh--downstream stuff...whatever. > Your problem." Do you not see the value to other people who think: > "Currently, 100% of the stuff I care about works. I don't want to jeopardize > core parts of my system just because someone wants a cleaner build--before > verifying my downstream works." > > I'm not saying you're way is wrong. > > I'm advocating that due time be given to allow downstream verification. That's totally fine. It sounds like you think I'm putting this into the book tomorrow, but that's not at all so. Perhaps you are missing a few key pieces of information: 1. As I already stated in this thread, I'm not trying to get this in before LFS makes its next release. And there is still time that will elapse before that release happens as part of the quality assurance process. 2. Any changes I make will go to either trunk or a branch and then trunk. That will give lots of time for testing and adapting before it's ready to go through a release process. BLFS is (unless something changed) aimed at being usable with the current stable and released version of LFS - so even more time for BLFS to be checked and verified. 3. I reverted the lib64 stuff as soon as Bryan made his first objection, because I realized he has a valid point. This discussion isn't about trying to get lib64 changes into the book in the very near future. It should be about how sysroot affects the bootstrap process, but unfortunately it's not. > Why not pursue a course more like: "Let's get some downstream (e.g., BLFS, > CLFS) people to see what the actual impact of my proposed changes will be to > actual consumers of LFS." That has always been what I was pursuing. If I wasn't advocating discussion and testing then I would have just pushed these changes to the repository. > You say you don't use LFS or BLFS. And, judging from your domain, you're > just using it as a cookbook to build your own OS. Well you didn't look very far then. Sure there are many things in my OS that originate with LFS, because this is where I came from, and there's much about how things are done here that I like. And I always endeavor to give kudos to LFS where appropriate. But there's a great deal that's different. For example, I didn't like the bloat of GNU, so I've recently switched to using a new libc, as well as some other tools. Eventually I'll publish more widely about what I've done with it. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
