Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Dark_Helmet, do I understand correctly that except for the commands cut and paste from the book, you typed that whole script by hand? Every last letter? I didn't see much that reminded me of the commands in the book. There was an especially large assortments of variables that must have been a load to type up. It would be extremely useful to know what parts were processed with regular expressions or grep or anything like that.
Everything in the script except for the commands from the book was typed by hand, yes. If you want to get technical, no: I wrote the Bash portion by hand (its variables and its entry in the case), pasted a copy of those pieces for each package and then did a repeated search-and-replace to adjust the variable names and their references.
You can find the commands from the book assigned to the series of PRE, CFG, MAKE, INSTALL, and POST variables for each package. If the book did not have a command for a particular step, I just assigned an "empty command" to that variable.
I don't know if I plan to make the script parse the LFS book. That's probably fairly tough to do unless the writers adhere stringently to strict authoring guidelines. I haven't looked at any version of the book's source yet to determine if that is the case. Since nALFS exists, it would seem likely they follow some guidelines, but that still doesn't guarantee strict adherence. Those lovable idiosynchracies tend to turn parsing a file into a patchwork of exceptions... not rules. I'll look into it eventually, but for now, I plan to work on the installation portion until I think it's solid.
If I were to sit down and poke at it right now, I'd probably look at the XML version of the book first. Then see if they actually separate the commands specifically by tagging them. something like:
<command [attribute ...]>command text</command>
If they did that all the way through the book, then it's simple to grep for the command tag.
Similarly, if they mark a package with an obvious tag like
<package [attribute ...]>package_name</package>
Again, that's simple IF they follow the same tagging scheme throughout the book.
The tricky part comes in when decisions have to be made. I've been reading/using the LFS books off-an-on since about 3.0, and I remember reading statements like this: "If you have an AMD Athlon processor and your distribution is using Glibc <some version> then you need to do this... Do not apply this fix if you do not have this configuration because it is likely to cause a segmentation fault in..." How is the script going to know it's an optional command? How can the script figure out what the conditions are? Even if it can, how would it decide what tests to run to see if it meets the criteria? That's the difficulty I'm worried about.
Yes, there appears to be the need to be interactive at some point for a comprehensive script. After a certain point I have to agree with those above who say that we are departing from the spirit of LFS which says anyone who follows the instructions can cobble their own installation of Linux together from just tarred/zipped packages. I really like that.
Since ncurses is part of the installation, maybe there is some way of applying this technology to this purpose. I am thinking about writing a piece like my Software for the Homebuilt Computer site at the link in my signature that would describe the process of making scripts to the complete beginner. I suspect that LFS is maybe a little intimidating for the absolute beginner. And yet that's what I always thought Linux was about when I first got involved with Linux. I was really suprised (relieved ) when I found automatic installations available.
Imagine LFS including such a process by which users were encouraged and taught to write their own scripts. This would closely parallel the fact that they are compiling their own software. Imagine also that they actually took a peek at some of the source code to better understand what they were doing with all the options being set. You yourself say you have some C experience.
When I first considered writing a script, I thought maybe there was some way of applying the "make" and "configure" operation to compile the whole thing as if it were a package of programs. I notice that many of the packages do not appear to be just one compile or make job at once. Some appear to be nested. I guess that there is a compile for each program that is installed in a package or something, I'm not sure.
Interesting how things will get you thinking... When you mentioned make, my mind did a 180 and I remembered you can use make to automate things other than compiles. A Makefile is far more cryptic that a shell script, but it should be reasonably easy to create a Makefile that would run a user-defined script for each package. The main benefit of this method would be that you break the installation routine into smaller, more manageable chunks that a beginner could work with. Writing a script to statically install bash is something completely different than a script to install LFS as a whole. Then again, I don't see much room for creativity writing basically the same script repeatedly for each package (aside from maybe displaying status messages, re-directing output, etc.).
I notice that many of the packages do not appear to be just one compile or make job at once. Some appear to be nested. I guess that there is a compile for each program that is installed in a package or something
I'm not sure I follow that first sentence correctly. Which packages don't? Well, almost all of them do "make" then "make install". If I understand make correctly, you could simply issue "make install" by itself and it would imply the original make (it can't install the binary until it's been compiled, which forces it to do the compile).
I'm not sure how familiar you are with make. If you know it pretty well, then you'd probably find this boring to say the least...
Yeah, every individual binary contained in a package gets a compile on its own. When you run configure, it generates all the necessary Makefiles for those programs. Usually there is a subdirectory for each binary to compile, and that subdirectory will have its own Makefile to direct how that binary will be compiled. Issuing make at the root of the source tree essentially starts a batch compilation of all those binaries in all the subdirectories with a single command.
... Usually there is a subdirectory for each binary to compile, and that subdirectory will have its own Makefile to direct how that binary will be compiled. Issuing make at the root of the source tree essentially starts a batch compilation of all those binaries in all the subdirectories with a single command.
Right. And the collection of packages could be considered to be in subdirectories of a directory for which there could be a make file that runs the rest? This is what I wonder about.