Many tutorials reference “package managers” and “package management tools.” If you are new to the Linux world and don’t understand the purpose of these technologies, or if you are familiar with one package management tool but want to learn how to use another, this guide will provide an introduction to the major package management tools.
Package Management Concepts
Contemporary distributions of Linux-based operating systems install software in pre-compiled packages, which are archives that contain binaries of software, configuration files, and information about dependencies. Furthermore, package management tools keep track of updates and upgrades so that we don’t have to hunt down information about bug and security fixes.
Without package management, users must ensure that all of the required dependencies for a piece of software are installed and up to date, compile the software from the source code (which takes time and introduces compiler-based variations from system to system), and manage configuration for each piece of software. Without package management, application files are located in the standard locations for the system to which the developers are accustomed, regardless of which system you’re using.
Package management systems attempt to solve these problems, and are the tools through which developers attempt to increase the overall quality and coherence of a Linux-based operating system. The features that most package management applications provide are:
- Package downloading: Operating system projects provide repositories of packages which allow users to download their packages from a single, trusted provider. When you download from a package manager, the software can be authenticated and will remain in the repository even if the original source becomes unreliable.
- Dependency resolution: Packages contain meta-data which provides information about what other packages are required by the package in question. This allows applications and their dependencies to be installed with one command, and for programs to rely on common shared libraries, reducing bulk and allowing the operating system to manage updates to the packages.
- A standard binary package format: Packages are prepared in a uniform way across the system in order to make installation easier. While some distributions share formats, there can be compatibility issues between similarly formatted packages for different operating systems.
- Common installation and configuration locations: Linux distribution developers often have conventions for how applications are configured and the layout of files in the
/etc/
and/etc/init.d/
directories; by using packages, distrubutions are able to enforce a single standard. - Additional system-related configuration and functionality: Occasionally, operating system developers will develop patches and helper scripts for their software which get distributed in the packages. These modifications can have a significant impact on user experience.
- Quality control: Operating system developers use the packaging process to test and ensure that the software is stable and free of bugs that might affect product quality, and that the software doesn’t cause the system to become unstable. The subjective judgments and community standards that guide packaging and package management guide the “feel” and “stability” of a given system.
In general, we recommend that you install the versions of software available in your distribution’s repository and packaged for your operating system. If packages for the application or software that you need to install aren’t available, we recommend that you find packages for your operating system, when available, before installing from source code.
The remainder of this guide will cover how to use specific package management systems and how to compile and package software yourself.
Debian and Ubuntu Package Management
The Debian package management system, based on a tool called dpkg
with the very popular apt
system is a powerful, popular, and useful method of package management. In addition to Debian, a number of other prominent distributions of GNU/Linux are derived from the Debian system, most notably the Ubuntu family of distributions.
As a result, these instructions apply for Debian and Ubuntu systems. While Debian and derived systems are not necessarily binary-compatible, .debs packaged for Debian are often compatible with Ubuntu (though this is not a supported workflow).
Advanced Packaging Tool (APT)
You may already be familiar with apt-get
, a command which uses the advanced packaging tool to interact with the operating system’s package system. The most relevant and useful commands are (to be run with root privileges):
apt-get install package-name(s)
– Installs the package(s) specified, along with any dependenciesapt-get remove package-name(s)
– Removes the package(s) specified, but does not remove dependenciesapt-get autoremove
– Removes any orphaned dependencies, meaning those that remain installed but are no longer requiredapt-get clean
– Removes downloaded package files (.deb) for software that is already installedapt-get purge package-name(s)
– Combines the functions ofremove
andclean
for a specific package, as well as configuration filesapt-get update
– Reads the/etc/apt/sources.list
file and updates the system’s database of packages available for installation. Run this after changingsources.list
.apt-get upgrade
– Upgrades all packages if there are updates available. Run this after runningapt-get update
.
While apt-get
provides the most often-used functionality, APT provides additional information in the apt-cache
command.
apt-cache search package-name(s)
– If you know the name of a piece of software butapt-get install
fails or points to the wrong software, this looks for other possible names.apt-cache show package-name(s)
– Shows dependency information, version numbers and a basic description of the packageapt-cache depends package-name(s)
– Lists the packages that the specified packages depends upon in a tree. These are the packages that will be installed with theapt-get install
command.apt-cache rdepends package-name(s)
– Outputs a list of packages that that depend upon the specified package. This list can often be rather long, so it is best to pipe its output through a command likeless
.apt-cache pkgnames
– Generates a list of the currently installed packages on your system. This list is often rather long, so it is best to pipe its output through a program likeless
, or direct the output to a text file.
Combining most of these commands with apt-cache show
can provide you with a lot of useful information about your system, the software that you might want to install, and the software that you have already installed. If you’re overwhelmed by apt-cache
check out the following resources for easy-to-read lists of available packages:
Aptitude
Aptitude is another front-end interface for APT. In addition to a graphical interface, Aptitude provides a combined command-line interface for most APT functionality. Some notable commands are:
aptitude update
,aptitude install
,aptitude remove
,aptitude clean
, oraptitude purge
– Same as their apt-get counterparts.aptitude search
oraptitude show
, – Same as their apt-cache counterparts.aptitude download
– Downloads a .deb file for a given package into the current directory.
Aptitude also includes safe upgrading, meaning it doesn’t remove existing packages, as well as holding, which prevents the system from upgrading specific packages.
/etc/apt/sources.list
The file /etc/apt/sources.list
controls repositories from which APT constructs its database. This file contains lines in the following format:
1 | deb location-of-resources distribution component(s) |
Here are some examples:
1 2 | deb http://mirrors.linode.com/debian/ jessie main contrib deb http://www.deb-multimedia.org jessie main non-free |
The first line specifies the Linode mirror for the the Debian 8 (code named Jessie) Linux distribution, as well as the main and contributed components. The next line specifies the deb-multimedia.org repository for Jessie, which provides some multimedia packages unavailable in the main repositories for licensing reasons, and its main and non-free components.
In general, one does not want to add new entries to sources.list
without a lot of scrutiny and diligence, as updating the package cache with additional repositories and running upgrades can sometimes result in the installation of broken packages, unmet dependencies, and system instability. In Debian systems, downgrading is often difficult.
For Debian systems, the repository names can either refer to the distribution code name ( e.g. jessie for current-stable, stretch for testing, sid for unstable, wheezy for old-stable) or to a specific branch (e.g. oldstable, stable, testing, unstable). For more information about Debian versions and choosing a Debian version or branch, read the Debian releases and branches page.
The component section of the line divides the repository based on how much support the developers of the operating system are able to offer for the contained packages (e.g. main vs. contrib), or if the software is considered “free-software” or simply freely-distributable (e.g. non-free).
The layout of sources.list
is a bit different in Ubuntu systems. The lines are in the same format but the names of the distributions and components are different:
- Ubuntu versions have a different naming scheme. Version 14.04 is named “trusty” in
sources.list
, 15.10 is “wily,” and 16.04 is “xenial.” These names follow an alphabetical pattern. - Ubuntu components are: “main” and “restricted” for supported free and non-free packages; “universe” and “multiverse” for unsupported free and non-free software.
Using dpkg
apt-get
and apt-cache
are merely front end programs that provide a more usable interface, and connections to repositories for the underlying package management tools called dpkg
and debconf
. These tools are quite powerful, and fully explaining their functionality is beyond the scope of this document. However, a basic understanding of how to use these tools is useful. Some important commands are:
dpkg -i package-file-name.deb
– Installs a .deb filedpkg --list search-pattern
– Lists packages currently installed on the systemdpkg --configure package-name(s)
– Runs a configuration interface to set a package updpkg-reconfigure package-name(s)
– Runs a configuration interface on an already installed package
For information about building your own packages, refer to the Debian New Maintainers Guide.
Fedora and CentOS Package Management
Fedora and CentOS are closely related distributions, being upstream and downstream (respectively) from Red Hat Enterprise Linux. Their main differences stem from how packages are chosen for inclusion in their repositories.
Both systems use yum
as a front end to interact with system repositories and install dependencies, and also include a lower-level tool called rpm
, which allows you to interact with individual packages.
Note: Many operating systems aside from RedHat use rpm
packages. These include OpenSuSE, AIX, and Mandriva. While it may be possible to install an RPM packaged for one operating system on another, this is not supported or recommended, and the results of this action can vary greatly.
Yellow Dog Updater, Modified (YUM)
The YUM tool was developed for the Yellow Dog Linux system as a replacement for the Yellow Dog Updater (YUP). RedHat found the YUM tool to be a valuable addition to their systems. Today, YUM is the default package and repository management tool for a number of operating systems.
You can use the following commands to interact with YUM:
yum install package-name(s)
– Installs the specified package(s) along with any required dependenciesyum erase package-name(s)
– Removes the specified package(s) from your systemyum search search-pattern
– Searches the list of package names and descriptions for packages that match the search pattern and provides a list of package names, with architectures and a brief description of the package contents. Note that regular expression searches are not permittedyum deplist package-name(s)
– Lists all of the libraries and modules that the named package depends on, along with the names of the packages (including versions) that provide those dependenciesyum check-update
– Refreshes the local cache of the yum database so that dependency information and the latest packages are always up to date.yum info package-name(s)
– The results of the info command provides the name, description of the package, as well as a link to the upstream home page for the software, release versions and the installed size of the software.yum reinstall package-name(s)
– Erases and then downloads a new copy of the package file and re-installs the software on your systemyum localinstall local-rpm-file
– Checks the dependencies of a local .rpm file and then installs ityum update optional-package-name(s)
– Downloads and installs all updates including bug fixes, security releases, and upgrades, as provided by the distributors of your operating system. Note that you can specify package names with the update commandyum upgrade
– Upgrades all packages installed in your system to the latest release
RPM Package Manager (RPM)
YUM is simply a front end to a lower-level tool called RPM, similar to apt-get
’s relationship with dpkg
. You will likely not need to interact with RPM very often, but there are a few commands that you may find useful.
The following commands should be run as root. The flags are expanded here, but the abbreviated syntax is also included:
rpm --install --verbose --hash local-rpm-file-name.rpm
orrpm -ivh filename.rpm
– Installs an rpm from the file.rpm
is also capable of installing RPM files from http and ftp sources as well as local filesrpm --erase package-name(s)
orrpm -e
– Removes the given package. Usually will not complete ifpackage-name
matches more than one package, but will remove more than one match if used with the--allmatches
flagrpm --query --all
orrpm -qa
– lists the name of all packages currently installedrpm --query package-name(s)
orrpm -q
– allows you to confirm whether a given package is installed in your systemrpm --query --info package-name(s)
orrpm -qi
– displays the information about an installed packagerpm --query --list package-name(s)
orrpm -ql
– generates a list of files installed by a given package. This is complemented by:rpm --query --file
orrpm -q qf filename
– checks to see what installed package “owns” a given file
Note that RPM does not automatically check for dependencies, so you must install them manually. For more information please consult these external sources:
/etc/yum.conf
The file located at /etc/yum.conf
provides system-wide configuration options for YUM, as well as information about repositories. Repository information may also be located in files ending in .repo
under /etc/yum.repos.d
The options in the [main]
stanza don’t need modification, though you may set alternate logging and cache locations for the database by adding the following lines:/etc/yum.conf
1 2 | logfile=/var/log/yum.log cachedir=/var/cache/yum |
You can use the following template to define a new stanza for a new repository, replacing the capitalized strings with your own values:/etc/yum.repos.d/example.repo
1 2 3 4 5 6 | [REPO-NAME] name=REPOSITORY-NAME mirrorlist=HTTP-ACCESSIBLE-MIRROR-LIST #baseurl=BASE-URL-FOR-REPOSITORY gpgcheck=BOOLEAN-VALUE-TO-VERIFY-REPOSITORY gpgkey=FILE-PATH-TO-GPG-KEY |
The following example is the default configuration for the “Base” repository in CentOS 7:/etc/yum.repos.d/CentOS-Base.repo
1 2 3 4 5 6 | [base] name=CentOS-$releasever – Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 |
Slackware Package Management
Credit: This section was kindly provided by JK Wood.
Packages in Slackware Linux are distributed as compressed tarballs, generally using gzip or lzma compression. These tarballs can be recognized by their suffixes, .tgz
or .txz
. This format includes a complete filesystem layout, as well as additional scripts to be run upon installation or removal of the software. Slackware packages do not offer dependency resolution information; this is generally viewed as allowing more flexibility and control.
Packages can also be built using SlackBuilds, shell scripts that compile source or repackage binary distribution packages for easy installation and removal on Slackware. These scripts have been adopted as a community standard by such sites as SlackBuilds.org, which provides many common third-party packages not available in Slackware proper.
Slackware includes pkgtool
for local package management and slackpkg
for remote installation of packages from official mirrors. For less interactive tasks, there are installpkg
, upgradepkg
, and removepkg
.
Working With Packages Locally
The pkgtool
program offers the ability to manage packages on the local system through a text-based menu interface. Each option is self-explanatory, from installing packages from the Current or an Other directory, to Removing installed packages, Viewing a list of files in a package, and running Slackware Setup scripts.
The package installation operations offer a list of packages in a menu, with the ability to choose which packages to install and which to leave alone. The package removal option offers a similar choice, with a list of installed packages. Viewing a package can be useful to determine what is in it. This information includes a description written by the creator of the package along with the expected list of files.
The Setup scripts options do not often apply to Linode, though there is a netconfig
option that may be helpful to some users.
For those seeking a command-line approach, the *pkg
commands are fairly straightforward in their use.
installpkg package-name(s)
– Installs a package from the current directory, or a pathname you specify. It accepts full filenames, as well as globs such as*/*.t?z
for all tgz, tbz, tlz, or txz packages in all immediately adjacent directories.upgradepkg package-name(s)
– Upgrades a package from the current directory, or a pathname you specify. If also accepts full filenames and globs likeinstallpkg
. Note that the--install-new
flag can be passed to allowupgradepkg
to operate likeinstallpkg
on packages that are not currently installed on the system.removepkg package-name(s)
– Removes a package from the system. This command does not require a full filename, but can often operate with only the software name associated with the package.
Working With Packages Remotely
The slackpkg
program is a recent addition to Slackware that allows official Slackware packages to be installed and upgraded using a remote FTP or HTTP mirror. Before using Slackpkg, a mirror should be set in /etc/slackpkg/mirrors
, and can be added or selected from the available list. Only one mirror can ever be active, and is chosen by uncommenting it (deleting the initial #).
While slackpkg
offers a menu-based interface, it can also be run in a console-only mode by setting DIALOG=off
in /etc/slackpkg/slackpkg.conf
.
slackpkg check-updates
– Checks for new entries to the changelog on the remote mirror. This can be useful in a cron script to notify the system administrator of new patches.slackpkg update
– Downloads updates to the Slackware changelog and file lists. This check is useful for finding security updates, and must be run before attempting to download updated software.slackpkg install-new
– Looks for new packages. While rarely useful on a static release, this command should be run before others on machines running the current development release or when upgrading to a new release.slackpkg install package-name(s)
– Looks for any packages matching the name given, and presents the user with a menu allowing the choice of installation. Note that all commands accepting a package name will also work with Slackware installation series, such as ap, d, or xap.slackpkg upgrade-all
– Presents the user with a menu listing all packages on the remote mirror that do not match the versions currently installed on your system. While this will generally result in upgrades, outdated software can sometimes be listed as an upgrade, such as when changing to an outdated mirror, or using self-built packages to replace standard Slackware packages. One common area this occurs is using alienBOB’s multilib glibc packages on Slackware 64-bit. Upon choosing and confirmation of upgrades, the chosen packages will be downloaded and upgraded.slackpkg upgrade package-name(s)
– Searches for any packages matching the name given, and presents a menu to allow upgradesslackpkg clean-system
– Presents a menu listing all packages on the local system that are not present on upstream mirrors. This includes self-built packages, packages installed from a third-party source, and packages that were once included in Slackware, but have since been removed.slackpkg remove package-name(s)
– Attempts to find any installed packages matching the name given, and presents the user with a menu allowing the choice of removalslackpkg reinstall package-name(s)
– Reinstalls the given package. This is useful if certain files in that package have been corrupted.slackpkg search package-name(s)
– Searches for the given package name, and displays matching packages as well as installation statusslackpkg file-search filename
– Searches installed and remote package descriptions for the given filename, and displays matching packages as well as installation statusslackpkg blacklist package-name(s)
– Adds the given package to the blacklist located in/etc/slackpkg/blacklist
. Blacklisted packages will not be installed, upgraded, or removed by slackpkgslackpkg info package-name(s)
– Displays standard information about the given package
SlackBuilds, sbopkg, and Third-Party Packages
Slackware does not offer as large a selection of official software as some other more community-oriented distributions, so it can include dubious third-party packages. For this reason, the use of third-party software repositories in Slackware is generally discouraged. Third-party package management tools such as slapt-get
are also frowned upon, as they have a reputation for disrupting systems.
The Slackware community have produced SlackBuilds.org, offering SlackBuild scripts for a growing volume of third-party software. These scripts are heavily vetted for integrity and proper operation. Dependencies are noted in README files, and all builds are verified to work as advertised in a clean build environment. Local compilation also verifies that packages for your machine will work on your machine.
To facilitate the management of SlackBuilds, sbopkg.org offers sbopkg
, which operates similarly to slackpkg
, but works with the SlackBuilds.org repository.
The sbopkg
program, like pkgtool
, offers a text-based menu interface. There is also a Sync option, which ensures that you are working with the latest version of all SlackBuilds. SlackBuilds can be browsed or searched for, as can their respective Changelogs. sbopkg
offers an Updates option, which compares local versions of your packages to remote versions of the SlackBuilds. Unlike slackpkg
, sbopkg
will not overwrite a newer package than what’s on the server by default. In addition, sbopkg
offers the ability to manage the order in which SlackBuilds are built using a queue system, and allows the user to make changes to the SlackBuild locally. You can also view which SlackBuilds packages are installed, choose a different repository version to work with, or look for updates to sbopkg
itself.
Package Management in Arch Linux with Pacman
Arch Linux uses binary packages in a .tar.xz
format, and also provides a “ports” build system that facilitates building packages.
Arch Linux runs on a rolling release schedule, which means packages are added to the main repository when they (and their dependencies) are ready for production. This means that there aren’t release versions of Arch, as all systems, once upgraded, are equivalent.
Therefore, administrators of Arch Linux must consider the output of pacman
carefully before agreeing to upgrade or update any packages.
Pacman
The pacman
tool is very powerful, but it is also very simple. There are three core commands for basic package management:
pacman --query package-name(s)
orpacman -Q
– Searches the package database for a package name and version numberpacman --sync package-name(s)
orpacman -S
– Installs new packages, downloads new content for the database and/or upgrades the system, depending on the options and the named package or packagespacman --remove package-name(s)
orpacman -R
– Removes the named package or packages
Note that the terse flags are all uppercase and case-sensitive. These terse flags are often combined with additional flags for additional functionality. Here are some examples with brief descriptions:
pacman -Qi package-name(s)
– Displays information about a given package, including dependency information, the date of the package, a link to the upstream source and other useful informationpacman -Qo filename
– Outputs the version number and name of the package that “owns” a given filepacman -Qs package-name(s)
– Searches among the installed packages for a given packagepacman -Qu
– Lists out-of-date installed packages that are in need of an updatepacman -Sy
– Triggers a database refresh, and synchronizes the local database with the remote database.pacman -Su
– Triggers a full system update and downloads new packages to upgrade the system. The update and refresh command can (and should) be run together, as in:pacman -Syu
.pacman -Sc
– Removes uninstalled packages from the cache and attempts to clean up old copies of the repository databasepacman -S --ignore package-name(s)
– Ignores upgrades to a given package or list of packagespacman -Rs
Removes a package and its dependencies, as long as the dependencies are not needed and were not explicitly installed by the user. This command is the inverse ofpacman -S
.pacman -Ru
Removes packages that are unneeded by any other packages
Configuration Options
The configuration for pacman
is defined in the /etc/pacman.conf
file, while the addresses of the repository mirrors are contained in /etc/pacman.d/mirrorlist
. The mirror list was created and prioritized during the installation process and you probably will not need to alter this.
The options in the stock /etc/pacman.conf
are documented in comments, and are beyond the scope of this document. You may access the manual page for this configuration file with the command man pacman.conf
.
While it is unlikely that you will need to modify the default pacman.conf
for most installations, you can change default installation and logging directories and specify packages to be held back from upgrades.
If you need to add an additional third party repository, add a repository stanza:/etc/pacman.conf
1 2 3 | [REPOSITORY-NAME] Server = SERVER-LOCATION Include = REPOSITORY-LIST |
The Server =
and Include =
lines are both optional, and the order indicates their priority. By default, the testing repository is disabled, which is wise if you’re planning to use the system for production work; however, if you need bleeding-edge packages, uncomment those lines.
The Arch Build System (ABS)
The Arch Build System allows users to compile and install software not included in the Arch repository. This brief guide outlines the steps to building a package using the ABS.
All commands explained here should be run as root unless otherwise specified.
Begin by installing the abs
framework and the base-devel
packages:
1 | pacman -Sy abs base-devel |
Edit /etc/abs.conf
so that the REPOS
line indicates the proper repositories. Note, repositories prefixed with a bang (!) are disabled. The line might look like:
1 | REPOS=(core extra community !testing) |
To create a local ABS tree in /var/abs
, run the the abs
command as root. You may now browse /var/abs
, which contains a representation of the package collection with folders representing each repository, category, and piece of software.
Arch recommends that you create a build directory at another location, such as ~/abs/
, where actual building will occur.
Begin the build process by copying the files from the ABS tree into your build directory as a non-root user:
1 | cp -r /var/abs/REPO/PACKAGE ~/abs |
Change to the package’s directory:
1 | cd ~/abs/PACKAGE |
You have the option of modifying the PKGBUILD
file. There’s a build shell function that you can use to add additional patches to the files if you have modifications to the software or the build process. That shell function generally looks like:~/abs/PACKAGE/PKGBUILD
1 2 3 4 5 6 7 8 9 10 | build() { cd $startdir/src/$pkgname-$pkgver.orig patch -Np1 -i $startdir/src/${pkgname}_${pkgver}-$_patchlevel.diff || return 1 ./configure –prefix=/usr make || return 1 make install } |
To build the package, use the following command as a non-root user:
1 | makepkg -s |
The makepkg
command creates a package that contains dependency information. As root, issue the following command:
1 | pacman -U PACKAGE.pkg.tar.xz |
Make sure to replace PACKAGE
with the full package name exactly as it appears in the file system. Arch will now install the package and any required dependencies.
Because ABS downloads source versions of the PKGBUILD
file as it creates the package – sometimes checking out a copy of the source code from the version control system – we don’t recommend removing files from the build directory hierarchy.
More Information About Pacman and ABS
If you’re interested in learning more about Arch and its package management tools, consult these external sources for the documentation provided by the Arch community:
Gentoo Linux Package Management
Gentoo provides its entire operating system in source format. These source packages, in concert with ebuild
scripts, provide a package management system that borrows and builds on many concepts from the BSD’s “portage” system.
Like Arch, the Gentoo project produces new versions of Gentoo Linux on a rolling release cycle.
This section addresses common package management tasks and functions using the emerge
front end for the portage system. We encourage you to install the “gentoolkit” to provide additional package management tools, such as equery
. Install this package with the following command:
1 | emerge app-portage/gentoolkit |
Emerge/Portage Commands
emerge --sync
– Updates the local copy of the portage tree, so that your local system can download and install the latest version of the softwareemerge --update --deep world
– Checks and updates all packages on the system to the latest version. This should be run regularly to avoid falling behind on a critical update.emerge --search keyword
oremerge -s keyword
– Searches the names of all of the packages for the given keyword. This command accepts a regular expression as the keyword argument.emerge --searchdoc keyword
oremerge -S keyword
– Searches the full description for a given keyword. This command accepts a regular expression as the keyword argument.emerge package-name(s)
– Installs the specified package or packagesemerge -u package-name(s)
– Updates the specified package to the latest version. Using the flag-uD
also updates dependencies.emerge --depclean package-name(s)
oremerge -c package-name(s)
– Removes the specified package or packagesemerge --depclean
– Removes packages that are orphaned. This means removal of all packages that weren’t explicitly installed and are not not depended upon by any specific package. We recommend that you run it with the--pretend
option before running this command on a production system.emerge -evp --deep world
– Lists all of the packages currently installed on the systemequery depends package-name(s)
– Lists all of the packages that depends upon the specified packageequery files package-name(s)
– Lists all of the files “owned” by a packageequery belongs filename
– Lists the package that “owns” a particular file
USE Flags
Portage also makes it possible to install additional variants of a package with USE flags, which allow the user to enable support for a particular option related to that package. To discover which USE flags are available for a given package, issue the following command:
1 | equery uses package-name |
The equery
command depends on the gentoolkit
package. This will provide information about what USE flags are available and which have been installed. To specify additional USE flags:
1 2 | echo “package-name USE-flags” >> /etc/portage/package.use emerge package-name |
This will install the specified package with the appropriate options enabled.
Views: 14