more on required packages

John Arrowwood John.Arrowwood at
Fri Sep 1 15:37:36 PDT 2000

Right now, the list of "universally required" packages (for compiling)

  bash, binutils, fileutils, gcc, glibc, grep, make, 
  makedev, sed, shellutils, textutils, util-linux

And those that are very frequently mentioned as being "required" (so far)

  diffutils, ed, flex, bison

For the most part, I intend to only symlink the individual utilities as they
are requested.  

But as I wrote that sentence, I thought of another idea:

When you symlink to an executable, and that executable looks at how it was
called, it gets the name of the symlink (as it should).  This can then be
used as a form of parameter.  For instance:  Instead of 

  $LFS/bin# ln -s ../usr/local/temp/bin/gcc gcc

which would cause the gcc command to be executed directly, do:

  $LFS/bin# ln -s log-executable gcc

Then, when you execute gcc, it actually calls log-executable, which writes a
log-entry containing the original executable name ($0) and perhaps any
parameters (probably not necessary).  The log would then contain a list of
every executable that was executed during the duration of the installation
of the single package.  How's THAT for thorough?  Then, if you just log a
"starting package BLAH" message, you can distinguish the start of each
package, and just make one really big log file.

I don't know for sure that this will work, although I've done something like
this in the past.  I'll try it over the weekend and let you know how it
turns out.

BTW: what that won't catch is cases like where you need to write to
/dev/null.  Maybe logging the parameters with the command name would help.
And capturing and analysing the output of configure, make, and make install
would also contribute toward finding all of these additional dependencies.

-----Original Message-----
From: Gerard Beekmans [mailto:gerard at]
Sent: Friday, September 01, 2000 3:15 PM
To: lfs-discuss at
Subject: Re: more on required packages

On Fri, 01 Sep 2000, you wrote:

> > I'm working on a dependency list, too.  So far, I have a list of
> that seem to be universally required, and a couple others that are very
> commonly required.  My list of dependencies only includes those packages
> NOT part of the universal list.
> For your review, in case there is a reason this isn't a good idea, here is
> how I intend to do the rest of my dependency checking:
> 1.  install all static packages to $LFS/usr/local/temp
> 2.  copy bash, gcc, and make to $LFS/bin, et al
> 3.  chroot to $LFS
> 4.  try and install a package.  For all commands that are part of the
> "universal" set which are referenced but not yet present, symlink them
> /bin, and record the dependency...thus I will have a list of what commands
> are actually needed from the "universally" needed packages (useful for
> knowing what to check for before beginning the process)
> 5.  when installing each package, install to /usr/local/<pkg>
> 6.  If a package fails because it requires another package, enter a
> subshell, then modify the path so that the /usr/local/<pkg>/bin directory
> is in the path, and try again.  I can then record the dependency, then
> the subshell which effectively removes the package from availability.

It will work but I'd like to know which program from package fileutils is 
needed for which other package. If you add /usr/local/fileutils/bin to $PATH

then you won't find out whether it needed ls or dir or ln or mv or all of 

Still install fileutils in /usr/local/fileutils but never add 
/usr/local/fileutils to $PATH. Just symlink /bin/filename to 

And when you have installed a package remove the /bin/ symlinks again that 
point to /usr/local/fileutils/bin/

It's tedious and takes a long time but at that's the way I plan on doing it,

unless somebody beats me to it of course. I'll then still do it as a 
verification. I know that there is a lot of work involved so mistakes are 
easily made.

> (darn it, is it depend-E-ncy or depend-A-ncy?  ARGH!)

it's dependency

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the lfs-dev mailing list