Barius Drubeck barius.drubeck at gmail.com
Sun Feb 18 04:45:12 PST 2007

On Saturday 17 February 2007 08:48, jignesh gangani wrote:
> I have still not understood
> the difference between --prefix=DIR and DESTDIR=DIR.
>    The --prefix=DIR switch in configure script will configure the
> package to install in DIR tree. DIR/bin,
> DIR/etc etc. If there is no configure script then I will modify the
> Makefile manually and write the correct prefix dir in it. Then why
> DESTDIR is used? If I give --prefix one DIR and DESTDIR= another
> dir then what will happen? 

Hi Jignesh, yes that's quite a fundamental question to this 
discussion.  The short answer is that it will install to 
$DESTDIR/$prefix but the program is compiled to work in $prefix.

Prefix works like you describe it.  What is important to remember is 
that the dir you choose for prefix is often coded into the binaries 
of the resulting package.

E.g. the compiled program knows to look for it's config file in 
DIR/etc and some other data file in DIR/share/mypkg.  If you 
move/copy that binary from DIR/bin to OTHER/DIR/bin, then it will 
still look for its config file in DIR/etc, not in OTHER/DIR/etc.

But often, we do not want to install the program immediately into 
DIR/*.  It is often useful to install all the files from the package 
into some other isolated location where we can easily look at only 
the files from that package, not mixed up with all the other files 
from other packages in bin, etc.

Having all the files in an isolated directory hierarchy makes it 
trivial to accurately identify all the contents of the package, 
avoiding the need for techniques like Nicolas' filelist script (and 
the potential flaws I mentioned in my previous post).  It is also 
useful to do some post-configuration and then save your binary 
package in a tarball.

So how to do that?  If you compile with prefix=OTHER/DIR, then the 
program will look for its config file in OTHER/DIR/etc, even if we 
install the package into DIR later.  Clearly that's not what we want.  
This is where DESTDIR becomes useful.  DESTDIR is an additional 
prefix that is only used during the actual copying of files for the 
make install.  You proceed as follows:

First compile as normal, with prefix pointing to where the program 
will actually run from:

./configure  --prefix=DIR   &&
make  &&
make -k check

Now, we install the files to a different location:

mkdir OTHER  &&
make DESTDIR=OTHER install

The last instruction will copy the program files to OTHER/DIR/bin, 
OTHER/DIR/etc, ....  If you look in the Makefiles of the package, you 
will usually find something like:

install -c -m 755 prog $(DESTDIR)$(BINDIR)

You can then edit the config file OTHER/DIR/etc/mypkg.conf or any 
other post-config you need.  This is also a good moment to strip the 
binaries if you want:

strip --strip-all OTHER/DIR/bin/*
strip --strip-unneeded OTHER/DIR/lib/*

You can get your file list with something like:

find . \! -type d > /mypkg.lst

The mypkg.lst will contain:


And your binary package tarball:

tar -czf /mypkg.tar.gz .

Now you can install the binary package onto your live system with:

cd /
tar -xf /mypkg.tar.gz

And later, you can uninstall with:

xargs rm -fv < /mypkg.lst

What I describe above is the theory of how DESTDIR is intended to be 
used.  I have skipped over some practical details, like dealing 
safely with symlinks, maintaining the info/dir, cleaning up empty 
directories, conflict handling, deviations for specific 
packages, ....  But it is already a usable technique as described 

You might also be interested to read the fakeroot hint:

> Well, every path to knowledge begins at 
> a question.

I can't argue with that :-)
I hope my answer helps you one step further along that path.


More information about the blfs-support mailing list