Is there any way to get APT to install packages to my home directory?

I don't want to make changes system wide.

Alternatively, are there any home-directory based linux package managers?


14 Answers 14


Dpkg do not have the --relocate feature that RPM has. It's worth considering how many RPM packages support that feature though. Basically, it can't be done.

What you could do is use a chroot if you want to test something before installing it globally on the system. To do this, you need to be able to get access to root. The first thing to do is to create a basic chroot:

# debootstrap lenny lenny-chroot

This creates a Lenny chroot inside the lenny-chroot directory.

Now we can enter the chroot:

# chroot lenny-chroot

Now we can do what ever we want and install anything without it messing up the rest of the system. When we're done, just type exit or press ctrl-D


Linuxbrew is another non-root package manager for Linux (based on the popular Homebrew package management system for OS X) that compiles from source and keeps binaries in your home directory.

Quoting the docs, Linuxbrew features are:

  • Can install software to a home directory and so does not require sudo
  • Install software not packaged by the native distribution
  • Install up-to-date versions of software when the native distribution is old
  • Use the same package manager to manage both your Mac and Linux machines

Gentoo prefix does exactly what you want.

It installs all packages into a specified directory. No root access required. If you want to get rid of it, just remove the base directory.

PS: This does not work on Ubuntu >= 11.04, or any other Debian derivative with Multiarch.

  • 1
    Gentoo builds from source, poster seems to want to install via package to a specific directory. That's not really the same thing. Nov 30, 2011 at 6:59
  • 1
    @AndrewCase Gentoo has packages too I believe. The fact that they aren't binary is irrelevant for the final installation.
    – jiggunjer
    Feb 6, 2017 at 12:47

Just as a minor addition to the option of compiling it, there's the half-way option of compiling into a package with a different prefix option at compile time (with "checkinstall" or perhaps some other method). The advantage is that the package will appear on package managers such as aptitude or synaptic.

Besides that I think it may be possible in some cases to download the actual .deb and force a different prefix via dpkg install, but I think that it's not something that can be done with any random package, but they got to have been compiled with some variable for their location (rather than the literal explicit prefix) that you'd export before installing. I don't know anything about the procedure though, google for "dpkg instdir prefix".


You can use fakechroot - have a look at the demo on their website.


Rootless GoboLinux can do exactly what you're asking for: package manager, with no elevated privileges, in your own home directory. Hopefully you know what you're doing; rootless isn't the most well-maintained installation mode of Gobo, and when I used to use it a few years ago it required a few tweaks as the installation script was a bit out of date relative to other Gobo changes.

There's also klik which repackages quite a few .debs, can install packages to your home directory, and requires no root privileges to operate... but the initial setup does require root.


There's very few cases where you'd need to install packages to your home folder.

However you can compile and install software to your local machine. Just unzip, then configure with ./configure --prefix=$HOME/local or some other directory. You can then make and make install as normal. This will compile and install that programme in ~/local/, eg the programme you execute will be in ~/local/bin/programmname.


I usually get the sources and check out a file like "INSTALL". Usually there are instructions to do ./configure --prefix=somedir. Then you have to add somedir/bin to your path.

  • it can be hard to get, compile and keep dependencies updated.
    – Paolo
    Feb 23, 2015 at 17:42
  • This is backwards. The question is about how to get package managers (which are preferable since the 1990s) to behave in this manner. Nov 12, 2017 at 18:43

No, I don't think you can.

The best I can think right of now is to use apt-get source and compile your package. Maybe you could somehow tweak the procedure (which can be more or less automated) to install the packages in your home.

Another one is to use dpkg -X to extract it on a directory of your choice.


I have a solution I've successfully used to install a BIG collection of cooperating software packages on a school Debian server, where I have no root access at all (not even for installing another package manger). It doesn't use deboostrap nor any package manager.

The method is partly manual, but I've done my best to make it convenient.

It uses this script I've called install (don't forget to chmod +x it):


# PREFIX is the installation root, i.e. a directory you have write access to

# unpack the archive to $PREFIX
ar p "$1" data.tar.xz | tar xJ -C $PREFIX

# go through all unpacked text files and search for occurences of /usr/...
# we're gonna replace some of them with $PREFIX/usr
files=$(dpkg --contents $1 | grep '^-' | awk '{print $6}' | sed 's/^..//' | sort | uniq)
for f in $files; do
    if grep -Iq . "$file"; then
        if grep -q '/usr' "$file"; then
            # interactively ask for each occurence, if it should be replaced
            vim -c '%s#/usr#'$PREFIX'/usr#gc' -c 'wq' "$file"
        echo "Leaving binary file $file unmodified"

So usually I first download a deb file using apt-get download package_name. Then I run ./install package_name_blabla.deb, and manually decide about each occurence of /usr in the unpacked files, if it should be replaced by $PREFIX/usr or not.

This decision completely depends on which packages are system-installed and which are installed using this method. Usually, e.g. the pkg-config files need this substitution, whereas shebang lines like #!/usr/bin/perl do not. The general rule of thumb is the resulting path should point to an existing file.

With packages installed this way, you obviously need to somehow tell the other programs about them. This can be accomplished by appending the correct values to LD_LIBRARY_PATH, PATH, PYTHONPATH, PKG_CONFIG_PATH, CMAKE_MODULES_PATH, CMAKE_PREFIX_PATH etc.

There is a caveat in this approach, that dependencies are not downloaded/installed automaticaly; you have to keep track of them manually.

Also APT doesn't obviously know about these packages, so it'll forever show them as missing. But that makes sense - who'd want to install a system-wide app that depends on a user's installation.

If you'd want to uninstall a program, you can list the contents of the deb archive using ar p "$1" data.tar.xz | tar tJ and then delete all these files from the PREFIX.


From my own experience there is no easy way to use existing DEB packages to install into another directory that isn't a chroot environment. The Debian/Ubuntu installation tools dpkg/aptitude/dselect all require root privileges to function properly.

Now given the source DEB you can modify the Debian/rules file to have the package build and install into a different directory tree, but then you are not using the binary packages already available.

As others have mentioned you can use debootstrap and easily build a chroot environment, which I have done in the past to have a 32-bit environment on a 64-bit host, but this requires installing a chroot with at least the base packages duplicated. If you have the space and this is a viable solution you can couple it with dchroot, or even better schroot, to allow easy execution of the applications installed within the chroot environment.


I have trouble imagining how that would work with the official repositories from a distribution. How should it resolve dependencies? From the system or from your home directories? What if it finds different versions in both?

The best I can think of would be a chroot'd environment like people do for 32-bit applications on 64-bit systems. It's more overhead as you would be calling debootstrap in the chroot, but with some symlinking, shell wrapper script fun, it might do what you want.


I'm still working on the problem, but debootstrap basically what you need, and should work with fakeroot. debootstrap is just a bunch of shell scripts, so I'm pulling it apart to see what makes it tick. The hard part will be in uninstalling the files once they are installed.

  • I (and thousands of other users) would whole heartedly encourage this. Something that taps into the already existing system-wide rpm (or apt alternative) database as well as a user-provided rpm database and install user located rpms. This would be amazing. This could even be merged into the mainline. Has any research been done on this previously? Nov 30, 2011 at 6:58

Unfortunately I haven't heard of any distro providing something like this (although I'm sure it would be super popular). You may be able to mimic the rpm based distro though... I haven't tried this, but you may be able to build a user based rpm database and then install rpm's into the user database.

Try setting up a new user based distro with:

rpm --initdb --dbpath DIRECTORY

Then there are several options that may help:

  • --prefix
  • --relocate

You must log in to answer this question.