Sorry for the delay, got buried in work. This has been sitting in my drafts folder all week.
On 07/21/2011 05:21 PM, Randy McMurchy wrote: > On 7/21/2011 2:13 PM, Rob Landley wrote: > >> So the message to people new the project is they have two choices: >> >> 1) Try the latest known-good release, which produces a system roughly on >> par with Ubuntu 8.04 "hardy heron" (desktop version end of lifed May >> 2011), or SuSE 11 (end of lifed June 2010). >> >> 2) Your first experience with BLFS can be attempting to build a nightly >> source control snapshot. You may get to be the first person EVER to try >> this particular combination. Which apparently has some fundamental >> reason for not having been turned into a stable release in forever. > > Yes, there are very good reasons. Additionally, using the most recent > release of LFS and BLFS Development is what is recommended. One would > hardly be the first person as you say. You're sure that a new user won't get unlucky? Because a new user won't be sure of that. >> While making this decision, ponder: was 2008 the last time the >> developers _bothered_ to cut a release, or the last time developers >> _managed_ to cut a release? Are they lazy, > > Far from it. > > >> or overwhelmed by their own >> project, or do they simply not care about giving outsiders a known good >> version? > > We do not look at a release as that important. The development book is > typically kept stable, and is the recommended version of BLFS to use. > See http://www.linuxfromscratch.org/blfs/download.html > > >> And you wonder why the flow of new users/developers into the project has >> tailed off? Releases are _important_. > > Perhaps to you they are. BLFS is struggling with time constraints on > all the editors. I could cut a release right now, but it would be > broken with current LFS. There apparently are more issues than you > are aware of. So you recommend new users try the development version, which is kept stable and is known broken with current LFS. You can't produce a release because releases and not important to new users, and due to time constraints on the editors. >> And exists right now in the one big book. Gnome is chapter 29 of the >> book, how many of the previous chapters do you need to install first? >> Even in the _relevant_ chapters, like 8, do you need libusb? How about >> libpthread-stubs? > > If I recall correctly, Xorg needs those packages, though I am not > certain about libusb. > > >> Chapter 10 has xterm, which requires the X libraries from chapter 23. >> Chapter 10 also has Xscreensaver which presumably also requires them, >> but doesn't say so... > > We have been really careful to document the dependencies correctly. > Do you have any evidence that the version of Xscreensaver in the -dev > book requires X libs? Now I'm curious: what do you think xscreensaver does, exactly? >> (why chapter 4 on >> security isn't in the networking section, I don't know...) > > Because there are several packages in Chapter 4 that have nothing > to do with networking. And the impetus for "securing" a system that isn't connected to any network is...? >> What's _left_ that you can't easily ignore should either be a base BLFS >> book or folded into LFS itself as an extra section at the end. > > Folded into LFS will never happen according to LFS doctrine as it > stands. LFS is meant to *teach* one how to build a base minimum > Linux system from scratch. Base minimum? busybox, uClibc, binutils, gcc, make, bash, and linux. A system built from those seven packages can rebuild itself under itself from source code, and I've built the full Linux From Scratch under such a system. There's tens of megabytes of wiggle room between that and what LFS currently produces, and some of it is utterly pointless. (Texinfo: the gopher-derived "info" format died around 1995, nobody but the FSF ever used it. Gettext isn't needed if you're not doing internationalization, which usually happens at the X11 level anyway. Libtool is a "portability" package to make non-ELF systems behave like ELF systems, which means on an ELF system like any Linux produced since ~1996 it's a NOP, and its consistent failure to do nothing _correctly_ is a trademark of the FSF.) But sure, LFS base is stable and widely used, I can see not wanting to add an appendix to it. > It is not meant to be a distro, but > instead a learning platform in which you can add to it by using > the BLFS book. It's a learning platform that has hint fils that show you how to install dpkg and add the whole of kde on top of it that way. BLFS seems to have made itself irrelevant to most of the LFS guys, especially since they're up to 6.8 and you're at 6.3. > Bruce wrote: >>> To suggest multiple books, we need to look at a proposal with what >>> packages go in each book. >> >> That was my first post to this thread. > > And a very good idea. I wish I had more time to devote to BLFS. > I used to commit 20-50 hours/week on BLFS. Life doesn't allow > that for me any longer. I do see it changing, however. I could put time into it but the feedback I've been getting is "Gnome is all that matters, and making changes to anything else might break gnome." I don't use Gnome, and am not going to start. > Bruce wrote: >>> That would be quite challenging and I'm sure >>> generate a lot of discussion. >> >> Not so far. > > Perhaps your idea needed to be repeated. Not everyone reads > *every single post* or thread, sometimes it doesn't hurt to bring > up a subject again to see if there might be interest. Or, perhaps, a reference given to where it exists in the archives? >> Great. Why not cut a release? > > Because it would be broken. More broken than what's there now? > And we are not in the habit of > releasing a broken book. You're not in the habit of releasing anything. You've fallen out of that habit some time ago. > I do see merit in your idea of splitting > things up. That way we could get timely releases out. BLFS has > grown leaps and bounds since its inception. It has grown much, > much more than LFS. It's grown much _bigger_ than LFS, but has far fewer _users_. > LFS is almost stagnant, other than packages > are updated. "Stagnant" meaning they've released 6.4, 6.5, 6.6, 6.7, and 6.8. It's feature complete. Does what it says on the tin. This is not a bad thing. > Yes, occasionally new packages are added to LFS, but > only for special situations (GLib, for example). Yeah, no idea why they did that. A better example might be gcc metasticizing. > Which brings me to why I keep using the term "a BLFS release would > be broken". LFS' version of GLib is not compatible with the version > of GTK+ in BLFS. Vim is in LFS, you have vim in chapter 6. gcc is in LFS, you have two different versions in chapter 12. This is a problem? > If we updated GTK+ in BLFS, there would be lots > and lots of testing to do. Gnome would certainly be broken. The only way I could care less about Gnome would involve heavy sedation, or perhaps falling into some kind of coma. > I realize you don't care about Gnome; however, others do. And we > don't want to release a broken book. Hence kicking gnome out to be its own book so it stops eating all the development cycles of the rest of the project. > Why do you think I started this thread to begin with. It was to > foster new ideas and thoughts on how to go forward. I like your > idea of multiple books. I just haven't commented due to time > constraints. > > Hopefully my remarks are taken by you to be constructive and with > heartfelt meaning, and not just trying to pacify you. It is not > like there are many developers. Go ahead and look over at CBLFS, > there are lots of combinations of packages that will not work > together peacefully. Cross Linux From Scratch was vaguely interesting to me, but never got far enough to be particularly useful. I had to get cross compiling information on my own, and my hobby project now supports a lot more targets than CLFS does. CBLFS isn't listed in the nav bar at the top, nor on the main linuxfromscratch.org page, therefore it doesn't exist. And in any case, I'm not just building BLFS for x86, I'm building it for arm and mips and powerpc and such. Native compiles under emulation are much better way to go than trying to cross compile more than absolutely necessary. QEMU is here and it works, and you can hook distcc up to it to call out to the cross compiler for you without your build having to even be aware of it. (Configure runs natively, make runs natively, headers are #included natively, linking happens natively. The heavy lifting of compilation gets moved outside the emulator but only to turn preprocessed .c files into .o files, which is the one thing cross compiling can't particularly screw up.) > I'm not sure a wiki is the way to go, there > needs to be some checks and balances to ensure that the instructions > are correct and compatible with everything else in the book. I'm pretty sure a wiki is not the way to go. A wiki is a way to collect a slush pile, but it sucks at having any sort of order and makes an editor's job _harder_. Editors fight off sturgeon's law. As Alan Cox says, "a maintainer's job is to say no". They bounce stuff back with comments, occasionally polishing things themselves but mostly telling the original author to rewrite it until it's ready. That's fundamentally not how wikis work. A book is something you read from beginning to end. With a wiki, that's usually not even possible. > Which leads me to: What if we do split the book up into several > books? It would be easy enough, but then we would still have the > problems that some of the books would be broken. And some of them wouldn't be. You keep bringing up how gnome screws up BLFS. Kicking gnome out into its own book wouldn't fix gnome, but it would prevent the first 2/3 of BLFS from being kept perpetually unstable by it. > Thanks Rob, for your insightful and thoughtful comments. I have > read them all. Let's continue to discuss. I know I can commit some > time, DJ checks in now and then, Wayne updates occasionally, but > we really need many, many more editors. My plans are to test the build, including regression testing across various platforms (primarily x86, x86-64, mips, arm, and powerpc, but I've got bits of sh4, mips64, sparc32, and m68k working, and other platforms are on my todo list). I'm happy to do some simple xml tweaks, but my time to work on things tends to come in spurts, and I've got the todo list of doom already. > Regards, > Randy Rob -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
