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

Import of pkgsrc-2016Q3

Browse Source
This commit is contained in:
Lionel Sambuc
2016-10-14 07:49:11 +02:00
committed by Lionel Sambuc
parent 9d819b6d54
commit 1242aa1e36
35952 changed files with 949749 additions and 377083 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
doc/CHANGES-2012
View File

@@ -1,4 +1,4 @@
$NetBSD: CHANGES-2012,v 1.4036 2015/08/10 16:08:29 wiz Exp $
$NetBSD: CHANGES-2012,v 1.4037 2016/06/19 20:51:33 wiz Exp $
Changes to the packages collection and infrastructure in 2012:
@@ -606,6 +606,7 @@ Changes to the packages collection and infrastructure in 2012:
Updated textproc/xmlrpc-c to 1.16.39 [adam 2012-02-06]
Updated shells/mksh to 40d [bsiegert 2012-02-06]
Added multimedia/ffmpeg2theora version 0.28 [tron 2012-02-06]
Added net/php-geoip version 1.0.8 [fhajny 2012-02-06]
Updated cross/avrdude to 5.11 [mef 2012-02-07]
Updated www/trac to 0.12.3 [gdt 2012-02-07]
Updated biology/py-mol to 1.4.1nb2 [sbd 2012-02-07]

3
doc/CHANGES-2014
View File

@@ -1,4 +1,4 @@
$NetBSD: CHANGES-2014,v 1.4976 2015/01/25 18:35:10 wiz Exp $
$NetBSD: CHANGES-2014,v 1.4977 2016/06/19 20:51:33 wiz Exp $
Changes to the packages collection and infrastructure in 2014:
@@ -402,6 +402,7 @@ Changes to the packages collection and infrastructure in 2014:
Added inputmethod/uim-mozc version 1.13.1651.102 [ryoon 2014-01-20]
Updated databases/py-ckanclient to 0.10 [wiz 2014-01-20]
Updated devel/py-cheetah to 2.4.4nb1 [wiz 2014-01-20]
Added devel/py-ephem3 version 3.7.5.1 [wiz 2014-01-20]
Updated databases/py-cdb to 0.35 [wiz 2014-01-20]
Updated audio/py-audiotools to 2.20 [wiz 2014-01-20]
Updated emulators/suse131_openssl to 13.1nb2 [obache 2014-01-20]

1570
doc/CHANGES-2015
View File

File diff suppressed because it is too large Load Diff

5636
doc/CHANGES-2016 Normal file
View File

File diff suppressed because it is too large Load Diff

4
doc/CHANGES-pkgsrc-2015Q3
View File

@@ -1,4 +0,0 @@
$NetBSD: CHANGES-pkgsrc-2015Q3,v 1.1.2.1 2015/09/24 22:18:58 wiz Exp $
Changes to the packages collection and infrastructure on the 2015Q3 branch:

4
doc/CHANGES-pkgsrc-2016Q3 Normal file
View File

@@ -0,0 +1,4 @@
$NetBSD: CHANGES-pkgsrc-2016Q3,v 1.1.2.1 2016/09/30 09:56:29 jperkin Exp $
Changes to packages and infrastructure on the pkgsrc-2016Q3 branch:

10
doc/HOWTO-use-crosscompile
View File

@@ -1,7 +1,7 @@
Cross-compilation in pkgsrc (user's guide) -*- outline -*-
Taylor R. Campbell <riastradh@NetBSD.org>
$NetBSD: HOWTO-use-crosscompile,v 1.2 2013/05/11 20:15:10 riastradh Exp $
$NetBSD: HOWTO-use-crosscompile,v 1.4 2016/05/04 02:05:22 riastradh Exp $
The following steps enable you to build binary packages for a machine
architecture other than the one you are building on. For example, you
@@ -27,7 +27,7 @@ mk.conf.
$ ./build.sh -m evbppc distribution
By default, the destdir will be /usr/obj/destdir.evbppc, and the
tooldir will be (say) /usr/obj/tooldir.NetBSD-6.1.amd64 if you're
tooldir will be (say) /usr/obj/tooldir.NetBSD-6.1-amd64 if you're
running NetBSD 6.1 on amd64.
* Set up mk.conf
@@ -57,11 +57,11 @@ In addition to whatever else you want in your mk.conf for pkgsrc, add:
# XXX There is no obvious variable that is set to amd64 so that we
# could use
#
# TOOLDIR= /usr/obj/tooldir.${OPSYS}-${OS_VERSION}.${NATIVE_xyz}
# TOOLDIR= /usr/obj/tooldir.${OPSYS}-${OS_VERSION}-${NATIVE_xyz}
#
# MACHINE is amd64 but, since it's not NATIVE_xyz, it's wrong.
# NATIVE_MACHINE_ARCH is x86_64, not amd64.
TOOLDIR= /usr/obj/tooldir.NetBSD-6.1.amd64
TOOLDIR= /usr/obj/tooldir.NetBSD-6.1-amd64
CROSS_DESTDIR= /usr/obj/destdir.evbppc
# Put target work and packages in separate directories. (You might
@@ -125,7 +125,7 @@ messing with the package installations I use for development.
NetBSD srcdir: ~/netbsd/current/src
NetBSD objdir: ~/netbsd/current/obj.evbppc
NetBSD tooldir: ~/netbsd/current/obj.evbppc/tooldir.NetBSD-6.1.amd64
NetBSD tooldir: ~/netbsd/current/obj.evbppc/tooldir.NetBSD-6.1-amd64
NetBSD destdir: ~/netbsd/current/obj.evbppc/destdir.evbppc
pkgsrc: ~/pkgsrc/current/pkgsrc
pkgsrc LOCALBASE: ~/pkgsrc/current/pkg

4
doc/Makefile-example
View File

@@ -1,4 +1,4 @@
# $NetBSD: Makefile-example,v 1.23 2014/10/09 14:06:32 wiz Exp $
# $NetBSD: Makefile-example,v 1.24 2016/01/29 23:10:18 rillig Exp $
# First paragraph - distfile and binary package data
# DISTNAME PKGNAME PKGREVISION CATEGORIES MASTER_SITES
@@ -16,7 +16,7 @@ HOMEPAGE= http://www.gnu.org/software/make/make.html
COMMENT= GNU version of 'make' utility # start with a capital, no articles at start
LICENSE= hptools-license # Licenses should be added to the pkgsrc/licenses directory.
# Parapraph for any build or run dependencies -- not libraries,
# Paragraph for any build or run dependencies -- not libraries,
# those should be handled using buildlink3.mk files.
# Not needed for gmake, just an example:
# BUILD_DEPENDS+= automoc4-[0-9]*:../../devel/automoc4

1253
doc/TODO
View File

File diff suppressed because it is too large Load Diff

8
doc/guide/Makefile
View File

@@ -1,4 +1,4 @@
# $NetBSD: Makefile,v 1.39 2012/10/31 11:25:50 asau Exp $
# $NetBSD: Makefile,v 1.40 2016/06/11 18:14:42 rillig Exp $
#
DISTNAME= pkgsrc-guide-${PKGVERSION}
@@ -31,6 +31,12 @@ OUTPUTS?= lint html html-split ascii pdf
INSTALLATION_DIRS= ${DOCDIR}
SUBST_CLASSES+= docbook45
SUBST_STAGE.docbook45= pre-configure
SUBST_FILES.docbook45= ${WRKDIR}/htdocs/share/xml/*
SUBST_SED.docbook45= -e 's,V4\.2,V4.5,'
SUBST_SED.docbook45+= -e 's,/4\.2/,/4.5/,'
.if defined(OUTPUTS)
. if !empty(OUTPUTS:Mascii)
# the html is needed to build the ascii version.

6
doc/guide/Makefile.common
View File

@@ -1,4 +1,4 @@
# $NetBSD: Makefile.common,v 1.5 2014/10/05 16:41:06 wiz Exp $
# $NetBSD: Makefile.common,v 1.6 2016/06/11 18:14:42 rillig Exp $
#
# This is included by doc/guide and meta-pkgs/pkgsrc-guide-tools.
#
@@ -13,8 +13,8 @@ _GUIDE_DEPTYPE?= build
_GUIDE_OUTPUTS?= lint html html-split ascii pdf
# html output
_GUIDE_DEPENDS+= docbook>=4.0:../../textproc/docbook
_GUIDE_DEPENDS+= docbook-xml>=4.0:../../textproc/docbook-xml
_GUIDE_DEPENDS+= docbook>=4.5:../../textproc/docbook
_GUIDE_DEPENDS+= docbook-xml>=4.5:../../textproc/docbook-xml
_GUIDE_DEPENDS+= docbook-xsl>=1.62.4:../../textproc/docbook-xsl
_GUIDE_DEPENDS+= dsssl-docbook-modular>=1.54:../../textproc/dsssl-docbook-modular
_GUIDE_DEPENDS+= opensp>=1.5:../../textproc/opensp

7
doc/guide/files/Makefile
View File

@@ -1,6 +1,9 @@
# $NetBSD: Makefile,v 1.16 2008/02/19 17:21:42 weinem Exp $
# $NetBSD: Makefile,v 1.17 2016/06/11 18:14:42 rillig Exp $
WEB_PREFIX?= ${.CURDIR}/../htdocs
WEB_PREFIX?= ${.CURDIR}/../htdocs
DBX_XML_CATALOG?= ${SGML_PREFIX}/docbook/4.5/catalog.xml
DBX_XML_DTD?= ${XML_PREFIX}/docbook/4.5/docbookx.dtd
DBX_SGML_CATALOG?= ${SGML_PREFIX}/docbook/4.5/catalog
DOC= pkgsrc

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: binary.xml,v 1.34 2007/09/18 08:17:21 rillig Exp $ -->
<!-- $NetBSD: binary.xml,v 1.35 2016/07/10 07:43:23 rillig Exp $ -->
<chapter id="binary">
<title>Creating binary packages</title>
@@ -17,10 +17,10 @@
directory in pkgsrc, and run <command>make
package</command>:</para>
<screen>
&rprompt; <userinput>cd misc/figlet</userinput>
&rprompt; <userinput>make package</userinput>
</screen>
<screen>
&uprompt; <userinput>cd misc/figlet</userinput>
&uprompt; <userinput>make package</userinput>
</screen>
<para>This will build and install your package (if not already done),
and then build a binary package from what was installed. You can

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: build.xml,v 1.76 2015/08/31 11:54:29 leot Exp $ -->
<!-- $NetBSD: build.xml,v 1.77 2016/03/29 11:32:58 tnn Exp $ -->
<chapter id="build">
<title>The build process</title>
@@ -743,6 +743,13 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
<para>Some other variables are:</para>
<variablelist>
<varlistentry><term><varname>INSTALL_UNSTRIPPED</varname></term>
<listitem><para>If set to <literal>yes</literal>, do not run &man.strip.1;
when installing binaries. Any debugging sections and symbols present in
binaries will be preserved.
</para></listitem></varlistentry>
<varlistentry><term><varname>INSTALLATION_DIRS</varname></term>
<listitem><para>A list of directories relative to

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: buildlink.xml,v 1.38 2014/12/30 15:18:59 wiz Exp $ -->
<!-- $NetBSD: buildlink.xml,v 1.39 2016/07/10 07:46:29 rillig Exp $ -->
<chapter id="buildlink">
<title>Buildlink methodology</title>
@@ -206,20 +206,20 @@ BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0
<programlisting>
# &#36;NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp &#36;
BUILDLINK_TREE+= tiff
BUILDLINK_TREE+= tiff
.if !defined(TIFF_BUILDLINK3_MK)
TIFF_BUILDLINK3_MK:=
BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1
BUILDLINK_ABI_DEPENDS.tiff+= tiff>=3.7.2nb1
BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff
BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1
BUILDLINK_ABI_DEPENDS.tiff+= tiff>=3.7.2nb1
BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff
.include "../../devel/zlib/buildlink3.mk"
.include "../../graphics/jpeg/buildlink3.mk"
.endif # TIFF_BUILDLINK3_MK
BUILDLINK_TREE+= -tiff
BUILDLINK_TREE+= -tiff
</programlisting>
<para>The header and footer manipulate

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: bulk.xml,v 1.21 2014/07/27 08:28:28 wiz Exp $ -->
<!-- $NetBSD: bulk.xml,v 1.23 2016/07/10 07:46:29 rillig Exp $ -->
<chapter id="bulk">
<title>Creating binary packages for everything in pkgsrc (bulk
@@ -11,9 +11,8 @@ 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>
The bulk build system, or pbulk ("p" stands for "parallel").
This chapter describes how to set it up.</para>
<sect1 id="bulk.pre">
<title>Preparations</title>
@@ -25,13 +24,13 @@ 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.
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
Essentially, you should provide a 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
@@ -87,11 +86,11 @@ unprivileged user doesn't work well at the moment.</para></listitem>
<sect2 id="bulk.pbulk.conf">
<title>Configuration</title>
<para>To simplify configuration we provide helper script <filename>mk/pbulk/pbulk.sh</filename>.</para>
<para>To simplify configuration, we provide the 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>
Create a user with name "pbulk".</para>
<para>Fetch and extract pkgsrc. Use a command like one of these:</para>
@@ -116,23 +115,22 @@ Create user with name "pbulk".</para>
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)
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>
with your list of packages, one per line without empty lines or comments. E.g.:</para>
<programlisting>
www/firefox

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: components.xml,v 1.51 2015/07/04 16:12:54 joerg Exp $ -->
<!-- $NetBSD: components.xml,v 1.53 2016/07/10 07:46:29 rillig Exp $ -->
<chapter id="components"> <?dbhtml filename="components.html"?>
<title>Package components - files, directories and contents</title>
@@ -190,9 +190,9 @@ converters games mbone print x11
digest, or checksum, of each distfile needed for the package. This
ensures that the distfiles retrieved from the Internet have not been
corrupted during transfer or altered by a malign force to introduce
a security hole. Due to recent rumor about weaknesses of digest
algorithms, all distfiles are protected using both SHA1 and RMD160
message digests, as well as the file size.</para>
a security hole. To provide maximum security, all distfiles are
protected using three different message digest algorithms (SHA1,
RMD160, SHA512), as well as the file size.</para>
<para>The <filename>distinfo</filename> file also contains the
checksums for all the patches found in the
@@ -200,8 +200,7 @@ converters games mbone print x11
linkend="components.patches"/>).</para>
<para>To regenerate the <filename>distinfo</filename> file, use the
<command>make makedistinfo</command> or <command>make mdi</command>
command.</para>
<command>make distinfo</command> command.</para>
<para>Some packages have different sets of distfiles depending on
the platform, for example <filename
@@ -213,18 +212,16 @@ converters games mbone print x11
</sect1>
<sect1 id="components.patches">
<title>patches/*</title>
<title><filename>patches/*</filename></title>
<para>Many packages still don't work out-of-the box on the various
platforms that are supported by pkgsrc. Therefore, a number of custom
patch files are needed to make the package work. These patch files are
<para>Some packages don't work out-of-the box on the various
platforms that are supported by pkgsrc. These packages need
to be patched to make them work. The patch files can be
found in the <filename>patches/</filename> directory.</para>
<para>In the <emphasis>patch</emphasis> phase, these patches are
applied to the files in <varname>WRKSRC</varname> directory after
extracting them, in <ulink
url="http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_03">alphabetic
order</ulink>.</para>
extracting them, in alphabetic order.</para>
<sect2 id="components.patch.structure">
<title>Structure of a single patch file</title>
@@ -254,7 +251,7 @@ converters games mbone print x11
</itemizedlist>
<para>In all, the patch should be commented so that any
<para>The patch should be commented so that any
developer who knows the code of the application can make some use of
the patch. Special care should be taken for the upstream developers,
since we generally want that they accept our patches, so we have less
@@ -438,7 +435,7 @@ monitor_file(...)
int fd = kqueue();
...
#else
...
...
#endif
}
</programlisting>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: configuring.xml,v 1.47 2015/01/06 20:35:59 bsiegert Exp $ -->
<!-- $NetBSD: configuring.xml,v 1.51 2016/09/12 12:18:43 maya Exp $ -->
<chapter id="configuring">
<title>Configuring pkgsrc</title>
@@ -13,22 +13,16 @@ that file depends on the installation. On NetBSD, when you use
<literal>${PREFIX}/etc/</literal>, depending on where you told the
bootstrap program to install the binary packages.</para>
<para>During the bootstrap, an example configuration file is created. To
use that, you have to create the directory
<filename>${PREFIX}/etc</filename> and copy the example file
there.</para>
<para>The format of the configuration file is that of the usual
BSD-style <filename>Makefile</filename>s. The whole pkgsrc configuration
is done by setting variables in this file. Note that you can define all
kinds of variables, and no special error checking (for example for
spelling mistakes) takes place, so you have to try it out to see if it
works.</para>
spelling mistakes) takes place.</para>
<sect1 id="general-configuration">
<title>General configuration</title>
<para>In this section, you can find some variables that apply to all
<para>The following variables apply to all
pkgsrc packages. A complete list of the variables that can be
configured by the user is available in
<filename>mk/defaults/mk.conf</filename>, together with some
@@ -90,7 +84,7 @@ works.</para>
<sect1 id="variables-affecting-build">
<title>Variables affecting the build process</title>
<para>XXX
<para>
<itemizedlist>
<listitem><para><varname>PACKAGES</varname>: The top level
directory for the binary packages. The default is
@@ -139,7 +133,7 @@ works.</para>
<sect1 id="variables-affecting-installation">
<title>Variables affecting the installation process</title>
<para>Most packages support installation into a
<para>Packages have to support installation into a
subdirectory of <varname>WRKDIR</varname>. This allows a package
to be built, before the actual filesystem is touched. DESTDIR
support exists in two variations:</para>
@@ -150,10 +144,6 @@ works.</para>
build, installation and packaging as normal user. Root
privileges are only needed to add packages.</para></listitem>
</itemizedlist>
<para>DESTDIR support is now the default. To switch back to non-DESTDIR,
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>With basic DESTDIR support, <userinput>make
clean</userinput> needs to be run as root.</para>
@@ -296,6 +286,33 @@ uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
install one of the GCC packages to use instead.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>PYTHON_DEFAULT_VERSION</varname>:</term>
<listitem>
<para>Specifies which version of python to use when several
options are available.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>PKGSRC_FORTRAN</varname>:</term>
<listitem>
<para>Specifies the fortran compiler to use.
The default is <varname>g95</varname>, and
<varname>gfortran</varname> is an alternative.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>GFORTRAN_VERSION</varname>:</term>
<listitem>
<para>If <varname>PKGSRC_FORTRAN</varname><literal>=</literal>
<varname>gfortran</varname> is used, this option specifies which
version to use.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
@@ -370,8 +387,8 @@ LDFLAGS+= -your -linkerflags
(normal, default, quiet operation); the value 1 will display
all shell commands before their invocation, and the value 2
will display both the shell commands before their invocation,
and their actual execution progress with <command>set
-x</command> will be displayed.</para></listitem>
as well as their actual execution progress with <command>set
-x</command>.</para></listitem>
</itemizedlist>
</para>
</sect1>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: creating.xml,v 1.19 2015/04/14 11:21:05 wiz Exp $ -->
<!-- $NetBSD: creating.xml,v 1.21 2016/06/30 18:03:46 wiz Exp $ -->
<chapter id="creating">
<title>Creating a new pkgsrc package from scratch</title>
@@ -145,9 +145,24 @@ PYTHON_VERSIONS_INCOMPATIBLE= 27
</programlisting></para>
<para>
If the packaged software is a Python module, include
<quote><filename>../../lang/python/extension.mk</filename></quote>.
In this case, the package directory should be called
If the packaged software is a Python module, include one of
<filename>../../lang/python/egg.mk</filename>,
<filename>../../lang/python/distutils.mk</filename>, or
<filename>../../lang/python/extension.mk</filename>.</para>
<para>Most Python packages use either <quote>distutils</quote> or
easy-setup/setuptools (<quote>eggs</quote>).
if the packaged software is using setuptools, you only need
to include <quote><filename>../../lang/python/egg.mk</filename></quote>.
Otherwise, if the software uses <quote>distutils</quote>, include
<quote><filename>../../lang/python/distutils.mk</filename></quote>.
so pkgsrc will use this framework.
<quote>distutils</quote> uses a script called <filename>setup.py</filename>,
if the <quote>distutils</quote> driver is not called
<filename>setup.py</filename>, set the <varname>PYSETUP</varname> variable
to the name of the script.</para>
<para>Either way, the package directory should be called
<quote>py-software</quote> and <varname>PKGNAME</varname> should be set to
<quote>${PYPKGPREFIX}-${DISTNAME}</quote>, e.g.
<programlisting>
@@ -165,20 +180,6 @@ For example:
REPLACE_PYTHON= *.py
</programlisting></para>
<para>Most Python packages use either <quote>distutils</quote> or
easy-setup (<quote>eggs</quote>).
If the software uses <quote>distutils</quote>, include
<quote><filename>../../lang/python/distutils.mk</filename></quote>.
so pkgsrc will use this framework.
<quote>distutils</quote> uses a script called <filename>setup.py</filename>,
if the <quote>distutils</quote> driver is not called
<filename>setup.py</filename>, set the <varname>PYSETUP</varname> variable
to the name of the script.</para>
<para>Otherwise, if the packaged software is egg-aware, you only need
to include
<quote><filename>../../lang/python/egg.mk</filename></quote>.</para>
<para>Some Python modules have separate distributions for Python-2.x
and Python-3.x support. In pkgsrc this is handled by the
<filename>versioned_dependencies.mk</filename> file. Set
@@ -188,7 +189,7 @@ packages that should be depended upon and include
then the pkgsrc infrastructure will depend on the appropriate package
version. For example:
<programlisting>
PYTHON_VERSIONED_DEPENDENCIES=dateutil dns
PYTHON_VERSIONED_DEPENDENCIES=dateutil
</programlisting>
Look inside <filename>versioned_dependencies.mk</filename> for a list
of supported packages.</para>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: devfaq.xml,v 1.13 2014/07/26 11:52:12 wiz Exp $ -->
<!-- $NetBSD: devfaq.xml,v 1.14 2016/06/11 18:14:42 rillig Exp $ -->
<chapter id="devfaq"> <?dbhtml filename="devfaq.html"?>
<title>Frequently Asked Questions</title>
@@ -79,21 +79,21 @@
<qandaentry id="devfaq.master_sites">
<question><para>What does
<literal>${MASTER_SITE_SOURCEFORGE:=package/}</literal> mean? I
don't understand the <literal>:=</literal> inside
<code>${MASTER_SITE_SOURCEFORGE:=package/}</code> mean? I
don't understand the <code>:=</code> inside
it.</para></question>
<answer><para>The <literal>:=</literal> is not really an
assignment operator, like you might expect at first sight.
<answer><para>The <code>:=</code> is not really an
assignment operator, although it looks like it.
Instead, it is a degenerate form of
<literal>${LIST:<replaceable>old_string</replaceable>=<replaceable>new_string</replaceable>}</literal>,
which is documented in the &man.make.1; man page and which you
may have seen as in <literal>${SRCS:.c=.o}</literal>. In the
<code>${LIST:<replaceable>old_string</replaceable>=<replaceable>new_string</replaceable>}</code>,
which is documented in the &man.make.1; man page and which is
commonly used in the form <code>${SRCS:.c=.o}</code>. In the
case of <varname>MASTER_SITE_*</varname>,
<replaceable>old_string</replaceable> is the empty string and
<replaceable>new_string</replaceable> is
<literal>package/</literal>. That's where the
<literal>:</literal> and the <literal>=</literal> fall
<code>package/</code>. That's where the
<code>:</code> and the <code>=</code> fall
together.</para></answer>
</qandaentry>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: faq.xml,v 1.51 2014/12/30 15:13:19 wiz Exp $ -->
<!-- $NetBSD: faq.xml,v 1.54 2016/07/10 07:46:29 rillig Exp $ -->
<chapter id="faq"> <?dbhtml filename="faq.html"?>
<title>Frequently Asked Questions</title>
@@ -222,25 +222,16 @@ utilities)</para>
<sect1 id="non-root-pkgsrc">
<title>How to use pkgsrc as non-root</title>
<para>If you want to use pkgsrc as non-root user, you can set some
variables to make pkgsrc work under these conditions. At the very least,
you need to set <varname>UNPRIVILEGED</varname> to <quote>yes</quote>; this
will turn on unprivileged mode and set multiple related variables to allow
installation of packages as non-root.</para>
<para>To install packages from source as a non-root user, download
pkgsrc as described in <xref linkend="getting"/>, cd into that
directory and run the command <command>./bootstrap/bootstrap
--unprivileged</command>.</para>
<para>In case the defaults are not enough, you may want to tune some other
variables used. For example, if the automatic user/group detection leads
to incorrect values (or not the ones you would like to use), you can change
them by setting <varname>UNPRIVILEGED_USER</varname> and
<varname>UNPRIVILEGED_GROUP</varname> respectively.</para>
<para>This will install the binary part of pkgsrc to
<filename>~/pkg</filename> and put the pkgsrc configuration &mk.conf;
into <filename>~/pkg/etc</filename>.</para>
<para>As regards bootstrapping, please note that the
<command>bootstrap</command> script will ease non-root configuration when
given the <quote>--ignore-user-check</quote> flag, as it will choose and
use multiple default directories under <filename>~/pkg</filename> as the
installation targets. These directories can be overridden by the
<quote>--prefix</quote> flag provided by the script, as well as some others
that allow finer tuning of the tree layout.</para>
<para>For more details, see <filename>mk/unprivileged.mk</filename>.</para>
</sect1>
@@ -270,7 +261,7 @@ provide <varname>FETCH_CMD</varname>, <varname>FETCH_BEFORE_ARGS</varname>,
like:</para>
<programlisting>
FETCH_USING= wget
FETCH_USING= wget
</programlisting>
</sect1>
@@ -596,6 +587,9 @@ check.</para>
extracted. Run <command>make clean clean-depends</command> to
verify this.</para></step>
<step><para>If you are a package developer who wants to invest
some work, have a look at <xref linkend="fixes"/>.</para></step>
<step><para>If the problem still exists, write a mail to the
<literal>pkgsrc-users</literal> mailing list.</para></step>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: fixes.xml,v 1.133 2015/08/31 11:54:29 leot Exp $ -->
<!-- $NetBSD: fixes.xml,v 1.144 2016/07/16 14:28:49 jakllsch Exp $ -->
<chapter id="fixes"> <?dbhtml filename="fixes.html"?>
<title>Making your package work</title>
@@ -6,15 +6,11 @@
<sect1 id="general-operation">
<title>General operation</title>
<sect2 id="portability-of-packages">
<title>Portability of packages</title>
<para>One appealing feature of pkgsrc is that it runs on many
different platforms. As a result, it is important to ensure,
where possible, that packages in pkgsrc are portable. This
chapter mentions some particular details you should pay
attention to while working on pkgsrc.</para>
</sect2>
<para>One appealing feature of pkgsrc is that it runs on many
different platforms. As a result, it is important to ensure,
where possible, that packages in pkgsrc are portable. This
chapter mentions some particular details you should pay
attention to while working on pkgsrc.</para>
<sect2 id="pulling-vars-from-etc-mk.conf">
<title>How to pull in user-settable variables from &mk.conf;</title>
@@ -31,16 +27,17 @@
<para>But note that some variables may not be completely defined
after <filename>../../mk/bsd.prefs.mk</filename> has been
included, as they may contain references to variables that are
not yet defined. In shell commands this is no problem, since
variables are actually macros, which are only expanded when they
are used. But in the preprocessor directives mentioned above and
in dependency lines (of the form <literal>target:
not yet defined. In shell commands (the lines in
<filename>Makefile</filename> that are indented with a tab) this
is no problem, since variables are only expanded when they are
used. But in the preprocessor directives mentioned above and in
dependency lines (of the form <literal>target:
dependencies</literal>) the variables are expanded at load
time.</para>
<note><para>Currently there is no exhaustive list of all
variables that tells you whether they can be used at load time
or only at run time, but it is in preparation.</para></note>
<note><para>To check whether a variable can be used at load time,
run <command>pkglint -Wall</command> on your package.</para></note>
</sect2>
<sect2 id="user-interaction">
@@ -75,103 +72,49 @@
</listitem>
</itemizedlist>
<para>The <varname>INTERACTIVE_STAGE</varname> definition is
provided to notify the pkgsrc mechanism of an interactive stage
which will be needed, and this should be set in the package's
<filename>Makefile</filename>, e.g.:</para>
<para>A package can set the <varname>INTERACTIVE_STAGE</varname>
variable to define which stages need interaction. This should be
done in the package's <filename>Makefile</filename>, e.g.:</para>
<programlisting>
INTERACTIVE_STAGE= build
</programlisting>
<para>Multiple interactive stages can be specified:</para>
<programlisting>
<programlisting>
INTERACTIVE_STAGE= configure install
</programlisting>
</programlisting>
<para>The user can then decide to skip this package by setting the
<varname>BATCH</varname> variable.</para>
<varname>BATCH</varname> variable. Packages that require interaction
are also excluded from bulk builds.</para>
</sect2>
<sect2 id="handling-licenses">
<title>Handling licenses</title>
<para>Authors of software can choose the licence under which
software can be copied. This is due to copyright law, and reasons
for license choices are outside the scope of pkgsrc. The pkgsrc
system recognizes that there are a number of licenses which some
users may find objectionable or difficult or impossible to comply
with. The Free Software Foundation has declared some licenses
"Free", and the Open Source Initiative has a definition of "Open
Source". The pkgsrc system, as a policy choice, does not label
packages which have licenses that are Free or Open Source.
However, packages without a license meeting either of those tests
are labeled with a license tag denoting the license. Note that a
package with no license to copy trivially does not meet either the
Free or Open Source test.</para>
<para>Authors of software can choose the licence under which software
can be copied. The Free Software Foundation has declared some
licenses "Free", and the Open Source Initiative has a definition of
"Open Source".</para>
<para>For packages which are not Free or Open Source, pkgsrc will
not build the package unless the user has indicated to pkgsrc that
packages with that particular license may be built. Note that
this documentation avoids the term "accepted the license". The
pkgsrc system is merely providing a mechanism to avoid
accidentally building a package with a non-free license;
judgement and responsibility remain with the user. (Installation
of binary packages are not currently subject to this mechanism;
this is a bug.)</para>
<para>By default, pkgsrc allows packages with Free or Open Source
licenses to be built. To allow packages with other licenses to be
built as well, the pkgsrc user needs to add these licenses to the
<varname>ACCEPTABLE_LICENSES</varname> variable in &mk.conf;. Note
that this variable only affects which packages may be
<emphasis>built</emphasis>, while the license terms often also
restrict the actual use of the package and its redistribution.</para>
<para>One might want to only install packages with a BSD license,
or the GPL, and not the other. The free licenses are added to the
default <varname>ACCEPTABLE_LICENSES</varname> variable. The
or the GPL, and not the other. The free licenses are added to the
default <varname>ACCEPTABLE_LICENSES</varname> variable. The pkgsrc
user can override the default by setting the
<varname>ACCEPTABLE_LICENSES</varname> variable with "=" instead
of "+=". The licenses accepted by default are:
<programlisting>
apache-1.1 apache-2.0
arphic-public
artistic artistic-2.0
boost-license
cc-by-sa-v3.0
cc0-1.0-universal
cddl-1.0
cpl-1.0
epl-v1.0
gnu-fdl-v1.1 gnu-fdl-v1.2 gnu-fdl-v1.3
gnu-gpl-v1
gnu-gpl-v2 gnu-lgpl-v2 gnu-lgpl-v2.1
gnu-gpl-v3 gnu-lgpl-v3
ibm-public-license-1.0
ipafont
isc
lppl-1.3c
lucent
miros
mit
mpl-1.0 mpl-1.1 mpl-2.0
mplusfont
ofl-v1.0 ofl-v1.1
original-bsd modified-bsd 2-clause-bsd
php
png-license
postgresql-license
public-domain
python-software-foundation
qpl-v1.0
sgi-free-software-b-v2.0
sleepycat-public
unlicense
x11
zlib
zpl
</programlisting>
</para>
of "+=". The licenses accepted by default are defined in the
<varname>DEFAULT_ACCEPTABLE_LICENSES</varname> variable in the file
<filename>pkgsrc/mk/license.mk</filename>.</para>
<para>The license tag mechanism is intended to address
copyright-related issues surrounding building, installing and
using a package, and not to address redistribution issues (see
<varname>RESTRICTED</varname> and
<varname>NO_SRC_ON_FTP</varname>, etc.).
<varname>NO_SRC_ON_FTP</varname>, etc.).
Packages with redistribution restrictions should set these
tags.</para>
@@ -182,22 +125,22 @@ INTERACTIVE_STAGE= configure install
license, e.g. in <filename
role="pkg">graphics/xv</filename>:</para>
<programlisting>
<programlisting>
LICENSE= xv-license
</programlisting>
</programlisting>
<para>When trying to build, the user will get a notice that the
package is covered by a license which has not been placed in the
<varname>ACCEPTABLE_LICENSES</varname> variable:</para>
<programlisting>
<programlisting>
&cprompt; <userinput>make</userinput>
===> xv-3.10anb9 has an unacceptable license: xv-license.
===> To view the license, enter "/usr/bin/make show-license".
===> To indicate acceptance, add this line to your /etc/mk.conf:
===> ACCEPTABLE_LICENSES+=xv-license
*** Error code 1
</programlisting>
</programlisting>
<para>The license can be viewed with <command>make
show-license</command>, and if the user so chooses, the line
@@ -205,31 +148,9 @@ LICENSE= xv-license
convey to pkgsrc that it should not in the future fail because of
that license:</para>
<programlisting>
<programlisting>
ACCEPTABLE_LICENSES+=xv-license
</programlisting>
<para>When adding a package with a new license, the following steps
are required:</para>
<orderedlist>
<listitem><para>Check if the file can avoid the -license filename tag as described above by referencing <ulink url="http://www.gnu.org/licenses/license-list.html">Various Licenses and Comments about Them</ulink> and <ulink url="http://opensource.org/licenses/alphabetical">Licenses by Name | Open Source Initiative</ulink>. If this is the case, additionally add the license filename to:</para>
<itemizedlist>
<listitem><para>DEFAULT_ACCEPTABLE_LICENSES in <filename>pkgsrc/mk/license.mk</filename></para></listitem>
<listitem><para>default_acceptable_licenses in <filename>pkgsrc/pkgtools/pkg_install/files/lib/license.c</filename></para></listitem>
<listitem><para>the ACCEPTABLE_LICENSES list in <filename>pkgsrc/doc/guide/files/fixes.xml</filename></para></listitem>
</itemizedlist>
<para>with the proper syntax as demonstrated in those files, respectively.</para></listitem>
<listitem><para>The license text should be added to <filename>pkgsrc/licenses</filename> for displaying. A list of known licenses can be seen in this directory.</para></listitem>
</orderedlist>
<para>When the license changes (in a way other than formatting),
please make sure that the new license has a different name (e.g.,
append the version number if it exists, or the date). Just
because a user told pkgsrc to build programs under a previous
version of a license does not mean that pkgsrc should build
programs under the new licenses. The higher-level point is that
pkgsrc does not evaluate licenses for reasonableness; the only
test is a mechanistic test of whether a particular text has been
approved by either of two bodies.</para>
</programlisting>
<para>The use of <varname>LICENSE=shareware</varname>,
<varname>LICENSE=no-commercial-use</varname>, and similar language
@@ -237,28 +158,70 @@ ACCEPTABLE_LICENSES+=xv-license
license text. Another problem with such usage is that it does not
enable a user to tell pkgsrc to proceed for a single package
without also telling pkgsrc to proceed for all packages with that
tag.</para> </sect2>
tag.</para>
<sect3 id="new-license">
<title>Adding a package with a new license</title>
<para>When adding a package with a new license, the following steps
are required:</para>
<orderedlist>
<listitem><para>Check whether the license qualifies as Free or Open
Source by referencing <ulink
url="http://www.gnu.org/licenses/license-list.en.html">Various Licenses
and Comments about Them</ulink> and <ulink
url="http://opensource.org/licenses/alphabetical">Licenses by Name |
Open Source Initiative</ulink>. If this is the case, the filename in
<filename>pkgsrc/licenses/</filename> does not need the
<filename>-license</filename> suffix, and the license name should be
added to:</para>
<itemizedlist>
<listitem><para>DEFAULT_ACCEPTABLE_LICENSES in <filename>pkgsrc/mk/license.mk</filename></para></listitem>
<listitem><para>default_acceptable_licenses in <filename>pkgsrc/pkgtools/pkg_install/files/lib/license.c</filename></para></listitem>
</itemizedlist>
</listitem>
<listitem><para>The license text should be added to <filename>pkgsrc/licenses</filename> for displaying. A list of known licenses can be seen in this directory.</para></listitem>
</orderedlist>
</sect3>
<sect3 id="change-license">
<title>Change to the license</title>
<para>When the license changes (in a way other than formatting),
make sure that the new license has a different name (e.g.,
append the version number if it exists, or the date). Just
because a user told pkgsrc to build programs under a previous
version of a license does not mean that pkgsrc should build
programs under the new licenses. The higher-level point is that
pkgsrc does not evaluate licenses for reasonableness; the only
test is a mechanistic test of whether a particular text has been
approved by either of two bodies (FSF or OSI).</para>
</sect3>
</sect2>
<sect2 id="restricted-packages">
<title>Restricted packages</title>
<para>Some licenses restrict how software may be re-distributed.
Because a license tag is required unless the package is Free or
Open Source, all packages with restrictions should have license
tags. By declaring the restrictions, package tools can
By declaring the restrictions, package tools can
automatically refrain from e.g. placing binary packages on FTP
sites.</para>
<para>There are four restrictions that may be encoded, which are
<para>There are four possible restrictions, which are
the cross product of sources (distfiles) and binaries not being
placed on FTP sites and CD-ROMs. Because this is rarely the exact
language in any license, and because non-Free licenses tend to be
different from each other, pkgsrc adopts a definition of FTP and
CD-ROM. Pkgsrc uses "FTP" to mean that the source or binary file
should not be made available over the Internet at no charge.
Pkgsrc uses "CD-ROM" to mean that the source or binary may not be
made available on some kind of media, together with other source
and binary packages, and which is sold for a distribution charge.
CD-ROM.
"FTP" means making the source or binary file available over the
Internet at no charge.
"CD-ROM" means making the source or binary available on some kind of
media, together with other source and binary packages, which is sold
for a distribution charge.
</para>
<para>In order to encode these restrictions, the package system
@@ -314,11 +277,11 @@ ACCEPTABLE_LICENSES+=xv-license
</listitem>
</itemizedlist>
<para>Please note that packages will to be removed from pkgsrc
when the distfiles are not distributable and cannot be obtained
for a period of one full quarter branch. Packages with manual /
interactive fetch must have a maintainer and it is his/her
responsibility to ensure this.</para>
<para>Please note that packages will be removed from pkgsrc when the
distfiles are not distributable and cannot be obtained for a period
of one full quarter branch. Packages with manual/interactive fetch
must have a maintainer and it is his/her responsibility to ensure
this.</para>
</sect2>
@@ -348,9 +311,9 @@ ACCEPTABLE_LICENSES+=xv-license
<para>The format for a <varname>BUILD_DEPENDS</varname> and a
<varname>DEPENDS</varname> definition is:</para>
<programlisting>
<programlisting>
&lt;pre-req-package-name&gt;:../../&lt;category&gt;/&lt;pre-req-package&gt;
</programlisting>
</programlisting>
<para>Please note that the <quote>pre-req-package-name</quote>
may include any of the wildcard version numbers recognized by
@@ -362,9 +325,9 @@ ACCEPTABLE_LICENSES+=xv-license
libraries to build and run, and if that package has a
<filename>buildlink3.mk</filename> file available, use it:</para>
<programlisting>
<programlisting>
.include "../../graphics/jpeg/buildlink3.mk"
</programlisting>
</programlisting>
</listitem>
<listitem>
@@ -372,9 +335,9 @@ ACCEPTABLE_LICENSES+=xv-license
libraries only for building, and if that package has a
<filename>buildlink3.mk</filename> file available, use it:</para>
<programlisting>
<programlisting>
.include "../../graphics/jpeg/buildlink3.mk"
</programlisting>
</programlisting>
<para>but set
<varname>BUILDLINK_DEPMETHOD.<replaceable>jpeg</replaceable>?=build</varname>
to make it a build dependency only. This case is rather
@@ -385,9 +348,9 @@ ACCEPTABLE_LICENSES+=xv-license
<para>If your package needs binaries from another package to build,
use the <varname>BUILD_DEPENDS</varname> definition:</para>
<programlisting>
<programlisting>
BUILD_DEPENDS+= scons-[0-9]*:../../devel/scons
</programlisting>
</programlisting>
</listitem>
<listitem>
@@ -407,9 +370,9 @@ BUILD_DEPENDS+= scons-[0-9]*:../../devel/scons
be able to execute the latex binary from the teTeX package
when it runs, and that is specified:</para>
<programlisting>
<programlisting>
DEPENDS+= teTeX-[0-9]*:../../print/teTeX
</programlisting>
</programlisting>
</listitem>
<listitem>
<para>You can use wildcards in package dependencies. Note that
@@ -427,9 +390,9 @@ DEPENDS+= teTeX-[0-9]*:../../print/teTeX
will only build against a certain minimum version of a
pre-requisite:</para>
<programlisting>
<programlisting>
DEPENDS+= ImageMagick>=6.0:../../graphics/ImageMagick
</programlisting>
</programlisting>
<para>This means that the package will build using version 6.0
of ImageMagick or newer. Such a dependency may be warranted
@@ -479,15 +442,15 @@ DEPENDS+= ImageMagick>=6.0:../../graphics/ImageMagick
use the same config file, you would set in
<filename>foo/bar/Makefile</filename>:</para>
<programlisting>
<programlisting>
CONFLICTS= baz-[0-9]*
</programlisting>
</programlisting>
<para>and in <filename>pkgsrc/foo/baz/Makefile</filename>:</para>
<programlisting>
<programlisting>
CONFLICTS= bar-[0-9]*
</programlisting>
</programlisting>
</sect2>
@@ -506,7 +469,7 @@ CONFLICTS= bar-[0-9]*
(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
opposed 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
@@ -580,10 +543,10 @@ CONFLICTS= bar-[0-9]*
(2, ...). The <quote>nb</quote> is treated like a
<quote>.</quote> by the package tools. e.g.</para>
<programlisting>
<programlisting>
DISTNAME= foo-17.42
PKGREVISION= 9
</programlisting>
</programlisting>
<para>will result in a <varname>PKGNAME</varname> of
<quote>foo-17.42nb9</quote>. If you want to use the original
@@ -595,9 +558,9 @@ PKGREVISION= 9
<varname>PKGREVISION</varname> should be removed, e.g. on a new
minor release of the above package, things should be like:</para>
<programlisting>
<programlisting>
DISTNAME= foo-17.43
</programlisting>
</programlisting>
<para><varname>PKGREVISION</varname> should be incremented for any
non-trivial change in the resulting binary package. Without a
@@ -642,7 +605,7 @@ DISTNAME= foo-17.43
easy-to-use interface for replacing text in files.
Example:</para>
<programlisting>
<programlisting>
SUBST_CLASSES+= fix-paths
SUBST_STAGE.fix-paths= pre-configure
SUBST_MESSAGE.fix-paths= Fixing absolute paths.
@@ -650,7 +613,7 @@ SUBST_FILES.fix-paths= src/*.c
SUBST_FILES.fix-paths+= scripts/*.sh
SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g'
SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g'
</programlisting>
</programlisting>
<para><varname>SUBST_CLASSES</varname> is a list of identifiers
that are used to identify the different SUBST blocks that are
@@ -703,7 +666,7 @@ SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g'
</sect2>
</sect1>
<sect1 id="fixes.fetch">
<title>Fixing problems in the <emphasis>fetch</emphasis> phase</title>
<title>The <emphasis>fetch</emphasis> phase</title>
<sect2 id="no-plain-download">
<title>Packages whose distfiles aren't available for plain downloading</title>
@@ -722,11 +685,11 @@ SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g'
<varname>FETCH_MESSAGE</varname> to a list of lines that are
displayed to the user before aborting the build. Example:</para>
<programlisting>
<programlisting>
FETCH_MESSAGE= "Please download the files"
FETCH_MESSAGE+= " "${DISTFILES:Q}
FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
</programlisting>
</programlisting>
</sect2>
@@ -744,17 +707,18 @@ FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
no trojan horse or so crept in.
Please mention that the distfiles were compared and what was found
in your commit message.</para>
<para>Then, the correct way to work around this is to
set <varname>DIST_SUBDIR</varname> to a unique directory name,
usually based on <varname>PKGNAME_NOREV</varname>. All
<varname>DISTFILES</varname> and
<para>Then, the correct way to work around this is to set
<varname>DIST_SUBDIR</varname> to a unique directory name, usually
based on <varname>PKGNAME_NOREV</varname> (but take care with
python or ruby packages, where <varname>PKGNAME</varname> includes
a variable prefix). All <varname>DISTFILES</varname> and
<varname>PATCHFILES</varname> for this package will be put in that
subdirectory of the local distfiles directory.
(See <xref linkend="bumping-pkgrevision"/> for more details.)
In case this
subdirectory of the local distfiles directory. (See <xref
linkend="bumping-pkgrevision"/> for more details.) In case this
happens more often, <varname>PKGNAME</varname> can be used (thus
including the <filename>nbX</filename> suffix) or a date stamp
can be appended, like <varname>${PKGNAME_NOREV}-YYYYMMDD</varname>.</para>
including the <filename>nbX</filename> suffix) or a date stamp can
be appended, like
<varname>${PKGNAME_NOREV}-YYYYMMDD</varname>.</para>
<para><varname>DIST_SUBDIR</varname> is also used when a distfile's name does not contain a version and the distfile is apt to change. In cases where the likelihood of this is very small, <varname>DIST_SUBDIR</varname> might not be required. Additionally, <varname>DIST_SUBDIR</varname> must not be removed unless the distfile name changes, even if a package is being moved or renamed.</para>
<para>Do not forget regenerating the <filename>distinfo</filename> file
after that, since it contains the <varname>DIST_SUBDIR</varname>
@@ -773,7 +737,7 @@ FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
<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>
<programlisting>
DISTNAME= exampleproject-1.0
MASTER_SITES= ${MASTER_SITE_GITHUB:=username/}
#GITHUB_PROJECT= # can be omitted if same as DISTNAME
@@ -786,33 +750,33 @@ EXTRACT_SUFX= .zip
<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>
<programlisting>
DISTNAME= example-1.0
MASTER_SITES= ${MASTER_SITE_GITHUB:example/}
MASTER_SITES= ${MASTER_SITE_GITHUB:=example/}
#GITHUB_PROJECT= # can be omitted if same as DISTNAME
GITHUB_TAG= 988881adc9fc3655077dc2d4d757d480b5ea0e11
</programlisting>
</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>
<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>
</programlisting>
</sect3>
</sect2>
</sect1>
<sect1 id="fixes.configure">
<title>Fixing problems in the <emphasis>configure</emphasis> phase</title>
<title>The <emphasis>configure</emphasis> phase</title>
<sect2 id="fixes.libtool">
<title>Shared libraries - libtool</title>
@@ -852,13 +816,13 @@ EXTRACT_SUFX= .zip
<quote>ar</quote>, <quote>ranlib</quote>, and <quote>ld
-Bshareable</quote> commands, and instead use:</para>
<programlisting>
<programlisting>
${LIBTOOL} --mode=link \
${CC} -o ${.TARGET:.a=.la} \
${OBJS:.o=.lo} \
-rpath ${PREFIX}/lib \
-version-info major:minor
</programlisting>
</programlisting>
<para>Note that the library is changed to have a
<filename>.la</filename> extension, and the objects are
@@ -874,7 +838,7 @@ ${LIBTOOL} --mode=link \
<para>From the libtool manual:</para>
<programlisting>
<programlisting>
So, libtool library versions are described by three integers:
CURRENT
@@ -891,7 +855,7 @@ AGE' to `CURRENT'.
If two libraries have identical CURRENT and AGE numbers, then the
dynamic linker chooses the library with the greater REVISION number.
</programlisting>
</programlisting>
<para>The <quote>-release</quote> option will produce
different results for a.out and ELF (excluding symlinks)
@@ -932,15 +896,15 @@ dynamic linker chooses the library with the greater REVISION number.
expects you to change that argument to be the
<filename>.la</filename> file. e.g.</para>
<programlisting>
<programlisting>
${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
</programlisting>
</programlisting>
<para>should be changed to:</para>
<programlisting>
<programlisting>
${LIBTOOL} --mode=link ${CC} -o <replaceable>someprog</replaceable> <replaceable>../somelib/somelib.la</replaceable>
</programlisting>
</programlisting>
<para>and it will do the right thing with the libraries.</para>
</listitem>
@@ -951,9 +915,9 @@ ${LIBTOOL} --mode=link ${CC} -o <replaceable>someprog</replaceable> <replaceable
--mode=install</quote>, and change the library name to
<filename>.la</filename>. e.g.</para>
<programlisting>
<programlisting>
${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
</programlisting>
</programlisting>
<para>This will install the static <filename>.a</filename>,
shared library, any needed symlinks, and run
@@ -1036,7 +1000,7 @@ ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
<para>For packages that need only autoconf:</para>
<programlisting>
<programlisting>
AUTOCONF_REQD= 2.50 # if default version is not good enough
USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13
...
@@ -1045,11 +1009,11 @@ pre-configure:
cd ${WRKSRC} &amp;&amp; autoconf
...
</programlisting>
</programlisting>
<para>and for packages that need automake and autoconf:</para>
<programlisting>
<programlisting>
AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
USE_TOOLS+= automake # use "automake14" for automake-1.4
...
@@ -1059,7 +1023,7 @@ pre-configure:
aclocal; autoheader; automake -a --foreign -i; autoconf
...
</programlisting>
</programlisting>
<para>Packages which use GNU Automake will almost certainly
require GNU Make.</para>
@@ -1177,7 +1141,7 @@ pre-configure:
</sect1>
<sect1 id="fixes.build">
<title>Fixing problems in the <emphasis>build</emphasis> phase</title>
<title>The <emphasis>build</emphasis> phase</title>
<para>The most common failures when building a package are that
some platforms do not provide certain header files, functions or
@@ -1363,7 +1327,7 @@ of functions.</para>
</sect1>
<sect1 id="fixes.install">
<title>Fixing problems in the <emphasis>install</emphasis> phase</title>
<title>The <emphasis>install</emphasis> phase</title>
<sect2 id="install-scripts">
<title>Creating needed directories</title>
@@ -1373,10 +1337,10 @@ of functions.</para>
directory at a time. As such, you should call
<literal>${INSTALL_*_DIR}</literal> like this:</para>
<programlisting>
<programlisting>
${INSTALL_DATA_DIR} ${PREFIX}/dir1
${INSTALL_DATA_DIR} ${PREFIX}/dir2
</programlisting>
</programlisting>
<para>You can also just append <quote><literal>dir1
dir2</literal></quote> to the
@@ -1444,15 +1408,15 @@ ${INSTALL_DATA_DIR} ${PREFIX}/dir2
and <varname>SPECIAL_PERMS</varname> is used to install setgid the game
binary:</para>
<programlisting>
USE_GAMESGROUP= yes
<programlisting>
USE_GAMESGROUP= yes
BUILD_DEFS+= VARBASE
BUILD_DEFS+= VARBASE
OWN_DIRS_PERMS+= ${VARBASE}/games/moon-buggy ${GAMEDIR_PERMS}
REQD_FILES_PERMS+= /dev/null ${VARBASE}/games/moon-buggy/mbscore ${GAMEDATA_PERMS}
SPECIAL_PERMS+= ${PREFIX}/bin/moon-buggy ${SETGID_GAMES_PERMS}
</programlisting>
OWN_DIRS_PERMS+= ${VARBASE}/games/moon-buggy ${GAMEDIR_PERMS}
REQD_FILES_PERMS+= /dev/null ${VARBASE}/games/moon-buggy/mbscore ${GAMEDATA_PERMS}
SPECIAL_PERMS+= ${PREFIX}/bin/moon-buggy ${SETGID_GAMES_PERMS}
</programlisting>
<para>Various <varname>INSTALL_*</varname> variables are also available:
<varname>INSTALL_GAME</varname> to install setgid game binaries,
@@ -1479,8 +1443,8 @@ SPECIAL_PERMS+= ${PREFIX}/bin/moon-buggy ${SETGID_GAMES_PERMS}
<itemizedlist>
<listitem><para><varname>PKG_DESTDIR_SUPPORT</varname> has to be
set to <quote>none</quote>, <quote>destdir</quote>, or
<quote>user-destdir</quote>. By default <varname>PKG_DESTDIR_SUPPORT</varname>
set to <quote>destdir</quote> or <quote>user-destdir</quote>.
By default <varname>PKG_DESTDIR_SUPPORT</varname>
is set to <quote>user-destdir</quote> to help catching more
potential packaging problems. If bsd.prefs.mk is included in the Makefile,
<varname>PKG_DESTDIR_SUPPORT</varname> needs to be set before
@@ -1513,13 +1477,13 @@ SPECIAL_PERMS+= ${PREFIX}/bin/moon-buggy ${SETGID_GAMES_PERMS}
following definitions in your <filename>Makefile</filename> (we
shall use <command>tclsh</command> in this example):</para>
<programlisting>
<programlisting>
REPLACE_INTERPRETER+= tcl
REPLACE.tcl.old= .*/bin/tclsh
REPLACE.tcl.new= ${PREFIX}/bin/tclsh
REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed,
# relative to ${WRKSRC}, just as in REPLACE_PERL
</programlisting>
</programlisting>
<note><para>Before March 2006, these variables were called
<varname>_REPLACE.*</varname> and
@@ -1550,9 +1514,9 @@ REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed,
(<varname>PERL5_INSTALLVENDORARCH</varname> by default),
e.g.:</para>
<programlisting>
<programlisting>
PERL5_PACKLIST= auto/Pg/.packlist
</programlisting>
</programlisting>
<para>The perl5 config variables
<varname>installarchlib</varname>,

17
doc/guide/files/gnome.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: gnome.xml,v 1.9 2009/04/03 01:52:24 snj Exp $ -->
<!-- $NetBSD: gnome.xml,v 1.10 2016/07/09 16:07:35 rillig Exp $ -->
<chapter id="gnome"> <?dbhtml filename="gnome.html"?>
<title>GNOME packaging and porting</title>
@@ -108,7 +108,7 @@ give you a general idea on the minimum required tools:</para>
build system. As a general rule you will need to tell this to your
package:</para>
<programlisting>
<programlisting>
GNU_CONFIGURE=yes
USE_LIBTOOL=yes
USE_TOOLS+=gmake
@@ -119,7 +119,9 @@ USE_TOOLS+=gmake
<para>If the package uses pkg-config to detect dependencies, add this
tool to the list of required utilities:</para>
<programlisting>USE_TOOLS+=pkg-config</programlisting>
<programlisting>
USE_TOOLS+=pkg-config
</programlisting>
<para>Also use <filename role="pkg">pkgtools/verifypc</filename> at
the end of the build process to ensure that you did not miss to
@@ -142,7 +144,9 @@ USE_TOOLS+=gmake
report. For such packages you should disable gtk-doc (unless it is
the default):</para>
<programlisting>CONFIGURE_ARGS+=--disable-gtk-doc</programlisting>
<programlisting>
CONFIGURE_ARGS+=--disable-gtk-doc
</programlisting>
<para>The default location of installed HTML files
(<filename>share/gtk-doc/&lt;package-name&gt;</filename>) is correct
@@ -151,7 +155,10 @@ USE_TOOLS+=gmake
<command>devhelp</command> will not be able to open them. You can
do that with an entry similar to:</para>
<programlisting>CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...</programlisting>
<programlisting>
CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
</programlisting>
</listitem>
</itemizedlist>

16
doc/guide/files/infr.design.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: infr.design.xml,v 1.8 2007/08/15 06:33:45 rillig Exp $ -->
<!-- $NetBSD: infr.design.xml,v 1.10 2016/07/09 16:19:15 rillig Exp $ -->
<chapter id="infr.design"> <?dbhtml filename="infr.design.html"?>
<title>Design of the pkgsrc infrastructure</title>
@@ -111,7 +111,7 @@ DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
<varname>CONFIGURE_ARGS</varname>. To make the effect more
clear, here is an example:</para>
<programlisting>
<programlisting>
CONFIGURE_ARGS= # none
CFLAGS= -O
CONFIGURE_ARGS+= CFLAGS=${CFLAGS:Q}
@@ -119,7 +119,7 @@ CONFIGURE_ARGS+= CFLAGS=${CFLAGS:Q}
CONFIGURE_ARGS:= ${CONFIGURE_ARGS}
CFLAGS+= -Wall
</programlisting>
</programlisting>
<para>This code shows how the use of the <literal>:=</literal>
operator can quickly lead to unexpected results. The first
@@ -147,10 +147,10 @@ CFLAGS+= -Wall
<title>How can variables be specified?</title>
<para>There are many ways in which the definition and use of a
variable can be restricted in order to detect bugs and
violations of the (mostly unwritten) policies. See the
<literal>pkglint</literal> developer's documentation for further
details.</para>
variable can be restricted in order to detect bugs and violations
of the (mostly unwritten) policies. A package can be checked with
<literal>pkglint -Wall</literal> to see whether it meets these
rules.</para>
</sect1>
@@ -181,7 +181,7 @@ CFLAGS+= -Wall
parameter since it is very likely that further text will be
added after calling the procedure, which would effectively apply
the procedure to only a part of the variable. Also, references
to other variables wit will be modified after calling the
to other variables will be modified after calling the
procedure.</para>
<para>A procedure can declare its output parameters either as

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: introduction.xml,v 1.34 2015/04/15 10:01:23 sevan Exp $ -->
<!-- $NetBSD: introduction.xml,v 1.38 2016/06/11 14:58:26 rillig Exp $ -->
<chapter id="introduction">
<title>What is pkgsrc?</title>
@@ -19,7 +19,7 @@ packages for himself, which is a time-costly task.</para>
<itemizedlist>
<listitem>
<para><filename role="pkg">www/apache</filename> - The Apache
<para><filename role="pkg">www/apache24</filename> - The Apache
web server</para>
</listitem>
@@ -34,12 +34,12 @@ packages for himself, which is a time-costly task.</para>
</listitem>
<listitem>
<para><filename role="pkg">meta-pkgs/kde3</filename> - The K
<para><filename role="pkg">meta-pkgs/kde4</filename> - The K
Desktop Environment</para>
</listitem>
</itemizedlist>
<para>...just to name a few.</para>
<para>&#x2026; just to name a few.</para>
<para>pkgsrc has built-in support for handling varying dependencies,
such as pthreads and X11, and extended features such as IPv6 support on
@@ -62,10 +62,10 @@ pkgsrc provides the following key features:
<listitem><para>All packages are installed in a consistent directory tree,
including binaries, libraries, man pages and other
documentation.</para></listitem>
<listitem><para>Package dependencies, including when performing package updates,
are handled automatically. The configuration files of various
packages are handled automatically during updates, so local changes
are preserved.</para></listitem>
<listitem><para>Tracking of package dependencies automatically, including when
performing updates, to ensure required packages are installed. The
configuration files of various packages are handled automatically during
updates, so local changes are preserved.</para></listitem>
<listitem><para>Like NetBSD, pkgsrc is designed with portability in mind and
consists of highly portable code. This allows the greatest speed of
development when porting to a new platform. This portability also
@@ -222,6 +222,11 @@ minutes!</para>
<entry align="center">Jul 2013</entry>
<entry><ulink url="http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.GNUkFreeBSD">README.GNUkFreeBSD</ulink></entry>
</row>
<row>
<entry><ulink url="http://www.bitrig.org/">Bitrig</ulink></entry>
<entry align="center">Jun 2014</entry>
<entry><ulink url="http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.Bitrig">README.Bitrig</ulink></entry>
</row>
</tbody>
</tgroup>
</table>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: makefile.xml,v 1.24 2014/12/03 07:05:05 ryoon Exp $ -->
<!-- $NetBSD: makefile.xml,v 1.26 2016/06/11 19:54:44 rillig Exp $ -->
<chapter id="makefile"> <?dbhtml filename="makefile.html"?>
<title>Programming in <filename>Makefile</filename>s</title>
@@ -78,28 +78,15 @@ correct:
not preceded by a backslash starts a comment that continues upto the
end of the logical line.</para>
<para><emphasis>Note:</emphasis> Because of this parsing algorithm
the only way to create a variable consisting of a single backslash
is using the ``!='' operator, for example: <!-- FIXME
--><varname>BACKSLASH!=echo "\\"</varname>.</para>
<para>So far for defining variables. The other thing you can do with
variables is evaluating them. A variable is evaluated when it is
part of the right side of the ``:='' or the ``!='' operator, or
directly before executing a shell command which the variable is part
of. In all other cases, &man.make.1; performs lazy evaluation, that
is, variables are not evaluated until there's no other way. The
``modifiers'' mentioned in the man page also evaluate the
variable.</para>
<para>The evaluation of variables either happens immediately or lazy.
It happens immediately when the variable occurs
on the right-hand side of the ``:='' or the ``!='' operator, in a
<varname>.if</varname> condition or a <varname>.for</varname> loop.
In the other cases, it is evaluated lazily.</para>
<para>Some of the modifiers split the string into words and then
operate on the words, others operate on the string as a whole. When
a string is split into words, it is split as you would expect
it from &man.sh.1;.</para>
<para>No rule without exception&mdash;the <command>.for</command>
loop does not follow the shell quoting rules but splits at sequences
of whitespace.</para>
a string is split into words, it is split like in &man.sh.1;.</para>
<para>There are several types of variables that should be handled
differently. Strings and two types of lists.</para>
@@ -152,216 +139,149 @@ correct:
</sect1>
<sect1 id="makefile.code">
<title>Code snippets</title>
<sect1 id="makefile.code">
<title>Code snippets</title>
<para>This section presents you with some code snippets you should
use in your own code. If you don't find anything appropriate here,
you should test your code and add it here.</para>
<sect2 id="adding-to-list">
<title>Adding things to a list</title>
<sect2 id="adding-to-list">
<title>Adding things to a list</title>
<para>When adding a string that possibly contains whitespace or quotes to
a list (example 1), it must be quoted using the <code>:Q</code>
modifier.</para>
<para>When adding another list to a list (example 2), it must not be
quoted, since its elements are already quoted.</para>
<programlisting>
STRING= foo * bar `date`
INT_LIST= # empty
ANOTHER_INT_LIST= apache-[0-9]*:../../www/apache
EXT_LIST= # empty
ANOTHER_EXT_LIST= a=b c=d
STRING= foo * bar `date`
LIST= # empty
ANOTHER_LIST= a=b c=d
INT_LIST+= ${STRING} # 1
INT_LIST+= ${ANOTHER_INT_LIST} # 2
EXT_LIST+= ${STRING:Q} # 3
EXT_LIST+= ${ANOTHER_EXT_LIST} # 4
LIST+= ${STRING:Q} # 1
LIST+= ${ANOTHER_LIST} # 2
</programlisting>
<para>When you add a string to an external list (example 3), it
must be quoted. In all other cases, you must not add a quoting
level. You must not merge internal and external lists, unless you
are sure that all entries are correctly interpreted in both
lists.</para>
</sect2>
</sect2>
<sect2 id="echo-literal">
<title>Echoing a string exacty as-is</title>
<sect2 id="converting-internal-to-external">
<title>Converting an internal list into an external list</title>
<programlisting>
EXT_LIST= # empty
.for i in ${INT_LIST}
EXT_LIST+= ${i:Q}""
.endfor
</programlisting>
<para>This code converts the internal list
<varname>INT_LIST</varname> into the external list
<varname>EXT_LIST</varname>. As the elements of an internal list
are unquoted they must be quoted here. The reason for appending
<varname>""</varname> is explained below.</para>
</sect2>
<sect2 id="passing-variable-to-shell">
<title>Passing variables to a shell command</title>
<para>Sometimes you may want to print an arbitrary string. There
are many ways to get it wrong and only few that can handle every
nastiness.</para>
<para>Echoing a string containing special characters needs special
work.</para>
<programlisting>
STRING= foo bar &lt; &gt; * `date` $$HOME ' "
EXT_LIST= string=${STRING:Q} x=second\ item
EXAMPLE_ENV= string=${STRING:Q} x=multiple\ quoted\ words
all:
echo ${STRING} # 1
echo "${STRING}" # 2
echo "${STRING:Q}" # 3
echo ${STRING:Q} # 4
echo x${STRING:Q} | sed 1s,.,, # 5
printf "%s\\n" ${STRING:Q}"" # 6
env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
echo ${STRING:Q} # 2
printf '%s\n' ${STRING:Q}'' # 3
env ${EXAMPLE_ENV} sh -c 'echo "$$string"; echo "$$x"' # 4
</programlisting>
<para>Example 1 leads to a syntax error in the shell, as the
characters are just copied.</para>
<para>Example 1 leads to a syntax error in the shell, as the characters
are just copied.</para>
<para>Example 2 leads to a syntax error too, and if you leave out
the last " character from <varname>${STRING}</varname>,
&man.date.1; will be executed. The <varname>$HOME</varname> shell
variable would be evaluated, too.</para>
<para>Example 2 quotes the string so that the shell interprets it
correctly. But the echo command may additionally interpret strings with a
leading dash or those containing backslashes.</para>
<para>Example 3 outputs each space character preceded by a
backslash (or not), depending on the implementation of the
&man.echo.1; command.</para>
<para>Example 3 can handle arbitrary strings, since &man.printf.1; only
interprets the format string, but not the next argument.</para>
<para>Example 4 handles correctly every string that does not start
with a dash. In that case, the result depends on the
implementation of the &man.echo.1; command. As long as you can
guarantee that your input does not start with a dash, this form is
appropriate.</para>
<para>In example 4, the <varname>EXAMPLE_ENV</varname> does not
need to be quoted because the quoting has already been done
when adding elements to the list.</para>
<para>Example 5 handles even the case of a leading dash
correctly.</para>
</sect2>
<para>Example 6 also works with every string and is the
light-weight solution, since it does not involve a pipe, which has
its own problems.</para>
<sect2 id="cflags-gnu-configure">
<title>Passing <varname>CFLAGS</varname> to GNU configure scripts</title>
<para>The <varname>EXT_LIST</varname> does not need to be quoted
because the quoting has already been done when adding elements to
the list.</para>
<para>When passing <varname>CFLAGS</varname> or similar variables to a
GNU-style configure script (especially those that call other configure
scripts), it must not have leading or trailing whitespace, since
otherwise the configure script gets confused. To trim leading and
trailing whitespace, use the <code>:M</code> modifier, as in the
following example:</para>
<para>As internal lists shall not be passed to the shell, there is
no example for it.</para>
<!--
Additional details, intentionally left out of the guide to keep the text
short:
</sect2>
<sect2 id="quoting-guideline">
<title>Quoting guideline</title>
<para>There are many possible sources of wrongly quoted variables.
This section lists some of the commonly known ones.</para>
<itemizedlist>
<listitem><para>Whenever you use the value of a list, think
about what happens to leading or trailing whitespace. If the
list is a well-formed shell expression, you can apply the
<varname>:M*</varname> modifier to strip leading and trailing
whitespace from each word. The <varname>:M</varname> operator
first splits its argument according to the rules of the shell,
and then creates a new list consisting of all words that match
the shell glob expression <varname>*</varname>, that is: all.
One class of situations where this is needed is when adding a
variable like <varname>CPPFLAGS</varname> to
<varname>CONFIGURE_ARGS</varname>. If the configure script
invokes other configure scripts, it strips the leading and
trailing whitespace from the variable and then passes it to the
other configure scripts. But these configure scripts expect the
(child) <varname>CPPFLAGS</varname> variable to be the same as
the parent <varname>CPPFLAGS</varname>. That's why we better
pass the <varname>CPPFLAGS</varname> value properly trimmed. And
here is how we do it:</para>
If the configure script calls other configure scripts, it strips the
leading and trailing whitespace from the variable and then passes it to
the other configure scripts. But these configure scripts expect the
(child) <varname>CPPFLAGS</varname> variable to be the same as the parent
<varname>CPPFLAGS</varname>.
-->
<programlisting>
CPPFLAGS= # empty
CPPFLAGS+= -Wundef -DPREFIX=\"${PREFIX:Q}\"
CPPFLAGS+= -Wundef -DPREFIX=\"${PREFIX}\"
CPPFLAGS+= ${MY_CPPFLAGS}
CONFIGURE_ARGS+= CPPFLAGS=${CPPFLAGS:M*:Q}
all:
echo x${CPPFLAGS:Q}x # leading and trailing whitespace
echo x${CONFIGURE_ARGS}x # properly trimmed
</programlisting></listitem>
echo x${CONFIGURE_ARGS:Q}x # properly trimmed
</programlisting>
<listitem><para>The example above contains one bug: The
<varname>${PREFIX}</varname> is a properly quoted shell
expression, but there is the C compiler after it, which also
expects a properly quoted string (this time in C syntax). The
version above is therefore only correct if
<varname>${PREFIX}</varname> does not have embedded backslashes
or double quotes. If you want to allow these, you have to add
another layer of quoting to each variable that is used as a C
string literal. You cannot use the <varname>:Q</varname>
operator for it, as this operator only works for the
shell.</para></listitem>
<para>In this example, <varname>CPPFLAGS</varname> has both leading and
trailing whitespace because the <code>+=</code> operator always adds a
space.</para>
<listitem><para>Whenever a variable can be empty, the
<varname>:Q</varname> operator can have surprising results. Here
are two completely different cases which can be solved with the
same trick.</para>
</sect2>
<sect2 id="empty-variables">
<title>Handling possibly empty variables</title>
<para>When a possibly empty variable is used in a shell program, it may
lead to a syntax error.</para>
<programlisting>
EMPTY= # empty
empty_test:
for i in a ${EMPTY:Q} c; do \
echo "$$i"; \
done
EGFILES= # empty
for_test:
.for i in a:\ a:\test.txt
echo ${i:Q}
echo "foo"
install-examples: # produces a syntax error in the shell
for egfile in ${EGFILES}; do \
echo "Installing $$egfile"; \
done
</programlisting>
<para>The shell only sees the text <code>for egfile in ; do</code>, since
<code>${EGFILES}</code> is replaced with an empty string by &man.make.1;.
To fix this syntax error, use one of the snippets below.</para>
<programlisting>
EMPTY= # empty
install-examples:
for egfile in ${EGFILES} ""; do \
[ -n "$$egfile" ] || continue; \
echo "Installing $$egfile"; \
done
</programlisting>
<para>In this case, an empty string is appended to the iteration list (to
prevent the syntax error) and filtered out later.</para>
<programlisting>
EGFILES= # empty
install-examples:
.for egfile in ${EGFILES}
echo "Installing ${egfile}"
.endfor
</programlisting>
<para>The first example will only print two of the three lines
we might have expected. This is because
<varname>${EMPTY:Q}</varname> expands to the empty string, which
the shell cannot see. The workaround is to write
<varname>${EMPTY:Q}""</varname>. This pattern can be often found
as <varname>${TEST} -z ${VAR:Q}</varname> or as <varname>${TEST}
-f ${FNAME:Q}</varname> (both of these are wrong).</para>
<para>This variant only works when <varname>EGFILES</varname> does not
contain filenames with spaces, since the <code>.for</code> loop splits on
simple whitespace.</para>
<para>The second example will only print three lines instead of
four. The first line looks like <varname>a:\ echo foo</varname>.
This is because the backslash of the value
<varname>a:\</varname> is interpreted as a line-continuation by
&man.make.1;, which makes the second line the arguments of the
&man.echo.1; command from the first line. To avoid this, write
<varname>${i:Q}""</varname>.</para></listitem>
<para>To have a shell command test whether a make variable is empty, use
the following code: <code>${TEST} -z ${POSSIBLY_EMPTY:Q}""</code>.</para>
</itemizedlist>
</sect2>
<sect2 id="bsd-make-bug-workaround">
<title>Workaround for a bug in BSD Make</title>
<para>The pkgsrc bmake program does not handle the following
assignment correctly. In case <varname>_othervar_</varname>
contains a ``-'' character, one of the closing braces is included
in <varname>${VAR}</varname> after this code executes.</para>
<programlisting>
VAR:= ${VAR:N${_othervar_:C/-//}}
</programlisting>
<para>For a more complex code snippet and a workaround, see the
package <filename role="pkg">regress/make-quoting</filename>, testcase
<varname>bug1</varname>.</para>
</sect2>
</sect1>
</sect2>
</sect1>
</chapter>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: pkginstall.xml,v 1.19 2014/06/10 15:09:42 joerg Exp $ -->
<!-- $NetBSD: pkginstall.xml,v 1.20 2016/06/10 21:20:51 rillig Exp $ -->
<chapter id="pkginstall"> <?dbhtml filename="pkginstall.html"?>
<title>The pkginstall framework</title>
@@ -102,7 +102,11 @@ directories anywhere in the file system:</para>
to be destroyed by the installation scripts. The difference between
the two is that the latter prompts the administrator to remove any
directories that may be left after deinstallation (because they were
not empty), while the former does not.</para>
not empty), while the former does not. Example:</para>
<programlisting>
MAKE_DIRS+= ${VARBASE}/foo/private
</programlisting>
</listitem>
<listitem>
@@ -114,7 +118,8 @@ directories anywhere in the file system:</para>
numerical mode. For example:</para>
<programlisting>
MAKE_DIRS_PERMS+= ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
MAKE_DIRS_PERMS+= ${VARBASE}/foo/private \
${REAL_ROOT_USER} ${REAL_ROOT_GROUP} 0700
</programlisting>
<para>The difference between the two is exactly the same as their
@@ -164,7 +169,8 @@ installation prefix:</para>
this order. For example:</para>
<programlisting>
REQD_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
REQD_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile \
${REAL_ROOT_USER} ${REAL_ROOT_GROUP} 0700
</programlisting>
<para>The difference between the two is exactly the same as their

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

@@ -1,7 +1,7 @@
<?xml version="1.0"?>
<!-- $NetBSD: pkgsrc.xml,v 1.28 2015/01/01 05:19:02 jnemeth Exp $ -->
<!-- $NetBSD: pkgsrc.xml,v 1.30 2016/06/11 18:14:42 rillig Exp $ -->
<!DOCTYPE book PUBLIC "-//NetBSD//DTD DocBook XML V4.2-Based DocBook Extension//EN" [
<!DOCTYPE book PUBLIC "-//NetBSD//DTD DocBook XML V4.5-Based DocBook Extension//EN" [
<!ENTITY % man-refs.ent PUBLIC "-//NetBSD//ENTITIES NetBSD Manual Page Entities//EN">
%man-refs.ent;
@@ -42,12 +42,12 @@
</authorgroup>
<copyright>
<year>1994-2015</year>
<year>1994-2016</year>
<holder role="mailto:www@NetBSD.org">The NetBSD Foundation, Inc</holder>
</copyright>
<pubdate>$NetBSD: pkgsrc.xml,v 1.28 2015/01/01 05:19:02 jnemeth Exp $</pubdate>
<pubdate>$NetBSD: pkgsrc.xml,v 1.30 2016/06/11 18:14:42 rillig Exp $</pubdate>
<abstract>

592
doc/guide/files/platforms.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: platforms.xml,v 1.84 2013/11/15 10:11:47 asau Exp $ -->
<!-- $NetBSD: platforms.xml,v 1.100 2016/07/10 01:49:39 sevan Exp $ -->
<chapter id="platforms">
<title>Using pkgsrc on systems other than &os;</title>
@@ -67,594 +67,8 @@
<sect1 id="platform-specific-notes">
<title>Platform-specific notes</title>
<para>Here are some platform-specific notes you should be aware of.</para>
<para>For platform-specific notes consult the <filename>README</filename>
files found in the notes column of <xref linkend="supported-platforms"/></para>
<sect2 id="cygwin">
<title>Cygwin</title>
<para>Cygwin 1.7.x and later are supported.</para>
<para>You need to install minimal base packages in `Base' category
plus any of compiler, gcc, gcc4, and/or clang.
For gcc and gcc4, C and C++ compiler will be installed by default,
but you can install Fortran compiler additionally
because it will be required to use libtool.
If it is not installed (or too old), Fortran compiler will be
installed with pkgsrc automatically.</para>
<para>As noted in
<ulink url="http://cygwin.com/faq-nochunks.html#faq.using.su">Cygwin FAQ: `Why doesn't su work?'</ulink>,
su(1) command has been in Cygwin distribution, but it has never worked.
Unless you bootstrap pkgsrc with the --unprivileged option, workaround is:
</para>
<itemizedlist>
<listitem>
<para>Right click "Cygwin Terminal" in your Start Menu,
then pick "Run as administrator".</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="darwin">
<title>Darwin (Mac OS X)</title>
<!-- Mention which MacOS X versions this corresponds to! -->
<para>Darwin 5.x and up are supported.</para>
<para>Before you start, you need to download and install
the Mac OS X Developer Tools from Apple's Developer Connection.
This requires (free) membership. See
<ulink url="http://developer.apple.com/macosx/">http://developer.apple.com/macosx/</ulink>
for details. Also, make sure you install X11 (an optional
package included with the Developer Tools) if you intend
to build packages that use the X11 Window System.
(If you don't want or need the full Xcode GUI,
download and install Command Line Tools for Xcode.)</para>
</sect2>
<sect2 id="freebsd">
<title>FreeBSD</title>
<para>FreeBSD 8.3 and 9.0 have been tested and are supported,
other versions may work.</para>
<para>Care should be taken so that the tools that this kit installs do not conflict
with the FreeBSD userland tools. There are several steps:</para>
<orderedlist>
<listitem>
<para>FreeBSD stores its ports pkg database in
<filename>/var/db/pkg</filename>. It is therefore
recommended that you choose a different location (e.g.
<filename>/usr/pkgdb</filename>) by
using the --pkgdbdir option to the bootstrap script.</para>
</listitem>
<listitem>
<para>If you do not intend to use the FreeBSD ports tools, it's probably a
good idea to move them out of the way to avoid confusion, e.g.</para>
<screen>
&rprompt; <userinput>cd /usr/sbin</userinput>
&rprompt; <userinput>mv pkg_add pkg_add.orig</userinput>
&rprompt; <userinput>mv pkg_create pkg_create.orig</userinput>
&rprompt; <userinput>mv pkg_delete pkg_delete.orig</userinput>
&rprompt; <userinput>mv pkg_info pkg_info.orig</userinput>
</screen>
</listitem>
<listitem>
<para>An example &mk.conf; file will be placed in
<filename>/etc/mk.conf.example</filename> file
when you use the bootstrap script.</para>
</listitem>
</orderedlist>
</sect2>
<sect2 id="gnukfreebsd">
<title>GNU/kFreeBSD</title>
<para>Debian GNU/kFreeBSD is the only GNU/kFreeBSD distribution now.
Debian GNU/kFreeBSD 7.0 or later is tested and supported.</para>
<para> You should install ncurses (libncurses and libncurses-dev)
packages.</para>
</sect2>
<sect2 id="interix">
<title>Interix</title>
<para>Interix is a POSIX-compatible subsystem for the Windows NT kernel,
providing a Unix-like environment with a tighter kernel integration than
available with Cygwin. It is part of the Windows Services for Unix
package, available for free for any licensed copy of Windows 2000, XP
(not including XP Home), or 2003. SFU can be downloaded from <ulink
url="http://www.microsoft.com/windows/sfu/">http://www.microsoft.com/windows/sfu/</ulink>.</para>
<para>Services for Unix 3.5 has been tested. 3.0 or 3.1 may work, but
are not officially supported. (The main difference in 3.0/3.1 is lack
of pthreads, but other parts of libc may also be lacking.)</para>
<para>Services for Unix Applications (aka SUA) is an integrated
component of Windows Server 2003 R2 (5.2), Windows Vista and
Windows Server 2008 (6.0), Windows 7 and Windows Server 2008 R2
(6.1). As of this writing, the SUA's Interix 6.0 (32bit) and
6.1 (64bit) subsystems have been tested. Other versions may
work as well. The Interix 5.x subsystem has not yet been tested
with pkgsrc.</para>
<sect3 id="platform.interix-sfu-install">
<title>When installing Interix/SFU</title>
<para>At an absolute minimum, the following packages must be installed from
the Windows Services for Unix 3.5 distribution in order to use pkgsrc:</para>
<itemizedlist>
<listitem><para>Utilities -&gt; Base Utilities</para></listitem>
<listitem><para>Interix GNU Components -&gt; (all)</para></listitem>
<listitem><para>Remote Connectivity</para></listitem>
<listitem><para>Interix SDK</para></listitem>
</itemizedlist>
<para>When using pkgsrc on Interix, DO NOT install the Utilities subcomponent
"UNIX Perl". That is Perl 5.6 without shared module support, installed to
/usr/local, and will only cause confusion. Instead, install Perl 5.8 from
pkgsrc (or from a binary package).</para>
<para>The Remote Connectivity subcomponent "Windows Remote Shell Service" does
not need to be installed, but Remote Connectivity itself should be
installed in order to have a working inetd.</para>
<para>During installation you may be asked whether to enable setuid
behavior for Interix programs, and whether to make pathnames default to
case-sensitive. Setuid should be enabled, and case-sensitivity MUST be
enabled. (Without case-sensitivity, a large number of packages including
perl will not build.)</para>
<para>NOTE: Newer Windows service packs change the way binary execution
works (via the Data Execution Prevention feature). In order to use
pkgsrc and other gcc-compiled binaries reliably, a hotfix containing
POSIX.EXE, PSXDLL.DLL, PSXRUN.EXE, and PSXSS.EXE (899522 or newer)
must be installed. Hotfixes are available from Microsoft through a
support contract; however, Debian Interix Port has made most Interix
hotfixes available for personal use from <ulink
url="http://www.debian-interix.net/hotfixes/">http://www.debian-interix.net/hotfixes/</ulink>.</para>
<para>In addition to the hotfix noted above, it may be necessary to
disable Data Execution Prevention entirely to make Interix functional.
This may happen only with certain types of CPUs; the cause is not fully
understood at this time. If gcc or other applications still segfault
repeatedly after installing one of the hotfixes note above, the
following option can be added to the appropriate "boot.ini" line on the
Windows boot drive: /NoExecute=AlwaysOff
(WARNING, this will disable DEP completely, which may be a security
risk if applications are often run as a user in the Administrators
group!)</para>
</sect3>
<sect3 id="platform.interix-sfu-postinstall">
<title>What to do if Interix/SFU is already installed</title>
<para>If SFU is already installed and you wish to alter these settings to work
with pkgsrc, note the following things.</para>
<itemizedlist>
<listitem>
<para>To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft
Windows Services for UNIX, then click Change. In the installer, choose
Add or Remove, then uncheck Utilities-&gt;UNIX Perl.</para>
</listitem>
<listitem>
<para>To enable case-sensitivity for the file system, run REGEDIT.EXE, and
change the following registry key:</para>
<para>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel</para>
<para>Set the DWORD value "obcaseinsensitive" to 0; then reboot.</para>
</listitem>
<listitem>
<para>To enable setuid binaries (optional), run REGEDIT.EXE, and change the
following registry key:</para>
<para>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX</para>
<para>Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.</para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="platform.interix-notes">
<title>Important notes for using pkgsrc</title>
<para>The package manager (either the pkgsrc "su" user, or the user
running "pkg_add") must be a member of the local Administrators
group. Such a user must also be used to run the bootstrap. This is
slightly relaxed from the normal pkgsrc requirement of "root".</para>
<para>The package manager should use a umask of 002. "make install" will
automatically complain if this is not the case. This ensures that
directories written in /var/db/pkg are Administrators-group writeable.</para>
<para>The popular Interix binary packages from http://www.interopsystems.com/
use an older version of pkgsrc's pkg_* tools. Ideally, these should
NOT be used in conjunction with pkgsrc. If you choose to use them at
the same time as the pkgsrc packages, ensure that you use the proper
pkg_* tools for each type of binary package.</para>
<para>The TERM setting used for DOS-type console windows (including those
invoked by the csh and ksh startup shortcuts) is "interix". Most systems
don't have a termcap/terminfo entry for it, but the following .termcap
entry provides adequate emulation in most cases:</para>
<programlisting>
interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
</programlisting>
</sect3>
<sect3 id="platform.interix-limits">
<title>Limitations of the Interix platform</title>
<para>Though Interix suffices as a familiar and flexible substitute
for a full Unix-like platform, it has some drawbacks that should
be noted for those desiring to make the most of Interix.</para>
<itemizedlist>
<listitem><para><emphasis role="strong">X11:</emphasis></para>
<para>Interix comes with the standard set of X11R6 client libraries,
and can run X11 based applications, but it does
<emphasis>not</emphasis> come with an X server. Some options are
<ulink url="http://www.starnet.com/products/xwin32/">StarNet X-Win32</ulink>,
<ulink url="http://connectivity.hummingbird.com/products/nc/exceed/">Hummingbird Exceed</ulink>
(available in a trimmed version for Interix from Interop Systems as the
<ulink url="http://www.interopsystems.com/InteropXserver.htm">Interop X Server</ulink>),
and the free X11 server included with
<ulink url="http://x.cygwin.com/">Cygwin</ulink>.</para>
</listitem>
<listitem><para><emphasis role="strong">X11 acceleration:</emphasis></para>
<para>Because Interix runs in a completely different NT subsystem from
Win32 applications, it does not currently support various X11
protocol extensions for acceleration (such as MIT-SHM or DGA).
Most interactive applications to a local X server will run
reasonably fast, but full motion video and other graphics
intensive applications may require a faster-than-expected CPU.</para></listitem>
<listitem><para><emphasis role="strong">Audio:</emphasis></para>
<para>Interix has no native support for audio output. For audio
support, pkgsrc uses the <command>esound</command> client/server
audio system on Interix. Unlike on most platforms, the
<filename role="pkg">audio/esound</filename> package does
<emphasis>not</emphasis> contain the <command>esd</command>
server component. To output audio via an Interix host, the
<filename role="pkg">emulators/cygwin_esound</filename> package
must also be installed.</para></listitem>
<listitem><para><emphasis role="strong">CD/DVDs, USB, and SCSI:</emphasis></para>
<para>Direct device access is not currently supported in Interix, so it
is not currently possible to access CD/DVD drives, USB devices,
or SCSI devices through non-filesystem means. Among other things,
this makes it impossible to use Interix directly for CD/DVD
burning.</para></listitem>
<listitem><para><emphasis role="strong">Tape drives:</emphasis></para>
<para>Due to the same limitations as for CD-ROMs and SCSI devices, tape
drives are also not directly accessible in Interix. However,
support is in work to make tape drive access possible by using
Cygwin as a bridge (similarly to audio bridged via Cygwin's
esound server).</para></listitem>
</itemizedlist>
</sect3>
<sect3 id="platform.interix-knownissues">
<title>Known issues for pkgsrc on Interix</title>
<para>It is not necessary, in general, to have a "root" user on the
Windows system; any member of the local Administrators group will
suffice. However, some packages currently assume that the user
named "root" is the privileged user. To accommodate these, you
may create such a user; make sure it is in the local group
Administrators (or your language equivalent).</para>
<para><command>pkg_add</command> creates directories of mode
0755, not 0775, in <filename>$PKG_DBDIR</filename>. For the
time being, install packages as the local Administrator (or
your language equivalent), or run the following command after
installing a package to work around the issue:</para>
<screen>
&rprompt; <userinput>chmod -R g+w $PKG_DBDIR</userinput>
</screen>
</sect3>
</sect2>
<sect2 id="irix">
<title>IRIX</title>
<para>You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro
compiler (cc/c89). Please set the <varname>CC</varname> environment variable
according to your preference. If you do not have a license for the MIPSpro
compiler suite, you can download a gcc tardist file from <ulink
url="http://freeware.sgi.com/">http://freeware.sgi.com/</ulink>.</para>
<para>Please note that you will need IRIX 6.5.17 or higher, as this is the earliest
version of IRIX providing support for &man.if.indextoname.3;, &man.if.nametoindex.3;,
etc.</para>
<para>At this point in time, pkgsrc only supports one ABI at a time. That is, you cannot
switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit ABI. If
you start out using "abi=n32", that's what all your packages will be built
with.</para>
<para>Therefore, please make sure that you have no conflicting
<varname>CFLAGS</varname> in your environment or the
&mk.conf;. Particularly, make sure that you do not
try to link n32 object files with lib64 or vice versa. Check your
<filename>/etc/compiler.defaults</filename>!</para>
<para>If you have the actual pkgsrc tree mounted via NFS from a different host,
please make sure to set <varname>WRKOBJDIR</varname> to a local directory,
as it appears that IRIX linker occasionally runs into issues when trying to
link over a network-mounted file system.</para>
<para>The bootstrapping process should set all the right options for programs such
as imake(1), but you may want to set some options depending on your local
setup. Please see <filename>pkgsrc/mk/defaults/mk.conf</filename> and, of
course, your compiler's man pages for details.</para>
<para>If you are using SGI's MIPSPro compiler, please set
<programlisting>
PKGSRC_COMPILER= mipspro
</programlisting>
in &mk.conf;. Otherwise, pkgsrc will assume you
are using gcc and may end up passing invalid flags to the compiler. Note that
bootstrap should create an appropriate <filename>mk.conf.example</filename> by
default.</para>
<para>If you have both the MIPSPro compiler chain installed as well as gcc,
but want to make sure that MIPSPro is used, please set your <varname>PATH</varname>
to <emphasis>not</emphasis> include the location of gcc (often
<filename>/usr/freeware/bin</filename>), and (important) pass the
'--preserve-path' flag.</para>
</sect2>
<sect2 id="linux">
<title>Linux</title>
<para>Some versions of Linux (for example Debian GNU/Linux) need
either libtermcap or libcurses (libncurses). Installing the
distributions libncurses-dev package (or equivalent) should fix
the problem.</para>
<para>pkgsrc supports both gcc (GNU Compiler Collection) and icc
(Intel C++ Compiler). gcc is the default. icc 8.0 and 8.1 on
i386 have been tested.</para>
<para>To bootstrap using icc, assuming the default icc installation
directory:</para>
<programlisting>
env ICCBASE=/opt/intel/cc/10.1.008 ./bootstrap --compiler=icc
</programlisting>
<note>
<para>For icc 8.0 you must add `LDFLAGS=-static-libcxa' to this.</para>
<para>For icc 8.1 you must add `LDFLAGS=-i-static' instead.</para>
<para>For icc 10.1 neither of these appears to be necessary.</para>
</note>
<para>Use a value for ICCBASE that corresponds to the directory
where icc is installed. After bootstrapping, set
<varname>ICCBASE</varname> in &mk.conf;:</para>
<programlisting>
ICCBASE= /opt/intel/cc/10.1.008
</programlisting>
<para>The pkgsrc default for <varname>ICCBASE</varname> is
<filename>/opt/intel_cc_80</filename>. This is the default
install directory for icc 8.0. If you are using a more recent
version, be sure to set the correct path explicitly.
</para>
<para>pkgsrc uses the static linking method of the runtime libraries
provided by icc, so binaries can be run on other systems which do not
have the shared libraries installed.</para>
<para>Libtool, however, extracts a list of libraries from the
&man.ld.1; command run when linking a C++ shared library and
records it, throwing away the -Bstatic and -Bdynamic options
interspersed between the libraries. This means that
libtool-linked C++ shared libraries will have a runtime
dependency on the icc libraries until this is fixed in
libtool.</para>
</sect2>
<sect2 id="mirbsd">
<title>MirBSD</title>
<para>pkgsrc has been tested on MirBSD #10-current (2011 and newer).
Older versions might also work. Releases before #10 are not
supported.</para>
<para>The package tools of the (older) native ports tree,
<ulink url="//www.mirbsd.org/ports.htm">MirPorts</ulink>,
have the same names as the ones used by pkgsrc. Care should be taken
that the right tools are used. When installing packages from source,
use the <filename>bmake</filename> command for pkgsrc and
<filename>mmake</filename> for MirPorts.</para>
<para>pkgsrc and MirPorts use the same location for the package
database, <filename>/var/db/pkg</filename>. It is strongly recommended
to use <filename>/usr/pkg/db</filename> instead, so that the pkgsrc
tree is self-contained. This is also the default setting used in the
binary package builds.</para>
<para>Binary packages for MirBSD/i386 can be found on the pkgsrc ftp
server. The bootstrap kit there already contains the
<command>pkgin</command> package manager. See the
<ulink url="https://www.mirbsd.org/pkgsrc.htm">pkgsrc on MirOS</ulink>
page for more details.</para>
</sect2>
<sect2 id="openbsd">
<title>OpenBSD</title>
<para>OpenBSD 5.1 has been tested and supported,
other versions may work.</para>
<para>Care should be taken so that the tools that this kit installs do not conflict
with the OpenBSD userland tools. There are several steps:</para>
<orderedlist>
<listitem>
<para>OpenBSD stores its ports pkg database in
<filename>/var/db/pkg</filename>. It is therefore
recommended that you choose a different location (e.g.
<filename>/usr/pkgdb</filename>) by
using the --pkgdbdir option to the bootstrap script.</para>
</listitem>
<listitem>
<para>If you do not intend to use the OpenBSD ports tools, it's probably a
good idea to move them out of the way to avoid confusion, e.g.</para>
<screen>
&rprompt; <userinput>cd /usr/sbin</userinput>
&rprompt; <userinput>mv pkg_add pkg_add.orig</userinput>
&rprompt; <userinput>mv pkg_create pkg_create.orig</userinput>
&rprompt; <userinput>mv pkg_delete pkg_delete.orig</userinput>
&rprompt; <userinput>mv pkg_info pkg_info.orig</userinput>
</screen>
</listitem>
<listitem>
<para>An example &mk.conf; file will be placed in
<filename>/etc/mk.conf.example</filename> file
when you use the bootstrap script. OpenBSD's make program uses
&mk.conf;
as well. You can work around this by enclosing all the pkgsrc-specific parts
of the file with:</para>
<programlisting>
.ifdef BSD_PKG_MK
# pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
.else
# OpenBSD stuff
.endif
</programlisting>
</listitem>
</orderedlist>
</sect2>
<sect2 id="solaris">
<title>Solaris</title>
<para>Solaris 2.6 through 10 are supported on both x86 and sparc.
You will need a working C compiler. Both gcc 4.5.3 and
Sun WorkShop 5 have been tested.</para>
<para>The following packages are required on Solaris 8 for the bootstrap
process and to build packages.</para>
<itemizedlist>
<listitem><para>SUNWsprot</para></listitem>
<listitem><para>SUNWarc</para></listitem>
<listitem><para>SUNWbtool</para></listitem>
<listitem><para>SUNWtoo</para></listitem>
<listitem><para>SUNWlibm</para></listitem>
</itemizedlist>
<para>Please note that the use of GNU binutils on Solaris is
<emphasis>not</emphasis> supported, as of June 2006.</para>
<para>Whichever compiler you use, please ensure the compiler tools and
your $prefix are in your <varname>PATH</varname>. This includes
<filename>/usr/ccs/{bin,lib}</filename>
and e.g. <filename>/usr/pkg/{bin,sbin}</filename>.</para>
<sect3 id="solaris-gcc-note">
<title>If you are using gcc</title>
<para>It makes life much simpler if you only use the same gcc consistently
for building all packages.</para>
<para>It is recommended that an external gcc be used only for bootstrapping,
then either build gcc from
<filename role="pkg">lang/gcc46</filename> or install a binary gcc
package, then remove gcc used during bootstrapping.</para>
<para>Binary packages of gcc can be found through <ulink
url="http://www.sunfreeware.com/"/>.</para>
</sect3>
<sect3 id="solaris-sun-workshop-note">
<title>If you are using Sun WorkShop</title>
<para>You will need at least the following packages installed (from WorkShop
5.0)</para>
<itemizedlist>
<listitem><para>SPROcc
- Sun WorkShop Compiler C 5.0</para></listitem>
<listitem><para>SPROcpl
- Sun WorkShop Compiler C++ 5.0</para></listitem>
<listitem><para>SPROild
- Sun WorkShop Incremental Linker</para></listitem>
<listitem><para>SPROlang
- Sun WorkShop Compilers common components</para></listitem>
</itemizedlist>
<para>You should set the following variables in your
&mk.conf; file:</para>
<programlisting>
CC= cc
CXX= CC
CPP= cc -E
CXXCPP= CC -E
</programlisting>
<note><para>The <varname>CPP</varname> setting might break some
packages that use the C preprocessor for processing things other
than C source code.</para></note>
</sect3>
<sect3 id="solaris-sunpro-64">
<title>Building 64-bit binaries with SunPro</title>
<para>To build 64-bit packages, you just need to have the
following lines in your &mk.conf; file:</para>
<programlisting>
PKGSRC_COMPILER= sunpro
ABI= 64
</programlisting>
<note><para>This setting has been tested for the SPARC
architecture. Intel and AMD machines need some more
work.</para></note>
</sect3>
<sect3 id="plat.sunos.problems"><title>Common problems</title>
<para>Sometimes, when using <command>libtool</command>,
<filename>/bin/ksh</filename> crashes with a segmentation fault.
The workaround is to use another shell for the configure
scripts, for example by installing <filename
role="pkg">shells/bash</filename> and adding the following lines
to your &mk.conf;:</para>
<programlisting>
CONFIG_SHELL= ${LOCALBASE}/bin/bash
WRAPPER_SHELL= ${LOCALBASE}/bin/bash
</programlisting>
<para>Then, rebuild the <filename
role="pkg">devel/libtool-base</filename> package.</para>
</sect3>
</sect2>
</sect1>
</chapter>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: plist.xml,v 1.22 2015/06/07 03:34:54 joerg Exp $ -->
<!-- $NetBSD: plist.xml,v 1.24 2016/07/10 07:46:29 rillig Exp $ -->
<chapter id="plist">
<title>PLIST issues</title>
@@ -19,9 +19,9 @@
<para>Be sure to add a RCS ID line as the first thing in any
<filename>PLIST</filename> file you write:</para>
<programlisting>
<programlisting>
@comment &#36;NetBSD&#36;
</programlisting>
</programlisting>
</sect1>
<sect1 id="automatic-plist-generation">
@@ -46,9 +46,9 @@
<filename>libdata/foo</filename> directory removed from the
resulting PLIST:</para>
<programlisting>
<programlisting>
PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }
</programlisting>
</programlisting>
</sect1>
<sect1 id="plist.misc">
@@ -123,9 +123,9 @@ well as searching the <filename>pkgsrc/mk</filename> directory with <command>gre
following way, similar to <varname>MESSAGE_SUBST</varname> (see <xref
linkend="components.optional"/>):</para>
<programlisting>
<programlisting>
PLIST_SUBST+= SOMEVAR="somevalue"
</programlisting>
</programlisting>
<para>This replaces all occurrences of <quote>${SOMEVAR}</quote>
in the <filename>PLIST</filename> with
@@ -144,22 +144,22 @@ PLIST_SUBST+= SOMEVAR="somevalue"
<quote><literal>"@comment "</literal></quote>.
For example, in <filename>Makefile</filename>:</para>
<programlisting>
PLIST_VARS+= foo
<programlisting>
PLIST_VARS+= foo
.if <replaceable>condition</replaceable>
PLIST.foo= yes
PLIST.foo= yes
.else
</programlisting>
</programlisting>
<para>And then in <filename>PLIST</filename>:</para>
<programlisting>
<programlisting>
@comment &#36;NetBSD&#36;
bin/bar
man/man1/bar.1
${PLIST.foo}bin/foo
${PLIST.foo}man/man1/foo.1
${PLIST.foo}share/bar/foo.data
</programlisting>
</programlisting>
</sect1>
@@ -230,9 +230,11 @@ ${PLIST.foo}share/bar/foo.data
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>
<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>.
@@ -256,9 +258,11 @@ ${PLIST.foo}share/bar/foo.data
<para>If a package needs an empty directory to work, create
the directory during installation as usual, and also add an
entry to the PLIST:
<programlisting>
<programlisting>
@pkgdir path/to/empty/directory
</programlisting>
</programlisting>
or take a look at <varname>MAKE_DIRS</varname> and
<varname>OWN_DIRS</varname>.
</para>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: porting.xml,v 1.5 2014/05/09 06:52:15 obache Exp $ -->
<!-- $NetBSD: porting.xml,v 1.6 2016/06/11 14:58:26 rillig Exp $ -->
<chapter id="porting"> <?dbhtml filename="porting.html"?>
<title>Porting pkgsrc</title>
@@ -51,11 +51,4 @@
</sect1>
<sect1 id="porting.compiler">
<title>Adding support for a new compiler</title>
<para>TODO</para>
</sect1>
</chapter>

70
doc/guide/files/regression.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: regression.xml,v 1.2 2006/12/15 13:22:14 martti Exp $ -->
<!-- $NetBSD: regression.xml,v 1.4 2016/07/10 07:46:29 rillig Exp $ -->
<chapter id="regression"> <?dbhtml filename="regression.html"?>
<title>Regression tests</title>
@@ -12,13 +12,6 @@
This chapter describes how regression tests work in pkgsrc and
how you can add new tests.</para>
<sect1 id="regression.descr">
<title>The regression tests framework</title>
<para></para>
</sect1>
<sect1 id="regression.run">
<title>Running the regression tests</title>
@@ -43,34 +36,58 @@
<sect2 id="regression.fun.override">
<title>Overridable functions</title>
<para>These functions do not take any parameters. They are all
called in <quote>set -e</quote> mode, so you should be careful
to check the exitcodes of any commands you run in the
test.</para>
<para>These functions do not take any parameters. Although they
are called in <quote>set -e</quote> mode, they don't stop at the
first failing command. See <ulink
url="http://stackoverflow.com/q/4072984">this StackOverflow
question</ulink> for details.</para>
<variablelist>
<varlistentry><term><varname>do_setup()</varname></term>
<varlistentry><term><varname>do_setup</varname></term>
<listitem><para>This function prepares the environment for the
test. By default it does nothing.</para></listitem>
</varlistentry>
<varlistentry><term><varname>do_test()</varname></term>
<varlistentry><term><varname>do_test</varname></term>
<listitem><para>This function runs the actual test. By default,
it calls <varname>TEST_MAKE</varname> with the arguments
<varname>MAKEARGS_TEST</varname> and writes its output including
error messages into the file
<varname>TEST_OUTFILE</varname>.</para></listitem>
<varname>TEST_OUTFILE</varname>.</para>
<para>When defining this function, make sure that all output that
needs to be checked is written to the correct output file.
Example:</para>
<programlisting>
do_test() {
echo "Example output"
} 1>$TEST_OUTFILE 2>&1
</programlisting>
</listitem>
</varlistentry>
<varlistentry><term><varname>check_result()</varname></term>
<varlistentry><term><varname>check_result</varname></term>
<listitem><para>This function is run after the test and is
typically used to compare the actual output from the one that is
expected. It can make use of the various helper functions from
the next section.</para></listitem>
the next section. Example:</para>
<programlisting>
check_result() {
exit_status 0
output_require "Example"
output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
output_prohibit "no such file or directory"
}
</programlisting>
</listitem>
</varlistentry>
<varlistentry><term><varname>do_cleanup()</varname></term>
<varlistentry><term><varname>do_cleanup</varname></term>
<listitem><para>This function cleans everything up after the
test has been run. By default it does nothing.</para></listitem>
</varlistentry>
@@ -83,17 +100,24 @@
<variablelist>
<varlistentry><term><varname>exit_status(expected)</varname></term>
<varlistentry><term><varname>exit_status expected</varname></term>
<listitem><para>This function compares the exitcode of the
<command>do_test()</command> function with its first parameter.
<command>do_test</command> function with its first parameter.
If they differ, the test will fail.</para></listitem>
</varlistentry>
<varlistentry><term><varname>output_require(regex...)</varname></term>
<varlistentry><term><varname>output_require regex...</varname></term>
<listitem><para>This function checks for each of its parameters
if the output from <command>do_test()</command> matches the
if the output from <command>do_test</command> matches the
extended regular expression. If it does not, the test will
fail.</para></listitem>
fail. Example:</para>
<programlisting>
output_require "looks fine"
output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
</programlisting>
</listitem>
</varlistentry>
<varlistentry><term><varname>output_prohibit(regex...)</varname></term>

6
doc/guide/files/share/default.dsl
View File

@@ -2,12 +2,14 @@
<!ENTITY netbsd.dsl PUBLIC "-//NetBSD//DOCUMENT DocBook DSSSL Stylesheet//EN" CDATA DSSSL>
]>
<!-- $NetBSD: default.dsl,v 1.1.1.1 2004/10/21 14:27:43 grant Exp $ -->
<!-- $NetBSD: default.dsl,v 1.2 2016/06/11 18:14:42 rillig Exp $ -->
<style-sheet>
<style-specification use="docbook">
<style-specification-body>
<![ %output.print; [
(element code ($mono-seq$))
]]>
</style-specification-body>
</style-specification>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: submit.xml,v 1.30 2014/08/12 05:12:41 schmonz Exp $ -->
<!-- $NetBSD: submit.xml,v 1.31 2016/03/01 12:34:14 wiz Exp $ -->
<chapter id="submit"> <?dbhtml filename="submit.html"?>
<title>Submitting and Committing</title>
@@ -46,7 +46,7 @@
<para>Alternatively, you can also import new packages into
pkgsrc-wip (<quote>pkgsrc work-in-progress</quote>); see the
homepage at <ulink url="http://pkgsrc-wip.sourceforge.net/"/>
homepage at <ulink url="http://pkgsrc.org/wip/"/>
for details.</para>
</sect1>

34
doc/guide/files/tools.xml
View File

@@ -1,4 +1,4 @@
<!-- $NetBSD: tools.xml,v 1.6 2011/10/30 22:08:17 wiz Exp $ -->
<!-- $NetBSD: tools.xml,v 1.7 2016/06/11 20:19:36 rillig Exp $ -->
<chapter id="tools">
<title>Tools needed for building or running</title>
@@ -90,36 +90,4 @@ TOOLS_PLATFORM.true?= true # shell builtin
</sect1>
<sect1 id="tools.questions">
<title>Questions regarding the tools</title>
<qandaset>
<qandaentry id="tools.new">
<question><para>How do I add a new tool?</para></question>
<answer><para>TODO</para></answer>
</qandaentry>
<qandaentry id="tools.listall">
<question><para>How do I get a list of all available
tools?</para></question>
<answer><para>TODO</para></answer>
</qandaentry>
<qandaentry id="tools.used">
<question><para>How can I get a list of all the tools that a
package is using while being built? I want to know whether it
uses sed or not.</para></question>
<answer><para>Currently, you can't. (TODO: But I want to be able
to do it.)</para></answer>
</qandaentry>
</qandaset>
</sect1>
</chapter>

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

@@ -1,4 +1,4 @@
<!-- $NetBSD: using.xml,v 1.39 2015/01/26 23:00:00 wiz Exp $ -->
<!-- $NetBSD: using.xml,v 1.40 2016/06/11 13:39:44 rillig Exp $ -->
<chapter id="using"> <?dbhtml filename="using.html"?>
<title>Using pkgsrc</title>
@@ -213,24 +213,6 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
administrative functions on the package system.</para>
</sect2>
<sect2 id="a-word-of-warning">
<title>A word of warning</title>
<para>Please pay very careful attention to the warnings
expressed in the &man.pkg.add.1; manual page about the
inherent dangers of installing binary packages which you did
not create yourself, and the security holes that can be
introduced onto your system by indiscriminate adding of such
files.</para>
<para>The same warning of course applies to every package you
install from source when you haven't completely read and
understood the source code of the package, the compiler that
is used to build the package and all the other tools that are
involved.</para>
</sect2>
</sect1>
<sect1 id="building-packages-from-source">

1744
doc/pkgsrc.html
View File

File diff suppressed because it is too large Load Diff

1402
doc/pkgsrc.txt
View File

File diff suppressed because it is too large Load Diff