On 8/31/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > On 8/31/05, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > On 8/31/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > > > Basically I found that the DESTDIR approach was the best solution for > > > creating a package before it was installed on the final system. > > > > I was wondering about that when I was considering package management. > > Do all packages respect the DESTDIR variable? Are there any other > > issues with this technique? > > Most of the pacakges do, though they use various envar names (DESTDIR, > INSTALL_ROOT, etc.). For most of the non-compliant packages, a make > prefix=$TMP_ROOT/usr is sufficient. The rest of them need some special > handling. One of these days I am planning to put my document my > scripts so that folks can view them. > > Another issue: For some pacakges the installation needs an additional > phase, the post-installation phase. The post-installation phase is > where you would need to perform operations that affect shared files > (e.g. scrollkeeper, fontconfig, info catalog, ...), add users, etc. > But I actually like it since it gives you a clear idea on what shared > files are being updated and why. >
One additional advantage of the DESTDIR approach is that all files that needed to be installed are installed in the fake root. That needs a bit of clarification :) For some packages, when performing upgrades or just reinstalling the same pacakge versions, some files are not installed if the destination files exist. Examples: * glibc does not install the header stubs.h if /usr/include/stubs.h already exists and is identical. * ncurses will not install some headers in /usr/include if they already exist. Needs a --enable-overwrite switch to force it. Package managers that rely on timestamp or LD_PRELOAD based approach will not log these cases. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
