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.

pkgrecv -s http://pkg.oracle.com/solaris/release -d /var/pkgrepo '*

pkg set-publisher -g http://your.repo.url solaris

pkgrepo add-publisher -s /var/pkgrepo "yourcompany.com"

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/[email protected]

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/[email protected].

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

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

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