On Thu, Mar 01, 2012 at 11:30:00AM -0800, Qrux wrote: > > 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."
You could, with equal justification, have said the same about changes in many previous LFS releases. For example, toolchain changes break things - it used to be that a new gcc release (sometimes even a point release) tightened up the standards, particularly for C++, and caused packages in BLFS (or not) to fail to build. Most recently, the rpc header removal in glibc in 7.0 has caused significant pain. But then, we're on the bleeding edge. In general, I don't think LFS/BLFS is fitted to be a production server - we don't have a security team the way that distros do. If you want something that will continue to work, and will be supported, look at debian stable, ubuntu LTS, RH and its derivatives. Actually, we used to have a guy who did run production servers - but he spent a lot of time keeping them up to date, and he built on one machine and then rolled the binaries out to the others after testing. To test a new LFS build - keep your previous build, and your buildscripts, until you have proved it works for you. If it is irretrievably broken, this is the place to report that. If you can only test one build, concentrate on the 7.1-rc release in case something broke - better that we can resolve that before users run into it. Mostly, seds or patches for the affected package, or a later version, are all that is needed. If you *can* test the new build method, noting what breaks might be helpful. Personally, I have no 32-bit binaries to care about, nor any nvidia/ati kernel modules, so I dislike /lib64 (it's unnecessary for me, and perhaps causes the 'appears to be moved' messages that libtool spits out on anything using .la files). And I abhor multilib (been there on x86_64 and ppc64 - it was an interesting learning experience, particularly when trying to *not* install two sizes of everything, but I never had the time to keep my multilib desktops current [ I always built first on 32-bit or pure64 to get an idea of the dependencies I needed/wanted, but then for multilib I had to go through and work out the sizes - in the end, nothing "needed" to be 32-bit on x86_64, and very little on ppc64 benefitted from being 64-bit (except the kernel, of course). ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
