On Tue, Nov 22, 2011 at 7:37 PM, Fernando de Oliveira <[email protected]> wrote:
>> > 1. What is exactly a or the toolchain. >> >> Binutils, gcc, and glibc. Arguably, whichever other >> packages gcc >> currently needs (gmp, mpc, mpfr). > > Thanks. However, encouraged by the Chapter 12. Programming of BLFS, sometime > ago I did upgrade gcc: Yes, that can be done. It won't affect anything already built, but it may cause problems with new builds. On the other hand, there is rarely a pressing need to update gcc. >> > 2. How far can one upgrade LFS >> I upgrade the non-toolchain LFS packages on my systems to >> fix vulnerabilities, I see no reason to upgrade them for any >> other reason - the versions in a released LFS book ought to work >> well together, upgrading something later might break >> things. I really don't have any problems with doing in-place upgrades beyond the tool chain. Some packages are sensitive to autoconf or automake, but generally that can be worked around. For most packages, they are not even used. > I can be wrong, but it seems the machines are getting faster as long as > upgrades are performed. For me, it is easier to upgrade as new versions are > appearing than search (I do not know where) for vulnerabilities. >> Also, if >> I'm fixing a vulnerability in perl, I prefer to patch the >> original version - otherwise, I'll have to reinstall all the perl >> modules that I've built later, because of where they get >> installed. How long does that take? Generally, I update a perl module only when some other application says it needs it and it only takes a minute or two. > The three machines have perl-5.14.2, now. > >> Similarly, for desktop packages I usually only upgrade to >> fix vulnerabilities, but occasionally for new functionality. >> Realistically, a desktop LFS that is more than 18 months >> old is probably due to be replaced. Perhaps, but I still use a 6 year old LFS system with few problems. Issues of vulnerabilities depends on the users of the system. In my case, there is no way to even see my system from the outside of my network. Even the LFS servers are older than 18 months. The issue of vulnerabilities really depend on how valuable the data on your system is to you. It's not like we need to prevent people from reading the public mailing lists. I'm not saying to disregard security issues, but the vulnerabilities should be evaluated against the risk. Actually this is especially true for servers. If you have a server with one or two admins, no users, and only a DB or apache server that is configured in a secure manner, it's rare that any updates are really needed. >> > 3. Why the toolchain cannot be upgraded. >> I'm not saying it can't ... but you are on your own >> when you do it. If it breaks, you get to keep the >> pieces (and you lose your system - unless you can revert the change). >> The regular binary distros do these upgrades all the time, and I think >> gentoo does as well, but we have no experience in doing it. The hard one to upgrade is glibc because every program relies on it. Upgrading gcc does not affect already built programs. You can upgrade binutils, but I have never seen a need to do so. As a general rule, I'd say to upgrade a package only when you know of a need. At some point, you make decide that you want to upgrade everything, so then build a new system, otherwise just use it. One of the big advantages of LFS is that you control what is being done and are not subject to "Patch Tuesday". Also I agree with Ken's comment on udev, but that also falls into the realm of update when needed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
