more on required packages

Gerard Beekmans gerard at
Fri Sep 1 15:15:01 PDT 2000

On Fri, 01 Sep 2000, you wrote:

> > I'm working on a dependency list, too.  So far, I have a list of packages
> 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 into
> /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 exit
> 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 -*-

More information about the lfs-dev mailing list