Application level package management
This meta article provides best practice recommendations on managing the coexistence of operating system and application level package managers on Gentoo.
Gentoo offers a variety of application level (or language based) package managers. Some application level package managers have been patched to prevent accidental misuse by the end users.
When to use an application level package manager
It is typical for an operating system's package manager and an application level package manager to provide the same package. Should the OS level or the application level package manager be used? The answer depends on purpose of the package. Generally speaking, the package provided via the OS level package manager should be used by default for the following reasons:
- Portage will keep the package up-to-date during standard system updates.
- Gentoo's glsa-check tool can be used to test for security vulnerabilities.
However, if the package is unavailable via the main ebuild repository and/or overlays, then alternatives such as application level package managers should be considered.
A limitation to the above recommendation would be for software development on Gentoo. Software developers must frequently employ application level package manager to install the necessary packages to build their application(s). Even in this case, the best practices should be observed.
THOU SHALT NOT
End users should NOT install packages from application level package managers:
- With root user privileges. This includes using privilege escalation such as sudo, doas, or su!
- Into system directories such as /bin, /lib, /lib64, /sbin, or /usr. Installing to these directories should not be possible if the first rule is observed.
Performing either of the above actions could irrevocably ruin the integrity of the OS packages.
End users should install packages from application level package managers:
- With standard user permissions.
- Into a home directory or software development workspace such as any non-LFH mount point, /srv, /mnt, or /opt.
Available software and articles
The following are some of the application level package managers available in Gentoo:
Programming language package managers
|Provides a method to 'vendor' gems for Ruby projects (depends on Ruby gems).
|The PyPA recommended tool for installing Python packages
|A centralized Ruby extension management system
|A concurrent garbage collected and typesafe programming language from Google
|Rust's build system and package manager
|A package manager for the Nim programming language
|A dependency manager for the Crystal language
A user's shell can set environment variables in order to instruct application level package managers to safely place new packages into a user's home directory. A system admin can use shell defaults at a global level (for all new users) via the /etc/skel directory.
For example, a bash shell user is developing a project and would like to add a Go package via go install. The user would modify their ~/.bash_profile file with the following values to define a path that Go will use to install packages, then modify their shell's PATH variable to source the newly added binaries.
# Set GOPATH path for bash shell users
# Set GOBIN path for bash shell users
# Append Go binary to user's PATH for binaries added via `go install`
For currently running instances of bash to recognize the environment changes, source the .bash_profile file:
- Go — an open source, statically typed, compiled programming language
- Pip — Python's package management system. It references packages available in the official Python Package Index (PyPI).
- Rust — a general-purpose, multi-paradigm, compiled, programming language.
- Portage — the official package manager and distribution system for Gentoo.
- Flatpak — a package management framework aiming to provide support for sandboxed, distro-agnostic binary packages for Linux desktop applications.