Table of Contents
The problem with package-defined variables that can be
overridden via MAKECONF or
/etc/mk.conf is that
make(1) expands a
variable as it is used, but evaluates preprocessor like
statements (.if, .ifdef and .ifndef) as they are read. So,
to use any variable (which may be set in /etc/mk.conf) in one of the .if*
statements, the file /etc/mk.conf must be included before that
.if* statement.
Rather than have a number of ad-hoc ways of including
/etc/mk.conf, should it
exist, or MAKECONF, should it
exist, include the pkgsrc/mk/bsd.prefs.mk file in the
package Makefile before any preprocessor-like .if, .ifdef,
or .ifndef statements:
.include "../../mk/bsd.prefs.mk"
.if defined(USE_MENUS)
...
.endif
If you wish to set the CFLAGS variable in /etc/mk.conf please make sure to use:
CFLAGS+= -your -flags
Using CFLAGS= (i.e. without
the “+”) may lead to
problems with packages that need to add their own flags.
Also, you may want to take a look at the devel/cpuflags package if you're
interested in optimization for the current CPU.
Some licenses restrict how software may be re-distributed. In order to satisfy these restrictions, the package system defines five make variables that can be set to note these restrictions:
RESTRICTED
This variable should be set whenever a restriction exists (regardless of its kind). Set this variable to a string containing the reason for the restriction.
NO_BIN_ON_CDROM
Binaries may not be placed on CD-ROM. Set this
variable to ${RESTRICTED} whenever a binary
package may not be included on a CD-ROM.
NO_BIN_ON_FTP
Binaries may not be placed on an FTP server. Set
this variable to ${RESTRICTED} whenever a binary
package may not not be made available on the
Internet.
NO_SRC_ON_CDROM
Distfiles may not be placed on CD-ROM. Set this
variable to ${RESTRICTED} if re-distribution of
the source code or other distfile(s) is not allowed
on CD-ROMs.
NO_SRC_ON_FTP
Distfiles may not be placed on FTP. Set this
variable to ${RESTRICTED} if re-distribution of
the source code or other distfile(s) via the Internet
is not allowed.
Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic make variables
to denote restrictions is deprecated, because they
unconditionally prevent users from generating binary
packages!
Your package may depend on some other package being
present - and there are various ways of expressing this
dependency. pkgsrc supports the BUILD_DEPENDS and DEPENDS definitions, as well as
dependencies via buildlink3.mk, which is the preferred way
to handle dependencies, and which uses the variables named
above. See Chapter 9,
Buildlink methodology for more information.
The basic difference between the two variables is as
follows: The DEPENDS
definition registers that pre-requisite in the binary
package so it will be pulled in when the binary package is
later installed, whilst the BUILD_DEPENDS definition does not, marking
a dependency that is only needed for building the
package.
This means that if you only need a package present
whilst you are building, it should be noted as a
BUILD_DEPENDS.
The format for a BUILD_DEPENDS and a DEPENDS definition is:
<pre-req-package-name>:../../<category>/<pre-req-package>
Please note that the “pre-req-package-name” may include any of the wildcard version numbers recognised by pkg_info(1).
If your package needs another package's binaries
or libraries to build or run, and if that package has
a buildlink3.mk file
available, use it:
.include "../../graphics/jpeg/buildlink3.mk"
If your package needs to use another package to
build itself and there is no buildlink3.mk file available, use
the BUILD_DEPENDS
definition:
BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
If your package needs a library with which to link
and again there is no buildlink3.mk file available, this
is specified using the DEPENDS definition. An example of
this is the print/lyx package, which uses the
xpm library, version 3.4j to build:
DEPENDS+= xpm-3.4j:../../graphics/xpm
You can also use wildcards in package dependences:
DEPENDS+= xpm-[0-9]*:../../graphics/xpm
Note that such wildcard dependencies are retained when creating binary packages. The dependency is checked when installing the binary package and any package which matches the pattern will be used. Wildcard dependencies should be used with care.
The “-[0-9]*” should be used instead
of “-*” to
avoid potentially ambiguous matches such as
“tk-postgresql” matching a
“tk-*”
DEPENDS.
Wildcards can also be used to specify that a package will only build against a certain minimum version of a pre-requisite:
DEPENDS+= tiff>=3.5.4:../../graphics/tiff
This means that the package will build against version 3.5.4 of the tiff library or newer. Such a dependency may be warranted if, for example, the API of the library has changed with version 3.5.4 and a package would not compile against an earlier version of tiff.
Please note that such dependencies should only be
updated if a package requires a newer pre-requisite,
but not to denote recommendations such as security
updates or ABI changes that do not prevent a package
from building correctly. Such recommendations can be
expressed using RECOMMENDED:
RECOMMENDED+= tiff>=3.6.1:../../graphics/tiff
In addition to the above DEPENDS line, this denotes that
while a package will build against tiff>=3.5.4, at
least version 3.6.1 is recommended. RECOMMENDED entries will be turned
into dependencies unless explicitly ignored (in which
case a warning will be printed). Packages that are
built with recommendations ignored may not be
uploaded to ftp.NetBSD.org by developers and should
not be used across different systems that may have
different versions of binary packages installed.
For security fixes, please update the package
vulnerabilities file as well as setting RECOMMENDED, see
Section 12.1.7, “Handling packages with
security problems” for more
information.
If your package needs some executable to be able
to run correctly and if there's agail no buildlink3.mk file, this is
specified using the DEPENDS variable. The print/lyx package needs to be
able to execute the latex binary from the teTeX
package when it runs, and that is specified:
DEPENDS+= teTeX-[0-9]*:../../print/teTeX
The comment about wildcard dependencies from previous paragraph applies here, too.
If your package needs files from another package to build, see the first part of the “do-configure” target print/ghostscript5 package (it relies on the jpeg sources being present in source form during the build):
if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract; \
fi
If you build any other packages that way, please make sure the working files are deleted too when this package's working files are cleaned up. The easiest way to do so is by adding a pre-clean target:
pre-clean:
cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean
Please also note the BUILD_USES_MSGFMT and BUILD_USES_GETTEXT_M4 definitions, which
are provided as convenience definitions. The former works
out whether msgfmt(1) is part of the base system, and, if
it isn't, installs the devel/gettext package. The latter adds
a build dependency on either an installed version of an
older gettext package, or if it isn't, installs the
devel/gettext-m4 package.
Your package may conflict with other packages a user might already have installed on his system, e.g. if your package installs the same set of files like another package in our pkgsrc tree.
In this case you can set CONFLICTS to a space separated list of
packages (including version string) your package conflicts
with.
For example x11/Xaw3d and x11/Xaw-Xpm install provide the same
shared library, thus you set in pkgsrc/x11/Xaw3d/Makefile:
CONFLICTS= Xaw-Xpm-[0-9]*
and in pkgsrc/x11/Xaw-Xpm/Makefile:
CONFLICTS= Xaw3d-[0-9]*
Packages will automatically conflict with other packages with the name prefix and a different version string. “Xaw3d-1.5” e.g. will automatically conflict with the older version “Xaw3d-1.3”.
There are several reasons why a package might be
instructed to not build under certain circumstances. If the
package builds and runs on most platforms, the exceptions
should be noted with NOT_FOR_PLATFORM. If the package builds
and runs on a small handful of platforms, set ONLY_FOR_PLATFORM instead. If the package
should be skipped (for example, because it provides
functionality already provided by the system), set
PKG_SKIP_REASON to a
descriptive message. If the package should fail because
some preconditions are not met, set PKG_FAIL_REASON to a descriptive
message.
IGNORE is deprecated
because it didn't provide enough information to determine
whether the build should fail.
To ensure that a package may not be deleted, once it has
been installed, the PKG_PRESERVE definition should be set in
the package Makefile. This will be carried into any binary
package that is made from this pkgsrc entry. A
“preserved” package
will not be deleted using
pkg_delete(1) unless the
“-f” option is
used.
When a vulnerability is found, this should be noted in
localsrc/security/advisories/pkg-vulnerabilities,
and after the commit of that file, it should be copied to
both /pub/NetBSD/packages/distfiles/pkg-vulnerabilities
and /pub/NetBSD/packages/distfiles/vulnerabilities
on ftp.NetBSD.org using localsrc/security/advisories/Makefile. In
addition, if a buildlink3.mk
file exists for an affected package, bumping PKGREVISION and creating a corresponding
BUILDLINK_RECOMMENDED. entry should be
considered. See Chapter 9,
Buildlink methodology for more information about
writing pkgbuildlink3.mk files
and BUILDLINK_*
definitions.
Also, if the fix should be applied to the stable pkgsrc branch, be sure to submit a pullup request!
Some source files trigger bugs in the compiler, based on combinations of compiler version and architecture and almost always relation to optimisation being enabled. Common symptoms are gcc internal errors or never finishing compiling a file.
Typically a workaround involves testing the MACHINE_ARCH and compiler version,
disabling optimisation for that file/MACHINE_ARCH/compiler combination, and
documenting it in pkgsrc/doc/HACKS. See that file for a
number of examples!
When making fixes to an existing package it can be
useful to change the version number in PKGNAME. To avoid conflicting with future
versions by the original author, a “nb1”, “nb2”, ... suffix can be used on
package versions by setting PKGREVISION=1 (2, ...). The
“nb” is treated like
a “.” by the pkg
tools. e.g.
DISTNAME= foo-17.42
PKGREVISION= 9
will result in a PKGNAME of
“foo-17.42nb9”.
When a new release of the package is released, the
PKGREVISION should be removed.
e.g. on a new minor release of the above package, things
should be like:
DISTNAME= foo-17.43
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. There are some particular details you should pay attention to while working on pkgsrc.
If you need to download from a dynamic URL you can set
DYNAMIC_MASTER_SITES and a
make fetch
will call files/getsite.sh
with the name of each file to download as an argument,
expecting it to output the URL of the directory from which
to download it. graphics/ns-cult3d is an example of
this usage.
If the download can't be automated, because the user
must submit personal information to apply for a password,
or must pay for the source, or whatever, you can set
_FETCH_MESSAGE to a macro
which displays a message explaining the situation.
_FETCH_MESSAGE must be
executable shell commands, not just a message. (Generally,
it executes ${ECHO}). As of
this writing, the following packages use this: audio/realplayer, cad/simian, devel/ipv6socket, emulators/vmware-module, fonts/acroread-jpnfont, sysutils/storage-manager, www/ap-aolserver, www/openacs. Try to be consistent with
them.
Sometimes authors of a software package make some
modifications after the software was released, and they put
up a new distfile without changing the package's version
number. If a package is already in pkgsrc at that time, the
md5 checksum will no longer match. The correct way to work
around this is to update the package's md5 checksum to
match the package on the master site (beware, any mirrors
may not be up to date yet!), and to remove the old distfile
from ftp.NetBSD.org's /pub/NetBSD/packages/distfiles directory.
Furthermore, a mail to the package's author seems
appropriate making sure the distfile was really updated on
purpose, and that no trojan horse or so crept in.
pkgsrc supports many different machines, with different object formats like a.out and ELF, and varying abilities to do shared library and dynamic loading at all. To accompany this, varying commands and options have to be passed to the compiler, linker, etc. to get the Right Thing, which can be pretty annoying especially if you don't have all the machines at your hand to test things. The devel/libtool pkg can help here, as it just “knows” how to build both static and dynamic libraries from a set of source files, thus being platform independent.
Here's how to use libtool in a pkg in seven simple steps:
Add USE_LIBTOOL=yes
to the package Makefile.
For library objects, use “${LIBTOOL} --mode=compile ${CC}”
in place of “${CC}”. You could even add it to
the definition of CC, if
only libraries are being built in a given Makefile.
This one command will build both PIC and non-PIC
library objects, so you need not have separate shared
and non-shared library rules.
For the linking of the library, remove any “ar”, “ranlib”, and “ld -Bshareable” commands, and instead use:
${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor
Note that the library is changed to have a
.la extension, and the
objects are changed to have a .lo extension. Change OBJS as necessary. This
automatically creates all of the .a, .so.major.minor, and ELF symlinks
(if necessary) in the build directory. Be sure to
include “-version-info”, especially when
major and minor are zero, as libtool will otherwise
strip off the shared library version.
From the libtool manual:
So, libtool library versions are described by three integers:
CURRENT
The most recent interface number that this library implements.
REVISION
The implementation number of the CURRENT interface.
AGE
The difference between the newest and oldest interfaces that this
library implements. In other words, the library implements all the
interface numbers in the range from number `CURRENT - AGE' to
`CURRENT'.
If two libraries have identical CURRENT and AGE numbers, then the
dynamic linker chooses the library with the greater REVISION number.
The “-release” option will produce different results for a.out and ELF (excluding symlinks) in only one case. An ELF library of the form “libfoo-release.so.x.y” will have a symlink of “libfoo.so.x.y” on an a.out platform. This is handled automatically.
The “-rpath argument” is the install directory of the library being built.
In the PLIST,
include all of the .a,
.la, and .so, .so. and
major.so.
files.major.minor
When linking shared object (.so) files, i.e. files that are
loaded via dlopen(3), NOT shared libraries, use
“-module
-avoid-version” to prevent them getting
version tacked on.
The PLIST file gets
the foo.so entry.
When linking programs that depend on these
libraries before they are installed,
preface the
cc(1) or
ld(1) line with
“${LIBTOOL}
--mode=link”, and it will find the
correct libraries (static or shared), but please be
aware that libtool will not allow you to specify a
relative path in -L (such as “-L../somelib”), because it
expects you to change that argument to be the
.la file. e.g.
${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
should be changed to:
${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
and it will do the right thing with the libraries.
When installing libraries, preface the
install(1) or
cp(1) command with
“${LIBTOOL}
--mode=install”, and change the library
name to .la. e.g.
${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
This will install the static .a, shared library, any needed
symlinks, and run
ldconfig(8).
In your PLIST,
include all of the .a,
.la, and .so, .so.CURRENT and .so.CURRENT.REVISION files (this is
a change from the previous behaviour).
Add USE_LIBTOOL=yes to the
package Makefile. This will override the package's own
libtool in most cases. For older libtool using packages,
libtool is made by ltconfig script during the do-configure
step; you can check the libtool script location by doing
make configure; find work*/
-name libtool.
LIBTOOL_OVERRIDE specifies
which libtool scripts, relative to WRKSRC, to override. By default, it is set
to “libtool */libtool
*/*/libtool”. If this does not match the
location of the package's libtool script(s), set it as
appropriate.
If you do not need *.a
static libraries built and installed, then use SHLIBTOOL_OVERRIDE instead.
If your package makes use of the platform independent
library for loading dynamic shared objects, that comes with
libtool (libltdl), you should include the libtool
buildlink3.mk (and set USE_BUILDLINK3=YES).
Some packages use libtool incorrectly so that the package may not work or build in some circumstances. Some of the more common errors are:
The inclusion of a shared object (-module) as a dependent library in an executable or library. This in itself isn't a problem if one of two things has been done:
The shared object is named correctly, i.e.
libfoo.la, not
foo.la
The -dlopen option is used when linking an executable.
The use of libltdl without the correct calls to
initialisation routines. The function lt_dlinit()
should be called and the macro LTDL_SET_PRELOADED_SYMBOLS included
in executables.
If a package needs GNU autoconf or automake to be
executed to regenerate the configure script and Makefile.in
makefile templates, then they should be executed in a
pre-configure target. Two Makefile fragments are provided
in pkgsrc/mk/autoconf.mk and
pkgsrc/mk/automake.mk to help
dealing with these tools. See comments in these files for
details.
For packages that need only autoconf:
AUTOCONF_REQD= 2.50 # if default version is not good enough
...
pre-configure:
cd ${WRKSRC}; ${AUTOCONF}
...
.include "../../mk/autoconf.mk"
and for packages that need automake and autoconf:
AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
...
pre-configure:
cd ${WRKSRC}; \
${ACLOCAL}; \
${AUTOHEADER}; \
${AUTOMAKE} -a --foreign -i; \
${AUTOCONF}
...
.include "../mk/automake.mk"
Packages which use GNU Automake will almost certainly
require GNU Make, but that's automatically provided for you
in mk/automake.mk.
There are times when the configure process makes
additional changes to the generated files, which then
causes the build process to try to re-execute the automake
sequence. This is prevented by touching various files in
the configure stage. If this causes problems with your
package you can set AUTOMAKE_OVERRIDE=NO in the package
Makefile.
To port an application to NetBSD, it's usually necessary for the compiler to be able to judge the system on which it's compiling, and we use definitions so that the C pre-processor can do this.
To test whether you are working on a 4.4 BSD-derived
system, you should use the BSD definition, which is defined
in <sys/param.h> on
said systems.
#include <sys/param.h>
and then you can surround the BSD-specific parts of your package's C/C++ code using this conditional:
#if (defined(BSD) && BSD >= 199306)
...
#endif
Please use the “__NetBSD__” definition sparingly - it should only apply to features of NetBSD that are not present in other 4.4-lite derived BSDs.
Packages should be taught to look for their
configuration files in ${PKG_SYSCONFDIR}, which is passed through
to the configure and build processes. PKG_SYSCONFDIR may be customized in
various ways by setting other make variables:
PKG_SYSCONFBASE is
the main config directory under which all package
configuration files are to be found. This defaults to
${PREFIX}/etc, but may
be overridden in /etc/mk.conf.
PKG_SYSCONFSUBDIR is
the subdirectory of PKG_SYSCONFBASE under which the
configuration files for a particular package may be
found, e.g. the Apache configuration files may all be
found under the httpd/
subdirectory of ${PKG_SYSCONFBASE}. This should be
set in the package Makefile.
By default, PKG_SYSCONFDIR is set to
${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR},
but this may be overridden by setting PKG_SYSCONFDIR.${PKG_SYSCONFVAR} for
a particular package, where PKG_SYSCONFVAR defaults to
${PKGBASE}. This is not
meant to be set by a package Makefile, but is
reserved for users who wish to override the
PKG_SYSCONFDIR setting
for a particular package with a special location.
The only variables that users should customize are
PKG_SYSCONFBASE and
PKG_SYSCONFDIR.${PKG_SYSCONFVAR}. Users
will typically want to set PKG_SYSCONFBASE to /etc, or to accept the default location
of ${PREFIX}/etc.
Occasionally, packages require interaction from the user, and this can be in a number of ways:
help in fetching the distfiles
help to configure the package before it is built
help during the build process
help during the installation of a package
The INTERACTIVE_STAGE
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 Makefile. e.g.
INTERACTIVE_STAGE= build
Multiple interactive stages can be specified:
INTERACTIVE_STAGE= configure install
A package may underly a license which the user has or has not agreed to accept. Usually, packages that underly well-known Open Source licenses (e.g. the GNU Public License, GPL) won't have any special license tags added in pkgsrc which require special action by the user of such packages, but there are quite a number of other licenses out there that pkgsrc users may not be able to follow, for whatever reasons. For these cases, pkgsrc contains a mechanism to note that a package underlies a certain license, and the user has to accept the license before the package can be installed.
Placing a certain package under a certain license works
by setting the LICENSE
variable to a string identifying the license, e.g. in
graphics/graphviz:
LICENSE= graphviz-license
When trying to build, the user will get a notice that the package underlies a license which he hasn't accepted (yet):
%make===> graphviz-1.12 has an unacceptable license: graphviz-license. ===> To build this package, add this line to your /etc/mk.conf: ===> ACCEPTABLE_LICENSES+=graphviz-license ===> To view the license, enter "/usr/bin/make show-license". *** Error code 1
The license can be viewed with make show-license, and if it is
considered appropriate, the line printed above can be added
to /etc/mk.conf to indicate
acceptance of the particular license:
ACCEPTABLE_LICENSES+=graphviz-license
When adding a package with a new license, the license
text should be added to pkgsrc/licenses for displaying. A list of
known licenses can be seen in this directory as well as by
looking at the list of (commented out) ACCEPTABLE_LICENSES variable settings in
pkgsrc/mk/defaults/mk.conf.
Is there is a really pressing need to accept
all licenses at once, like when trying to download or
mirror all distfiles or doing a bulk build to test if all
packages in pkgsrc build, this can be done by setting
_ACCEPTABLE=yes.
There are two make variables used to control the
creation of package-specific groups and users at
pre-install time. The first is PKG_GROUPS, which is a list of
group[:groupid] elements, where the groupid is optional.
The second is PKG_USERS, which
is a list of elements of the form:
user:group[:[userid][:[description][:[home][:shell]]]]
where only the user and group are required, the rest being optional. A simple example is:
PKG_GROUPS= foogroup
PKG_USERS= foouser:foogroup
A more complex example is that creates two groups and two users is:
PKG_GROUPS= group1 group2:1005
PKG_USERS= first:group1::First\\ User \
second:group2::Second\\ User:/home/second:${SH}
By default, a new user will have home directory
/nonexistent, and login shell
/sbin/nologin unless they are
specified as part of the user element.
The package Makefile must
also set USE_PKGINSTALL=YES.
This will cause the users and groups to be created at
pre-install time, and the admin will be prompted to remove
them at post-deinstall time. Automatic creation of the
users and groups can be toggled on and off by setting the
PKG_CREATE_USERGROUP variable
prior to package installation.
Certain packages, most of them in the games category,
install a score file that allows all users on the system to
record their highscores. In order for this to work, the
binaries need to be installed setgid and the score files
owned by the appropriate group and/or owner (traditionally
the "games" user/group). The following variables,
documented in more detail in mk/defaults/mk.conf, control this
behaviour: SETGIDGAME,
GAMEDATAMODE, GAMEGRP, GAMEMODE, GAMEOWN.
Note that per default, setgid installation of games is
disabled; setting SETGIDGAME=YES will set all the other
variables accordingly.
A package should therefor never hard code file ownership
or access permissions but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these
correctly.
If the purpose of the package is to provide a login
shell, the variable PKG_SHELL
should contain the full pathname of the shell executable
installed by this package. The package Makefile must also set USE_PKGINSTALL=YES to use the
automatically generated INSTALL/DEINSTALL scripts.
An example taken from shells/zsh:
USE_PKGINSTALL= YES
PKG_SHELL= ${PREFIX}/bin/zsh
The shell is registered into /etc/shells file automatically in the
post-install target by the generated INSTALL script and removed in the
deinstall target by the DEINSTALL script.
If your package contains interpreted perl scripts, set
REPLACE_PERL to ensure that
the proper interpreter path is set. REPLACE_PERL should contain a list of
scripts, relative to WRKSRC,
that you want adjusted.
Your package may also contain scripts with hardcoded
paths to other interpreters besides (or as well as) perl.
To correct the full pathname to the script interpreter, you
need to set the following definitions in your Makefile (we shall use
tclsh in this
example):
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
Makefiles of packages providing perl5 modules should
include the Makefile fragment ../../lang/perl5/module.mk. It provides a
do-configure
target for the standard perl configuration for such modules
as well as various hooks to tune this configuration. See
comments in this file for details.
Perl5 modules will install into different places
depending on the version of perl used during the build
process. To address this, pkgsrc will append lines to the
PLIST corresponding to the
files listed in the installed .packlist file generated by most perl5
modules. This is invoked by defining PERL5_PACKLIST to a space-separated list
of paths to packlist files, e.g.:
PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent the three
locations in which perl5 modules may be installed, and may
be used by perl5 packages that don't have a packlist. These
three variables are also substituted for in the
PLIST.
Some packages install info files or use the “makeinfo” or “install-info” commands. Each of the info files:
is considered to be installed in the directory
${PREFIX}/${INFO_DIR},
is registered in the Info directory file
${PREFIX}/${INFO_DIR}/dir,
and must be listed as a filename in the
INFO_FILES variable in
the package Makefile.
INFO_DIR defaults to
“info” and can be
overridden in the package Makefile. INSTALL and DEINSTALL scripts will be generated to
handle registration of the info files in the Info directory
file. The “install-info” command used for the
info files registration is either provided by the system,
or by a special purpose package automatically added as
dependency if needed.
A package which needs the “makeinfo” command at build time must
define the variable USE_MAKEINFO in its Makefile. If a minimum
version of the “makeinfo” command is needed it should
be noted with the TEXINFO_REQD
variable in the package Makefile. By default, a minimum version
of 3.12 is required. If the system does not provide a
makeinfo
command or if it does not match the required minimum, a
build dependency on the devel/gtexinfo package will be added
automatically.
The build and installation process of the software
provided by the package should not use the
install-info
command as the registration of info files is the task of
the package INSTALL script,
and it must use the appropriate makeinfo command.
To achieve this goal the pkgsrc infrastructure creates
overriding scripts for the install-info and
makeinfo
commands in a directory listed early in PATH.
The script overriding install-info has no effect except
the logging of a message. The script overriding
makeinfo logs
a message and according to the value of USE_MAKEINFO and TEXINFO_REQD either run the appropriate
makeinfo
command or exit on error.
If a package installs .schemas or .entries files, used by GConf2, you need
to take some extra steps to make sure they get registered
in the database:
Include ../../devel/GConf2/schemas.mk
instead of its buildlink3.mk file. This takes care
of rebuilding the GConf2 database at installation and
deinstallation time, and tells the package where to
install GConf2 data files using some standard
configure arguments. It also disallows any access to
the database directly from the package.
Ensure that the package installs its .schemas files under ${PREFIX}/share/gconf/schemas. If
they get installed under ${PREFIX}/etc, you will need to
manually patch the package.
Check the PLIST and remove any entries under the etc/gconf directory, as they will be handled automatically. See Section 6.13, “Configuration files handling and placement” for more information.
Define the GCONF2_SCHEMAS variable in your
Makefile with a list of
all .schemas files
installed by the package, if any. Names must not
contain any directories in them.
Define the GCONF2_ENTRIES variable in your
Makefile with a list of
all .entries files
installed by the package, if any. Names must not
contain any directories in them.
If a package installs .omf
files, used by scrollkeeper, you need to take some extra
steps to make sure they get registered in the database:
Include ../../textproc/scrollkeeper/omf.mk
instead of its buildlink3.mk file. This takes care
of rebuilding the scrollkeeper database at
installation and deinstallation time, and disallows
any access to it directly from the package.
Check the PLIST and remove any entries under the
libdata/scrollkeeper
directory, as they will be handled automatically.
Remove the share/omf
directory from the PLIST. It will be handled by
scrollkeeper.
If a package installs font files, you will need to
rebuild the fonts database in the directory where they get
installed at installation and deinstallation time. This can
be automatically done by using mk/fonts.mk, which you need to include in
your Makefile.
When the file is included, you can list the directories
where fonts are installed in the FONTS_ variables,
where type_DIRStype can be
one of “TTF”,
“TYPE1” or
“X11”. Also make
sure that the database file fonts.dir is not listed in the PLIST.
Note that you should not create new directories for fonts; instead use the standard ones to avoid that the user needs to manually configure his X server to find them.
If a package installs gtk2 immodules or loaders, you need to take some extra steps to get them registered in the GTK2 database properly:
Include ../../x11/gtk2/modules.mk instead
of its buildlink3.mk
file. This takes care of rebuilding the database at
installation and deinstallation time.
Set GTK2_IMMODULES=YES if your package
installs GTK2 immodules.
Set GTK2_LOADERS=YES
if your package installs GTK2 loaders.
Patch the package to not touch any of the gtk2 databases directly. These are:
libdata/gtk-2.0/gdk-pixbuf.loaders
libdata/gtk-2.0/gtk.immodules
Check the PLIST and remove any entries under the
libdata/gtk-2.0
directory, as they will be handled automatically.
If a package installs SGML or XML data files that need to be registered in system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some extra steps:
Include ../../textproc/xmlcatmgr/catalogs.mk
in your Makefile, which
takes care of registering those files in system-wide
catalogs at installation and deinstallation time.
Set SGML_CATALOGS to
the full path of any SGML catalogs installed by the
package.
Set XML_CATALOGS to
the full path of any XML catalogs installed by the
package.
Set SGML_ENTRIES to
individual entries to be added to the SGML catalog.
These come in groups of three strings; see
xmlcatmgr(1) for more information (specifically,
arguments recognized by the 'add' action). Note that
you will normally not use this variable.
Set XML_ENTRIES to
individual entries to be added to the XML catalog.
These come in groups of three strings; see
xmlcatmgr(1) for more information (specifically,
arguments recognized by the 'add' action). Note that
you will normally not use this variable.
If a package provides extensions to the MIME database by
installing .xml files inside
${PREFIX}/share/mime/packages, you need
to take some extra steps to ensure that the database is
kept consistent with respect to these new files:
Include ../../databases/shared-mime-info/mimedb.mk
(avoid using the buildlink3.mk file from this same
directory, which is reserved for inclusion from other
buildlink3.mk files).
It takes care of rebuilding the MIME database at
installation and deinstallation time, and disallows
any access to it directly from the package.
Check the PLIST and remove any entries under the
share/mime directory,
except for
files saved under share/mime/packages. The former are
handled automatically by the update-mime-database
program, but the later are package-dependent and must
be removed by the package that installed them in the
first place.
Remove any share/mime/* directories from the
PLIST. They will be handled by the shared-mime-info
package.
If a package uses intltool during its build, include the
../../textproc/intltool/buildlink3.mk
file, which forces it to use the intltool package provided
by pkgsrc, instead of the one bundled with the distribution
file.
This tracks intltool's build-time dependencies and uses the latest available version; this way, the package benefits of any bug fixes that may have appeared since it was released.
If you have found any bugs in the package you make available, if you had to do special steps to make it run under NetBSD or if you enhanced the software in various other ways, be sure to report these changes back to the original author of the program! With that kind of support, the next release of the program can incorporate these fixes, and people not using the NetBSD packages system can win from your efforts.
Support the idea of free software!