Design, Implementation and Operation of
NetBSD Base System Packaging
Yuuki Enomoto∗

Abstract
It is believed that UNIX operating system (OS)built on fine granular small parts is preferable to one
built on the traditional large tarballs in order to support speedy security update, easy replacement androllback of specific parts. In Linux distributions, thesystem are already divided into many small packages.
On the other hand, BSD Unix variants are behindthe curve on the base system packaging. To improve
NetBSD base system granularity, we propose a framework for OS base system packaging. We have developed a software “basepkg” by making the best use of
pkgsrc framework and operate an experimental basepackage distribution server to evaluate our softwarein realistic environment. It is shown that replacement of a few OS granular parts is clearly faster andcan provide extra useful functions for NetBSD users
and customers.
Key words: Unix, NetBSD, Open Source Software,
System Management

1

Background

Historically operating system (OS) has been managed on one source tree and the source tree set has
been distributed.
In this quarter century, either of a large or smallarchive or the combination is used for OS distribution.
∗ Chitose Institute of Science and Technology, e-mail:mail@e-yuuki.org† Chitose Institute of Science and Technology, e-mail: kfukama@photon.chitose.ac.jp

Ken’ichi Fukamachi†”tarball” (which extension is known as ”.tgz”) is
one of typical large archive formats. BSD UNIX distributes the base system as a set of tarballs where theterm “base system” implies a set of programs oﬃcially maintained and distributed by the project. In almost cases, OS base system distribution is divided byroles to a set of tarballs such as ”base.tgz” (mandatory for the operating system), ”comp.tgz” (compiler
tools), ”man.tgz” (manual) and so on.
There is another classification such as the base system or 3rd party software. Historically BSD UNIXconsiders that the system consists of the following
two categories: (1) the base system built from theoﬃcial source tree and (2) 3rd party software notcontained on the source tree. Usually the latter 3rdparty software are managed as a set of small archives
called as “package” where this “package” implies acontainer which consists of software, documentation,
configuration files and this package’s meta data required to operate in installation and de-installation.
Each package role, format and manager diﬀers fromone Unix OS to another. Table 1 shows a list of OS,
package format and package manager.
Historically BSD Unix has been developed in its
own source tree including kernel, general command-

nameformatmanager

FreeBSDNetBSD
DebianRed Hat
openSUSE

txz
tgz
deb
rpm
rpm

pkg
pkg install
apt
yum
zypperTable 1: List of OS, package format and the manager

s, configuration files, and manuals. “Linux” distribution is the opposite. What we call “Linux” wasreleased as just a kernel with a few core programs.
Accidentally, Linux distributions needed to assemble
a lot of system utilities in order to build a whole Unix clone system. For that reason, the base systemmanagement based on a lot of small packages wasinevitable and a good idea for Linux distributions.
Major Linux distributions such as Debian and Red
Hat Enterprise Linux are already divided into manysmall packages. These OS’s can manage both its
own base system and third-party software throughits package manager.
On the other hand, BSD Unix such as FreeBSD and NetBSD have each package framework e.g.
ports(7) and pkgsrc(7), but they have been used
only for third-party software management.
However today, for users and customers, it is betterthat OS can be assembled on a lot of small parts
easily added or removed. It is suitable especially for
rapid security update, easy replacement and rollbackof specific parts. In this paper we call this granularbase system building “base system packaging”.
To implement a granular NetBSD base system withfeatures mentioned above, we have developed a basesystem packaging utility “basepkg” for NetBSD.
The rest of this paper is organized as follows. In
Chapter 2, we review idea and technique for software packaging on UNIX. In Chapter 3, we describe
basepkg usage and the internals to show how to write
a sustainable shell program by making the best useof pkgsrc framework. We operate a base package distribution server experimentally and estimate the processing speed. In Chapter 4, we discuss several issues
to resolve in our system.

+COMPACT MANIFEST+MANIFESTbin/hangman

meta-data, JSON format
a subset of +MANIFEST
meta-data, JSON format
includes the whole information
binaryTable 2: Content of FreeBSD ports(7) package
hangman-0.9.2 12.txz.
In this section, we briefly summarize both 3rd party and base package system on FreeBSD and NetBSD
since the technical details are referenced in the latter
section.

2.1

Packages for 3rd Party Software

2.1.1

FreeBSD ports(7)We review FreeBSD ports(7) briefly since FreeBSD ports(7) system is the ancestor of NetBSD
pkgsrc(7).
FreeBSD ports(7) is 3rd party software management framework for “installing from source, andpackages, for installing from pre-built binaries”[2].
make(1) command is used to build a package. The
package consists of meta-data, compiled binaries,
configuration files and so on. Table 2 shows the content of “hangman” package. We can also use pkg(8)command to manage packages.
2.1.2

NetBSD pkgsrc(7)NetBSD pkgsrc(7) is a “ framework for building
and maintaining third-party software on NetBSD andother UNIX-like systems.”[3]. Initially pkgsrc(7)was a spin-oﬀ of FreeBSD ports(7). Hence, the fundamental usage of pkgsrc is similar to one of FreeBSD
2 Packages in BSD UNIXports(7).
Consider an example of “openssh” (pkgsrc/
As mentioned above, BSD UNIX consists of the
security/openssh) installation.
To build anbase system and optional 3rd party software not dis“openssh” package, you run make package intributed within the base system. The 3rd party softpkgsrc/security/openssh directory to generate
ware are called ports(7) on FreeBSD and OpenBSD,
the package openssh-7.5.1nb1.tgz in pkgsrc/
and pkgsrc(7) on NetBSD. We can use pkgsrc(7)packages/All directory. The package consists of1
on a lot of platforms .
the meta-data and the program content. Figure 1
1 http://www.pkgsrc.org/#platforms
shows the content of openssh-7.5.1nb1.tgz. The

openssh-7.5.1nb1.tgz/+CONTENTS+COMMENT+DESC+INSTALL+DEINSTALL+DISPLAY+BUILD_VERSION+BUILD_INFO+SIZE_PKG+SIZE_ALL
bin/
scp
sftp
ssh
...snip...

2.2

Package Details for Base System

2.2.1

FreeBSD PkgBase

It is traditional that FreeBSD uses make(1) to build
the kernel and userlands.
FreeBSD 11 introduced a base packaging mechanism PkgBase (packaged base) and a new package manager called “pkg” to manage the packages for bothbase and 3rd party software. PkgBase is a “beta feature in the FreeBSD 11 branch with r298107”[5] tomanage the packaged base system in using pkg(8).
The packages are created by running make packages
after make buildworld and make buildkernel operations. The format of these packages is same as oneof ports(7)’s package. In our environment FreeBSD base system comprises around 795 packages in thecase of amd64 architecture by default.
Figure 1: Content of of NetBSD pkgsrc package
In addition FreeBSD has another update utility
openssh-7.5.1nb1.tgz. Unlike FreeBSD ports, p- freebsd-update(8) that is “used to fetch, install,
kgsrc meta-data consist of small separate files.
and rollback binary updates to the FreeBSD base system” [6].
files beginning with the character “+” are meta-data 2.2.2 NetBSD syspkg
as same as ports(7). However unlike ports(7), the
NetBSD also uses traditional make in actual buildmeta-data consist of small separate files(Figure 1).
ing process of the kernel and userlands but NetBSD
To manage packages, we can use programs pre- has a top level dispatcher build.sh[7] to build crossfixed by pkg .
We run pkg add(1) to install, platform tool-chain, distributable tarballs and instalpkg delete(1) to de-install and pkg info(1) to dis- lation media and update the base system. It enables
play the information of the specified package. It is automatic cross build for all architectures NetBSD
important for us that several meta data files are used supports.
For base system packaging, NetBSD has a frameas running hooks in installation and de-installation
work called “syspkg” introduced at January 8, 2002
processes (Table 3).
by jwise @, syspkg is also merged into build.sh as afeature of the oﬃcial building process. NetBSD wiki says “There has been a lot of work in this area
+CONTENTS list of contents and other information
hooked within pkg add(1) and pkg delete(1)already, but it has not yet been finalized”[8].
modify ownership, groupship and permission
However syspkg is stagnant these years2 . There+INSTALLa shell script
has been several problems in syspkg for these years.
hooked within pkg add(1)+DEINSTALL+DISPLAY

a shell script
hooked within pkg delete(1)message shown after installation

Table 3: A part of meta data contained in NetBSD
pkgsrc package. They can be used to run hooks ininstallation/de-installation processes. For more details, see the online manual of pkg create(1)[4].

• syspkg database has been incomplete. See
syspkg files such as deps, comments, and attrs
under src/distrib/sets/ for more details.
2 For example, PR46937 (2012) is still open[9]. You can findsyspkg has not been maintained since February 21, 2010 byjudging log messages of distrib/syspkg directory in the sourcetree.

base-sys-usr-7.1.0.20170311.tgz/+CONTENTS+COMMENT+DESC+BUILD_INFO+PRESERVE
usr/
bin/
lib/
...snip...

Figure 2: Example format of a syspkg package
base-sys-usr-7.1.0.20170311.tgz. This format is
old pkgsrc one. Compare this with Figure 1.

• syspkg package format is not eﬀective today
since it lacks several contents the current pkgsrc defines. Figure 2 shows the content ofbase-sys-usr-7.1.0.20170311.tgz created byrunning build.sh syspkgs.
• We can overwrite or remove important files byaccident since +PRESERVE handling is incomplete.
Accidental removal should be prohibited.
+PRESERVE file implies “used to denote thatthe package should not be deleted”[4]. It is
used to indicate that this package should not be
removed. This property is important especiallyfor some critical packages e.g. etc-*.tgz whichcontains /etc/passwd, /etc/group and so on.
Also the overwrite should be prohibited. For
example, when we can install packages e.g.
etc-*.tgz using pkg add(1), existing /etc files
are overwritten by pkg add(1).

featuresyspkgbasepkg

languageinstall script
kernel package
imported to

Makefile and Bourne shell
none
none
oﬃcial source tree

Bourne shell
available
supporting GENERIC kernel
pkgsrc-wip

Table 4: Comparison of features between syspkg andbasepkg3

Basepkg

3.1

What is Basepkg?

We have developed a new framework “basepkg”
that can package NetBSD base system instead ofsyspkg. basepkg is an open source software distributed under BSD License. It published on github.
com/user340/basepkg in Oct 26, 2016. It is imported to pkgsrc-wip on May 19, 2017. The feature comparison between basepkg and syspkg are shown at
Table 4.
basepkg is a Bourne shell script. It analyzes metadata(s) and dispatches the corresponding pkg * programs. basepkg is just a shell script up to about
1000+ lines, well coded and documented, so it iseasy to read. basepkg makes the best use of pkgsrc framework as could as possible. In the caseof syspkg, make and shell programming styles are
mixed, and syspkg is at least 2 times larger thanbasepkg3 . Hence we consider basepkg is simpler andcan be maintained more easily than syspkg.
It is commonly seen that a program will be used
longer than the author expected. To write a sustainable program, basepkg is written to be POSIX
compliant and portable as could as possible. Infact the current coding is POSIX compliant except hostname(1), mktemp(1) and pkg create(1). We
use ShellCheck4 to validate and gain code quality andmake the code warning-less as could as possible.
basepkg package format is same as pkgsrc one.
Hence the packages can be managed by pkg * utilities.

It looks hard to directly fix syspkg framework
which consists of a lot of makefiles, scripts and undocumented data. For this reason, we have developed
3 The number of lines even in the two files ( src/distrib/
another base packaging mechanism as a third party syspkg/mk/bsd.syspkg.mk
and distrib/sets/regpkg ) aresoftware by using only syspkg meta-data and making about 1700 lines.
4 http://www.shellcheck.net/
the best use of pkgsrc framework.

$SRCDIR (/usr/src)
syspkg meta-data$SRCDIR/build.sh$SRCDIR/distrib/sets/mi$SRCDIR/distrib/sets/md.$ARCH+
basepkg patches$DESTDIR

basepkg.shbasepkg.sh temporary meta-data

genarete under $category/$package/+PERSERVE+BUILD_INFO+CONTENTS+DESC+COMMENTS+INSTALL+DEINSTALL

work/$category/FILES
work/$category/$package/PLIST

pkg_create ...

/usr/pkg/share/basepkg/packages/$VERSION/$ARCH-$MACHINE_ARCH/$package.tgz

Figure 3: Basepkg Processing Internals: basepkg requires the built NetBSD base system on DESTDIR
build.sh generates. It reads files at /usr/src/distrib/sets/ with basepkg patches. It parses files togenerate processed meta data temporarily and creates several pkgsrc style files under each package directory.
Finally it runs pkg create(1) to create the packages.
basepkg meta-data are derived from syspkg but
corrected. For example, package utilities should notremove a package holding a “+PRESERVE” file.
syspkg meta data are incomplete but basepkg has introduced a new essential5 list to handle the preservation more correctly. Also basepkg checks package
dependency more correctly.

3.2

Basepkg Processing Internals

We describe the basepkg processing details (Figure3). It runs as follows:
5 It seems that syspkg also tried it but it has been incomplete since distrib/sets/attrs contains a list with preserveflag.

1. basepkg gathers meta data from syspkg one andprepare the next step.
basepkg reads list of a set of (file name, package name and options) from sets/lists/base/mi (machine/architecture independent list) andsets/lists/base/md.ARCH (ARCHitecture dependent list) under /usr/src/disrib/ directory (see distrib/sets/README for more details
on file definitions under sets/). After excluding
files defined as obsolete in the mi and md.ARCH
files, basepkg parses the list to generate FILES
for each category e.g. base, etc and so on. Each
FILES has a mapping between package names
and filenames.
2. basepkg generates temporary meta data.

(a) basepkg reads FILES to create directories pkgsrc-wip, basepkg is installed to /usr/pkg/share/
for the corresponding base packages.
basepkg directory by default.
(b) basepkg creates PLIST files for each package. Each PLIST holds a list contained in
3.4 How to Build Base Packages
the package.
3. basepkg emulates the generation of pkgsrc metadata.
(a) basepkg reads sets/essential to generate proper +PRESERVE files in the corresponding directories. It indicates that thispackage should not be removed.
(b) basepkg creates +BUILD INFO file for eachpackage. It holds environment informationin package building.
(c) basepkg creates +CONTENTS file for eachpackage. It holds a list of files each package
contains and commands for pkg * tools.
(d) basepkg creates +DESC and +COMMENT files
for each package. These are brief descriptions for the package.
(e) basepkg
creates+INSTALL
and+DEINSTALL files to be hooked in installation (pkg add(1)) and de-installation(pkg delete(1)) processes.

The basepkg requires the built NetBSD base system (the whole set under DESTDIR in the term ofbuild.sh) and pkg * tools.
Firstly, we prepare the NetBSD binary at DESTDIR. We recommend building it from the NetBSD
source tree6 .
# cd /usr/src# ./build.sh -O ../obj -T ../tools tools# ./build.sh -O ../obj -T ../tools distribution# ./build.sh -O ../obj -T ../tools kernel=GENERIC

In this example, we assume the source directory
is /usr/src, the obj root directory is /usr/obj, thetools directory is /usr/tools and basepkg root directory is the default one /usr/pkg/share/basepkg.
Secondly, we change to the directory wherebasepkg is installed (/usr/pkg/share/basepkg by
default in using pkgsrc-ip). we run basepkg.shwith “pkg” and “kern” options to build base packages. basepkg generates packages at packages/[NetBSD_version]/[MACHINE]-[MACHINE_ARCH]
4. basepkg runs pkg create(1) for all packages (up directory under /usr/pkg/share/basepkg directory
to about 800) to generate packages. In creating by default. For example, if you run basepkg.sh on
packages, basepkg gathers the package content NetBSD-7.1/amd64, the corresponding packages are
generated at /usr/pkg/share/basepkg/packages/
under DESTDIR directory build.sh generated.
7.1/amd64-x86_64 directory.
5. basepkg creates the checksum files (both MD5and SHA512) over all packages.
# cd /usr/pkg/share/basepkg# ./basepkg.sh pkg

For regression test, we have verified that the con# ./basepkg.sh kerntent of tarball category.tgz is same as the sum ∑ofcategory-*.tgz base packages e.g. base.tgz ==Figure 4 shows the part of etc-sys-etc-7.1.tgz
base-*.tgz.
package content created by basepkg. The format
is same as pkgsrc one described above (See Sec3.3 Basepkg Installation
tion 2.1.2), so the package can be handled by pkg *The latest version of basepkg can be obtained tools used in pkgsrc.
at github.com/user340/basepkg/releases. It re6 In fact, the latest basepkg works well except for the kernel
quires the latest pkgtools/pkg_install, so we rec- packagebuilding when we fetch binaries from NetBSD daiommend the use of pkgsrc-wip/basepkg to in- ly build system (nycdn.netbsd.org) and extract them understall basepkg. When you install basepkg using DESTDIR.

etc-sys-etc-7.1.tgz/+CONTENTS+COMMENT+DESC+INSTALL+DEINSTALL+BUILD_INFO
boot.cfg
dev/
MAKEDEV...snip...

Test

real time (s)user time (s)system time (s)123

7.237419.2955
3.46560.22670.94570.08380.8443
1.17250.0924

Table 5: Comparison between processing time average among old and new installation methods.
raw pkg * tools.

3.6

Estimation of Basepkg Overhead

Figure 4: Content of base package etc-sys-etc-7.1.tgz.
The format is aligned to the modern pkgsrc style.

Packaging implies that an OS is built on a lot ofsmall packages. Hence the OS update process to add
or delete small parts must be faster. However the
3.5 How to Handle Base Packages
package size to add or delete is not proportional to the
In the previous section basepkg processing is men- update processing speed since packaging introduces
tioned from the point of administration or base pack- several new overheads e.g. resolution of dependencies
age provider view. In this section, we describe how among packages, execution of install scripts and sousers and customers handle their system by using the on.
We have compared the installation time between
base packages.
thetraditional (tarball extraction) and our new
Firstly, it is easy to add or delete the specific basemethod(basepkg based). We processed the following
package by using pkg * tools since the package forupdates
100 times on NetBSD-7.1/amd64. We used
mat is same as pkgsrc one. pkg add (1) can beused to install the package. To remove it, we use time(1) command to measure the processing speed.
The target category we used is “game” since “game”
pkg delete(1).
To avoid confliction between pkgsrc and basepkg category is not mission critical.
packages, we should specify the other database path
1. Fetchatarball”games.tgz”
fromsuch as /var/db/basepkg by “-K” option in using
ftp.jp.netbsd.org/pub/NetBSD/NetBSD-7.
pkg * tools,
1/amd64/binary/sets/, then extract it at# cd ./packages/7.1/amd64-x86_64$HOME/tmp directory.
# pkg_add-K /var/db/basepkg games-games-bin# pkg_delete -K /var/db/basepkg games-games-bin

Currently in using raw pkg * tools to manipulatebase packages, we need to be very careful to handle
etc-* base packages such as etc-sys-etc-7.1.tgz
since it overwrites files under the /etc directory. To
avoid this disaster, once we extract the contents inanother directory and determine to apply the content
or not to /etc explicitly by hand.

2. Install all packages beginning with ”games-”
to system from basepkg.netbsd.fml.org/pub/
NetBSD/basepkg/7.1/amd64-x86_64
3. Install one ”games-games-bin” package tosystem from basepkg.netbsd.fml.org/pub/
NetBSD/basepkg/7.1/amd64-x86_64
where basepkg.netbsd.fml.org is an experimental# pkg_add -K /var/db/basepkg -p tmp/basepkg \ base package distribution server we build and operetc-sys-etc-7.1.tgz
ate (See Appendix A for the server details). Table 5... apply it or not to /etc ...

To avoid these critical operations, we should prepare a wrapper for users and customers not to handle

shows the average time of the processing speed.
Table 5 verifies that our new installation using
basepkg is faster than the traditional one. However

it is not faster than we expected because of overheads
mentioned above. Only when we update a few packages in the system, the process is comparable to the
traditional one. In almost cases under normal operation, we replace only a few small parts for rapid security update. In addition it is good we explicitly know
which parts we replace, not a large archive base.tgz.
Hence we consider base packaging is meaningful forusers and customers.

4

Discussion

Firstly, we summarize changes and improvementsfrom AsiaBSDCon2017[1].
• import to pkgsrc-wip repository.
• syspkg meta-data handling fixes:– not generate obsolete packages.
– enhance +PRESERVE handling to coverbase, etc and shlib.
• hook support running +INSTALL and +DEINSTALL.
• cross build support.
• multi platform support.
We have verified basepkg.sh can run on Ubuntu
17.04.
There are a lot of technical issues to resolve as follows:• basepkg processing speed.
We need to profile basepkg to improve the processing speed. basepkg runs slower than syspkg.
Table 5 shows that basepkg user mode processing is about 4 times larger than syspkg one. It
is not clear but the low speed may come fromthat basepkg creates a lot of directories.
We must need to try better shell coding technique. For example, we should not use for nor
while loop as could as possible, instead use internal loops such as find and grep. Matsuuraet.al. says “Processing speed can be improved
when we use POSIX command chain throughpipes with least bifurcations and loops.” [10].

• basepkg database maintenance.
basepkg can run hooks within the processing. We need to maintain hooks for such as
PRE-INSTALL, POST-INSTALL et.al. withinbasepkg own meta data in addition to the current patches. It is by nature better to merge itback to /usr/src/distrib/.
• syspkg database maintenance.
basepkg uses syspkg meta data under src/
distrib/sets/. It is not clear who ensures theconsistency under src/distrib/sets/ files. For
example, it looks src/distrib/sets/descrs
and src/distrib/sets/comments has been incomplete.
• more user friendly naming convention.
syspkg database naming convention is not clear
for users and customers. It should be changed
to more plain naming convention. For example, a base package name base-postfix-bin for
postfix is obvious. However base-secsh-bin
for openssh is far from openssh we expect. It
is more diﬃcult to find openssl than examples
mentioned above. The shared library libssl.so
is contained in base-crypto-shlib. The library
libssl.a used in compilation is contained incomp-c-lib. In this example, the granularity
should be too re-considered since comp-c-lib includes several kinds of libraries. To resolve thisdiﬃculty, as a workaround, it is better to provide
a wrapper with naming mapping service.
• a wrapper convenient for users and customers.
To resolve the issue mentioned at Section 3.5,
we should provide a wrapper utility to manipulate base packages. This utility hides raw
use of pkg * tools and the database location/var/db/basepkg. It is useful to provide thefollowing functions.
– It warns or asks the user instructions stepby step if etc-* is specified as the argument
to avoid unexpected overwrite of /etc.

– It is better to provide alias mapping
for ambiguous package names. For example, wrapper update openssh actually runs pkg delete base-secsh-bin.tgz
and pkg add base-secsh-bin.tgz.

Currently we build and operate an experimentalbase package distribution server (See Appendix
A for the server details) but our machine power
can generate base packages for at most 30 architectures on only latest NetBSD stable branchwithin one day. Appendix A discusses the cost
evaluation to operate more rapid up-to-date system.

– It caches the fetched packages under /var/cache/baspekg for later use. The cache remains unless you run wrapper clean.
– It can rollback the specified base package
cached above.
• integrated system management support.
For users and customers, it must be useful toprovide automatic management function for thebase system like apt (Debian/Linux Advanced
Package Tool). For example, wrapper update
fetches the latest package database and wrapper
upgrade upgrades (deletes and adds) base packages automatically. This function implies support of automatic vulnerability check for basepackages.
basepkg is built on pkg * tools, so integration
with pkgsrc framework must be easy.
Currently pkgsrc vulnerability can be checked
automatically but the base system check depends on your eyes7 . The automatic vulnerability
check for base system is useful for users and customers.
The vulnerability database of base packages canbe managed under pkgsrc audit-packages framework. The database is same as /var/db/pkg/
pkg-vulnerabilities like this:sys-secsh-bin<20171220

reason...

url...

It must be better that basepkg works withpkgin(pkgsrc/pkgtools/pkgin) to cover bothbase and pkgsrc packages totally.
• base package distribution support.
It is not useful unless latest base packages are
not provided. It is required to support automatic
updates, rollbacks et.al. described above.
7 You need to action based on NetBSD security advisory
release.

5

Conclusion

We have developed another framework “basepkg”
to package NetBSD base system. It is shown that thisframework provides more granular and faster updateof NetBSD base system and useful functions for users
and customers. However we have a lot of issues toresolve for realistic system operations, so we need tocontinue dogfooding and development.

References

A[1] Yuuki Enomoto and Ken’ichi Fukamachi, 2017,
Maintain the NetBSD Base System Using pkg *,A.1
www.netbsd.org/gallery/presentations/
yuuki/2017_AsiaBSDCon/basepkg.pdf
A.1.1[2] The FreeBSD Documentation Project, Revision: 51193, Chapter 4. Installing Applications: Packages and Ports, FreeBSD Handbook,www.freebsd.org/doc/handbook/ports.html[3] NetBSD, 2007, pkgsrc, Miscellaneous Information Manual.
[4] Jordan Hubbard, John Kohl and Hubert Feyrer,
2010, pkg create, General Commands Manual[5] wiki.freebsd.org/PkgBase[6] Colin Percival, 2017, freebsd-update, FreeBSD
System Manager’s Manual.
[7] Luke Mewburn and Matthew Green, 2003,
build.sh: Cross-building NetBSD, BSDCon ‘03.
[8] The NetBSD Project, 2014, syspkgs, wiki.
netbsd.org/projects/project/syspkgs/[9] Lloyd
Parkes,
2012,
Lots
of
broken syspkgs,
NetBSD Problem Report#46937,
gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=46937

Estimation of Base Package
Distribution
Build By Ourself
Current VPS Case

Experimentally we operate a base package distribution server basepkg.netbsd.fml.org which runs
on SAKURA Internet VPS ( SAKURA VPS(v3) 2G
plan: 3 CORE CPU, 200GB storage, about 150 USD(16,745 JPY) per year )8 . Currently we provide 30
architectures in NetBSD 7 STABLE.
We need to run a set of build.sh and basepkg.sh
for all target architectures since basepkg.sh requires
compiled objects at DESTDIR build.sh generates(Section 3). Fortunately this process can run parallelly, so we can run one set for one architecture on
one CPU CORE. If we can prepare enough large storage (5GB per architecture per version), we canrun build.sh with -u option (do not run “makecleandir”). The upper limit of 30 architectures
are restricted by this storage limit (200GB) to run
build.sh -u.
The base package building process costs about 1
hour per target where build.sh -u requires about1000 sec. and basepkg.sh requires about 2000 sec.
Hence we need 10 hours to prepare 30 architectureseven if we can run processes parallelly per CPU
CORE. When we clean up the working directories(i.e. build.sh runs normally without -u option), thebuilding process requires 6 times processing time pertarget.

[10] Tomoyuki Matsuura, Hiroyuki Ohno andNobuaki Tonaka, 2017, POSIX Centric Programming to Make Software More Compatible and Sustainable, Digital Practice 8(4), 352- A.1.2 Cloud Case
360, https://www.ipsj.or.jp/dp/contents/
The evaluation is underway.
publication/32/S0804-R1601.html.
Cloud service is more suitable for intermittent work
like this. The updates for stable branches are rare,
so we do not need to build base packages daily. If
we run this building process only when a NetBSD
security advisory is released and the target can be
restricted to stable branches, modern cloud service ismore proper than the current VPS service. We needto estimate the cloud speed and cost whether the cost
8 https://vps.sakura.ad.jp/

may be lower since cloud is CPU meter rate charging.
In the case of cloud service, we assume the following
usage:• Normally the build process does not run. The
low cost cloud archive holds the built data (theprevious build result).
• On demand, we wake up the cloud service, extract the built data from the archive, build
base packages (by running build.sh -u andbasepkg), update web servers, re-archive thebuilt data and make the cloud sleep again.

A.2

Using NetBSD Daily Build System

Today it looks NetBSD daily build system can prepare daily binaries for some branches e.g. NetBSD
7.1 stable branch. Hence basepkg distribution server
can fetch the tarballs and build base packages basedon them.
The processing time seems almost comparable tothe VPS case running build.sh -u described above
but with less storage consumption (1GB per architecture per version). Hence we hope to operate basepackage distribution server at a low cost but only forlatest branches. The details of evaluation will be reported at AsiaBSDCon 2018.