Package dependencies

Gerard Beekmans gerard at
Wed Jun 18 11:29:11 PDT 2003

On June 17, 2003 07:44 pm, you wrote:
> Ah Ha!  This is why I posted first.  I knew I was missing something.
> Thanks Greg.  Do you have any suggestions to a solution?  (I am not
> asking you to implement or write anything, just provide help).  There
> has got to be a way to automate the dependancy check for packages in
> some way. I am not looking for full automation in the least, just a way
> to make it quicker.  If we can get that, then maybe we can look at
> something better down the road.

It will be very hard. There is human interaction required. Like others have 
said, configure can potentially check for many programs, but they are not 
required for the build process itself. Often because some packages use a 
generic configure script that checks for a host of programs it doesn't even 

Then again some programs configure checks for are only required during 
configure's phase itself, for example most all configure scripts need sed, 
cut, mv, ls, rm, whatever to do their job of checking for features and 
creating Makefile files.

I still think the best way to do this is doing  things manually. I've gone to 
a more direct approach: have empty /bin /sbin /usr/bin and /usr/sbin 
directories and an empty $PATH as well. Just run ./configure and you will get 
a fatal error of a program missing.

Add this program to the proper dir (ie /bin) and rerun configure. Then when 
configure runs properly, on to 'make' and 'make install'.

This will take many, many tries but the end result is that you only have files 
in the various bin and sbin directories that are actually needed. But there 
are gotcha's. Sometimes when configure doesn't find a program it'll happily 
continue, make and make install may continue as well, but those missing 
programs were needed for a normal functioning program or library, so when you 
see "configure:xxxx checking for" you need to interpret if that 
missing file is actually needed for a good working program. Some program 
features are disabled when certain programs are missing, but won't cause a 
fatal error during build time.

So you can see, this manual method has some pro's and con's. The pro's is that 
you get a true dependency list. The (very) big con is that you need to be 
very familiar with a program and know which missing files will cause in 
different program  behaviour.

Gerard Beekmans

/* Linux Consultant --- OSDN / DevChannel *
 * Technical Writer --- CheapBytes        */

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

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list