Re: Incremental upgrades
On Wed, 18 Jul 2007 01:14:52 +0100, Ken Moffat wrote: More to the point, I've long thought that we don't really cover the long-term care of your LFS system (e.g. I don't think we point out Care and maintenance of any complicated entity, a house, a garage, a method of building an OS, maintaining an OS, a car, a job, or writing near-bulletproof code is as much of an art as it is a procedure--and it varies from one person to the next. What we can do is try to gently encourage new users, who may not be familiar with Xen and the Art of LFS Maintenance, into habits which will lead them to be good admins (both for themselves and for others, if that applies). As always there is reading required: http://catb.org/~esr/writings/unix- koans/ OTOH, I think I can remember a large effort to prevent the book being dumbed-down, so maybe this is something that should be obvious to builders who intend to stay with LFS. That's also a very good point to recognize. It doesn't so much matter if we want people to stay, or if there are people who want to stay: what matters is if they do stay. If we involve ourselves deeply in every problem that they have then we will only frustrate ourselves and them. If we remain too aloof then the project will dwindle. There is a balance to be found by encouraging good practices and discouraging bad ones. Maintaining a system running a packaged distro on at least one machine will help the user to recognize things which need to be updated and give them insight how to go about it. When the set of packages that Debian Sid updates meshes nicely with the set of security alerts which I've seen in the last week then I know that I'm watching the right stuff. One last note on glibc updates: When Debian updates a glibc there aren't often many packages which need to be updated alongside of it. This must be due to a very careful watch by the devs on what changes are actually made in the glibc--and that may be related to social connections and manpower that LFS doesn't have (though I tend to believe that the LFS devs know how to stay on top of the bleeding edge of their respective areas of interest). The only consistent part of a glibc .deb update that I remember is that most (all?) active running services are restarted. That's about it. Yay for dynamic linking at runtime perhaps? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Incremental upgrades
I've been thinking about how to upgrade a system without going through a full LFS build. AFAICT, almost every package on a system can be upgraded without a reboot. BLFS packages are very straight forward as well as gcc, and most of the other LFS packages. Of course a kernel upgrade would need a reboot. About the only packages I can see might cause a problem are glibc and possibly binutils. Has anyone tried rebuilding and installing these packages in place on the current system? If so, what experiences have you had? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Incremental upgrades
On Tue, 17 Jul 2007 14:57:46 -0500, Bruce Dubbs wrote: Has anyone tried rebuilding and installing these packages in place on the current system? If so, what experiences have you had? From memory it's a major PITA to upgrade gcc or glibc on a running system--I don't think I was ever successful. I never tried binutils but, again from memory, the general rule was that anything in the toolchain was going to present its own special set of piles of problems. As you've noted just about everything else is easy to upgrade provided that the code author maintains backwards compatibility and the filesystem footprint of the installation is the same. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Incremental upgrades
From memory it's a major PITA to upgrade gcc or glibc on a running system--I don't think I was ever successful. I never tried binutils but, again from memory, the general rule was that anything in the toolchain was going to present its own special set of piles of problems. Like Steve said, an in place Glibc upgrade has a tendency to go wrong. It doesn't take much to mis-compile it just enough for existing installed programs to start segfaulting on you. Even if it's not because of the builder's doing. The crashing program in question could just be badly programmed (or wrongly compiled the first time around). A recompile or relink is sometimes your only solution. The who truly is to be blamed game can go on for a while. To check every program after a Glibc upgrade is tedious enough. I'd say hardly anybody would be excited to do that kind of grunt work. There's always the brute force way of recompiling all your packages after a Glibc upgrade, or at least your main software (things like X, email clients, window/desktop managers and so forth). If you automate that, it'll take away from the tediousness, but to a degree you're installing LFS from scratch again. Keeping that above bit in mind, most people probably skip a Glibc upgrade unless there's an actual reason to do so. If there is no performance or feature benefit to doing so, other than it being a thorn in your side (the old part of your otherwise spiffy new system), most would probably want to skip it and save the hassles that come with it. A minor Glibc version upgrade can typically be done a lot easier. Often there aren't any problems as far as I can remember. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Incremental upgrades
On Tue, Jul 17, 2007 at 05:48:15PM -0600, Gerard Beekmans wrote: A minor Glibc version upgrade can typically be done a lot easier. Often there aren't any problems as far as I can remember. No doubt if I keep casting aspersions on the likely appearance of 2.5.1 I'll aggravate one of the developers sufficiently and it will be released (meanwhile, I note that 2.6.1 is still not out, despite the malloc debug issue Greg pointed to in http://www.diy-linux.org/pipermail/diy-linux-dev/2007-May/001040.html ) so please forgive my scepticism that glibc will ever issue minor version upgrades again. More to the point, I've long thought that we don't really cover the long-term care of your LFS system (e.g. I don't think we point out that people need to monitor security lists). I periodically see mails from people who built LFS in a single partition using all of their disk - maybe we should admit that long term you should be rebuilding your LFS to get to a new version, and therefore you might want to consider your partitioning (e.g. perhaps put /home on a separate partition as well as leaving space for the next build) ? OTOH, I think I can remember a large effort to prevent the book being dumbed-down, so maybe this is something that should be obvious to builders who intend to stay with LFS. ĸ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
