On Tue, Nov 22, 2011 at 03:12:26PM -0800, Fernando de Oliveira wrote: > > Please, let me know if I understand correctly: with this, I do not need to > build chapter 5?
No, that is NOT what I meant. The who "build just enough in chapter 5, then use that to build the new LFS system" is part of "pure LFS" (merged for LFS-5.0, I think - before that we had all manner of weird results in some builds). What I meant was "when you want to upgrade the toolchain, build a new LFS. First, build the kernel version you intend to run in the new system. If your current version of gcc is too old to build that kernel, build current binutils and gcc in /opt/kgcc or somewhere else, and use them to build the new kernel. Boot to that kernel, then build the new LFS". > > I would like to understand: > > 1. What is exactly a or the toolchain. Binutils, gcc, and glibc. Arguably, whichever other packages gcc currently needs (gmp, mpc, mpfr). > 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. 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. 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. A server might last 3 years, perhaps more, but you will have a lot more work to fix vulnerabilities in old packages (unless you have a version that one of the distros is using for long-term support) - in many cases, a vulnerability fix means upgrading to a newer version and that often adds newer dependencies [ been there on my old server - got stuck on the 2.6.24.7 kernel because the changes in ide after that broke my old hardware which needed ide=reverse, and I couldn't move on until I eventually switched to grub2 ]. > 3. Why the toolchain cannot be upgraded. > I'm not saying it can't (in the days when glibc had a series of point releases, some people did upgrade those, e.g. to get the latest changes to daylight saving time), 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. > To do that, first I decided to make a copy of a virtual machine (I think it > was LFS 6.5) and tried to upgrade everything. Of course, did not work. > > After I started using Paco, it is easier to keep packages upgraded, so I > started upgrading BLFS and other non-*LFS packages but Gnome (of which I use > a small subset just to satisfy dependencies). > > At the risk of breaking the so-called toolchain, I decided to do the same > with some LFS which I see other distributions upgrading regularly, and now > only 9 packages remain unchanged. > > LFS (7.0) SVN-20111116 chapter 6 consists of 55 packages. With respect to > SVN-20111116, my LFS - 6.5 6.7 6.8 have: > > 1. 9 packages older (unchanged) > 2. 1 package upgraded and older > 3. 4 packages upgraded and more recent > 4. 41 packages upgraded > > Below, you can find a list of the unchanged and more recent packages. > > Package versions unchanged as in the original LFS - 6.5 6.7 6.8: > > 1. Linux API Headers > 2. Glibc 2.10.1 2.12.1 2.13 > 3. Binutils 2.19.1 2.20.1.20100303 2.21 > 4. Coreutils 7.4 8.5 8.10 > 5. Bash 4.0.28 4.1.7 4.2.0 > 6. GRUB-1.98 > 7. Man-DB 2.5.5 2.5.7 2.5.9 > 8. Psmisc 22.8 22.12 22.13 > 9. Sysvinit 2.86 2.88dsf 2.88dsf (probably) > > Package version upgraded but older version than LFS (7.0) SVN-20111116: > 1. GCC-4.5.2 > > Package versions upgraded more recent than LFS (7.0) SVN-20111116: > > 1. Ncurses-5.9.20110404 > 2. Grep-2.1.0 > 3. Udev-175 > 4. Vim-7.3.353 > Having the confidence to try out newer versions is great. I think your grep version is a typo, and for vim and (maybe) ncurses we've decided to stick to proper releases - unlike e.g. fedora or debian-unstable. Actually, you're braver than I am - upgrading udev scares me to death (had to do it in the past because of vulnerabilities) because so much changes in the build instructions with each new release. As long as your upgrades work for what you are doing, or you can revert them if they don't (e.g. a tarball of '/' - ignoring other filesystems such as /home, installed from another system on the same machine), it isn't a problem. But there is so much potential for things to go wrong and trash your system that I can't recommend it as a general way to procede. Also, the one package that you should update frequently (in my opinion) is the kernel (but not the kernel headers). ĸ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
