A Suggestion For A Simple Package Manager
frank.peters at comcast.net
Wed Mar 18 08:51:36 PDT 2009
On Wed, 18 Mar 2009 07:50:01 -0600
Mike McCarty <Mike.McCarty at 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
> 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
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
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.
More information about the lfs-support