On Wed, 18 Mar 2009 07:50:01 -0600 Mike McCarty <mike.mcca...@sbcglobal.net> wrote:
> > Ah, we disagree here. What I'm looking for is "my machine, > MY rules", not "I want to become an expert on all aspects > of Linux build and system maintenance". If I had a decent > source distro which actually gave me the control I want over > what features got built into the object, and which objects > got built and installed, then I'd use it. I haven't found > one. > > Becoming a Linux "fiddler" isn't a goal of mine. > You should understand, though, that to have "MY machine" with "MY rules", one must first have a thorough and comprehensive knowledge of Linux. To have "MY machine" with "MY rules" one must first be fully aware of all the possibilities and options and that essentially means being something of a Linux expert. Otherwise one will just use the work of someone else, i.e. the standard distributions. The LFS project, at least as I see it, is much more than just a "paint by numbers" method of building software. LFS attempts to involve the user in the intricacies of Linux and thereby make him totally aware of his system, or, in other words, it attempts to make him an expert. This is an honorable goal, but, IMO, it lacks a means to take the hard edge off of the manual building process. Now, as regards a package or build manager, we could argue endlessly about what is needed and how to accomplish it. Instead, I would like to toss out some concrete suggestions. The X Window developers have created a simple Bash script that can be used to compile the two hundred or so individual packages that make up the X system. The script just contains a list (actually there are several categorized lists) of packages and some variables and options that can be specified by the user. I do not see why something like this simple shell script could not be adapted as a general build manager for any set of packages. Customized configure strings and CFLAG variables for each package would be no problem to add. I stress the idea of being simple and straightforward. Other package managers rely on high-level languages, external databases, and a multitude of configuration files and hence their operation becomes rather impenetrable to the average user. A simple Bash script could be very transparent and easily modifiable. The only thing lacking, however, is a means of keeping track of where packages are finally installed on the system, or in other words, a build log -- and this is a critical omission. The problem, I strongly feel, is in the make program itself. For some reason, the developers of the standard GNU build sequence, that is "./configure, make, and make install," did not choose to create an install log for the user after the final step. The make program will simply write all files to disk without creating any nice and neat record of what it is doing. Considering the critical importance of knowing where all the files are located, I can't understand why an install log provision has ever been left out. The developers of the make program should include the creation of an install log as part of the make process. A lot of programs that provide some sort of package management, such as installwatch and CheckInstall, will intercept system write calls during the make process and then use that information to determine file locations and create an installation log. This kind of complex interception would be completely unnecessary if the make program would just create the build log itself. The make program has been around for a long, long time and, for reasons that defy my understanding, nobody complains. It is time, I think, to indicate to the make developers that there is a great need to produce an install log. If make were to create a usable build log then more that half the work for a simple and workable build manager would be already finished. So far I have said nothing about the issue of dependencies. Once again I will claim that dependencies are not a major problem and that a simple build manager can ignore them. As a Linux user learns about his system the basic dependencies will become more and more apparent. If not, most packages will describe their dependencies in the README file or other documentation. At worst, a missing dependency will cause a loader error message that will plainly reveal the problem which can then be corrected by building the missing package. This approach may seem inelegant but to maintain simplicity the burden of dependency management must be shifted to the user. The main goal, as I see it, is to automate the tedious manual build process so that the user can concentrate on the far more important task of mastering the details of a Linux system. The attractiveness of Linux is that it is vastly configurable and customizable, but that attractiveness is lost if the user has to manually grapple with each of the hundreds of packages that currently exist. Frank Peters -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
