Thank you for this very instructive reply, Ken. --- Em ter, 22/11/11, Ken Moffat <k...@linuxfromscratch.org> escreveu:
> De: Ken Moffat <k...@linuxfromscratch.org> > Assunto: Re: [lfs-dev] Binutils 2.22 > Para: "LFS Developers Mailinglist" <lfs-dev@linuxfromscratch.org> > Data: Terça-feira, 22 de Novembro de 2011, 21:52 > 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? ... > 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). Thanks. However, encouraged by the Chapter 12. Programming of BLFS, sometime ago I did upgrade gcc: LFS 6.8 6.7 6.5 gcc 4.5.2 4.5.1 4.4.1 My gcc 4.5.2 4.5.2 4.5.2 I tested gcc 4.6.2 (or 4.6.1, cannot remember) in LFS 6.8, got a problem and reverted to 4.52. > > 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 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. 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. It may not make sense, but I was so proud when I got the LFS's running, that I got attatched to them, and would like them to survive as long as I can upgrade packages so that presumably vulnerabilities are solved. :-) ... > > > 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. Ok. ... > > 6. GRUB-1.98 Actually, in LFS 6.5, I have upgraded grub. Another thing, All systems have been upgraded ferom ext3 to rxt4 file system, with further improvement of speed (I do such upgrades either using rsync or clonezilla). > > > > 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, Sorry, you are right: Grep-2.10 is the correct version. > 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. Almost the same with me. First time I upgraded udev (LFS-6.5) I had breath difficulty, while observing the system boot. > > 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. You are right. Some of the upgrade attempts were first tested with a backup of the system and only after some days, if passed the test, I deleted the backup. > > Also, the one package that you should update frequently > (in my > opinion) is the kernel (but not the kernel headers). > > ĸen Yes, it is always updated. At the moment the systems have two kernels installed (I keep the older versions of vmlinux, config and System.map in /boot/old: $ paco -dd linux 12-Nov-2011 00:30 linux-3.1.1 22-Nov-2011 00:16 linux-3.1.2 Thank you very much again. []s, Fernando de Oliveira Natal, RN, BRAZIL -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
