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: BINDIR=$(prefix)/bin ... 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: cd OTHER find . \! -type d > /mypkg.lst The mypkg.lst will contain: ./DIR/bin/prog ./DIR/etc/mypkg.conf .... And your binary package tarball: cd OTHER 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 above. You might also be interested to read the fakeroot hint: http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt > 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. -- Barius -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
