2008/2/27, Gerard Beekmans <[EMAIL PROTECTED]>: > Without a better ALFS integration, people are going to find themselves > unable to use LFS in production on more than one computer. I could not > see myself running vanilla LFS on the servers I maintain at work. One is > doable but not even full time when you have other duties. When you end > up with a dozen or more systems, you either get ALFS working, or you > give up and go back to a distribution. > > Package management has been brought up by various people. It's a simple > requirement if you plan to use the system for a while, besides just > learning. ALFS would be able to tackle that problem as well.
Thanks for bringing these two points close to each other. Indeed, automating the build and setting up the infrastructure for seamless upgrades & tryouts is important even on one machine. It is even more important if the actual distribution of packages to the other machine is going to take place. However, there is one more thing I would like to see: something that avoids newbies' attempts to build LFS directly on their i486-class laptops (when they also have fast Athlons) and thus only waste time. Something is needed that shows how to use a faster computer as a build factory for i486, so that one only has to transfer the result to a slower machine in a binary form. Or how to make a binary backup for the case when something is screwed up. BTW, a solution that shows how to build for i486 without the kernel uname hack is already in the LiveCD repository (but it can and should be transformed into the toolchain and perl ./configure arguments and thus separated from the other config.site hacks). > What if ALFS became the main way to do an LFS system? You might argue > the fact that it takes away from the LFS methodologies. There is great > benefit to be had from doing it all manually. But let's be honest - the > majority of the book is running configure, make, make install. Does that > really provide much educational value? It's not like you can actually > read the output fly by on modern machines. In years past you could > sometimes read along and get an idea of what it was doing. Not so much > anymore. And not really important unless you're a programmer too and > have an interest in knowing those details. No objections. Using some form of ALFS would certainly eliminate errors due to stupid typos, and won't remove the educational value at all, because the process of creating or adjusting the configuration files is the real learning experience. However, there is one requirement on the ALFS implementation: it should be easy to deviate from the book intentionally and experiment. Jhalfs may or may not be the best solution. Of course, the rationale notices for the existing ./configure arguments and patches should stay in the book, and rationale notices for not using certain "broken" arguments or not upgrading to a "broken" package version should, IMHO, be added. > LFS started out as more of an LFS+BLFS combined (read the 1.x series). > Then it was decided to split the core of LFS from the optional parts as > the optional parts are too user specific. Not everybody likes a chosen > email program, web browser, etc. Here is a little problem, because the split point before which there are no optional packages is not well-defined. E.g., one may want to compile gpm before ncurses in order to be able to click through the dialogs in pure ncurses-based applications (that know nothing about gpm) on Linux text console. On the other hand, for a server without mouse, or for a person who spends all the time in X window system, gpm is just a useless package. Also there was a discussion (without conclusion) whether to treat autofoo as optional packages. > I don't know that we want to merge LFS and BLFS in its entirety but > maybe ALFS can become the "official" glue between the two. If nothing > else, to take away the manual burden of trying to install all the needed > packages. This would require some work on the BLFS side. Namely, making sure that the default ./configure arguments don't result in a package with a severely cut-down functionality just because adding the rest of the arguments pulls down the dependencies marked as "optional" (i.e., a more clear distinction between "optional" and "recommended" dependencies). Then, making a statement about which sets of optional dependencies and ./configure flags were actually tested. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
