When installing applications via the software center or by a DEB file they will usually be installed system wide for all users.
Is there a way to install an application for a single user only?
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.Sign up to join this community
Depending on what you want to accomplish, there may be different ways to make this work (or at least give a hacky semblance of the functionality you want).
Installation of software in many ways comes down to making resources available, or allowing access to things that are already present on the system.
Whether you are talking about granting access to printers, or allowing a user to execute programs in a certain directory, there are ways to accomplish this, and though they may be native to Ubuntu, these kinds of solutions are generally (of course) going to be added after the fact of a .deb installation.
Here are two general classes of post-installation control that can be added. Note that, given the right environment, e.g. when a tightly controlled group policy is in place, this might be easier once you have the basic system in place. These kind of permission can even be tied to LDAP or a similar system which can give per-user or group authentication and authorization.
I've had a perhaps somewhat similar situation myself, but in my case, the users were not (yet) very sophisticated (all of them being under 7 years old). For me, just hiding Gnome menus and or removing desktop launchers worked.
Removing the executable bit from directories eliminates the ability of processes to search or traverse them. It can effectively render them invisible, and user-wise, make them unavailable. If you have a default system policy which creates menus based on file access, for instance, you can get this kind of cosmetic solution in place, and then have it work for subsequent installations with little additional effort.
Control of the resource can be done via Unix permissions, apparmor profiles, SELinux permissions, and so on. There may be other levels of control filtering which may come into play depending on the application. In the absence of more targeted solutions, you might have to write wrappers around certain programs to control user or process access.
dpkg won't help you as this isn't its design aim. It wants to be a root-owned sole census of packages installed on a system.
The only thing that jumps to mind is just extracting the package and trying to place the files manually in the home dir.
However this will only work for some things. Plenty of packages are split into chunks (executables or scripts in
/usr/bin, libraries in
/lib and other garb in
/usr/share, etc) and these locations are hard-coded in by the build scripts. Thus if you try and pull in something like this into
~, it will break. You could spend hours unwinding the dependencies but you could be doing something useful with your time like finding the cure for cancer or absorbing some of the beauty in the world.
You'd do much better just to grab a non-packaged version from whoever writes the software. Almost all free software is available in some form of compressed archive as source so grab that and just build it. You don't do the
make install step. Your app is built, just put it where you want it.
I don't know too much about this subject, but it seems from the other answers that you may be able to install a package to another directory instead of
dpkg, using the
--root parameter, and then do a
chroot to the dir which the package was "installed" in (which can of course be a dir in the home directory of the user).
To install a package for a user other than
root, it might be possible to use the above process with
fakechroot instead of
Disclaimer: I did not try this, and do not have much experience at the time of writing with
chroot, but from what I do know about these tools, this process just might work.
Links which have information which may be useful for people who want to achieve the effect of
I now have done a little bit with things which touch on this subject, and found out some more...
Fragments (local environment building blocks):
Full (complete local environment providers):
binfmt_misc, and running binaries from other architectures using qemu-user-space
Summary: By emulating, or actually having, root privileges locally, DEB packages can be installed for a local environment.
The deb's are mainly archives that get extracted to the root of your filesystem when installed (plus some config). If you wanted to install them just for one user, you would need to somehow install them to /home/user folder. Even if you did so, they wouldn't work, as f.e. application binaries won't land in /usr/bin (or sth similar), and system will not find them if you'll try to launch them. Similarly libraries etc. would be useless, as the system wouldn't know there are somewhere in the /home. You could try the brute-force approach, and adjust the PATH variable to point to wherever you extracted the files from the deb archive, but that would be not only VERY insecure, but might cause may compatibility problems (f.e. menu entries wouldn't work, as GNOME extects the .desktop files to be in /usr/share/applications).
Moreover, if you installed a package just for some users, it might cause crazy dependency problems, if any other user installed package that conflicts with another one you have had installed just for yourself - and possibly tons of other package management related issues would appear.
All these troubles make it extremely difficult to manage packages separately for users, so it seems it's not possible to install them just for one user, because the idea behind the .debs disallows that.