Both Apt and DNF/Yum, the two most popular package management schemes for Linux distributions to my knowledge, only support system-wide installation of packages: Files owned by root, binaries go in (/usr)?/s?bin, settings go in /etc and so on.

However, on systems in which there are multiple individual users who don't have root privileges, it very often - if not always - happens that a user wants to install some apps or utilities which are available for that distribution; and s/he is fine with an installation that's personal and not common to many/all users.

Now, it does not seem a far-fetched or even incredibly complicated idea for packages to be adaptable, at installation time, with a different root directory or set of root directories, so that users can do this. Nor is it much of an issue to manage a user-specific registry of installed packages (whether or not an individual user has his/her own package DB).

So what's the reason that this functionality has not been added to those common package management systems/schemes?

Note: This is an informative question, i.e. I'm asking about what people know about the past, not what people think about this feature.

  • 3
    If it had been provided it would have saved much of my time compiling software from source on computers which I don't have superuser privilege. I am eager to know the answer. – Weijun Zhou Dec 28 '17 at 18:04
  • 1
    Admittedly my knowledge on this isn't the greatest, but it could have been done to prevent users from filling up hard drives with the dependencies of the software they personally installed. If apt isn't run as root it can't update system libraries, so the user now has a newer version than the system does. Repeat for every user and older, smaller hard drives would have been filling up pretty fast. – Thegs Dec 28 '17 at 19:00
  • 1
    @Thegs: I doubt that this was the consideration. Few software projects avoid significant features because of considerations such as "if people did this they would fill up their disk drive". If it were some kind of security risk, maybe. Also, on multi-user systems, there would be quotas; and few people would ever use this anyway. Plus this is all speculation... – einpoklum Dec 28 '17 at 20:01
  • 2
    In short: It's not the job of the system package manager to mess with user data. ~/bin, ~/lib, etc are, from the POV of the system, "user data". – cas Dec 29 '17 at 2:03
  • 1
    I've seen a few packages distributed via pip, npm and gopkg -- partially because they're distro-independent and partially because they generally allow user-specific installation. – Bob Dec 29 '17 at 6:23

While common package managers don't address this use case, there are several projects that do:

My best guess as to why traditional package managers don't address this use case is that it greatly complicates the package building and installation process, since package maintainers will need to be very careful to ensure that their packages correctly support a dynamic installation directory. In fact, many common package formats such as RPM support a dynamic installation directory, but hardly any maintainers take advantage of this feature when building packages due to the high additional overhead.

  • So, RPM supports this but, say, dpkg doesn't? – einpoklum Dec 28 '17 at 20:03
  • 1
    I don't know about dpkg to be quite honest, since I've never built .deb packages. I'd guess dpkg does support dynamic installation directories, but I doubt many .deb package maintainers do. – jayhendren Dec 28 '17 at 20:29
  • Another thing... do these typically build from scratch, bootstrap, or keep relying on whatever's installed at the system-wide level? – einpoklum Dec 28 '17 at 20:37
  • 1
    The system-wide package management assumes nothing is available if it hadn't installed it, so searching for dependencies in terms of files is equivalent to searching for dependencies in terms of installed packages containing those files. But with a secondary package manager, there's the system-wide packages/files and the user-specific packages/files. Do the package managers typically rely only on what they have downloaded and/or built? – einpoklum Dec 28 '17 at 22:12
  • 2
    Depends. Those that compile from source like Homebrew and Emerge generally just try to build the package without a lot of dependency tracking. Others bundle dependencies with the packages (this is how most App Store style tools work, as well as Flatpak and Snaps). Others like Zero Install install all dependencies as individual user-level packages. – jayhendren Dec 28 '17 at 22:58

So what's the reason that this functionality has not been added to those common package management systems/schemes?

Because it increases complexity of managing systems beyond what is necessary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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