This chapter introduces the new Solaris packaging system. The first part will introduce key concepts to be understood. The second part will give specific examples of the most common tasks a sysadmin will need to perform.
The details about installing a new Solaris machine from scratch are covered in Chapter 2, Solaris 11 Installation Methods, in this book. This chapter primarily deals with package management on an already running Solaris 11 system.
Solaris 11 has an all new packaging system for OS-related packages, in which the packages are primarily accessed via the
pkg
command. This new command handles the acquisition/downloading of OS packages, as well as local installation and removal of the files on local storage.
Legacy format packages, also known as System V Release 4 (SVR4) style packages, are still supported; pkgadd
and related commands still work. This is not merely for third-party developers. Oracle itself still distributes some Solaris 11-related packages in SVR4 packages.
Even though Oracle has not stopped using SVR4 packages, the new
pkg
interface has some notable benefits, such as extra hooks to integrate safely with zones, and automatic use of
ZFS snapshots for certain types of package upgrades. It is for this reason that Solaris 11 does not support
UFS as a root filesystem. The new packaging system requires ZFS for part of its standard operations.
This chapter breaks down the concepts of the new package system into four main areas:
An overview of package repositories
Understanding package naming
Understanding conceptually how packages are installed
Practical use of the
pkg
command
The majority of the chapter is taken up with the practical use section.
The new
pkg
style is primarily network-based, rather than file-based.
While it has recently become possible to transfer a single .p5i
package via the file transport mechanism of your choice, you lose the automatic upgrade capability of IPS. For that, it requires a
repository to be running somewhere (commonly referred to as a repo). That said, it is certainly possible to have a copy of the full Solaris repository on your own machine.
A point of interest is that the new pkg
system is differential-based in an attempt to be network efficient. If you have an older version of a package, and if you request that a new version be installed, it will only pull the newer files from the repository server, rather than the entire package.
Note
The good news (or bad news) is that the default repo is provided by Oracle itself at oracle.com. It is a highly robust and high-bandwidth public server. Because of this, it is no longer strictly required to have a fully up-to-date local repository for network installs. You can get by with a small bootstrap image somewhere.
It is important to note that Oracle most likely logs access to its repo, so you should probably not be updating a score of machines from it unless you are confident of your licensing status.
It is possible to have a locally running repository server if you wish. Oracle provides a Repository
Image download in the same place where it provides regular ISO image downloads for Solaris 11. If you do decide to run a repository yourself, the standard Service Management Facility (SMF) name for the IPS-specific service is svc:/application/pkg/system-repository
. More details on how to do this is given in the Creating your own IPS repository and packages section in this chapter.
It is also possible to serve a local repository out using
NFS and using file:///
style URLs to access it. However, Oracle recommends using the custom server at this time.
A Solaris machine is configured to know about a particular repository, using a repository URI. This type of URI is sometimes referred to as an origin.
It is actually possible to access multiple, separate repositories via the same repository URI as long as they are provided by separate publishers. The standard publisher name used for the Solaris OS is "solaris", not "oracle".
An IPS client is configured to point to one or more publisher-repository combinations as a source for packages.
The standard Oracle URI for Solaris 11 is http://pkg.oracle.com/solaris/release.
To configure your system to know about it (even though it is already known), you can use the following command:
pkg set-publisher -g http://pkg.oracle.com/solaris/release solaris
This tells your system the URI to use for the publisher named solaris
.
It should be noted that, while the address of an IPS repository is given with an http:
or https:
URL, the repository itself is not browsable with a web browser in the way you might expect. While the Oracle repository server does allow a web browser to connect and even query packages, there is no single link that says "here, download the package you want". For that, you have to use the appropriate client-side tool.
Packages are now named and referred to with a naming scheme that is somewhat similar to the SMF style naming introduced in Solaris 10.
Package references in the IPS format look like this:
pkg:/somebase/leafname@version,num-here pkg://publisher/somebase/leafname@version,num-here
Specific examples of the previously mentioned IPS format are:
pkg:/runtime/java/jre-6@1.6.0.0-0.175.0.0.0.2.0 pkg://solaris/runtime/java/jre-6@1.6.0.0-0.175.0.0.0.2.0
Note that even though both the standard Solaris repository URL and the publisher component from the previously mentioned pkg
FMRI have the string solaris
in them, they are in completely different namespaces. Changing one would not affect the other.
The good news in this confusion is that, as with SMF, you can use short forms most of the time. For example, the following commands all give the same output:
pkg list pkg://solaris/runtime/java/jre-6
pkg list pkg:/runtime/java/jre-6
pkg list /runtime/java/jre-6
pkg list runtime/java/jre-6
pkg list jre-6
In summary, for most uses, you can ignore everything to the right of the @
symbol in the FMRI, and to the left of any forward slashes (/
) in the FMRI, in order to get a short form name.
The bad news is that, sometimes, a short form that you might expect to work does not work. So, if an abbreviated form turns up nothing for a command, make sure to try the long form as well, and/or wildcards.
Tip
For most purposes, you can ignore the version part after the @
sign, even for long form purposes. The version part only really matters at times when you have to consider whether or not to update a package.
Note that, at the current moment in time, Oracle uses package naming and version information inconsistently.
First of all, the same package may have two different long forms. Taking a package at random, let's examine the installed
gzip
package. The first two listings in the following output show it as /compress/gzip
.
However, the full information on the package, via pkg info
, gives a longer reference for the
gzip
package (calling it an FMRI), with the additions of /solaris
and extra numbers in the version part of it. More details on version numbers will be given later on, in the next section.
Once again, there is good news and bad news. The bad news is that these inconsistencies exist when they shouldn't. The good news is that the pkg
system is somewhat flexible about accepting any of the variants as input most of the time. So, reading the output becomes simpler, if you can train yourself as to which parts can be safely ignored.
A comparison between the different output types is as follows:
$ pkg search gzip PACKAGE pkg:/compress/gzip@1.3.5-0.175.0.0.0.2.537 $ pkg list gzip NAME VERSION compress/gzip 1.3.5-0.175.0.0.0.2.537 $ pkg info gzip|grep FMRI FMRI pkg://solaris/compress/gzip@1.3.5,5.11-0.175.0.0.0.2.537:20111019T091246Z
As mentioned previously, the
@
version parts can usually be ignored. So the thing of interest then becomes the //solaris
component. This is an artifact of the network source of the package.
In this case, solaris
is not the product or package name, but what Oracle chose to name the publisher of this set of packages in its repository. The full output of the
pkg list gzip
command would show this as the case.
99 percent of Solaris users will most likely be using only one publisher (solaris
), so this component can usually be ignored.
Note that the version indicator (the stuff to the right of the
@
sign) must be strictly numeric at this time. This may cause problems if one tries to match some "freeware" programs up with this scheme, where letters (a, b, c, and d) are used as a part of the version number scheme as well.
As demonstrated earlier, the version part is unfortunately used inconsistently by Oracle at this time.
Some subcommands of the pkg
command display it as @{release}-{branch}
. For example:
pkg:/compress/gzip@1.3.5-0.175.0.0.0.2.537
For other subcommands, the same package may be displayed as @{release},{build}-{branch}
. For example:
pkg://solaris/compress/gzip@1.3.5,5.11-0.175.0.0.0.2.537
For packages provided with Solaris itself, the {build}
section (here, 5.11
) is described by Oracle as being the version of the OS under which it was compiled, in this case, Solaris 11, or SunOS 5.11.
The 0.175 in Oracle Solaris packages represents a particular build number of Solaris branch that folks external to Oracle might think of as the subrelease identifier or perhaps similar to a patch level. All packages associated with that subrelease of Solaris seem to get a branch identifier mostly in the same numeric range. An earlier release of Solaris 11 seems to have mostly 0.151 as its associated branch identifier, whereas the 11/11 release seems to mostly have 0.175.0 as a branch identifier Solaris 11.1 uses 0.175.1.
In this section we'll first summarize the old system of packages and patching before covering how they have changed.
The old style of packages had only three basic pieces of information for a sysadmin to care about:
The package name; for example,
SUNWcsr
The package description/name; for example, core binaries
The package version (and corresponding patch level)
All of this information was mostly contained in the package itself. To update it, you should either have installed an entirely new version of the package, or applied a patch, which would have updated one or more packages to different patch versions.
Prior to Solaris 11, patches were downloaded and applied manually unless you used a tool such as PCA or Sun's smpatch utility. Then, even if you applied the package, there was a slight disconnect between the package version and the patch level of a package.
Previously, new Sun/Oracle packages were copied from a DVD (physical or virtual image) and then manually applied. New vendor packages were similarly copied, or sometimes downloaded, unless you had a network-aware tool such as pkg-get, which is similar to Debian's apt-get.
Now, things are very different. Almost every facet mentioned previously has changed with Solaris's new pkg
system.
With IPS, new OS patches, packages, and even new minor OS versions are all handled via a unified mechanism. If there is a bugfix available for a package, it comes in the form of a newer version of that package. There are no more hidden patch levels internal to a package; variants of a particular version of a package generate a new branch of a version. It is no longer possible to have multiple patches applied to a single package; you always have only a single version of it, with a single, unique number-based identifier for it.
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/zones
command fails to return a valueThe
pkg list /system/zones
command 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/zones
command returns a matchThe
pkg list system/zones
command returns a matchThe
pkg search pkg.fmri:zones
command returns a matchThe
pkg list zones
command 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 zonestat
pkg search /usr/bin/zonestat
Unfortunately, neither of the following will work:
pkg search bin/zonestat
pkg 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/make
pkg list developer/build/make
pkg list build/make
pkg list '*/make'
pkg list '*make*'
pkg list make
The following commands will not work to match pkg:/developer/build/make
:
pkg list /build/make
pkg 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-desktop
group/system/solaris-large-server
group/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 Name
pkg 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.
At the current point in time, there are not too many public IPS repositories running. That said, it is good to know how to query them. As briefly mentioned just now, the
pkgrepo
tool is the command to interact with repositories at the top level.
To find the repositories that your system is currently using, you can use the following command:
pkg publisher
You can then take the URI field from each of the output lines and run pkgrepo
against it.
Official Oracle URIs for repositories are usually of the following format:
http://host.on.network/publisher/XXXXXXX
Once you have the URI of the repository you are interested in, you can query it for high-level information such as how many total packages are in the repository and the last time it was updated, as shown in the following output:
pkgrepo info -s http://pkg.oracle.com/solaris/release
This command will lead to the following output:
PUBLISHER PACKAGES STATUS UPDATED solaris 4292 online 2011-11-09T15:23:27.281209Z
Do note that, for some reason, Oracle has chosen the publisher in this case to be solaris
, rather than oracle
, so there is some unexpectedness in naming choices to get used to.
One advantage of using the
pkgrepo
command over the pkg
command is that you can query packages from repos that are not currently configured as your current installation source.
pkgrepo list -s http://pkg.oracle.com/solaris/release \ 'group/system/*'
While it is also possible to do a similar search with the pkg search -s http://...
command, the output format of pkgrepo
, in this case, is more readable, at least to me.
You can also use pkgrepo
to get a list of potentially useful properties that the administrators of the repo may have set (somewhat akin to ZFS properties, using zfs get
).
For example, the following command lets you know that there is a mirror of the Oracle repository available:
pkgrepo get -p all -s http://pkg.oracle.com/solaris/release \ repository/mirrors
The preceding command will lead to the following output:
PUBLISHER SECTION PROPERTY VALUE solaris repository mirrors (http://pkg-cdn1.oracle/com/solaris/release/)
At some point, you may wish to create your own IPS repository, particularly if you wish to have some custom scripts applied to automated installs. The old jumpstart "finish script" concept no longer exists; instead, hooks are given to load in custom services, which must be referenced through custom packages. Or, you may simply wish to have a local copy of the Solaris packages available.
Before you can create a package, you must first create a local repository. The old workflow of generating a single file.pkg
to distribute is gone. The new tools are geared towards uploading files directly into a repository.
Happily, creating a simple repository with no access controls is relatively easy, so long as you follow the guidelines of always doing your packaging work on the same system that your repository lives on.
To make a repo in a designated directory, such as /var/pkgrepo
, you just need to initialize the directory with the magic tool, as follows:
pkgrepo create /var/pkgrepo
This creates the directory, and a single master file inside it, called pkg5.repository
.
If you plan on serving many files to many machines, Oracle recommends that you create a separate zfs
filesystem for it, with access time (atime
) turned off, for example:
zfs create somepool/repo zfs set atime=off somepool/repo
Once you have created the basic top-level repo, you will want to create a publisher section. This can be done for your own company or for a copy of outside repositories, or both.
The publisher designation for Solaris packages is not oracle.com
but solaris
. Therefore, if you plan to create a local copy of Solaris packages, you will effectively be setting up a mirror for the publisher named solaris
.
Once you have created the top-level repository, use the pkgrecv
command to mirror all packages in the Oracle repository to it. We can use the following command:
pkgrecv -s http://pkg.oracle.com/solaris/release -d /var/pkgrepo '*
Once that is done, you can override the default settings for where the system gets the Solaris packages by using the following command:
pkg set-publisher -g http://your.repo.url solaris
Unlike the SVR4 pkg
creation tools, you should normally dedicate an entire, untouched directory tree for your package creation efforts.
For clarity, let's presume a standard location for this that we'll call /stageroot
.
Then, when you would normally install a program to /usr/local/bin/prog
, for packaging purposes, it will get installed to /stageroot/usr/local/bin/prog
.
Once you have assembled all the contents of your potential package under /stageroot
, you must then generate a manifest for it with the following command:
pkgsend generate /stageroot >mypkg.mf
Next, you need to give the package an identity. This can be done by adding a single line, such as the following command, anywhere in the mypkg.mf
file to designate its identity:
set name=pkg.fmri value=pkg://yourcompany.com/prog@1.0
Keep in mind that the
value
field can be as simple, or as complicated, as you like, within the boundaries of the IPS package naming scheme previously mentioned. For example, you may instead choose it to be pkg://yourcompany.com/utils/lowlevel/prog@1.0.1-75
.
Now that you have a complete manifest file and a staged tree of files for your package contents, you may integrate your package into your repository. This only takes one command, as follows:
pkgsend publish -s /var/pkgrepo -d /stageroot mypkg.mf
Tip
The
pkgsend
command will happily publish the exact same package collection multiple times, resulting in redundant packages in your repository. Be sure you have your versioning correct.
If the
publish
subcommand is completed successfully, you should be able to see the new version of your package, with the following command:
pkgrepo -s /var/pkgrepo list
Technically, it is quite possible to publish a package from normally installed program locations (that is to say, without a /stageroot
prefix). Unfortunately, the IPS tools do not support the same functionality as the old pkgproto
utility, which used to let you pass it a simple list of files and would then do the rest. This was allowed for relatively safe automated strategies such as:
find /usr/local -newer xyz | pkgproto >prog.template
Instead, with IPS, you would be required to hand-edit the manifest to have the needed paths in it, after which you could run the publish
step without the -d
option. However, this may lead to the creation of incomplete packages. Therefore, it is recommended that you use the method just explained, using the full but previously empty /stageroot
.
Once you can see your new packages successfully with a local test via pkgrepo
, it is appropriate to open up access to the repository for other machines that need it.
The simplest way to do that is to share that directory via NFS and allow machines in your network to use your new repository. This can be done with the help of the following command:
pkg set-publisher -O /net/servername/var/pkgrepo yourcompany.com
Alternatively, you can set up a full IPS package server by configuring and enabling the application/pkg/server
SMF service, as follows:
svccfg -s application/pkg/server setprop pkg/inst_root=/var/pkgrepo svccfg -s application/pkg/server setprop pkg/readonly=true //optionally, change the port number it runs on, with svccfg -s application/pkg/server setprop pkg/port=(someportnum) svcadm refresh application/pkg/server svcadm enable application/pkg/server
Tip
If you have stuck with our example location of /var/pkgrepo
, you will not actually have to mess around with svccfg
properties. The default pkg/inst_root
location is /var/pkgrepo
. The default port is 80.
If you follow the SMF route, you will be able to configure clients with the following command:
pkg set-publisher -O http://your.server yourcompany.com
Once you have set a publisher entry for your custom repository, you should be able to run normal pkg
commands on any client machines, thus:
pkg install prog
Or, you can use:
pkg install pkg://yourcompany.com/prog
As mentioned in the first half of this chapter, patching as a separate process no longer exists. To patch, you must upgrade to a newer version of the software package in question.
At a simple level, to update all packages on your system, if newer versions are available on your configured repository, you can just run the following command:
pkg update
If you are unsure whether you need to run an update or would like to know which packages need an update first, you can use the following command:
pkg list -u
If you want to downgrade a package, or similarly, do not want to upgrade it to the latest version, you can also call the update subcommand with a specific version of a package if it is available, for example:
pkg update somepkg@1.2.3
That being said, Solaris packages are usually locked into a particular set of revisions via a meta package called entire. It is normally not possible to manually install a package from a newer release of Solaris 11: one must first explicitly upgrade to a newer entire package. To see the available versions, use the following command
pkgrepo list -s (repo_url) entire
If you have chosen to previously set up your own repository for Solaris, (as mentioned in the first part of this chapter, by downloading your own Solaris Repository Image from Oracle), you might add your own local repository. As pkg update
and pkg install
will by default install the latest version of a package, if it finds that multiple are available, there is not much risk involved in having this available as a
fallback.
Here's an example of configuring your own repository to be the primary source for Solaris packages, with the Oracle site as a backup:
pkg set-publisher -g http://your.site solaris pkg set-publisher -m http://pkg.oracle.com/solaris/release solaris
Gaining access to the latest versions of Solaris packages (that is, patch updates) requires a support contract to get access to a private repository. Full details for this can be found at:
The new IPS package tools are a drastic change for anyone used to the long-time standard of SVR4 style packages in Solaris. Where to get them has changed. How to get them has changed. How to install and uninstall them has changed. How to list and query them has changed. Even the style of naming packages has changed.
There are some similarities to popular Linux package management tools but there are differences as well. IPS is truly a system unto itself and requires some unique learning.
While it is possible to continue using the old tried-and-true SVR4 packaging for in-house software, being a Solaris 11 system administrator requires learning at least the basics covered in the first half of this chapter. While it may not be required to know how to set up and create your own packages, it is critical that the System Administrator understands the basics of IPS package administration.
For a quick reference of IPS commands, see the Appendix A, IPS Package Reference, part of this book.