Well 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 / with 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 chroot.
Disclaimer: I did not try this, and do not have much experience at the time of writing with dpkg or 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 chroot without root capabilities:
This page about read-only bind mounts (it seems that this can be useful even to people doing a "standard" chroot
binfmt_misc - Can run files, using their interpreters, as if they are native binaries; useful together with qemu-user for working with binaries (or in a (fake)chroot) of foreign architectures (scripts/qemu-binfmt-conf.sh which comes with the QEMU source code automates this)
Qemu user space - Can run binaries of other architectures; can be used with some of these tools when they do not support some processor architectures
LwIP - A TCP/IP networking stack which can be run from user space
Full (complete local environment providers):
User mode linux - runs another linux system as a regular process/program
PRoot - Provides functionalities of chroot(1), mount --bind, binfmt_misc, and running binaries from other architectures using qemu-user-space
Linux namespaces - Allows to have full root inside a local environment, when using user namespaces, a feature that is available in Linux kernel versions 3.8 and after.
Summary: By emulating, or actually having, root privileges locally, DEB packages can be installed for a local environment.
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.
Visiblity control
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.
Execution control
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.
You can probably use the --root option of dpkg to install to another directory. But will probably run into problems if the application looks for stuff in fixed places like /etc.
You could change the executable file's ownership so that only one user would be able to run it. Then, if needed, you can remove the application from the menus of other users.
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.
Well
dpkgwon'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/liband 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 installstep. 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
/withdpkg, using the--rootparameter, and then do achrootto 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 withfakechrootinstead ofchroot.Disclaimer: I did not try this, and do not have much experience at the time of writing with
dpkgorchroot, 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
chrootwithoutrootcapabilities:chrootfakechroot)Update
I now have done a little bit with things which touch on this subject, and found out some more...
Fragments (local environment building blocks):
chroot(1)Full (complete local environment providers):
chroot(1),mount --bind,binfmt_misc, and running binaries from other architectures using qemu-user-spaceSummary: By emulating, or actually having, root privileges locally, DEB packages can be installed for a local environment.
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.
Visiblity control
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.
Execution control
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.
You can probably use the
--rootoption ofdpkgto install to another directory. But will probably run into problems if the application looks for stuff in fixed places like/etc.In short, I don't think there is an easy way.
You could change the executable file's ownership so that only one user would be able to run it. Then, if needed, you can remove the application from the menus of other users.
Doubtful.
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.