Auto-DESTDIR
This is the main web site for Auto-DESTDIR, a set of
programs for POSIX/Unix/Linux systems
that helps automate program installation from source code.
The Auto-DESTDIR tools (run-redir and make-redir)
redirect file installations so that the installed
files are placed inside the the $DESTDIR directory,
even if the provided “makefile” doesn’t support the DESTDIR convention.
In most cases you can replace “make install” with
“make-redir DESTDIR=xyz install”, and
suddenly the DESTDIR environment variable will be implemented, allowing
you to store files in a different place than where they run from —
even if the original makefile doesn’t support DESTDIR.
It will even automatically create directories as necessary
(e.g., if $DESTDIR/usr/bin doesn’t exist, and a program tries to copy
a file into /usr/bin/somename, then Auto-DESTDIR
will automatically create the directory
$DESTDIR/usr/bin and then copy the file into $DESTDIR/usr/bin/somename).
Auto-DESTDIR is released under the
“MIT” license, so it is
Free-libre/open source software (FLOSS).
Many programs for Unix/Linux are provided as source code; they must be
configured, built, and installed, and that last step is normally performed
by typing “make install”.
The “make install” step normally writes directly
to privileged directories like “/usr/bin”
to perform the installation.
Unfortunately, because of security concerns and other issues,
this is often no longer permitted.
The DESTDIR convention resolves this, but only (til now) if
programs supported it.
Why is supporting DESTDIR important?
Here are two examples:
-
DESTDIR helps create native packages. The tools for creating native
packages in deb and rpm formats (the two most popular Linux distribution
package formats) require that “installed” files be specially-placed by
a “make install” during package creation. This is something
DESTDIR enables. For example, Debian’s documentation explains
that during the packaging process, you must “install the program
into a temporary subdirectory from which the maintainer tools will
build a working... package. Everything that is contained in this
directory will be installed on a user’s system when they install
your package...”.
Fedora’s Creating Package HowTo
has similar requirements for Fedora.
For example, when creating a package for an RPM-based system like Fedora,
the “installation” would actually copy files into an intermediate location
(called the “build root”, though “install root” would be more accurate).
The packaging software then copies files from
that intermediate location (e.g., the build root)
into an archive for later installation in the final
“right” place. It’s easy to specially place files to be installed if
the program already supports the “DESTDIR” variable, because DESTDIR
tells the installer the intermediate location to install software.
(For example, to create an RPM package, just set DESTDIR to %{buildroot}
and you’re done!)
But if the software source code does not support DESTDIR,
it can be difficult to create native packages.
-
DESTDIR helps install local packages from source.
Many people use programs
like GNU stow (or similar conventions) to help manage locally-installed
packages from source code.
Examples of such programs include
GNU stow (GPL),
Graft (GPL),
Encap/epkg (GPL),
toast (GPLv3+),
xstow (GPL, a C++ re-implementation
of GNU stow),
spill (GPL, in C),
and
STORE (GPL).
For example, GNU stow is designed to let you
store a program into some directory like /usr/local/stow/MYPROGRAM and
have binaries in /usr/local/stow/MYPROGRAM/bin/myprogram, yet have the
program be invoked as /usr/local/bin/myprogram. That way, plug-ins and
extensions will automatically work correctly. GNU stow’s documentation
specifically notes that you need to do this. GNU stow’s documentation
suggests using make prefix=Y install as a work-around, but as they note,
many programs (including emacs!) automatically force a recompilation
when the prefix is changed, making this moot. It can also cause subtle
problems when installing; it makes more sense to have a separate prefix
and DESTDIR value, so that each can be used where appropriate.
Auto-DESTDIR is implemented using a set of bash shell scripts that
wrap typical install commands (such as install, cp, ln, and mkdir).
These wrappers are placed in a special directory.
The run-redir command modifies the PATH so that the directory with these
scripts is listed first, and then runs the given command.
The make-redir command invokes “make” using run-redir, along with
some extra settings to simplify things.
For more information on this approach,
and why this is a good way to automate DESTDIR, see the paper
Automating DESTDIR, especially its
section on wrappers.
Yes, this is an odd way to solve the problem.
But other “technically correct” solutions turn out to have serious
problems that make them “not work” in practice.
This approach is small, easy to understand, highly portable, and reliable
(since it’s not sensitive to race conditions and small architectural changes);
in short, it works in “real life”.
Some advantages of this approach, compared to the “obvious”
approaches, are that:
- Unlike LD_PRELOAD-based approaches, it works with the commands that
install scripts use (commands like cp and mkdir are often statically linked).
It does not suffer from race conditions when the C library upgrades, and
it works well with programs that do depend on setting LD_PRELOAD
(e.g., auto-DESTDIR works just fine with fakeroot).
- Unlike ptrace()-based approaches, it does not require complex,
low-level, architecture-sensitive manipulation; that means it's portable
and it keeps working when low-level details are changed.
- Unlike chroot()-based approaches, it does not require special security
privileges, and it doesn't require any complicated/time-consuming
effort to create the chroot environment.
Since it has no security ramifications, and it's very fast to use, people
are more likely to be willing to use it.
My hope is that auto-DESTDIR will be a helpful step toward one-click
installation of most programs directly from source code on typical
Unix/Linux systems.
There are lots of useful programs out there for Unix and Linux, and programs
like
toast help make them easy
to install, but little awkwardnesses like failure to support DESTDIR
make it difficult to automate installation.
Hopefully this tool will make it easier to automate the whole process.
You may:
The older Version 1.0 is also available
though for most people will want the current version.
You can also view
my home page.