On 07/03/2011 06:42 PM, Randy McMurchy wrote: > Hi all, > > It has been some time, though I have read every message to all the lists > for the last several months. I want to keep this short, but start a > conversation that could lead us to the direction (if there is any) we need > to go.
I've been using LFS on and off for a decade now, and my Aboriginal Linux project is about the fourth regeneration of my Linux From Scratch build. (Along the way I tried to replace as much of the bloated gnu crap as I could with busybox and uClibc, and wound up becoming busybox maintainer for a while because I was doing so much work upgrading busybox until I _could_. But it was LFS that set the whole thing off...) My project makes system images you can boot under qemu, which provide a minimal native development environment (uClibc+busybox based) for various target platforms (arm, mips, powerpc-32, x86, x86-64 should work fully. sparc-32, sh4,and mips64 boot to a shell prompt but have obvious flaws if you try to build more software packages under them. I haven't done a ppc64 or s390 because uClbic doesn't support them. QEMU doesn't support m68k or alpha so I've done both but can't really test them, although somebody ran my m68k system image under aranym so I checked that in.) I got a little info from cross linux from scratch, and a little by picking apart other build systems, but mostly I had to bug people who were already doing cross compiling to work out how, and then I make native build environments so nobody else HAS to... I have a fully automated LFS 6.7 build control image, which you plug into a system image and it takes over instead of giving you a shell prompt and runs an automated build of all the packages. (It basically treats the system image as chapter 5, and then does chapter 6. So it turns my minimal environment into an LFS environment.) I'm updating that to LFS 6.8 now, and I've had BLFS as a todo item for a while. > What do we do with the behemoth that is BLFS? > > Is it maintainable? > > There are just so many dependencies in the grand scheme of things now, that > it is almost impossible to update one package without it affecting (or > requiring) another package. It is dependency hell, now. Or so it seems. > > Suggestions are welcome. Volunteers are required. LFS is skating by with > only two people contributing. BLFS needs much more support than that. I've used BLFS to build basic X11 support, and I've used it to build a few servers. I cherry picked because building the whole thing is ridiculous. Possibly it's time to split the thing into smaller chunks? The layers I see are (roughly): 1) Infrastructure (chapters 3, 5-8, 10-12). 2) Networking (chapters 4, 13-22) 3) Multimedia (chapters 9, 23-25, 31-44) And then separate appendices on KDE and Gnome and XFCE and such. What I'm looking at is "what might people want to skip?" A headless box may not need any of the multimedia stuff. A DVD player may not need any of the networking stuff. (It's likely that #2 and #3 are going to need things out of #1, but they need stuff out of the base LFS too, prerequisites are inevitable you just try to keep them under control.) I do note that BLFS-stable is coming up on 3 years old: the stable version is semi-irrelevant, so it's probably time to ship SOMETHING newer than that. A snapshot of BLFS-dev may not be perfect, but it took me a week to notice that -dev was still being _developed_ with the release that old. > Discussion? Or is the thought of a maintainable BLFS unachievable? I think it's achievable, but you're doing all the work of a small distribution for an educational resource. It's a potentially infinite time sink, with no clear boundaries telling you where to STOP. (The above sections approach at least lets you say that doesn't go _here_.) Half the point of my Aboriginal Linux project is avoiding falling into the "accidental distribution" trap that turned buildroot from a uclibc/busybox test harness into a pile of hundreds of packages. Then the OpenEmbedded founders got fed up with buildroot and created bitbake so they'd do the same thing with a package management system (but not any of the existing ones like rpm, dpkg, portage...) One of my current hobby projects is figuring out how to bootstrap portage/catalyst and RPM/koji and debootstrap and such, starting from my minimal "busybox, uClibc, and a toolchain" environment and winding up with Ubuntu. (They all want to build under themselves, and their prerequisites are totally undocumented... but that's a different book.) Distros tend to have a dozen people managing their repository, updating package versions, build recipes, and dependencies. You're not tied to a specific build tool, instead your job is to document this stuff in human readable form. But you can leverage the stuff the portage guys are doing fairly easily, their build recipes are in bash... :) I do note that if I get my BLFS control image implemented, it's an easy way to regression test the builds when you update a package. Start from a clean system and build everything all over again with the one change... Building a control image from the .xml files might be more useful, but I haven't got a script that does that.) > For what it is worth I'm building a GNOME 3.x system now and have many > updates I could do, but is it worth it? Is building gnome worth it? I don't think so and neither does Mark Shuttleworth or Linus Torvalds, but apparently Novell still does. *shrug* No less important than reiserfs, anyway. Myself, I think gnome should be a separate book, so I can more easily ignore it. Rob -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
