On Sat, Jun 16, 2012 at 12:16:20PM -0400, alex lupu wrote: > > Bruce commented, based on > > >> Alex's words: > >> IRONICALLY, the one and only problem that could possibly be ascribed to > >> working "in place" is _exactly_ (and coincidentally) the one described > >> in the (original) subject of this thread. > > > I don't know where anyone said that you shouldn't update packages in > > place. Except for glibc, I've been doing it when required for years. > > In the reply to my OP on this thread, Ken wrote: > > "And at the risk of boring people, and attracting scorn from those > who *do* update glibc versions in-place, I repeat that the only > recommended way to update glibc versions on LFS is to make a new > build on a different partition." > Maybe other people take a different approach to LFS, but I tend to build new development versions a *lot*, just to keep an eye on what is happening. Last year I took my eye off the ball before 6.8 to do other things. By the time I came back, 7.0 was out and I've contributed a lot of time in getting various BLFS things fixed - not that I fixed them all, just that I spent a lot of time reviewing and testing. Now I'm back to building a new system every month or two, just to find what (if anything) has broken in the meantime.
So, taking the simple approach (building a new version of current LFS) holds no terrors for me, and all my systems have partitions I can use to do this. In the LFS packages, on my *old* (strictly, it was cross-lfs - LFS didn't handle x86_64 when I built it) server I think I had to upgrade gcc to try to build newer kernels - in that case, I just did the pass-1 binutils and gcc in /opt/kgcc. I've also had to upgrade udev in the distant past after some vulnerabilities came to light. Beyond that, and rebuilding perl for a vulnerability fix, I don't think I've upgraded LFS packages on existing systems for many years: in general, the improvements from newer non-toolchain packages are minimal, and I prefer older toolchains (they are usually faster). Of course, if I'd still been using hjl binutils on x86, I would have to upgrade his recent binutils to be able to build 3.4 kernels. So, your needs might be different from mine. BLFS is different - many upgrades to desktop packages on *all* the old systems I label as "I might want to still use this". Not so many of those systems now I've upgraded my hardware :) Mostly, upgrades are without problems (anything using gecko used to be an aggravation, because of the need to rebuild it when firefox was updated, but now I only have firefox itself in that category). OTOH, some things *have* caused me problems in upgrades - libxml2 comes to mind (in 2.6 days), most recently a problem in other apps using it, fixed by adding a patch from fedora to reinstate library versioning. Summary: whatever we do, things *will* break from time to time. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
