user package hint & gnome-panel

Tushar Teredesai sukucorp at
Wed Aug 31 15:17:48 PDT 2005

On 8/31/05, Tushar Teredesai <sukucorp at> wrote:
> On 8/31/05, Dan Nicholson <dbn.lists at> wrote:
> > On 8/31/05, Tushar Teredesai <sukucorp at> 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:tushar at

More information about the blfs-support mailing list