Rob Landley wrote: > 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:
>> 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. The support list is reasonably active. If there are problems, they generally get addressed. After LFS, a user should be able to do some trouble shooting. > 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. Generally it is OK. I use it quite regularly. I do usually check for more recent packages and build those, but the instructions and prereqs stay fairly constant. >> 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...? How about a kiosk system? >>> 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. The purpose of LFS is not to build the most minimal system possible. It is to show a reasonable cross section of basic applications that are available on most Linux systems. The major exceptions are X and window managers. You can always argue that omitting some packages or adding others are appropriate. Users are quite free to do that if they want. The group of packages in LFS is simply the choice that Gerard originally made when the book was created and modified slightly over the years by different editors as package requirements evolved. > 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.) Can you point to any other major distro that doesn't have these packages, at least as a loadable option? They may not be needed by every user, but they are generally expected. As far as gettext goes, most packages expect it to be available and we have many international users and several international editors. > 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. Not to me. Just the table of contents is useful. Outdated instructions are better than no instructions. >>> Great. Why not cut a release? >> Because it would be broken. > > More broken than what's there now? A release implies that all the instructions have been checked against the current LFS. That's not really possible at the current interest level. > It's grown much _bigger_ than LFS, but has far fewer _users_. An assertion without data. BLFS is about 6 times larger than LFS. The difference is that users are expected to build all of LFS. For BLFS, users are expected to choose. If they do nothing other than read the section on The Bash Shell Startup Files, users get useful information. >> 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. GLib and pcre were added as prerequsites to pkg-config upstream. Have you looked at the rationale or dependencies sections of LFS? > Vim is in LFS, you have vim in chapter 6. gcc is in LFS, you have two > different versions in chapter 12. But Gvim is not. LFS does not build all the compilers in gcc. They are in BLFS as a convenience to the users. Thanks for your feedback. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
