Table of Contents
Once you have built and installed a package, you can create a binary package which can be installed on another system with pkg_add(1) This saves having to build the same package on a group of hosts and wasting CPU time. It also provides a simple means for others to install your package, should you distribute it.
To create a binary package, change into the appropriate directory in pkgsrc, and run make package:
#cd misc/figlet#make package
This will build and install your package (if not already
done), and then build a binary package from what was
installed. You can then use the pkg_* tools to manipulate it.
Binary packages are created by default in /usr/pkgsrc/packages, in the form of a
gzipped tar file. See Section B.2, “Packaging
figlet” for a continuation of the above misc/figlet example.
See Chapter 14, Submitting and Committing for information on how to submit such a binary package.
If you want to get a full set of precompiled binary packages, this section describes how to get them. Beware that the bulk build will remove all currently installed packages from your system! Having a FTP server configured either on the machine doing the bulk builds or on a nearby NFS server can help to make the packages available to everyone. See ftpd(8) for more information. If you use a remote NFS server's storage, be sure to not actually compile on NFS storage, as this slows things down a lot.
You may want to set things in /etc/mk.conf. Look at pkgsrc/mk/defaults/mk.conf for details
of the default settings. You will want to ensure that
ACCEPTABLE_LICENSES meet
your local policy. As used in this example, _ACCEPTABLE=yes accepts all licenses.
PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
BSDSRCDIR= /usr/src
BSDXSRCDIR= /usr/xsrc # for x11/xservers
OBJHOSTNAME?= yes # use work.`hostname`
FAILOVER_FETCH= yes # insist on the correct checksum
PKG_DEVELOPER?= yes
_ACCEPTABLE= yes
In pkgsrc/mk/bulk, copy
build.conf-example to
build.conf and edit it,
following the comments in that file. This is the config
file that determines where log files are generated after
the build, where to mail the build report to, where your
pkgsrc tree is located and which user to
su(8) to to do a
cvs
update.
It is possible to configure the bulk build to perform
certain site specific tasks at the end of the pre-build
stage. If the file pre-build.local exists in /usr/pkgsrc/mk/bulk it will be executed
(as a sh(1) script) at the end of the usual pre-build
stage. An example use of pre-build.local is to have the
line:
#echo "I do not have enough disk space to build this pig." \ > pkgsrc/games/crafty-book-enormous/$BROKENF
to prevent the system from trying to build a particular package which requires nearly 3 GB of disk space.
As /usr/pkg will be
completely deleted at the start of bulk builds, make sure
your login shell is placed somewhere else. Either drop it
into /usr/local/bin (and
adjust your login shell in the passwd file), or
(re-)install it via
pkg_add(1) from
/etc/rc.local, so you can
login after a reboot (remember that your current process
won't die if the package is removed, you just can't start
any new instances of the shell any more). Also, if you use
NetBSD earlier than 1.5, or you still want to use the
pkgsrc version of ssh for some reason, be sure to install
ssh before starting it from rc.local:
( cd /usr/pkgsrc/security/ssh ; make bulk-install )
if [ -f /usr/pkg/etc/rc.d/sshd ]; then
/usr/pkg/etc/rc.d/sshd
fi
Not doing so will result in you being not able to log in via ssh after the bulk build is finished or if the machine gets rebooted or crashes. You have been warned! :)
Make sure you don't need any of the packages still installed.
During the bulk build, all packages will be removed!
Be sure to remove all other things that might interfere
with builds, like some libs installed in /usr/local, etc. then become root and
type:
#cd /usr/pkgsrc#sh mk/bulk/build
If for some reason your last build didn't complete (power failure, system panic, ...), you can continue it by running:
#sh mk/bulk/build restart
At the end of the bulk build, you will get a summary via
mail, and find build logs in the directory specified by
FTP in the build.conf file.
The bulk builds consist of three steps:
The script updates your pkgsrc tree via (anon)cvs, then cleans out any broken distfiles, and removes all packages installed.
This is basically “make bulk-package” with an optimised order in which packages will be built. Packages that don't require other packages will be built first, and packages with many dependencies will be built later.
Generates a report that's placed in the directory
specified in the build.conf file named broken.html, a short version of
that report will also be mailed to the build's
admin.
During the build, a list of broken packages will be
compiled in /usr/pkgsrc/.broken (or .../.broken.${MACHINE} if OBJMACHINE is set), individual build logs
of broken builds can be found in the package's directory.
These files are used by the bulk-targets to mark broken
builds to not waste time trying to rebuild them, and they
can be used to debug these broken package builds later.
Currently, roughly the following requirements are valid for NetBSD 2.0/i386:
10 GB - distfiles (NFS ok)
8 GB - full set of all binaries (NFS ok)
5 GB - temp space for compiling (local disk recommended)
Note that all pkgs will be de-installed as soon as they are turned into a binary package, and that sources are removed, so there is no excessively huge demand to disk space. Afterwards, if the package is needed again, it will be installed via pkg_add(1) instead of building again, so there are no cycles wasted by recompiling.
If you don't want all the pkgs nuked from a machine (rendering it useless for anything but pkg compiling), there is the possibility of doing the pkg bulk build inside a chroot environment.
The first step to do so is setting up a chroot sandbox,
e.g. /usr/sandbox. After
extracting all the sets from a NetBSD installation or doing
a make distribution
DESTDIR=/usr/sandbox in /usr/src/etc, be sure the following items
are present and properly configured:
Kernel
#cp /netbsd /usr/sandbox
/dev/*
#cd /usr/sandbox/dev ; sh MAKEDEV all
/etc/resolv.conf
(for security/smtpd and mail):
#cp /etc/resolv.conf /usr/sandbox/etc
Working(!) mail config (hostname, sendmail.cf):
#cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
/etc/localtime (for
security/smtpd):
#ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
/usr/src (system
sources, for sysutils/aperture, net/ppp-mppe):
#ln -s ../disk1/cvs .#ln -s cvs/src-1.6 src
Create /var/db/pkg
(not part of default install):
#mkdir /usr/sandbox/var/db/pkg
Create /usr/pkg (not
part of default install):
#mkdir /usr/sandbox/usr/pkg
Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:
#cd /usr/sandbox/usr#cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
Do not mount/link this to the copy of your pkgsrc tree you do development in, as this will likely cause problems!
Make /usr/sandbox/usr/pkgsrc/packages
and .../distfiles point
somewhere appropriate. NFS- and/or nullfs-mounts may
come in handy!
Edit /etc/mk.conf,
see Section 5.3.1.1,
“/etc/mk.conf”.
Adjust mk/bulk/build.conf to suit your
needs.
If you have set CVS_USER in build.conf, make sure that account
exists and can do a cvs
${CVS_FLAGS} update properly!
When the chroot sandbox is setup, you can start the build with the following steps:
#cd /usr/sandbox/usr/pkgsrc#sh mk/bulk/do-sandbox-build
This will just jump inside the sandbox and start
building. At the end of the build, mail will be sent with
the results of the build. Created binary pkgs will be in
/usr/sandbox/usr/pkgsrc/packages
(wherever that points/mounts to/from).
In addition to building a complete set of all packages
in pkgsrc, the pkgsrc/mk/bulk/build script may be used
to build a subset of the packages contained in pkgsrc. By
setting defining SPECIFIC_PKGS
in /etc/mk.conf, the
variables
SITE_SPECIFIC_PKGS
HOST_SPECIFIC_PKGS
GROUP_SPECIFIC_PKGS
USER_SPECIFIC_PKGS
will define the set of packages which should be built. The bulk build code will also include any packages which are needed as dependencies for the explicitly listed packages.
One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
periodically to have a complete set of the binary packages
needed for your site available without the overhead of
building extra packages that are not needed.
After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set of the resulting binary packages to assist in installing packages on other machines. The pkgtools/cdpack package provides a simple tool for creating the ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that keeps all the dependencies for given package on the same CD as that package.
Complete documentation for cdpack is found in the
cdpack(1) manpage. The following short example assumes that
the binary packages are left in /usr/pkgsrc/packages/All and that
sufficient disk space exists in /u2 to hold the ISO 9660 images.
#mkdir /u2/images#pkg_add /usr/pkgsrc/packages/All/cdpack#cdpack /usr/pkgsrc/packages/All /u2/images
If you wish to include a common set of files
(COPYRIGHT, README, etc.) on each CD in the
collection, then you need to create a directory which
contains these files. e.g.
#mkdir /tmp/common#echo "This is a README" > /tmp/common/README#echo "Another file" > /tmp/common/COPYING#mkdir /tmp/common/bin#echo "#!/bin/sh" > /tmp/common/bin/myscript#echo "echo Hello world" >> /tmp/common/bin/myscript#chmod 755 /tmp/common/bin/myscript
Now create the images:
#cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
Each image will contain README, COPYING, and bin/myscript in their root
directories.