On Mon, Sep 12, 2016 at 04:03:57PM -0500, Bruce Dubbs wrote: > Wayne Sallee wrote: > > What advice can you give for updating LFS without crashing the system, as > > various programs need to be updated. > > > > Obviously some programs would be more risky than others. > > The only program that I don't update 'in place' is glibc. I know some > people do that, but my position is that glibc is the heart of the system and > if that needs to be updated, then I rebuild everything. > > Side note: I've never really felt the *need* to update glibc on a working > system. > > -- Bruce
I have tended to keep examples of old (desktop) LFS releases, with the corresponding BLFS, and I normally only update a built system for any known usability fixes (uncommon) or vulnerabilities - but for firefox I tend to update that, and several deps, when a new major version comes out (even if the Release Notes suggest there are no vulnerability fixes). Oh, and I tend to scrap the old systems when too much needs to be updated (e.g. openssl major version becomes unmaintained) : my gcc-4.9.2 systems have moved to seamonkey because they can no-longer build current firefox. Hmm, one of the openssl vulnerability fixes required several packages to be recompiled, and I probably missed some others. For LFS, there have been fixes all over the place from time to time (I nearly updated perl to a newer version once, but after looking at what I would have to recompile - everything which installed a perl module) I patched the current version instead. For gcc, because there are _so_many_ static libs, I would be wary if upgrading for a vulnerability. For glibc, when the vulnerability which caused us to throw away LFS-7.9-rc1 came out, I did upgrade the current version of glibc (I patched a few lines). I also did something similar to one version in the past, because some sort of usability problem (in audio, I think) was fixed. But for my older systems at the time of that glibc vulnerability : a couple were patched, but I was unable to backport the fixes to the version of glibc used in a couple of older systems - so I scrapped those. I know that some people embrace the "rolling release" concept more than I do, maybe they have a different approach ? Short answer: it really depends on what you want to update. For BLFS, on a desktop you may need to be outside of Xorg (e.g. to upgrade qt, or to update a DE). For other things (e.g. new minor version of gtk / gnome) it probably isn't worth the effort. If using systemd, I assume that updating systemd or dbus might be painful - no idea. The simple answer: build a new system! For desktops, I used to build at least two or three svn versions between LFS releases, but for a user the release should only need BLFS vulnerability for the first few months. These days, I lack time and there is so much more in the books. One of my desktops won't be moving from 7.9 for a few weeks, I've got too much investment in installed fonts, I'm even reluctant to try -rc kernels there (that is one of the main things I've done for years) until I get to a convenient place to reboot :-p For servers, running for two or three years with only kernel updates (long-term stable versions, so 4.4 at the moment) and vulnerability fixes (openssl, openssh, mariadb or postgresql if you use those) should still be ok. ĸen -- `I shall take my mountains', said Lu-Tze. `The climate will be good for them.' -- Small Gods -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
