Application level package management

This article is a stub. Please help out by expanding it - how to get started.

Resources

This meta article provides best practice recommendations on managing the coexistence of operating system and application level package managers on Gentoo.

Considerations

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.

Note
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.

Best practices

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.

THOU SHALL

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

Name	Package	Homepage	Description
Bundler	dev-ruby/bundler	https://bundler.io/	Provides a method to 'vendor' gems for Ruby projects (depends on Ruby gems).
Pip	dev-python/pip	https://pip.pypa.io/en/stable/	The PyPA recommended tool for installing Python packages
Gem	dev-ruby/rubygems	https://rubygems.org/	A centralized Ruby extension management system
Go	dev-lang/go	https://go.dev	A concurrent garbage collected and typesafe programming language from Google
Cargo	dev-lang/rust	https://github.com/rust-lang/cargo	Rust's build system and package manager
Nimble	dev-lang/nim	https://github.com/nim-lang/nimble	A package manager for the Nim programming language
Shards	dev-lang/crystal	https://github.com/crystal-lang/shards	A dependency manager for the Crystal language

Configuration

User profiles

Shell

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.

FILE ~/bash_profileDefining GOPATH, GOBIN, and append Go binaries to user's PATH

# Set GOPATH path for bash shell users
export GOPATH="${HOME}/go"
# Set GOBIN path for bash shell users
export GOBIN="${GOPATH}/bin"
# Append Go binary to user's PATH for binaries added via `go install`
export PATH="${PATH}:${GOBIN}"

For currently running instances of bash to recognize the environment changes, source the .bash_profile file:

user $source ${HOME}/.bash_profile