|This page documents building an older way to build packages. It has been superseded by: https://pkgsrc.joyent.com/docs/building/|
The pk framework helps manage daily tasks related to pkgsrc binary packages. The config files included with the pk framework plug into the pkgsrc configuration to aid in building on SmartOS when using standard pkgsrc workflows. However, you can also wrap them around pkgsrc tools and use them to repeatedly manage predefined sets of packages.
|The pk framework does currently support full bulk builds. In other words, build the complete pkgsrc tree.|
The best way to build pkgsrc packages on SmartOS and/or the Joyent Public Cloud, is to start with a machine provisioned using a 'base' or 'base64' image (these very previously known as 'smartos' and 'smartos64'). Other images will also work but will include extra packages you may or may not need (as far as pkgsrc is concerned).
Note: if you use the previous (smartos/smartos64) images, the GCC compiler available there cannot automatically build 32bit or 64bit objects as needed, and need to build something manually (outside of pkgsrc control), make sure to pass -m64 to GCC in order to get 64bit objects. The base64 image uses GCC 4.7, which finally supports a default 64bit target, so you don't need to do that. (Also, building through pkgsrc automatically adjusts the flags as needed too, regardless of the GCC version.)
|For these instructions, the parent path is arbitrary. However, you will need to adjust a config file if you do not plan to use the default path of /opt/pkgsrc.|
- Ensure git is installed and install the GNU Compiler Collection (gcc) from the repository.
- Clone the main pkgsrc tree from github.
This will take several minutes to complete.
- Install pkgsrc modules.
This is optional but recommended. Joyent uses both repositories as submodules when building out the standard package set for SmartOS. If you only care about packages available in the main pkgsrc repository, you can safely ignore these submodules.
- Clone the pk framework from github.
- Add the pk framework path to your PATH environment variable.
- Open /opt/local/etc/mk.conf and ensure all values are set correctly. You do not need to change anything unless you install pk framework in a path other than the default. If you install pk framework in a different directory, adjust the OVERLAY path accordingly.
This ensures the pk configuration files are sourced properly by pkgsrc.
You can test the install by running this command:
If successful, you will see something similar to the following:
You can define many of the variables internally used in pk through a simple config file. This allows you to avoid passing in an unwieldy number of options on the command line if you are running the pk framework in a non-standard way. Use the configuration file found at config/pkrc.example as a template. You can create a similar file at /.pkrc or copy the example file as @/.pkrc@ and change as needed.
Here is an example of building a simple package with no dependencies.
|For now, you can safely ignore the warning about the availability of ZFS rollback. See below for more information.|
The proper way to pass packages to the pk build command is to use full PKGPATH notation. In other words, the relative category/package_name path under the pkgsrc tree. Look under /opt/pkgsrc.
In the above example, the first thing pkgsrc does is to determine that gmake is needed to build this particular package. At that point, it builds the package and installs it, resulting in a binary for each package. Packages are stored in a PACKAGES directory, which is a variable based on the current pkgsrc release and the compiler chosen. In this example, packages are stored in /opt/pk/packages/2012Q1/i386/All/.
|You can see the PACKAGES path by using pk info. See the above pk info example.|
Once the build completes, nothing is installed except package dependencies. You can use packages that you build by adding the path to your packages in your pkgin setup. For example:
|If more than one version of a package exists across all registered repositories, pkgin will default to the latest version.|
If you need to install an earlier version of a package, specify the full version binary or use the "greater than" (>) or "less than" (<) symbols to install an earlier version than what you specify. The following commands will install PHP 5.2 before the current version of PHP 5.3:
You can also use pkg_add with an absolute path to the package binary files or set PKG_PATH to the repository path before you call pkg_add. The following lines perform the same action:
|If ZFS delegation (TBD) is not available, anything installed explicitly or as a dependency will stay in place until you remove it yourself.|
The packages built by pkgsrc are just files on disk. So, you can use the web server of your choice to serve up the packages you build. The pk script can rsync the binary packages over to a different system.
When using Joyent Public Cloud use the base 1.7.x image. You can upgrade previous smartos JoyentCloud machines to 2012Q1 by installing the 'smtools' package from the 2012Q1 package set, and calling the 'sm-rebuild-pkgsrc' script contained in the package. Pick the package set that matches the architecture you need (i.e. 'i386' for the 32bit smartos/base image, and 'x86_64' for the 64bit smartos64/base64 image):
and follow the instructions.