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 -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:
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