This section of the chapter contains practical examples of how to use the pkg command. This section will not describe all options and usage methods as there are many possible options. Just the most useful are shown here, in detail.
It is important to note that, at times, requesting that a single package be installed results in multiple packages being installed.
One of the new beneficial features is the ability to do an installation dry run. You can find out basic or detailed information on what the impact to your system will be. Given that requesting a single package install may trigger a cascade of 10, 20, or more required dependencies, having a dry run is useful for those systems where disk space or bandwidth may be at a premium.
The following command will tell you how many packages will be installed, how many services will be affected, and whether a backup Boot Environment will be created as a safety measure:
pkg install -n [pkg-list ...]
To also find out how much space will be used, we can add the
-v option, as follows:
pkg install -nv pkg-list
When you are looking for a particular piece of functionality, you first need to decide whether you wish to look by package name or by filename.
One of the commands you can use is the
pkg search command.
It is crucial to note, however, that the
pkg search command is multifaceted. It can search for more than just filenames. Among other things, it can also search for basenames of files as well as full paths. It can also search for dependencies of packages and descriptions of packages.
Because of this, if you only want to search for a filename, it is best to limit its search to only be on filenames or you may get much more output than you actually need. The best way to do this is given later in this chapter.
There is a shortcut for searching package names (rather than files) called the pkg list command. By default, it only works for already-installed packages. It gives additional information regarding whether a package is installed, not installed, or frozen, if you use the -a command option.
There is unfortunately some amount of overlap between the
pkg search and
pkg list subcommands. There is also some slight incompatibility between valid search strings for each of them, as mentioned in the following tip.
Sysadmins familiar with
grep—the most common sysadmin search tool—will expect that, if your search pattern matches anything in a line, that line will show up. Searches in pkg are more similar to shell-level wildcarding. However, there are some inconsistencies even with that comparison.
Tip
pkg search and
pkg list have a different set of matching rules from grep, and sometimes, they are slightly different even from each other.
To limit pkg search to only search package names, we must use the following modifier: pkg.fmri.
However, even using that, we will note the following inconsistency:
The
pkg search pkg.fmri:/system/zonescommand fails to return a valueThe
pkg list /system/zonescommand correctly returns the full package FMRI
Unlike the filename search, it is best not to use a leading / for package name searches even though the actual search results contain one. That way, both tools will match similarly, albeit with slightly different output.
The
pkg search pkg.fmri:system/zonescommand returns a matchThe
pkg list system/zonescommand returns a matchThe
pkg search pkg.fmri:zonescommand returns a matchThe
pkg list zonescommand returns a match
Sometimes, you are looking for a tool and want to know what package to install to get it.
If you already know the key filename you are interested in and have it conveniently in a cut-and-paste buffer, you can use the following type of command:
pkg search -r /full/path/to/filename
Otherwise, you can use wildcards if needed. The most important thing is to start the filename search with a / character.
Note
The pkg search command searches multiple levels of information, such as filenames, package names, descriptions, and so on. If you want to avoid voluminous output, be sure to give it some hint of what layer of information you wish to search through.
The -r flag stands for "remote" and ensures that you search the remote listing of what is actually available rather than what you have already installed.
In contrast, if you have a particular local file and want to know the package name for it, you can search with the local flag, -l.
pkg search -l some-filename
Be warned that the
pkg search command thinks it is "smart" and that it knows what you want better than you do. For people who are used to using grep, this can be counterintuitive.
If for example, you are trying to find the package containing the command /usr/bin/zonestat, the following will work:
pkg search zonestatpkg search /usr/bin/zonestat
Unfortunately, neither of the following will work:
pkg search bin/zonestatpkg search usr/bin/zonestat
Tip
It is important to note that even though normal pkg search output has no leading /, you are required to put one in your search string or a leading wildcard; otherwise, it will not return anything.
For filename searches, unlike other search types such as pkg name, you cannot use a multisegment match of the right-hand side. You must match the entire path exactly, or exactly the end part (the "basename" component), or else, you must use a wildcard. Wildcard styles that work are similar to the following:
pkg search '*bin/zonestat'pkg search '*/zonestat'
If you wish to search for an exact match of the last component only, and if you wish to be a little more efficient than the last wildcard search shown, you can use a special indexed file search modifier, as shown in the following command:
pkg search basename:zonestat
If you would like to avoid learning multiple ways to search for packages and don't care about knowing the installed status of a package, you can also search for package names using the pkg search command. However, this general search tool may pull up much more information related to a package than just its name. To avoid unnecessary output, add the modifier pkg.fmri: in front of your search token.
Generally speaking, pkg search pkg.fmri:NAME and pkg list -a NAME will match the same things. However, the output will be different. For one thing, pkg list output is usually formatted to fit in 80 columns, and so may be preferable in many cases.
When searching for packages, a subcommand has been provided that can be easier than the general pkg search tool. Using pkg list leads to
slightly cleaner output.
Remember that, as mentioned earlier, these commands do not behave like grep style searching.
Let's say you are looking for information about the following installed package: pkg:/developer/build/make.
All the following commands will work (although some may match additional packages):
pkg list /developer/build/makepkg list developer/build/makepkg list build/makepkg list '*/make'pkg list '*make*'pkg list make
The following commands will not work to match pkg:/developer/build/make:
pkg list /build/makepkg list 'make*'
So, as you can see, you need to match the whole line, except when you don't (ha ha). The important thing is to match whole words, and in particular, the rightmost words. Matching from the left-hand side does not work unless you use wildcards. Note that unlike filename searches, you can get away with doing multiple right side token matches with pkg names rather than rightmost only. That is to say that searching for "build/make" will match "pkg:/developer/build/make". In contrast, if you were attempting to do a filename search of a similar name that way, you would not find it.
If you wish to search for those packages that are available for install on the remote server, you can add the -a flag to pkg list. If using a search that has multiple matches, you should take note of which packages may be installed already.
pkg list -a editor/*
The command will tell you which editors you have installed support for, versus which additional ones may be available to download. In the following abbreviated output for this command, the
dia package is not installed, the gedit package is already installed, and the ghex package is flagged as being "obsolete".
NAME (PUBLISHER) VERSION IFO editor/diagram/dia 0.97.1-0.175.0.0.0.0.0 --- editor/gedit 2.30.4-0.175.0.0.0.2.0 i-- editor/ghex 2.24.0-0.175.0.0.0.0.0 --o
Let's say that you are considering removing a package but are not sure what this will affect. To find out which files will be removed by a pkg remove operation, you can use the following command:
pkg contents pkg/name
Alternatively, if you are curious about the contents of a package that has not yet been installed, you must add the -r flag to query the remote side for information.
This procedure might be more commonly associated with installation time; however, sometimes (even after initial installation), you want to upgrade an existing installation from a "bare-bones" system to a more fully-fledged set of packages.
There are a few predefined collections of packages, somewhat akin to the old Core/Developer/Full package cluster choices. They are organized under the group subdivision of Oracle's FMRI listings for Solaris 11.
The ones that are currently visible are as follows:
group/system/solaris-auto-install(the default small system install)group/system/solaris-desktopgroup/system/solaris-large-servergroup/system/solaris-small-server
There are a few different ways with which you can view which groups are available from the repo server. Any of the following commands will work; they just generate output in different formats:
pkgrepo list -s http://pkg.oracle.com/solaris/release \'group/system/*'pkg info -r 'group/system/*' | grep Namepkg list -a 'group/system/*'
There is an assortment of other day-to-day pkg subcommands that can be found in the manpage, some of which are avoid, unavoid, fix, revert, mediator, freeze, unfreeze, variant, and facet.
However, after 20 years of observing the problems generated by people using similar features on other systems, my recommendation to you is to avoid all of the previously mentioned advice entirely and stick to the basics. One of the worst things to have to debug as a sysadmin is attempting to repair a seemingly normal system on which you've forgotten that you did something clever a year or three back.
The one additional rarely used command I shall take time to mention is the history command.
pkg history [-l]
This command will give you a history of all pkg related activity on the machine timestamped. If you want to identify an activity at a particular time of interest, you can then use the -l flag to get more details.