Minix/pkgsrc-ng
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Import of pkgsrc-2015Q1

Browse Source
This commit is contained in:
Lionel Sambuc
2015-04-22 14:34:26 +02:00
committed by Lionel Sambuc
parent 9a8c06dafb
commit 4af1cdf7a9
25114 changed files with 870550 additions and 795435 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
doc/guide/files/build.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: build.xml,v 1.64 2012/09/19 15:26:34 wiz Exp $ -->
<!-- $NetBSD: build.xml,v 1.71 2014/05/31 21:08:50 asau Exp $ -->
<chapter id="build">
<title>The build process</title>
@@ -252,7 +252,8 @@ GTKDIR_DEFAULT= ${LOCALBASE}
<para>The variable <varname>DISTFILES</varname> specifies
the list of distfiles that have to be fetched. Its value
defaults to <literal>${DISTNAME}${EXTRACT_SUFX}</literal>,
defaults to <literal>${DEFAULT_DISTFILES}</literal> and
its value is <literal>${DISTNAME}${EXTRACT_SUFX}</literal>,
so that most packages don't need to define it at all.
<varname>EXTRACT_SUFX</varname> is
<literal>.tar.gz</literal> by default, but can be changed
@@ -262,7 +263,7 @@ GTKDIR_DEFAULT= ${LOCALBASE}
operator, but you have write for example:</para>
<programlisting>
DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
DISTFILES= ${DEFAULT_DISTFILES} additional-files.tar.gz
</programlisting>
<para>Each distfile is fetched from a list of sites, usually
@@ -298,8 +299,20 @@ MASTER_SITES= http://www.example.com/download.cgi?file=
</programlisting>
<para> The exception to this rule are URLs starting with a dash.
In that case the URL is taken as is, fetched and the result stored
under the name of the distfile.</para>
In that case the URL is taken as is, fetched and the result
stored under the name of the distfile. You can use this style
for the case when the download URL style does not match the
above common case. For example, if permanent download URL is a
redirector to the real download URL, or the download file name
is offered by an HTTP Content-Disposition header. In the
following example, <filename>foo-1.0.0.tar.gz</filename> will be
created instead of the default
<filename>v1.0.0.tar.gz</filename>.</para>
<programlisting>
DISTNAME= foo-1.0.0
MASTER_SITES= -http://www.example.com/archive/v1.0.0.tar.gz
</programlisting>
<para>There are some predefined values for
<varname>MASTER_SITES</varname>, which can be used in
@@ -319,13 +332,18 @@ ${MASTER_SITE_GENTOO}
${MASTER_SITE_GNOME}
${MASTER_SITE_GNU}
${MASTER_SITE_GNUSTEP}
${MASTER_SITE_HASKELL_HACKAGE}
${MASTER_SITE_IFARCHIVE}
${MASTER_SITE_KDE}
${MASTER_SITE_MOZILLA}
${MASTER_SITE_MOZILLA_ALL}
${MASTER_SITE_MOZILLA_ESR}
${MASTER_SITE_MYSQL}
${MASTER_SITE_NETLIB}
${MASTER_SITE_OPENOFFICE}
${MASTER_SITE_PERL_CPAN}
${MASTER_SITE_PGSQL}
${MASTER_SITE_RUBYGEMS}
${MASTER_SITE_R_CRAN}
${MASTER_SITE_SOURCEFORGE}
${MASTER_SITE_SOURCEFORGE_JP}
@@ -334,6 +352,7 @@ ${MASTER_SITE_SUSE}
${MASTER_SITE_TEX_CTAN}
${MASTER_SITE_XCONTRIB}
${MASTER_SITE_XEMACS}
${MASTER_SITE_XORG}
</programlisting>
<para>Some explanations for the less self-explaining ones:
@@ -1272,6 +1291,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
</varlistentry>
<varlistentry>
<!-- TODO: old bulk build? -->
<term>bulk-package</term>
<listitem>
@@ -1279,7 +1299,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
package already exists, no action is taken. If not, this
target will compile, install and package it (and its
depends, if <varname>PKG_DEPENDS</varname> is set
properly. See <xref linkend="binary.configuration"/>).
properly. See <xref linkend="bulk"/>).
After creating the binary package, the sources, the
just-installed package and its required packages are
removed, preserving free disk space.</para>

8
doc/guide/files/buildlink.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: buildlink.xml,v 1.36 2013/07/30 07:14:09 wiz Exp $ -->
<!-- $NetBSD: buildlink.xml,v 1.38 2014/12/30 15:18:59 wiz Exp $ -->
<chapter id="buildlink">
<title>Buildlink methodology</title>
@@ -317,13 +317,11 @@ BUILDLINK_TREE+= -tiff
<filename>+CONTENTS</filename> input into a list of files
relative to
<filename>${BUILDLINK_PREFIX.<replaceable>pkg</replaceable>}</filename>
on stdout. By default for overwrite packages,
on stdout. By default,
<varname>BUILDLINK_CONTENTS_FILTER.<replaceable>pkg</replaceable></varname>
outputs the contents of the <filename>include</filename>
and <filename>lib</filename> directories in the package
<filename>+CONTENTS</filename>, and for pkgviews packages,
it outputs any libtool archives in
<filename>lib</filename> directories.</para>
<filename>+CONTENTS</filename>.</para>
</listitem>
<listitem>

725
doc/guide/files/bulk.xml
View File

@@ -1,19 +1,47 @@
<!-- $NetBSD: bulk.xml,v 1.12 2013/12/31 19:27:06 dholland Exp $ -->
<!-- $NetBSD: bulk.xml,v 1.21 2014/07/27 08:28:28 wiz Exp $ -->
<chapter id="bulk">
<title>Creating binary packages for everything in pkgsrc (bulk
builds)</title>
<para>When you have multiple machines that should run the same packages,
it is wasted time if they all build their packages themselves from
source. There are two ways of getting a set of binary packages: The old
bulk build system, or the new (as of 2007) parallel bulk build (pbulk)
system. This chapter describes how to set them up so that the packages
<para>For a number of reasons you may want to build binary packages
for a large selected set of packages in pkgsrc or even for all pkgsrc packages.
For instance, when you have multiple machines that should run the same software,
it is wasted time if they all build their packages themselves from source.
Or you may want to build a list of packages you want and check them before
deploying onto production system.
There is a way of getting a set of binary packages:
The bulk build system, or pbulk ("p" stands for "parallel).
This chapter describes how to set it up so that the packages
are most likely to be usable later.</para>
<sect1 id="bulk.pre">
<title>Think first, build later</title>
<title>Preparations</title>
<para>First of all, you have to decide whether you build all packages
or a limited set of them. Full bulk builds usually consume a lot more resources,
both space and time, than builds for some practical sets of packages.
There exists a number of particularly heavy packages that are not actually
interesting to a wide audience.
<!-- approximate resource consumption for full bulk build is given in section <put a reference here/> -->
For a limited bulk builds you need to make a list of packages you want to build.
Note, that all their dependencies will be built, so you don't need to track them manually.
</para>
<para>During bulk builds various packages are installed and deinstalled
in <filename>/usr/pkg</filename> (or whatever <filename>LOCALBASE</filename> is),
so make sure that you don't need any package during the builds.
Essentially, you should provide fresh system, either a chroot environment
or something even more restrictive, depending on what the operating system provides,
or dedicate the whole physical machine.
As a useful side effect this makes sure that bulk builds cannot
break anything in your system. There have been numerous cases where
certain packages tried to install files outside the
<filename>LOCALBASE</filename> or wanted to edit some files in
<filename>/etc</filename>.
</para>
<!-- Developer-only information follows:
<para>Since a bulk build takes several days or even weeks to finish, you
should think about the setup before you start everything. Pay attention
to at least the following points:</para>
@@ -42,22 +70,104 @@ unprivileged user doesn't work well at the moment.</para></listitem>
</itemizedlist>
</listitem>
<listitem><para>Make sure that the bulk build cannot break anything in
your system. Most bulk builds run as root, so they should be run at least
in a chroot environment or something even more restrictive, depending on
what the operating system provides. There have been numerous cases where
certain packages tried to install files outside the
<filename>LOCALBASE</filename> or wanted to edit some files in
<filename>/etc</filename>. Furthermore, the bulk builds install and
deinstall packages in <filename>/usr/pkg</filename> (or whatever
<filename>LOCALBASE</filename> is) during their operation, so be sure
that you don't need any package during the build.</para></listitem>
</itemizedlist>
-->
</sect1>
<sect1 id="bulk.pbulk">
<title>Running a pbulk-style bulk build</title>
<para>Running a pbulk-style bulk build works roughly as follows:</para>
<itemizedlist>
<listitem><para>First, build the pbulk infrastructure in a fresh pkgsrc location.</para></listitem>
<listitem><para>Then, build each of the packages from a clean installation directory using the infrastructure.</para></listitem>
</itemizedlist>
<sect2 id="bulk.pbulk.conf">
<title>Configuration</title>
<para>To simplify configuration we provide helper script <filename>mk/pbulk/pbulk.sh</filename>.</para>
<para>In order to use it, prepare a clear system (real one, chroot environment, jail, zone, virtual machine).
Configure network access to fetch distribution files.
Create user with name "pbulk".</para>
<para>Fetch and extract pkgsrc. Use a command like one of these:</para>
<screen>
&rprompt; <userinput>(cd /usr &amp;&amp; ftp -o - http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz | tar -zxf-)</userinput>
&rprompt; <userinput>(cd /usr &amp;&amp; fetch -o - http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz | tar -zxf-)</userinput>
&rprompt; <userinput>(cd /usr &amp;&amp; cvs -Q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot get -P pkgsrc)</userinput>
</screen>
<para>Or any other way that fits (e.g., curl, wget).</para>
<para>Deploy and configure pbulk tools, e.g.:</para>
<screen>
&rprompt; <userinput>sh pbulk.sh -n # native (NetBSD)</userinput>
&rprompt; <userinput>sh pbulk.sh -n -c mk.conf.frag # native, apply settings from given mk.conf fragment</userinput>
&rprompt; <userinput>sh pbulk.sh -nlc mk.conf.frag # native, apply settings, configure for limited build</userinput>
</screen>
<note><para><filename>mk.conf.frag</filename> is a fragment of
<filename>mk.conf</filename> that contains settings you want to
apply to packages you build. For instance,</para>
<programlisting>
PKG_DEVELOPER= yes # perform more checks
X11_TYPE= modular # use pkgsrc X11
SKIP_LICENSE_CHECK= yes # accept all licences (useful when building all packages)
</programlisting>
</note>
<!-- Think how to merge this or maintain short reference of useful settings.
<itemizedlist>
<listitem><para><literal><varname>PKG_DEVELOPER</varname>=yes</literal>, to enable many consistency checks,</para></listitem>
<listitem><para><literal><varname>WRKOBJDIR</varname>=/tmp/pbulk-outer</literal>, to keep <filename>/usr/pkgsrc</filename> free from any modifications,</para></listitem>
<listitem><para><literal><varname>DISTDIR</varname>=/distfiles</literal>, to have only one directory in which all distfiles (for the infrastructure and for the actual packages) are downloaded,</para></listitem>
<listitem><para><literal><varname>ACCEPTABLE_LICENSES</varname>+=...</literal>, to select some licenses additional to the usual Free/Open Source licenses that are acceptable to you,</para></listitem>
<listitem><para><literal><varname>SKIP_LICENSE_CHECK</varname>=yes</literal>, to bypass the license checks.</para></listitem>
</itemizedlist>
-->
<para>If configured for limited list, replace the list in <filename>/usr/pbulk/etc/pbulk.list</filename>
with your list of packages one per line without empty lines or comments. E.g.:</para>
<programlisting>
www/firefox
mail/thunderbird
misc/libreoffice4
</programlisting>
<para>At this point you can also review configuration in <filename>/usr/pbulk/etc</filename>
and make final amendments, if wanted.</para>
<para>Start it:</para>
<screen>
&rprompt; <userinput>/usr/pbulk/bin/bulkbuild</userinput>
</screen>
<para>After it finishes, you'll have <filename>/mnt</filename> filled with distribution files, binary packages, and reports,
plain text summary in <filename>/mnt/bulklog/meta/report.txt</filename>
</para>
<note><para>The <filename>pbulk.sh</filename> script does not cover all possible use cases.
While being ready to run, it serves as a good starting point to understand and build more complex setups.
The script is kept small enough for better understanding.</para>
</note>
<note><para>The <filename>pbulk.sh</filename> script supports running
unprivileged bulk build and helps configuring distributed bulk builds.</para>
</note>
</sect2>
</sect1>
<sect1 id="bulk.req">
<title>Requirements of a bulk build</title>
<title>Requirements of a full bulk build</title>
<para>A complete bulk build requires lots of disk space. Some of the
disk space can be read-only, some other must be writable. Some can be on
@@ -72,7 +182,7 @@ temporary filesystems, others must survive a sudden reboot.</para>
<listitem><para>1 GB for the pkgsrc tree (read-only, remote, permanent)</para></listitem>
<listitem><para>5 GB for <filename>LOCALBASE</filename> (read-write, local, temporary for pbulk, permanent for old-bulk)</para></listitem>
<listitem><para>5 GB for <filename>LOCALBASE</filename> (read-write, local, temporary)</para></listitem>
<listitem><para>10 GB for the log files (read-write, remote, permanent)</para></listitem>
@@ -80,581 +190,6 @@ temporary filesystems, others must survive a sudden reboot.</para>
</itemizedlist>
</sect1>
<sect1 id="bulk.old">
<title>Running an old-style bulk build</title>
<note><para>There are two ways of doing a bulk build. The old-style
one and the new-style <quote>pbulk</quote>. The latter is the recommended
way.</para></note>
<sect2 id="binary.configuration">
<title>Configuration</title>
<!-- begin old -->
<sect3 id="binary.bulk.build.conf">
<title><filename>build.conf</filename></title>
<para>The <filename>build.conf</filename> file is the main
configuration file for bulk builds. You can configure how your
copy of pkgsrc is kept up to date, how the distfiles are
downloaded, how the packages are built and how the report is
generated. You can find an annotated example file in
<filename>pkgsrc/mk/bulk/build.conf-example</filename>. To use
it, copy <filename>build.conf-example</filename> to
<filename>build.conf</filename> and edit it, following the
comments in that file.</para>
</sect3>
<sect3 id="binary.mk.conf">
<title>&mk.conf;</title>
<para>You may want to set variables in &mk.conf;.
Look at <filename>pkgsrc/mk/defaults/mk.conf</filename> for
details of the default settings. You will want to ensure that
<varname>ACCEPTABLE_LICENSES</varname> meet your local policy.
As used in this example, <varname>SKIP_LICENSE_CHECK=yes</varname>
completely bypasses the license check.</para>
<programlisting>
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
SKIP_LICENSE_CHECK= yes
</programlisting>
<para>Some options that are especially useful for bulk builds
can be found at the top lines of the file
<filename>mk/bulk/bsd.bulk-pkg.mk</filename>. The most useful
options of these are briefly described here.</para>
<itemizedlist>
<listitem><para>If you are on a slow machine, you may want to
set <varname>USE_BULK_BROKEN_CHECK</varname> to
<quote>no</quote>.</para></listitem>
<listitem><para>If you are doing bulk builds from a read-only
copy of pkgsrc, you have to set <varname>BULKFILESDIR</varname>
to the directory where all log files are created. Otherwise the
log files are created in the pkgsrc directory.</para></listitem>
<listitem><para>Another important variable is
<varname>BULK_PREREQ</varname>, which is a list of packages that
should be always available while building other
packages.</para></listitem>
</itemizedlist>
<para>Some other options are scattered in the pkgsrc
infrastructure:</para>
<itemizedlist>
<listitem><para><varname>ALLOW_VULNERABLE_PACKAGES</varname>
should be set to <literal>yes</literal>. The purpose of the
bulk builds is creating binary packages, no matter if they
are vulnerable or not. Leaving this variable unset would
prevent the bulk build system from even trying to build
them, so possible building errors would not show
up.</para></listitem>
<listitem><para><varname>CHECK_FILES</varname>
(<filename>pkgsrc/mk/check/check-files.mk</filename>) can be set to
<quote>yes</quote> to check that the installed set of files
matches the <filename>PLIST</filename>.</para></listitem>
<listitem><para><varname>CHECK_INTERPRETER</varname>
(<filename>pkgsrc/mk/check/check-interpreter.mk</filename>) can be set to
<quote>yes</quote> to check that the installed
<quote>#!</quote>-scripts will find their
interpreter.</para></listitem>
<listitem><para><varname>PKGSRC_RUN_TEST</varname> can be
set to <quote><literal>yes</literal></quote> to run each
package's self-test before installing it. Note that some
packages make heavy use of <quote>good</quote> random
numbers, so you need to assure that the machine on which you
are doing the bulk builds is not completely idle. Otherwise
some test programs will seem to hang, while they are just
waiting for new random data to be
available.</para></listitem>
</itemizedlist>
</sect3>
<sect3 id="pre-build.local">
<title><filename>pre-build.local</filename></title>
<para>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
<filename>pre-build.local</filename> exists in
<filename>/usr/pkgsrc/mk/bulk</filename>, it will be executed
(as a &man.sh.1; script) at the end of the usual pre-build
stage. An example use of
<filename>pre-build.local</filename> is to have the line:</para>
<screen>echo "I do not have enough disk space to build this pig." \
&gt; misc/openoffice/$BROKENF</screen>
<para>to prevent the system from trying to build a particular package
which requires nearly 3 GB of disk space.</para>
</sect3>
</sect2>
<sect2 id="other-environmental-considerations">
<title>Other environmental considerations</title>
<para>As <filename>/usr/pkg</filename> will be completely
deleted at the start of bulk builds, make sure your login
shell is placed somewhere else. Either drop it into
<filename>/usr/local/bin</filename> (and adjust your login
shell in the passwd file), or (re-)install it via
&man.pkg.add.1; from <filename>/etc/rc.local</filename>, 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 &os; 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 <filename>rc.local</filename>:</para>
<programlisting>
(cd /usr/pkgsrc/security/ssh && make bulk-install)
if [ -f /usr/pkg/etc/rc.d/sshd ]; then
/usr/pkg/etc/rc.d/sshd
fi
</programlisting>
<para>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! :)</para>
</sect2>
<sect2 id="operation">
<title>Operation</title>
<para>Make sure you don't need any of the packages still
installed.</para>
<warning>
<para>During the bulk build, <emphasis>all packages, their
configuration files and some more files from
<filename>/var</filename>, <filename>/home</filename> and
possibly other locations will be removed! So don't run a bulk
build with privileges that might harm your
system.</emphasis></para>
</warning>
<para>Be sure to remove all other things that might
interfere with builds, like some libs installed in
<filename>/usr/local</filename>, etc. then become root and type:</para>
<screen>
&rprompt; <userinput>cd /usr/pkgsrc</userinput>
&rprompt; <userinput>sh mk/bulk/build</userinput>
</screen>
<para>If for some reason your last build didn't complete (power
failure, system panic, ...), you can continue it by
running:</para>
<screen>&rprompt; <userinput>sh mk/bulk/build restart</userinput></screen>
<para>At the end of the bulk build, you will get a summary via mail,
and find build logs in the directory specified by
<varname>FTP</varname> in the <filename>build.conf</filename>
file.</para>
</sect2>
<sect2 id="what-it-does">
<title>What it does</title>
<para>The bulk builds consist of three steps:</para>
<variablelist>
<varlistentry>
<term>1. pre-build</term>
<listitem>
<para>The script updates your pkgsrc tree via (anon)cvs, then
cleans out any broken distfiles, and removes all
packages installed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>2. the bulk build</term>
<listitem>
<para>This is basically <quote>make bulk-package</quote> 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>3. post-build</term>
<listitem>
<para>Generates a report that's placed in the directory
specified in the <filename>build.conf</filename> file
named <filename>broken.html</filename>, a short version
of that report will also be mailed to the build's
admin.</para>
</listitem>
</varlistentry>
</variablelist>
<para>During the build, a list of broken packages will be compiled
in <filename>/usr/pkgsrc/.broken</filename> (or
<filename>.../.broken.${MACHINE}</filename> if
<varname>OBJMACHINE</varname> 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.</para>
</sect2>
<sect2 id="disk-space-requirements">
<title>Disk space requirements</title>
<para>Currently, roughly the following requirements are valid for
NetBSD 6.99/amd64:</para>
<itemizedlist>
<listitem>
<para>40 GB - distfiles (NFS ok)</para>
</listitem>
<listitem>
<para>30 GB - full set of all binaries (NFS ok)</para>
</listitem>
<listitem>
<para>5 GB - temp space for compiling (local disk recommended)</para>
</listitem>
</itemizedlist>
<para>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 &man.pkg.add.1; instead of building again, so
there are no cycles wasted by recompiling.</para>
</sect2>
<sect2 id="setting-up-a-sandbox">
<title>Setting up a sandbox for chrooted builds</title>
<para>If you don't want all the packages nuked from a machine
(rendering it useless for anything but pkg compiling), there
is the possibility of doing the package bulk build inside a
chroot environment.</para>
<para>The first step is to set up a chroot sandbox,
e.g. <filename>/usr/sandbox</filename>. This can be done by
using null mounts, or manually.</para>
<para>There is a shell script called
<filename>mksandbox</filename> installed by the <filename
role="pkg">pkgtools/mksandbox</filename> package, which will set
up the sandbox environment using null mounts. It will also
create a script called <filename>sandbox</filename> in the
root of the sandbox environment, which will allow the null
mounts to be activated using the <command>sandbox
mount</command> command and deactivated using the
<command>sandbox umount</command> command.</para>
<para>To set up a sandbox environment by hand, after extracting all
the sets from a &os; installation or doing a <command>make
distribution DESTDIR=/usr/sandbox</command> in
<filename>/usr/src/etc</filename>, be sure the following items
are present and properly configured:</para>
<procedure>
<step>
<para>Kernel</para>
<screen>&rprompt; <userinput>cp /netbsd /usr/sandbox</userinput></screen>
</step>
<step>
<para><filename>/dev/*</filename></para>
<screen>&rprompt; <userinput>cd /usr/sandbox/dev ; sh MAKEDEV all</userinput></screen>
</step>
<step>
<para><filename>/etc/resolv.conf</filename> (for <filename
role="pkg">security/smtpd</filename> and mail):</para>
<screen>&rprompt; <userinput>cp /etc/resolv.conf /usr/sandbox/etc</userinput></screen>
</step>
<step>
<para>Working(!) mail config (hostname, sendmail.cf):</para>
<screen>&rprompt; <userinput>cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail</userinput></screen>
</step>
<step>
<para><filename>/etc/localtime</filename> (for <filename
role="pkg">security/smtpd</filename>):</para>
<screen>&rprompt; <userinput>ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime</userinput></screen>
</step>
<step>
<para><filename>/usr/src</filename> (system sources,
rarely used by packages if at all:</para>
<screen>&rprompt; <userinput>ln -s ../disk1/cvs .</userinput>
&rprompt; <userinput>ln -s cvs/src-2.0 src</userinput></screen>
</step>
<step>
<para>Create <filename>/var/db/pkg</filename> (not part of default install):</para>
<screen>&rprompt; <userinput>mkdir /usr/sandbox/var/db/pkg</userinput></screen>
</step>
<step>
<para>Create <filename>/usr/pkg</filename> (not part of default install):</para>
<screen>&rprompt; <userinput>mkdir /usr/sandbox/usr/pkg</userinput></screen>
</step>
<step>
<para>Checkout pkgsrc via cvs into
<filename>/usr/sandbox/usr/pkgsrc</filename>:</para>
<screen>
&rprompt; <userinput>cd /usr/sandbox/usr</userinput>
&rprompt; <userinput>cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc</userinput>
</screen>
<para>Do not mount/link this to the copy of your pkgsrc tree
you do development in, as this will likely cause problems!</para>
</step>
<step>
<para>Make
<filename>/usr/sandbox/usr/pkgsrc/packages</filename> and
<filename>.../distfiles</filename> point somewhere
appropriate. NFS- and/or nullfs-mounts may come in handy!</para>
</step>
<step>
<para>Edit &mk.conf;, see <xref linkend="binary.mk.conf"/>.</para>
</step>
<step>
<para>Adjust <filename>mk/bulk/build.conf</filename> to suit your needs.</para>
</step>
</procedure>
<para>When the chroot sandbox is set up, you can start
the build with the following steps:</para>
<screen>
&rprompt; <userinput>cd /usr/sandbox/usr/pkgsrc</userinput>
&rprompt; <userinput>sh mk/bulk/do-sandbox-build</userinput>
</screen>
<para>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
<filename>/usr/sandbox/usr/pkgsrc/packages</filename>
(wherever that points/mounts to/from).</para>
</sect2>
<sect2 id="building-a-partial-set">
<title>Building a partial set of packages</title>
<para>In addition to building a complete set of all packages in
pkgsrc, the <filename>pkgsrc/mk/bulk/build</filename> script
may be used to build a subset of the packages contained in
pkgsrc. By setting <varname>SPECIFIC_PKGS</varname>
in &mk.conf;, the variables</para>
<itemizedlist>
<listitem><para>SITE_SPECIFIC_PKGS</para></listitem>
<listitem><para>HOST_SPECIFIC_PKGS</para></listitem>
<listitem><para>GROUP_SPECIFIC_PKGS</para></listitem>
<listitem><para>USER_SPECIFIC_PKGS</para></listitem>
</itemizedlist>
<para>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.</para>
<para>One use of this is to do a bulk build with
<varname>SPECIFIC_PKGS</varname> 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.</para>
</sect2>
<sect2 id="bulk-upload">
<title>Uploading results of a bulk build</title>
<para>This section describes how pkgsrc developers can upload binary
pkgs built by bulk builds to ftp.NetBSD.org.</para>
<para>If you would like to automatically create checksum files for the
binary packages you intend to upload, remember to set
<varname>MKSUMS=yes</varname> in your
<filename>mk/bulk/build.conf</filename>.</para>
<para>If you would like to PGP sign the checksum files (highly
recommended!), remember to set
<varname>SIGN_AS=username@NetBSD.org</varname> in your
<filename>mk/bulk/build.conf</filename>. This will prompt you for
your GPG password to sign the files before uploading everything.</para>
<para>Then, make sure that you have <varname>RSYNC_DST</varname>
set properly in your <filename>mk/bulk/build.conf</filename>
file, i.e. adjust it to something like one of the following:</para>
<screen>RSYNC_DST=ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload</screen>
<para>Please use appropriate values for "20xxQy" (the branch),
"a.b.c" (the OS version) and "arch" here. If your login on ftp.NetBSD.org
is different from your local login, write your login directly
into the variable, e.g. my local account is "feyrer", but for my
login "hubertf", I use:</para>
<screen>RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload</screen>
<para>A separate <filename>upload</filename> directory is used
here to allow "closing" the directory during upload. To do
so, run the following command on ftp.NetBSD.org next:</para>
<screen>nbftp% <userinput>mkdir -p -m 750 /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload</userinput></screen>
<para>Before uploading the binary pkgs, ssh authentication needs
to be set up. This example shows how to set up temporary keys
for the root account <emphasis>inside the sandbox</emphasis>
(assuming that no keys should be present there usually):</para>
<screen>
&rprompt; <userinput>chroot /usr/sandbox</userinput>
chroot-&rprompt; <userinput>rm $HOME/.ssh/id-dsa*</userinput>
chroot-&rprompt; <userinput>ssh-keygen -t rsa</userinput>
chroot-&rprompt; <userinput>cat $HOME/.ssh/id-rsa.pub</userinput>
</screen>
<para>Now take the output of <filename>id-rsa.pub</filename> and
append it to your <filename>~/.ssh/authorized_keys</filename>
file on ftp.NetBSD.org. You should remove the key after the
upload is done!</para>
<para>Next, test if your ssh connection really works:</para>
<screen>chroot-&rprompt; <userinput>ssh ftp.NetBSD.org date</userinput> </screen>
<para>Use "-l yourNetBSDlogin" here as appropriate!</para>
<para>Now after all this works, you can exit the sandbox and start
the upload:</para>
<screen>
chroot-&rprompt; <userinput>exit</userinput>
&rprompt; <userinput>cd /usr/sandbox/usr/pkgsrc</userinput>
&rprompt; <userinput>sh mk/bulk/do-sandbox-upload</userinput>
</screen>
<para>The upload process may take quite some time. Use &man.ls.1; or
&man.du.1; on the FTP server to monitor progress of the
upload. The upload script will take care of not uploading
restricted packages.</para>
<para>After the upload has ended, first thing is to revoke ssh access:</para>
<screen>nbftp% <userinput>vi ~/.ssh/authorized_keys</userinput>
Gdd:x! </screen>
<para>Use whatever is needed to remove the key you've entered
before! Last, move the uploaded packages out of the
<filename>upload</filename> directory to have them accessible
to everyone:</para>
<screen>
nbftp% <userinput>cd /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy</userinput>
nbftp% <userinput>mv upload/* .</userinput>
nbftp% <userinput>rmdir upload</userinput>
nbftp% <userinput>chgrp -R netbsd .</userinput>
nbftp% <userinput>find . -type d | xargs chmod 775</userinput>
</screen>
<!-- end old -->
</sect2>
</sect1>
<sect1 id="bulk.pbulk">
<title>Running a pbulk-style bulk build</title>
<para>Running a pbulk-style bulk build works roughly as follows:</para>
<itemizedlist>
<listitem><para>First, build the pbulk infrastructure in a fresh pkgsrc location.</para></listitem>
<listitem><para>Then, build each of the packages from a clean installation directory using the infrastructure.</para></listitem>
</itemizedlist>
<sect2 id="bulk.pbulk.prepare">
<title>Preparation</title>
<para>First, you need to create a pkgsrc installation for the pbulk infrastructure. No matter on which platform you are (even on NetBSD), you should bootstrap into its own directory. Let's take the directory <filename>/usr/pbulk</filename> or <filename>$HOME/pbulk</filename> for it. This installation will be bootstrapped and all the tools that are required for the bulk build will be installed there.</para>
<screen>
$ <userinput>cd /usr/pkgsrc</userinput>
$ <userinput>./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap</userinput>
$ <userinput>rm -rf /tmp/pbulk-bootstrap</userinput>
</screen>
<para>Now the basic environment for the pbulk infrastructure is installed. The specific tools are still missing. This is a good time to edit the pkgsrc configuration file <filename>/usr/pbulk/etc/mk.conf</filename> to fit your needs. Typical things you might set now are:</para>
<itemizedlist>
<listitem><para><literal><varname>PKG_DEVELOPER</varname>=yes</literal>, to enable many consistency checks,</para></listitem>
<listitem><para><literal><varname>WRKOBJDIR</varname>=/tmp/pbulk-outer</literal>, to keep <filename>/usr/pkgsrc</filename> free from any modifications,</para></listitem>
<listitem><para><literal><varname>DISTDIR</varname>=/distfiles</literal>, to have only one directory in which all distfiles (for the infrastructure and for the actual packages) are downloaded,</para></listitem>
<listitem><para><literal><varname>ACCEPTABLE_LICENSES</varname>+=...</literal>, to select some licenses additional to the usual Free/Open Source licenses that are acceptable to you,</para></listitem>
<listitem><para><literal><varname>SKIP_LICENSE_CHECK</varname>=yes</literal>, to bypass the license checks.</para></listitem>
</itemizedlist>
<para>Now you are ready to build the rest of the pbulk infrastructure.</para>
<screen>
$ <userinput>cd pkgtools/pbulk</userinput>
$ <userinput>/usr/pbulk/bin/bmake install</userinput>
$ <userinput>rm -rf /tmp/pbulk-outer</userinput>
</screen>
<para>Now the pbulk infrastructure is built and installed. It still needs to be configured, and after some more preparation, we will be able to start the real bulk build.</para>
</sect2>
<sect2 id="bulk.pbulk.conf">
<title>Configuration</title>
<para>TODO; see pkgsrc/doc/HOWTO-pbulk for more information.</para>
<para>TODO: continue writing</para>
</sect2>
</sect1>
<sect1 id="creating-cdroms">

44
doc/guide/files/components.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: components.xml,v 1.44 2012/10/17 16:16:32 abs Exp $ -->
<!-- $NetBSD: components.xml,v 1.50 2014/11/28 12:11:24 bsiegert Exp $ -->
<chapter id="components"> <?dbhtml filename="components.html"?>
<title>Package components - files, directories and contents</title>
@@ -30,25 +30,16 @@ sections.</para>
website.</para></listitem>
<listitem><para><varname>PKGNAME</varname> is the name of the
package, as used by pkgsrc. You only need to provide it if
package, as used by pkgsrc. You need to provide it if
<varname>DISTNAME</varname> (which is the default) is not a good
name for the package in pkgsrc. Usually it is the pkgsrc
name for the package in pkgsrc or <varname>DISTNAME</varname> is not
provided (no distribution file is required). Usually it is the pkgsrc
directory name together with the version number. It must match the
regular expression
<varname>^[A-Za-z0-9][A-Za-z0-9-_.+]*$</varname>, that is, it
starts with a letter or digit, and contains only letters, digits,
dashes, underscores, dots and plus signs.</para></listitem>
<listitem><para><varname>SVR4_PKGNAME</varname> is the name of
the package file to create if the <varname>PKGNAME</varname>
isn't unique on a SVR4 system. The default is
<varname>PKGNAME</varname>, which may be shortened when you use
<filename role="pkg">pkgtools/gensolpkg</filename>. Only add
<varname>SVR4_PKGNAME</varname> if <varname>PKGNAME</varname>
does not produce an unique package name on a SVR4 system.
The length of <varname>SVR4_PKGNAME</varname> is limited to 5
characters.</para></listitem>
<listitem><para><varname>CATEGORIES</varname> is a list of categories
which the package fits in. You can choose any of the top-level
directories of pkgsrc for it.</para>
@@ -80,7 +71,7 @@ converters games mbone print x11
<para>The second section contains information about separately
downloaded patches, if any.
<itemizedlist>
<listitem><para><varname>PATCHFILES:</varname>
<listitem><para><varname>PATCHFILES</varname>:
Name(s) of additional files that contain distribution patches.
There is no default. pkgsrc will look for them at
<varname>PATCH_SITES</varname>.
@@ -90,7 +81,12 @@ converters games mbone print x11
</listitem>
<listitem><para><varname>PATCH_SITES</varname>:
Primary location(s) for distribution patch files (see
<varname>PATCHFILES</varname> below) if not found locally.</para>
<varname>PATCHFILES</varname> above) if not found locally.</para>
</listitem>
<listitem><para><varname>PATCH_DIST_STRIP</varname>:
an argument to &man.patch.1; that sets the pathname strip count to
help find the correct files to patch. It defaults to
<command>-p0</command>.</para>
</listitem>
</itemizedlist></para>
<para>The third section contains the following variables.
@@ -608,9 +604,21 @@ MESSAGE_SUBST+= SOMEVAR="somevalue"
</listitem>
</varlistentry>
<varlistentry><term><filename>ALTERNATIVES</filename></term>
<listitem><para>FIXME: There is no documentation on the
alternatives framework.</para></listitem></varlistentry>
<varlistentry>
<term><filename>ALTERNATIVES</filename></term>
<listitem>
<para>This file is used by the alternatives framework.
It creates, configures, and destroys generic wrappers used to
run programs with similar interfaces.
See pkg_alternatives(8) from pkgtools/pkg_alternatives
for more information.</para>
<para>Each line of the file contains two filenames, first
the wrapper and then the alternative provided by the package.
Both paths are relative to <varname>PREFIX</varname>.</para>
</listitem>
</varlistentry>
</variablelist>

61
doc/guide/files/configuring.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: configuring.xml,v 1.39 2011/07/31 08:48:22 spz Exp $ -->
<!-- $NetBSD: configuring.xml,v 1.47 2015/01/06 20:35:59 bsiegert Exp $ -->
<chapter id="configuring">
<title>Configuring pkgsrc</title>
@@ -47,7 +47,7 @@ works.</para>
</listitem>
<listitem><para><varname>X11BASE</varname>: Where
X11 is installed on the system. The default is
<filename>/usr/X11R6</filename>.</para>
<filename>/usr/X11R7</filename>.</para>
</listitem>
<listitem><para><varname>DISTDIR</varname>: Where to store the
downloaded copies of the original source distributions used
@@ -124,8 +124,11 @@ works.</para>
<listitem><para><varname>DEPENDS_TARGET</varname>:
By default, dependencies are only installed, and no binary
package is created for them. You can set this variable to
<literal>package</literal> to automatically create binary
packages after installing dependencies.</para>
<literal>package-install</literal> to automatically create binary
packages after installing dependencies. Please note that the
<varname>PKGSRC_KEEP_BIN_PKGS</varname> can be set to
<literal>yes</literal> to preserve binary packages when
using the <literal>install</literal> as well.</para>
</listitem>
<!-- DISTDIR -->
@@ -151,14 +154,6 @@ works.</para>
you can set
<varname>USE_DESTDIR=no</varname>; this setting will be deprecated though,
so it's preferable to convert a package to DESTDIR instead.</para>
<para>DESTDIR support changes the behaviour of various targets
slightly. To install a package after building it, use
<literal>package-install</literal>. <literal>package</literal> and
<literal>install</literal> don't do that any
longer. <literal>package-install</literal> can be used as
<varname>DEPENDS_TARGET</varname>. <literal>bin-install</literal>
will ask for the root password to install the package and fail,
<literal>package-install</literal> will ask again.</para>
<para>With basic DESTDIR support, <userinput>make
clean</userinput> needs to be run as root.</para>
@@ -176,20 +171,20 @@ uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
should be needed
<programlisting>
&uprompt; make USE_DESTDIR=yes install
&uprompt; make stage-install
</programlisting>
Create a package without root privileges
<programlisting>
&uprompt; make USE_DESTDIR=yes PACKAGES=$HOME/packages package
&uprompt; make PACKAGES=$HOME/packages package
</programlisting>
For the following command, you must be able to gain root
privileges using &man.su.1;
<programlisting>
&uprompt; make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install
&uprompt; make PACKAGES=$HOME/packages install
</programlisting>
Then, as a simple user
@@ -222,29 +217,57 @@ uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
<!-- TODO: update this list after jlam's changes in May 2005 -->
<itemizedlist>
<listitem><para><varname>distcc</varname>:
distributed C/C++ (chainable)</para>
<listitem><para><varname>ccc</varname>:
Compaq C Compilers (Tru64)</para>
</listitem>
<listitem><para><varname>ccache</varname>:
compiler cache (chainable)</para>
</listitem>
<listitem><para><varname>clang</varname>:
Clang C and Objective-C compiler</para>
</listitem>
<listitem><para><varname>distcc</varname>:
distributed C/C++ (chainable)</para>
</listitem>
<listitem><para><varname>f2c</varname>:
Fortran 77 to C compiler (chainable)</para>
</listitem>
<listitem><para><varname>icc</varname>:
Intel C++ Compiler (Linux)</para>
</listitem>
<listitem><para><varname>ido</varname>:
SGI IRIS Development Option cc (IRIX 5)</para>
</listitem>
<listitem><para><varname>gcc</varname>:
GNU C/C++ Compiler</para>
</listitem>
<listitem><para><varname>hp</varname>:
HP-UX C/aC++ compilers</para>
</listitem>
<listitem><para><varname>mipspro</varname>:
Silicon Graphics, Inc. MIPSpro (n32/n64)</para>
</listitem>
<listitem><para><varname>mipspro</varname>:
<listitem><para><varname>mipspro-ucode</varname>:
Silicon Graphics, Inc. MIPSpro (o32)</para>
</listitem>
<listitem><para><varname>sunpro</varname>:
Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio</para>
</listitem>
<listitem><para><varname>xlc</varname>:
IBM's XL C/C++ compiler suite (Darwin/MacOSX)</para>
</listitem>
</itemizedlist>
<para>The default is
@@ -326,7 +349,7 @@ LDFLAGS+= -your -linkerflags
<title>Developer/advanced settings</title>
<!-- USE_ABI_DEPENDS -->
<para>XXX
<para><!-- XXX -->
<itemizedlist>
<listitem><para><varname>PKG_DEVELOPER</varname>:
Run some sanity checks that package developers want:

10
doc/guide/files/creating.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: creating.xml,v 1.16 2014/01/18 20:18:50 wiz Exp $ -->
<!-- $NetBSD: creating.xml,v 1.18 2014/05/09 07:04:16 obache Exp $ -->
<chapter id="creating">
<title>Creating a new pkgsrc package from scratch</title>
@@ -49,7 +49,7 @@ Your package may then look like this:</para>
<programlisting>
[...]
BUILD_DEPENDS+= lua>=5.0:../../lang/lua
BUILD_DEPENDS+= libxslt-[0-9]*:../../textproc/libxslt
DEPENDS+= screen-[0-9]*:../../misc/screen
DEPENDS+= screen>=4.0:../../misc/screen
@@ -122,11 +122,11 @@ package from the set of installed files.</para></step>
</sect2>
<sect2 id="creating.kde-app">
<title>KDE applications</title>
<title>KDE3 applications</title>
<para>KDE applications should always include
<para>KDE3 applications should always include
<filename>meta-pkgs/kde3/kde3.mk</filename>, which contains numerous
settings that are typical of KDE packages.</para>
settings that are typical of KDE3 packages.</para>
</sect2>

5
doc/guide/files/devfaq.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: devfaq.xml,v 1.11 2007/07/30 21:13:00 kano Exp $ -->
<!-- $NetBSD: devfaq.xml,v 1.13 2014/07/26 11:52:12 wiz Exp $ -->
<chapter id="devfaq"> <?dbhtml filename="devfaq.html"?>
<title>Frequently Asked Questions</title>
@@ -199,8 +199,7 @@ anyway.</para>
have.</para></listitem>
<listitem><para>Review packages for which review was requested on
the <ulink
url="http://pkgsrc-wip.sourceforge.net/">pkgsrc-wip</ulink> review
the <ulink url="http://www.NetBSD.org/mailinglists/index.html#tech-pkg">tech-pkg</ulink>
mailing list.</para></listitem>
</itemizedlist>
</answer></qandaentry>

13
doc/guide/files/faq.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: faq.xml,v 1.50 2014/02/03 16:09:34 wiz Exp $ -->
<!-- $NetBSD: faq.xml,v 1.51 2014/12/30 15:13:19 wiz Exp $ -->
<chapter id="faq"> <?dbhtml filename="faq.html"?>
<title>Frequently Asked Questions</title>
@@ -61,17 +61,6 @@ it contains items for both pkgsrc users and developers.</para>
<!-- ================================================================== -->
<sect1 id="pkgviews-docs">
<title>Where's the pkgviews documentation?</title>
<para>Pkgviews is tightly integrated with buildlink. You can find a
pkgviews User's guide in
<filename>pkgsrc/mk/buildlink3/PKGVIEWS_UG</filename>.</para>
</sect1>
<!-- ================================================================== -->
<sect1 id="faq-pkgtools">
<title>Utilities for package management (pkgtools)</title>

110
doc/guide/files/fixes.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: fixes.xml,v 1.123 2013/08/24 16:55:21 bsiegert Exp $ -->
<!-- $NetBSD: fixes.xml,v 1.130 2015/03/07 21:31:15 tnn Exp $ -->
<chapter id="fixes"> <?dbhtml filename="fixes.html"?>
<title>Making your package work</title>
@@ -476,31 +476,33 @@ DEPENDS+= {perl>=5.10.0,p5-version-[0-9]*}:../../devel/p5-version
<para>Your package may conflict with other packages a user might
already have installed on his system, e.g. if your package
installs the same set of files as another package in the pkgsrc
tree.</para>
tree or has the same <varname>PKGNAME</varname>.</para>
<para>In this case you can set <varname>CONFLICTS</varname> to a
<para>These cases are handled automatically by the packaging tools
at package installation time and do not need to be handled
manually.</para>
<para>In case the conflicts can not be recognized automatically
(e.g., packages using the same config file location but no other
shared files), you can set <varname>CONFLICTS</varname> to a
space-separated list of packages (including version string) your
package conflicts with.</para>
<para>For example, <filename role="pkg">x11/Xaw3d</filename>
and <filename role="pkg">x11/Xaw-Xpm</filename>
install the same shared library, thus you set in
<filename>pkgsrc/x11/Xaw3d/Makefile</filename>:</para>
<para>For example, if both <filename role="pkg">foo/bar</filename>
and <filename role="pkg">foo/baz</filename>
use the same config file, you would set in
<filename>foo/bar/Makefile</filename>:</para>
<programlisting>
CONFLICTS= Xaw-Xpm-[0-9]*
CONFLICTS= baz-[0-9]*
</programlisting>
<para>and in <filename>pkgsrc/x11/Xaw-Xpm/Makefile</filename>:</para>
<para>and in <filename>pkgsrc/foo/baz/Makefile</filename>:</para>
<programlisting>
CONFLICTS= Xaw3d-[0-9]*
CONFLICTS= bar-[0-9]*
</programlisting>
<para>Packages will automatically conflict with other packages
with the name prefix and a different version
string. <quote>Xaw3d-1.5</quote> e.g. will automatically
conflict with the older version <quote>Xaw3d-1.3</quote>.</para>
</sect2>
@@ -510,9 +512,20 @@ CONFLICTS= Xaw3d-[0-9]*
<para>There are several reasons why a package might be
instructed to not build under certain circumstances. If the
package builds and runs on most platforms, the exceptions
should be noted with <varname>NOT_FOR_PLATFORM</varname>. If
should be noted with <varname>BROKEN_ON_PLATFORM</varname>. If
the package builds and runs on a small handful of platforms,
set <varname>ONLY_FOR_PLATFORM</varname> instead.
set <varname>BROKEN_EXCEPT_ON_PLATFORM</varname> instead.
Both <varname>BROKEN_ON_PLATFORM</varname> and
<varname>BROKEN_EXCEPT_ON_PLATFORM</varname> are OS triples
(OS-version-platform) that can use glob-style
wildcards.</para>
<para>If a package is not appropriate for some platforms (as
oopposed to merely broken), a different set of variables should be
used as this affects failure reporting and statistics.
If the package is appropriate for most platforms, the exceptions
should be noted with <varname>NOT_FOR_PLATFORM</varname>. If
the package is appropriate for only a small handful of platforms
(often exactly one), set <varname>ONLY_FOR_PLATFORM</varname> instead.
Both <varname>ONLY_FOR_PLATFORM</varname> and
<varname>NOT_FOR_PLATFORM</varname> are OS triples
(OS-version-platform) that can use glob-style
@@ -765,6 +778,50 @@ FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
telling them that changing distfiles after releases without
changing the file names is not good practice.</para>
</sect2>
<sect2 id="build.fetch.github">
<title>Packages hosted on github.com</title>
<para>Helper methods exist for packages hosted on github.com which will often have distfile names that clash with other packages, for example <filename>1.0.tar.gz</filename>. Use one of the three recipes from below:
</para>
<sect3 id="build.fetch.github.tag">
<title>Fetch based on a tagged release</title>
<para>
If your distfile URL looks similar to <literal>http://github.com/username/exampleproject/archive/v1.0.zip</literal>, then you are packaging a tagged release.
</para>
<programlisting>
DISTNAME= exampleproject-1.0
MASTER_SITES= ${MASTER_SITE_GITHUB:=username/}
#GITHUB_PROJECT= # can be omitted if same as DISTNAME
GITHUB_TAG= v${PKGVERSION_NOREV}
EXTRACT_SUFX= .zip
</programlisting>
</sect3>
<sect3 id="build.fetch.github.commit">
<title>Fetch based on a specific commit</title>
<para>
If your distfile URL looks similar to <literal>http://github.com/example/example/archive/988881adc9fc3655077dc2d4d757d480b5ea0e11.tar.gz</literal>, then you are packaging a specific commit not tied to a release.
</para>
<programlisting>
DISTNAME= example-1.0
MASTER_SITES= ${MASTER_SITE_GITHUB:example/}
#GITHUB_PROJECT= # can be omitted if same as DISTNAME
GITHUB_TAG= 988881adc9fc3655077dc2d4d757d480b5ea0e11
</programlisting>
</sect3>
<sect3 id="build.fetch.github.release">
<title>Fetch based on release</title>
<para>
If your distfile URL looks similar to <literal>http://github.com/username/exampleproject/releases/download/rel-1.6/offensive-1.6.zip</literal>, then you are packaging a release.
</para>
<programlisting>
DISTNAME= offensive-1.6
PKGNAME= ${DISTNAME:S/offensive/proper/}
MASTER_SITES= ${MASTER_SITE_GITHUB:=username/}
GITHUB_PROJECT= exampleproject
GITHUB_RELEASE= rel-${PKGVERSION_NOREV} # usually just set this to ${DISTNAME}
EXTRACT_SUFX= .zip
</programlisting>
</sect3>
</sect2>
</sect1>
@@ -1094,9 +1151,9 @@ pre-configure:
and set <varname>REPLACE_PERL</varname> to ensure that the proper
interpreter path is set. <varname>REPLACE_PERL</varname> should
contain a list of scripts, relative to <varname>WRKSRC</varname>,
that you want adjusted. Every occurrence of
<filename>*/bin/perl</filename> will be replaced with the full
path to the perl executable.</para>
that you want adjusted. Every occurrence of
<filename>*/bin/perl</filename> in a she-bang line will be
replaced with the full path to the perl executable.</para>
<para>If a particular version of perl is needed, set the
<varname>PERL5_REQD</varname> variable to the version number. The
@@ -1114,6 +1171,10 @@ pre-configure:
and <varname>REPLACE_KSH</varname> can be used to replace shell
hash bangs in files. Please use the appropriate one, prefering
<varname>REPLACE_SH</varname> in case this shell is sufficient.
Each should contain a list of scripts, relative to
<varname>WRKSRC</varname>, that you want adjusted. Every
occurrence of the matching shell in a she-bang line will be
replaced with the full path to the shell executable.
When using <varname>REPLACE_BASH</varname>, don't forget to add
<filename>bash</filename> to <varname>USE_TOOLS</varname>.</para>
</sect2>
@@ -1187,6 +1248,7 @@ Haiku __HAIKU__
Interix __INTERIX
IRIX __sgi (TODO: get a definite source for this)
Linux linux, __linux, __linux__
Mac OS X __APPLE__
MirBSD __MirBSD__ (__OpenBSD__ is also defined)
Minix3 __minix
NetBSD __NetBSD__
@@ -1229,9 +1291,13 @@ SunPro C++ __SUNPRO_CC (0x580 for Sun C++ 5.8)
<para>Typically, a workaround involves testing the
<varname>MACHINE_ARCH</varname> and compiler version, disabling
optimisation for that combination of file,
<varname>MACHINE_ARCH</varname> and compiler, and documenting it
in <filename>pkgsrc/doc/HACKS</filename>. See that file for a
number of examples.</para>
<varname>MACHINE_ARCH</varname> and compiler.</para>
<para>This used to be a big problem in the past, but is rarely
needed now as compiler technology has matured. If you still need
to add a compiler specific workaround, please do so in the file
<filename>hacks.mk</filename> and describe the symptom and
compiler version as detailed as possible.</para>
</sect2>

29
doc/guide/files/getting.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: getting.xml,v 1.32 2013/11/07 08:52:43 jnemeth Exp $ -->
<!-- $NetBSD: getting.xml,v 1.33 2014/11/14 21:51:13 snj Exp $ -->
<chapter id="getting">
<title>Where to get pkgsrc and how to keep it up-to-date</title>
@@ -21,7 +21,7 @@ and dashes.</para>
quarterly basis from the current branch and only gets modified
for security updates. The names of the stable branches are built
from the year and the quarter, for example
<literal>2009Q1</literal>.</para>
<literal>2014Q3</literal>.</para>
<para>The second step is to decide <emphasis>how</emphasis> you
want to download pkgsrc. You can get it as a tar file or via CVS.
@@ -30,9 +30,6 @@ and dashes.</para>
<para>Note that tar archive contains CVS working copy.
Thus you can switch to using CVS at any later time.</para>
<para>Note also that quarterly branch is not frozen in stone.
It receives critical updates.</para>
<sect2 id="getting-via-tar">
<title>As tar archive</title>
@@ -58,9 +55,9 @@ and dashes.</para>
<para>You can fetch the same files using FTP.</para>
<para>The tar file for the stable branch 2013Q1 is in the
directory <filename>pkgsrc-2013Q1</filename> and is also called <ulink
url="ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-2013Q1/pkgsrc.tar.gz"><filename>pkgsrc.tar.gz</filename></ulink>.</para>
<para>The tar file for the stable branch 2014Q3 is in the
directory <filename>pkgsrc-2014Q3</filename> and is also called <ulink
url="ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-2014Q3/pkgsrc.tar.gz"><filename>pkgsrc.tar.gz</filename></ulink>.</para>
<para>To download a pkgsrc stable tarball, run:</para>
@@ -69,9 +66,9 @@ and dashes.</para>
<para>Where <replaceable>pkgsrc-20xxQy</replaceable> is the
stable branch to be downloaded, for example,
<quote>pkgsrc-2013Q1</quote>.</para>
<quote>pkgsrc-2014Q3</quote>.</para>
<para>You can use fetch it also using "wget", "curl",
<para>If you prefer, you can also fetch it using "wget", "curl",
or your web browser.</para>
<!--
<para>After downloading the tar file, change to the directory
@@ -81,7 +78,7 @@ and dashes.</para>
-->
<para>Then, extract it with:</para>
<screen>&uprompt; <userinput>tar -xzf <replaceable>pkgsrc-20xxQy</replaceable>.tar.gz -C /usr</userinput></screen>
<screen>&uprompt; <userinput>tar -xzf pkgsrc.tar.gz -C /usr</userinput></screen>
<para>This will create the directory <filename>pkgsrc/</filename>
in <filename>/usr/</filename> and all the package source will be
@@ -101,7 +98,7 @@ and dashes.</para>
</screen>
<para>Where <replaceable>pkgsrc-20xxQy</replaceable> is the stable
branch to be checked out, for example, <quote>pkgsrc-2009Q1</quote></para>
branch to be checked out, for example, <quote>pkgsrc-2014Q3</quote></para>
<para>This will create the directory <filename>pkgsrc/</filename>
in your <filename>/usr/</filename> directory and all the package source
@@ -112,7 +109,7 @@ and dashes.</para>
<screen>&uprompt; <userinput>cd /usr &amp;&amp; cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc</userinput>
</screen>
<para>Refer to the <ulink url="http://www.NetBSD.org/mirrors/">list of available mirrors</ulink> to choose a faster CVS mirror, if needed.</para>
<para>Refer to the <ulink url="http://www.NetBSD.org/mirrors/#anoncvs">list of available mirrors</ulink> to choose a faster CVS mirror, if needed.</para>
<!-- FIXME: All this CVS magic should move into appendix or so. -->
<para>If you get error messages from <literal>rsh</literal>, you need to set CVS_RSH variable. E.g.:</para>
@@ -171,8 +168,8 @@ release -d
<para>Note that by default the distfiles and the binary packages
are saved in the pkgsrc tree, so don't forget to rescue them
before updating. You can also configure pkgsrc to use other than
the default directories by setting the
before updating. You can also configure pkgsrc to store distfiles
and packages in directories outside the pkgsrc tree by setting the
<varname>DISTDIR</varname> and <varname>PACKAGES</varname>
variables. See <xref linkend="configuring"/> for the details.</para>
@@ -204,7 +201,7 @@ release -d
by adding the option <quote>-A</quote> after the
<quote>update</quote> keyword. To switch from the current branch
back to the stable branch, add the
<quote>-rpkgsrc-2009Q3</quote> option.</para>
<quote>-rpkgsrc-2014Q3</quote> option.</para>
</sect3>
<sect3 id="uptodate-cvs-changes">

2
doc/guide/files/introduction.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: introduction.xml,v 1.30 2013/08/22 13:54:51 ryoon Exp $ -->
<!-- $NetBSD: introduction.xml,v 1.32 2014/12/06 03:28:07 ryoon Exp $ -->
<chapter id="introduction">
<title>What is pkgsrc?</title>

4
doc/guide/files/makefile.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: makefile.xml,v 1.23 2007/06/01 11:07:25 rillig Exp $ -->
<!-- $NetBSD: makefile.xml,v 1.24 2014/12/03 07:05:05 ryoon Exp $ -->
<chapter id="makefile"> <?dbhtml filename="makefile.html"?>
<title>Programming in <filename>Makefile</filename>s</title>
@@ -209,7 +209,7 @@ EXT_LIST+= ${i:Q}""
nastiness.</para>
<programlisting>
STRING= foo bar < > * `date` $$HOME ' "
STRING= foo bar &lt; &gt; * `date` $$HOME ' "
EXT_LIST= string=${STRING:Q} x=second\ item
all:

6
doc/guide/files/pkginstall.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: pkginstall.xml,v 1.17 2012/05/16 16:46:43 wiz Exp $ -->
<!-- $NetBSD: pkginstall.xml,v 1.19 2014/06/10 15:09:42 joerg Exp $ -->
<chapter id="pkginstall"> <?dbhtml filename="pkginstall.html"?>
<title>The pkginstall framework</title>
@@ -219,7 +219,7 @@ set based upon the following variables:</para>
<filename>Makefile</filename> (i.e., it is not user-customizable).</para>
<para>As an example, consider the Apache package,
<filename role="pkg">www/apache2</filename>, which places its
<filename role="pkg">www/apache24</filename>, which places its
configuration files under the
<filename>httpd/</filename> subdirectory of
<varname>PKG_SYSCONFBASE</varname>. This should be set in the package
@@ -538,7 +538,7 @@ installation prefix. Consider the following example, taken from <filename
role="pkg">fonts/dbz-ttf</filename>:</para>
<programlisting>
FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF
FONTS_DIRS.ttf= ${PREFIX}/share/fonts/X11/TTF
</programlisting>
<!-- ================================================================== -->

6
doc/guide/files/pkgsrc.xml
View File

@@ -1,5 +1,5 @@
<?xml version="1.0"?>
<!-- $NetBSD: pkgsrc.xml,v 1.26 2007/09/18 08:17:21 rillig Exp $ -->
<!-- $NetBSD: pkgsrc.xml,v 1.28 2015/01/01 05:19:02 jnemeth Exp $ -->
<!DOCTYPE book PUBLIC "-//NetBSD//DTD DocBook XML V4.2-Based DocBook Extension//EN" [
@@ -42,12 +42,12 @@
</authorgroup>
<copyright>
<year>1994-2007</year>
<year>1994-2015</year>
<holder role="mailto:www@NetBSD.org">The NetBSD Foundation, Inc</holder>
</copyright>
<pubdate>$NetBSD: pkgsrc.xml,v 1.26 2007/09/18 08:17:21 rillig Exp $</pubdate>
<pubdate>$NetBSD: pkgsrc.xml,v 1.28 2015/01/01 05:19:02 jnemeth Exp $</pubdate>
<abstract>

29
doc/guide/files/plist.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: plist.xml,v 1.19 2009/08/25 13:19:50 wiz Exp $ -->
<!-- $NetBSD: plist.xml,v 1.21 2015/03/02 16:40:54 sevan Exp $ -->
<chapter id="plist">
<title>PLIST issues</title>
@@ -131,9 +131,10 @@ PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next;
</varlistentry>
</variablelist>
<para>For a complete list of values which are replaced by
default, please look in <filename>bsd.pkg.mk</filename> (and
search for <varname>PLIST_SUBST</varname>).</para>
<para>For a list of values which are replaced by
default, the output of <command>make help topic=PLIST_SUBST</command> as
well as searching the <filename>pkgsrc/mk</filename> directory with <command>grep</command> for
<varname>PLIST_SUBST</varname> should help.</para>
<para>If you want to change other variables not listed above, you
can add variables and their expansions to this variable in the
@@ -240,6 +241,24 @@ ${PLIST.foo}@dirrm share/bar
</itemizedlist>
</sect1>
<sect1 id="build-plist">
<title>Build-specific PLISTs</title>
<para>Some packages decide to generate hard-to-guess file names
during installation that are hard to wire down.</para>
<para>In such cases, you can set the
<varname>GENERATE_PLIST</varname> variable to shell code
terminated (with a semicolon) that will output PLIST entries which
will be appended to the PLIST</para>
<para>You can find one example in editors/xemacs:</para>
<programlisting>
GENERATE_PLIST+= ${ECHO} bin/${DISTNAME}-`${WRKSRC}/src/xemacs -sd`.dmp ;
</programlisting>
<para>which will append something like
<filename>bin/xemacs-21.4.23-54e8ea71.dmp</filename> to the
<filename>PLIST</filename>.
</para>
</sect1>
<sect1 id="faq.common-dirs">
<title>Sharing directories between packages</title>
@@ -261,6 +280,8 @@ ${PLIST.foo}@dirrm share/bar
<programlisting>
@pkgdir path/to/empty/directory
</programlisting>
or take a look at <varname>MAKE_DIRS</varname> and
<varname>OWN_DIRS</varname>.
</para>
</sect1>

22
doc/guide/files/porting.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: porting.xml,v 1.4 2007/04/19 16:54:58 joerg Exp $ -->
<!-- $NetBSD: porting.xml,v 1.5 2014/05/09 06:52:15 obache Exp $ -->
<chapter id="porting"> <?dbhtml filename="porting.html"?>
<title>Porting pkgsrc</title>
@@ -37,26 +37,6 @@
other files and edit it to your
needs.</para></listitem></varlistentry>
<varlistentry><term><filename>mk/platform/<replaceable>MyOS</replaceable>.pkg.dist</filename></term>
<listitem><para>This file contains a list of directories,
together with their permission bits and ownership. These
directories will be created automatically with every package
that explicitly sets <varname>USE_MTREE</varname>. This feature will
be removed.</para></listitem></varlistentry>
<varlistentry><term><filename>mk/platform/<replaceable>MyOS</replaceable>.x11.dist</filename></term>
<listitem><para>Just copy one of the pre-existing x11.dist files
to your
<filename><replaceable>MyOS</replaceable>.x11.dist</filename>.</para></listitem></varlistentry>
<varlistentry><term><filename>mk/tools/bootstrap.mk</filename></term>
<listitem><para>On some operating systems, the tools that are
provided with the base system are not good enough for pkgsrc.
For example, there are many versions of &man.sed.1; that have a
narrow limit on the line length they can process. Therefore
pkgsrc brings its own tools, which can be enabled
here.</para></listitem></varlistentry>
<varlistentry><term><filename>mk/tools/tools.<replaceable>MyOS</replaceable>.mk</filename></term>
<listitem><para>This file defines the paths to all the tools
that are needed by one or the other package in pkgsrc, as well

7
doc/guide/files/submit.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: submit.xml,v 1.28 2014/02/25 02:30:06 mspo Exp $ -->
<!-- $NetBSD: submit.xml,v 1.30 2014/08/12 05:12:41 schmonz Exp $ -->
<chapter id="submit"> <?dbhtml filename="submit.html"?>
<title>Submitting and Committing</title>
@@ -12,7 +12,7 @@
protect our users! You're still free to put up your home-made
binary packages and tell the world where to get them. NetBSD
developers doing bulk builds and wanting to upload them please
see <xref linkend="bulk-upload"/>.</para>
see <xref linkend="bulk"/><!-- TODO: was "bulk-upload"-->.</para>
</sect1>
@@ -115,8 +115,7 @@ you can check by running <quote>cvs status</quote>. An example:</para>
&uprompt; vi Makefile # add SUBDIRS+=pkgname line
&uprompt; cvs commit Makefile
&uprompt; cd pkgname
&uprompt; make CTYPE=Added changes-entry
&uprompt; make commit-changes-entry
&uprompt; make CTYPE=Added commit-changes-entry
</programlisting>
<para>The commit message of the initial import should include part of the

6
doc/guide/files/using.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: using.xml,v 1.38 2010/03/18 10:56:18 wiz Exp $ -->
<!-- $NetBSD: using.xml,v 1.39 2015/01/26 23:00:00 wiz Exp $ -->
<chapter id="using"> <?dbhtml filename="using.html"?>
<title>Using pkgsrc</title>
@@ -57,7 +57,7 @@ and you can still use binary packages from someone else.</para>
<title>Installing binary packages</title>
<para>In the directory from the last section, there is a
subdirectory called <filename>All</filename>, which contains all the
subdirectory called <filename>All/</filename>, which contains all the
binary packages that are available for the platform, excluding those
that may not be distributed via FTP or CDROM (depending on which
medium you are using).</para>
@@ -68,7 +68,7 @@ and you can still use binary packages from someone else.</para>
<screen>
&rprompt; <userinput>PATH="/usr/pkg/sbin:$PATH"</userinput>
&rprompt; <userinput>PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/<replaceable>OPSYS</replaceable>/<replaceable>ARCH</replaceable>/<replaceable>VERSIONS</replaceable>/All"</userinput>
&rprompt; <userinput>PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/<replaceable>OPSYS</replaceable>/<replaceable>ARCH</replaceable>/<replaceable>VERSIONS</replaceable>/All/"</userinput>
&rprompt; <userinput>export PATH PKG_PATH</userinput>
</screen>