This is probably a stupid question, but I recently realized that I have no idea why there's no single-user functionality with apt-get.

Answers I'm not looking for:

  • "It's because apt writes to system-level directories". This is the surface-level why, but I'm looking for a level deeper. Is there something fundamentally blocking a single-user environment (a la pip + virtualenv)?
  • "You can just build from source". This is a workaround, but does not address my question. I don't want to fix a short-term issue, and I have root access on all of my machines anyway.
  • I hope you know you can build any package from source in your home directory.
    – jobin
    Mar 28, 2014 at 2:51
  • Right, but I'm looking for the why underlying the apt-get limitation. Building from source does not answer that. Mar 28, 2014 at 3:01
  • 1
    I think the question you're really asking is "Why isn't most Linux software relocatable?". It would be perfectly possible to allow apt-get to install software into user-local directories, but since most software doesn't support this there would be little point in doing so.
    – user21322
    Mar 28, 2014 at 12:14

5 Answers 5


Why does apt-get require sudo?

Not always. You can perfectly use apt-get without sudo. There are instances where you don't need sudo at all, like using apt-get download which downloads a package to your current directory, apt-get source which downloads the debian sources files to your current directory, changelog which downloads and prints the changelog of a given package, and any command which has the --simulate/--dry-run/--no-act (in the case of install you need also --no-download).

This is because these actions/commands doesn't require to write system directories.

Now, why apt-get needs sudo? Actually it doesn't. You can ditch apt-get, download a package with wget and use dpkg --extract and extract the package in whatever directory you like. There's also --instdir which should work for binary only package.

Now, why this isn't the default? Because it's a pain. To do what you want, we would need to repackage each package twice, one for the right way, and another to do what you want. At build, binaries normally need to know where are the files and libraries they need (in some cases, this is hardcoded at compilation).

Now, what you can do instead? Just chroot some environment a la virtualenv, where you can install packages without root.

Summary, this is not the way that apt-get was meant to be used, and I don't know another package manager similar to apt-get which allows you to do that. At the end of the day, apt-get is just a front-end to dpkg which could do some of this.


It's not a stupid question.

What you're asking is, why does Apt only install software at a system-level, which requires superuser privileges? Why can't it optionally install software at a user level, requiring no such privileges?

The short, glib answer is that that isn't Apt's role. Apt's role is the management and installation of software that forms part of your system. If you want to install software at a user level, you can do that yourself, but you don't use Apt for it. You can compile it yourself, or grab a statically compiled binary from somewhere, or using something like flatpak. Or spin your own method for deploying.

The role of Apt

Ubuntu is a Linux distribution. A Linux distribution is at its core a collection of software from many different sources, all which have been collected into one place by the distribution's managers so that you can install a complete, working system from it.

For this to work, the distribution can't just make software available completely unmodified - for each piece of software that forms part of the system it has to "install" it in a particular way into the system so that it works correctly with the rest of the software on that system.

Distributions like Ubuntu maintain repositories of software that comprise this system. The repositories consist of many packages, which are discrete parts of the system that can be chosen and installed separately. Each such package lays out the software inside it in a way that allows it to be installed into a working system, so all the software and supporting files are already in the directory paths they will reside in on the target system. In addition to this the package comes with install, configure and/or uninstall scripts that perform any other work required.

The laying out of the files inside the package, and the install/configure/uninstall scripts in the package, all assume the package will be part of a whole system. Thus, it's not easy to take a single package and install it somewhere else, because the scripts and the layout of the package won't have been designed for this.

On top of this, the packages in the system frequently are relied upon by other packages. And, if the software in a package is relied upon - is a dependency of - another package, it has to be placed into its correct place in the filesystem and in many cases the install and configure scripts have to have been run to ensure it's installed correctly.

The tool on Ubuntu and Debian which install packages and run their install/configure/uninstall scripts is called DPKG. But, the tool that finds packages in the repository and ensures that all packages that are dependencies of other packages are also installed is called APT.

As you can see from this, every part of the software distribution stack is designed so that software is installed into a predictable location so that it can work as part of the system, and so that software can depend on other software to be there, and so on.

Operating systems like Ubuntu draw a very clear distinction between software that is provided as part of the system and software the user has installed themself. This distinction is even built into the Filesystem Hierarchy Standard (FHS) which dictates how Linux distributions (and unix-like operating systems) lay out their software. Software that is installed by the user is to go into separate directories on the system, such as

  • /opt - for system wide software that isn't part of the OS but is provided by other vendors
  • /usr/local/* - for system wide software that was installed by the system admin manually, that isn't part of the OS
  • home directories - for software installed by end users in their user account, not system wide

In addition to the above, other directories can be used if there is justification for making up your own directory scheme and not using the above.

What other options are there?

If you write software yourself or you grab it from an upstream source and adapt it yourself, you can modify your software to be installed where you like and work how you like. So that's always an option.

If you want to use your operating system's (or another Linux distribution's) packages but install them in another location, various hacks exist to get software out of a package and do this. But, the extent of success of doing this will depend on how the package is written, how its install and configure scripts work, how dependencies in the package work and so on.

You can use containerisation (with chroot) to install into a directory, and even run a separate copy of Apt in that directory. Then, you have basically a cut-down Linux distribution in its own right inside a directory within your OS.

A technique like this is what is employed by technologies like Snap or Flatpak, and is why they are pretty flexible in how and where they can install software.

  • Thanks for answering, and thanks for the thoroughness. I understand the system-wide nature of apt-get, but what I'm trying to understand is why it has to be that way. Mar 28, 2014 at 12:16
  • 1
    It didn't have to be that way. It just happens to be the way Ubuntu (and Debian) were designed. There would be nothing stopping someone designing an operating system where the normal way of installing software was per-user. Mar 28, 2014 at 12:22

Information in the package itself determines where files will be installed, so you need sudo both to write to / and to change the package database.

When you are installing packages, you are installing pre-built binary files and associated configuration and meta files and scripts that are essential parts of the package. These scripts and configuration files are tightly linked to dependencies and the rest of the system. You wouldn't want to change these lightly unless you knew exactly what you are doing.

If you are on a system, say at work, where you don't have sudo access, you can compile from source and set the installation directory to your home. Then, there's no need for sudo. When you are installing from source, you are generally not changing the package database.

  • Thanks for answering! I know and use the workarounds, but what I'm trying to figure out is why I've been using them. I believe you're saying that the issue is that the install path is hardcoded by the package maintainers - why can't this be changed? Mar 28, 2014 at 2:35

Why apt-get installs to / (or similar) directories by default?

The simple reason for this is that apt-get does not decide where to install software. It is decided by the developers and coded inside the application itself.

Can I install to other directories?

Yes, you can install to other directories.For open source software, get the source, change the installation directory, compile, build and install it. There is usually an option to the included configure script that lets you specify where to install. This is usually --prefix.

But I insist on using apt-get. What to do now?

OK. There is still a way to do this with apt-get, though it would be too much for a end user. Follow the steps.

  1. Get the source.
  2. Change the installation directory to something like $HOME.
  3. Compile and build.
  4. package it into a .deb file.
  5. Create a launchpad account.
  6. Sign the ubuntu code of conduct(I'm not sure if this one is necessary).
  7. create a ppa for yourself.
  8. Upload the deb package to the ppa.
  9. add the ppa to your sources.
  10. Run sudo apt-get update.
  11. Run apt-get install package.

That was too easy/hard.Is it possible to select directory during installation?

Yes and no.

Yes because it is possible, some softwares use this method, the only one that I know is Qt5.It has a .run file which, when executed asks for installation directory among many other inputs.

No because this method does not use apt-get.

Could I do this easily some day, with apt-get?

I don't think developers of apt-get and/or developers of softwares would be interested in doing this, but some software can be developed which will do the source, change, compile, build, install steps automatically by only asking for the installation directory.

My 6th sense tells me that the command would be

apt-dont-get install pkg1 pkg2 ...
  • Thanks for the answer - it's thorough and addresses my question. I don't understand why there would be no interest in developing single-user functionality into apt-get, however. It seems like that functionality would be highly useful in certain use cases. Mar 28, 2014 at 14:07
  • Good info, but a Q&A format within the Q&A...? :) Idk, maybe you should edit into a standard format? Just a thought.
    – chaskes
    Mar 28, 2014 at 14:39
  • @PattimusPrime Such cases are mostly rare, because in most cases admins install all necessary software & others don't need to install software. Also the facts that building from source is very easy & that implementing such a functionality would be useless as long as software developers don't implement it in there own software will stop apt-get developers from doing so. Also, many existing programs depend upon other programs and they search them in /usr directory.Implementing such a functionality would require change in all existing softwares that have dependencies(this no goes in thousands). Mar 29, 2014 at 3:41
  • Is a Debian policy violation to install files in $HOME. You should never do that. If anything, use /opt/package and chmod the directory instead.
    – Braiam
    Mar 29, 2014 at 15:38
  • @Braiam: I have seen people recommending installing packages in $HOME/opt/ if they don't have required privilege for installing packages in /opt/..
    – Aditya
    Mar 30, 2014 at 7:10

Cause it editing files that are chmodded so you cant use them. You might be able to chmod them so you cant I dont reccomend doing that though

  • Thanks for answering. I'm looking for why it only edits chmodded files. It seems to me that a single-user functionality would be easy to implement and immensely useful in some areas (e.g. supercomputing clusters) Mar 28, 2014 at 3:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .