AFAIK, all the updates since 6.3 have been things which will probably still work there. We're now fast approaching the stage where various (primarily, desktop) updates to the book won't work until everything else has caught up (e.g. gnome-2.24 needs an updated set of xrandr packages from xorg, e.g. 7.4, for gnome-desktop, gnome will also need updated atk-cairo-glib-gtk-pango, and loads of other things need to be updated.
There are some more "can be updated independently" things, but most or all of those are not particularly urgent. So, should we just jump in and update things, knowing that the book will be broken until a lot more has been updated ? Would a note in the ChangeLog saying something like "this is probably broken in places" help ? (Particularly since it is already broken for the current LFS book). Unlike in the early days of BLFS, we now have so much, sometimes in such detail (testsuites are my personal bugbear) that no one editor can hope to build it all. How should we be thinking about getting towards 7.4 from where we are now ? I raised a number of tickets this afternoon for version upgrades, there are a load more I need to raise after I've confirmed things are working. Firefox3 had *some* discussion, but there is still a lack of any obvious consensus. I think I'm with dj on this one, but I need to find time to see if I can make the included nss in 3.0.4/1.9.0.4 use the system libraries such as zlib. Got to finish beating Qt to death first! I'm also assuming we don't need to support versions of gcc and binutils older than what is in LFS-6.4 ? As an aside, any interest in a page explaining why static libraries are not necessarily a good idea, and gradual implementation of the instructions to suppress them (as an option), like I did in my "firefox-example" book ? For gnome-2.24, I'm building less of it than I used to (as noted earlier, I'm stuck on an old version of gdm at the moment because I'm not willing to build all the current dependencies such as hal and pam), so I can't update all of it. I *can* update the parts I use, but that will obviously break the rest of it in the book until someone else comes along. I also need guidance about new dependencies - for gnome, gvfs is obviously going to be in because it's an integral part of gnome, but what about libtasn1 ? The gimp-2.6 needs babl and gegl (and the docs are still stuck at 2.4). Kde4 wants various things for postscript and pdf support, such as gnu-ghostscript which can now replace AFPL ghostscript (and IMHO we can drop espgs). Undoubtedly there are others - where should we draw the line about what is in the book and what is just a link ? There is also the kde question. Again, I only use part of it, and I've dropped some of the dependencies I didn't find useful (for gwenview), but the bigger question is "do we go to kde4 now (and drop kde3), or do we have instructions for both ? My experience suggests that trying to run kde3 and kde4 programs from the same uid will probably be an exercise in misery (my shared .kderc in a common /home partition broke konqueror-3.5 after I had used kde4, until I deleted .kderc). Also, some of the necessities for kde4 haven't been released - I'll probably end up taking automoc4 from wherever I can find it (I think I extracted it originally from an srpm, but I guess it must be in debian), but is there a preferred hierarchy of where to take not-really-released sourcecode from ? e.g. for phonon-4.2.0 (tagged in svn, but not downloadable as a tarball, and still being developed) I've been taking it from debian with the renamed _4.2.0.orig.tar.gz but I did manage to find the -4.2.0.tar.bz2 in a subdirectory of rpmfind.net! For kde4, comments about what is needed for kmail and other things I don't build will be particularly welcome. According to http://techbase.kde.org/Getting_Started/Build/KDE4/LFS the following are needed, but I don't need any of htem for -base, -graphics, -multimedia : QCA-2.0.0, GMM, Akonadi, Eigen, Eigen2. I'd also appreciate any help in identifying *what* needs boost - I started building it because gnash is thought to need it, but I haven't noticed anything in a log which definitively says something is looking for boost. Unfortunately, most of the hits for boost at www.google.com/linux are about making things faster. Similarly, the page at techbase.kde.org mentions boost among "other useful libraries" - it's a real PITA to build - people with infinite amounts of cpu power and disk space may disagree - and it has "issues" with recent gcc (for my own builds, I'm following fedora and using a patched old version - they upgraded to 1.36, then reverted that the next day). Unless I can justifiably mark it as a dependency, I'm not going to raise a ticket for it. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
