Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

From my research, I seem to notice that all package managers insist on being used as a privileged user and must be installed into /.

Typically, what I like to do is create a throwaway account, compile some software, and install to $HOME for that account. I can try a variety of setups and then when I'm done, just destroy the account.

However, compiling software becomes tedious.

My experience is really just limited to yum, but I don't understand why I wouldn't be able to drop a repo file into ~/etc/yum.repos.d and have yum install everything into a home account.

Is there any reason why package managers must be used as a privleged user to install software?

share|improve this question

7 Answers 7

up vote 18 down vote accepted

Binary packages are compiled with the assumption that they will be installed to specific locations in /. This is not always easily changed, and it would take additional QA effort (which is difficult enough in the first place!) to determine whether specific binaries are or aren't relocatable.

To an extent, you can use things like fakechroot to create an entire system in a subdirectory as a non-root user, but this is tedious and fragile.

You will have better luck with source packages. Gentoo Prefix and Rootless GoboLinux are both package managers that can install to non-/ locations and may be usable by non-root users.

share|improve this answer
I'd add that there are 2 kinds of relocatability. Package may assume it is always in certain place or other things are in certain places (like /bin) or it may assume that it is installed in place specified by --prefix. While the latter may be work around by those projects the former requires patches on source code. –  Maciej Piechotka Jan 8 '11 at 14:42
Another option a la Gentoo Prefix, Rootless, and Nix is pkgsrc. It comes from NetBSD but works on a variety of platforms. –  Michael Ekstrand Jun 2 '12 at 16:36
Binary packages are compiled with the assumption that they will be installed to specific locations in / This sounds like a requirement which could be justified maybe 30 years ago but not now. Isn't for example the env program meant to solve this kind of problems? If not it's easy to come out with a scheme to configure any binary to look for other binaries in specific locations. –  Piotr Dobrogost Feb 26 '13 at 20:58

There's a package manager project--Nix--with an interesting foundational idea (a "functional" pkg manager), which also supports a per-user operation:

Multi-user support

Starting at version 0.11, Nix has multi-user support. This means that non-privileged users can securely install software. Each user can have a different profile, a set of packages in the Nix store that appear in the user’s PATH. If a user installs a package that another user has already installed previously, the package won’t be built or downloaded a second time. At the same time, it is not possible for one user to inject a Trojan horse into a package that might be used by another user.

A NOTE I WANT TO ADD: Nix ought to be usable in a Unix-like system of your choice (e.g., a Linux distro).

There are also an associated large collection of packages that can be installed with the Nix package manager--Nixpkgs--built for a number of platforms:

  • GNU/Linux on 32-bit and 64-bit x86 (i686-linux and x86_64-linux)
  • Mac OS X (i686-darwin and x86_64-darwin)
  • FreeBSD (i686-freebsd and x86_64-freebsd)
  • OpenBSD (i686-openbsd)
  • Windows / Cygwin (i686-cygwin),

and an associated distro--NixOS:

NixOS is a Linux distribution based on Nix. It uses Nix not just for package management but also to manage the system configuration (e.g., to build configuration files in /etc). This means, among other things, that it’s possible to easily roll back the entire configuration of the system to an earlier state. Also, users can install software without root privileges. Read more…

and an associated "continuous" build system--Hydra.

share|improve this answer
Nice summary. Recently GNU Guix was announced. GNU package manager based on nix. savannah.gnu.org/forum/forum.php?forum_id=7436 –  Davorak Nov 29 '12 at 1:10

First of all it is due to dependencies. Some packages may not be installed by user - like PolicyKit. Therefore it would require additional burden on packager who donate their free time and usually installing program is as easy as typing sudo (single-user station) or nagging administrator.

There are options for installing in $HOME

  • Language primitive 'package managers' usually supports it out of box (like gem for Ruby or cabal for Haskell) or with small tweaking (I forgot name for python)
  • Good old ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install (or varitations like jhbuild).
  • There was program to install at $HOME few years ago. However I cannot find it - I guess nearly noone used it as they either installed them themselves or nag administrators.
share|improve this answer
I don't really see how this is a convincing argument. Just because a package doesn't work since it's not invoked as root doesn't mean that the idea is not feasible. It's expected that PolicyKit wouldn't work for this type of situation. There are plenty of other packages that can be installed without root privileges. I am aware of software package managers (Python's is EasyInstall), but those aren't globally applicable as yum or apt-get are. Does anyone know the name of the program that Maciej is referring to? –  elmt Jan 8 '11 at 3:24
@elmt: Possibly stow, which might interest you anyway (but it's a tool, not a package source). –  Gilles Jan 8 '11 at 12:46
@Gilles: No - it had GUI and was meant to be 'simple'. I guess that current direction is more of synaptic/packagekit. –  Maciej Piechotka Jan 8 '11 at 14:11

Another one with a rather different model is 0install. It's based on the idea that you don't really install packages, but merely run them from a global namespace which downloads, compiles if necessary, and caches the software you want to use.

share|improve this answer

My experience is really just limited to yum, but I don't understand why I wouldn't be able to drop a repo file into ~/etc/yum.repos.d and have yum install everything into a home account.

The mainstream Linux package managers view the world as a sysadmin would ... where the machine is a single entity. This allows you to get answers to questions like "what outstanding errata apply to system X" and "how do system X and system Y differ". This also allows yum to have "a history" which is usable, have rpmdb versions and do things like "yum --security update" etc.

There are some package managers, like zero-install, which try to view the world as a user would ... ie. what applications do I have access to.

You might think the later is a better model, but IMNSHO there is a reason you haven't heard of zero-install but have heard of yum.

share|improve this answer

If you're fine with compiling from source and resolving dependencies yourself, primarily wanting the package manager to handle deploy/undeploy/upgrade operations, you might want to take a look at GNU Stow or the somewhat improved XStow. With them, you stage the installation to a separate directory (typically under $PREFIX/stow) and then stow makes symlinks to the software from your real prefix. This makes it easy to then remove the software completely. I use it successfully to manage my custom-installed software at my university.

share|improve this answer

The tools used by Slackware, specifically installpkg, can. From the man page:

--root /otherroot
       Install using a location other than / (the default) as the root of the 
       filesystem to install on. In the example given, use /otherroot instead.
       Setting the ROOT environment variable does the same thing.

However, I don't know of any of the better frontends that are able to do this (e.g. slapt-get, as far as I know, cannot do this). Theoretically, you should be able to alias installpkg to installpkg --root ~/Apps - however, I think that most frontends require root to run, which defeats the point.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.