24

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.

Improve this question
9
  • 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
    Commented Dec 28, 2017 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
    Commented Dec 28, 2017 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
    Commented Dec 28, 2017 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
    Commented Dec 29, 2017 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
    Commented Dec 29, 2017 at 6:23

2 Answers 2

Reset to default
15

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.

Improve this answer
7
  • So, RPM supports this but, say, dpkg doesn't?
    – einpoklum
    Commented Dec 28, 2017 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
    Commented Dec 28, 2017 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
    Commented Dec 28, 2017 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
    Commented Dec 28, 2017 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
    Commented Dec 28, 2017 at 22:58
6

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.

Improve this answer
0

You must log in to answer this question.

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