-
Notifications
You must be signed in to change notification settings - Fork 9
Home
The pk framework is intended to help with daily tasks related to pkgsrc binary package management. It comes with helpful config files that plug into the pkgsrc configuration to aid in building on SmartOS when using standard pkgsrc workflows, but can be used to wrap around pkgsrc tools and manage predefined sets of packages repeatedly.
Currently there is no support for full bulk builds (i.e build the whole of pkgsrc), and the entire project is a heavy work-in-progress.
The best way to build pkgsrc packages on SmartOS and/or the Joyent Public Cloud, is to start with a machine provisioned using the smartos or smartos64 image. Other images will do fine, they just come with extra packages installed (as far as pkgsrc is concerned).
Also, it doesn’t matter whether you pick the 32bit smartos image, or the smartos64 64bit one, because the default behavior of GCC on SunOS based platforms (including SmartOS) is to always build 32bit objects by default, and cross-build 64bit ones if -m64 is passed (pkgsrc intervenes there by bootstrapping to a preferred ABI, but the ability to switch stays).
First, make sure git is installed, and get the compiler suite from the package repository:
pkgin in scmgit-base gcc-compilerGet the main pkgsrc tree (this will take a while):
cd /opt && git clone git://github.com/mamash/pkgsrc.gitThe (currently) stable pkgsrc_2011Q4 branch will be checked out by default. The parent path is arbitrary, though you will need to adjust one config file if you do not want the default /opt/pkgsrc path.
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, feel free to ignore both though.
The joyent repository holds packages that do not exist in upstream pkgsrc at all, for whatever reason. Over time, many will make a transition to either pkgsrc or pkgsrc-wip, while others may stay here. This repository also gives a hint how to create your own set of packages that you do not plan on committing to any upstream.
The wip repository holds a mirror of the pkgsrc-wip project, a nightly conversion from the CVS repository upstream. The joyent branch holds some modifications from Joyent.
cd /opt/pkgsrc && git submodule init && git submodule updateGet the pk framework:
cd /opt && git clone git://github.com/mamash/pk.gitThe parent path is entirely arbitrary, though you will need to adjust the main config file if you do not want the default /opt/pk path.
Add path to the pk script to your PATH environment:
sed -i'' '\,^PATH,s,$,:/opt/pk/bin,' ~/.profile && source ~/.profileOpen /opt/local/etc/mk.conf and make sure everything’s correct. Normally you don’t need to change anything. If you put pk in a different directory, adjust the OVERLAY path accordingly. This is to make sure the pk config files are sourced properly by pkgsrc.
Now run pk info. You should see something like this:
Current setup:
pkgsrc release : 2011Q4
prefix : /opt/local
prefix mounted : n/a
architecture : 32bitcompiler type : gcc
compiler path : /opt/local/bin/gcc
compiler version : 4.6.2
Many variables internally used in pk can be changed in a simple config file. See the config/pkrc.example file on how – just create a similar file at /.pkrc (or copy the example file as @/.pkrc@ and uncomment/change as needed). This way you can avoid having to pass many options on the command line, if you are running on a non-default kind of setup.
Let’s try a simple package that doesn’t have many dependencies, unzip:
[root@62f1b818-caa7-4cfa-b439-cfda2c67cea4 ~]# pk build archivers/unzip
20120327-103105: this is 2011Q4, gcc 4.6.2, 32bit ABI, for /opt/local
20120327-103105: skipping ‘zfs rollback’ functionality, ZFS not delegated properly
20120327-103105: * archivers/unzip
20120327-103106: * archivers/unzip: start
20120327-103336: archivers/unzip: BUILD_OK
20120327-103336: archivers/unzip: changed package files: unzip-6.0.tgz gmake-3.82nb3.tgz
For now, ignore the warning about zfs rollback not being available, more on that later. The proper way to pass packages to the pk build command is to use a full PKGPATH notation, i.e. the category/package_name relative path under the pkgsrc tree. Look under /opt/pkgsrc.
pkgsrc has figured out that gmake is needed to build this particular package, built it and installed. A binary package will be generated for each, and stored under PACKAGES, which is a variable based on the current pkgsrc release and the compiler chosen. In this environment (as shown under pk info above), it will be under /opt/pk/packages/2011Q4/gcc46/All/.
Except for dependencies, the final packages will not be installed when the build is done. To use packages that you pre-build conveniently, add the path to your packages to your pkgin setup:
echo 'file:///opt/pk/packages/2011Q4/gcc46/All' >> /opt/local/etc/pkgin/repositories.conf
pkgin -f updateNote, however, that pkgin will by default auto-pick the latest version of any package, if more than one version exists across all registered repositories. If you need a lower version installed, specify the full version, or use a lower/greater kind of notation. All these commands will favor PHP 5.2 before the default PHP 5.3:
pkgin in php-5.2.17
pkgin in php-5.2
pkgin in 'php<5.3'Also, you may use pkg_add with absolute path to the package binary files, or set PKG_PATH to the repository path before you call pkg_add. These two lines are equal:
pkg_add /opt/pk/packages/2011Q4/gcc46/All/unzip-6.0.tgz
pkg_add /opt/pk/packages/2011Q4/gcc46/All/unzip
PKG_PATH=/opt/pk/packages/2011Q4/gcc46/All pkg_add unzipNote that if no zfs delegation (TBD) is available, anything installed explicitly, or as a dependency, will stay in place until you remove it yourself.
pkgsrc packages are just files on disk, hence any web server will do as a means of serving the packages to public or private consumers. The pk script can rsync the binary packages over to a different system, and more documentation will follow here on that.
TBD
TBD