pkgsrc is a framework for building over 17,000 open source software packages. It is the native package manager on SmartOS, NetBSD, and Minix, and is portable across 23 different operating systems. Use one package manager across all of your systems!
Joyent provide binary packages for SmartOS/illumos, Mac OS X, and Linux.
This tutorial will use augeas as an example, as it happens to be a package that was recently created.
First, install the
pkgtools/url2pkg package, as this massively simplifies the
task in hand.
Then create a new package directory, choosing the most appropriate category (in
devel), then run
url2pkg giving it an argument of the source
First it will open an editor session on
Makefile. You should customise a few
MAINTAINER either to your email address, or to
pkgsrc-users@NetBSD.org if you do not want to be the primary maintainer of
Write a brief one-line
COMMENT describing what the package is.
LICENSE to a list of the licenses the package is made available under
mk/license.mk for an available list).
Here is what was used for augeas:
After writing the file and exiting the editor session,
url2pkg will continue
and download the source tarball, create the
files, then unpack the source ready for you to start applying patches.
At this point you should edit
DESCR and put in a few lines which describe the
The general cycle will then be:
Try building the package with
If something goes wrong, modify the
Makefile or patch the source with
until the package builds. Before running your first
bmake, I would strongly
PKG_DEVELOPER=yes to your
mk.conf to turn on a lot of
augeas, a couple of things were needed.
The first problem hit was:
In this case pkgsrc gives us a very helpful message telling us about the
problem and what needs to be done to fix it (unfortunately not all problems are
handled this well!). As
configure is pretty important, we'll need to patch
This is the usual way of handling patches (ensuring
This was enough to fix the
Dependencies in pkgsrc are primarily handled in two ways, either with a
buildlink file when depending upon shared libraries or particular
infrastructure, or a simple
DEPENDS line to pull in a required package.
The first dependency problem was:
Ok, so this package depends upon readline. As that is a library, we are
looking for a suitable
buildlink3.mk file, and one of the easiest ways to do
To use that file, all we need to do is add an
.include line at the bottom of
Makefile, just above the
bmake clean; bmake to try again. The next problem was:
Ok, so similar method:
configure message said libxml-2.0, so we'll pick
you want to be more thorough you can look at the
PLIST files for each of the
possible candidate packages - experience often comes into play here.
The bottom of
Makefile now looks like this:
You'll note that we try to keep all includes other than
bsd.pkg.mk (which is
special) sorted alphabetically.
After this, the package finally completes a
bmake with no problems. The
final step is to get the
install phase working.
First we need to run a
stage-install which will execute
make install into a
This will almost certainly fail as we haven't configured the
PLIST yet, so
pkgsrc has no idea what will be installed from this package.
However, now that we have a populated
DESTDIR, we can use the
target to generate it for us:
Finally, it's worth doing a full clean and install to ensure everything works as expected.
As we are installing a library package, we should provide a
file of our own so that other packages can depend on us correctly. Again,
there is a package that can help with this -
This will create a template file but you should read and edit, removing the
lines marked with
XXX and making any changes they recommend.
Once we have a working package it's worth doing a couple of checks to make sure everything looks ok:
We also should run
pkgtools/pkglint) which will perform some
sanity checks on our infrastructure files prior to us importing the package
into pkgsrc itself. In my case it pointed out some possible issues:
For the first issue, add
Makefile which will ensure that
the pkgsrc libtool is used (has better support for cross-platform issues), and
for the second, add a comment at the top of the file explaining what it is for,
After making those changes, everything looks great:
The final - and sometimes most challenging - part is to get your shiny new package integrated into pkgsrc. There are a few options:
Find a NetBSD developer who can review your package and put it straight into pkgsrc.
Get a pkgsrc-wip account and work on your packages there, before getting it reviewed and integrated.
If it's somewhat niche just publish it up on GitHub or similar for people to use, in a similar way to what we do with pkgsrc-joyent
This post only scratches the surface of adding a new package. pkgsrc provides a huge amount of infrastructure to help get packages working on multiple platforms, and there are lots of options available.
Certain parts of the infrastructure, like buildlink, are very complicated, and for more in-depth information you should refer to the pkgsrc guide.
The best way is often just to look at other packages to see what they do and re-use useful bits you find. With 13,000+ packages there is almost certainly another package which does something similar to what you need!