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 having 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.
Documentation should be installed into ${PREFIX}/share/doc/${PKGBASE} or
${PREFIX}/share/doc/${PKGNAME} (the
latter includes the version number of the package).
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, the USE_TOOLS definition, as well as
dependencies via buildlink3.mk, which is the preferred way
to handle dependencies, and which uses the variables named
above. See Chapter 11,
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 recognized 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).
To ignore these dependency recommendations and
just use the required DEPENDS, set IGNORE_RECOMMENDED=YES. This may
make it easier and faster to update packages built
using pkgsrc, since older compatible dependencies can
continue to be used. This is useful for people who
watch their rebuilds very carefully; it is not very
good as a general-purpose hammer. If you use it, you
need to be mindful of possible ABI changes, including
those from the underlying OS.
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 16.1.8, “Handling packages with
security problems” for more
information.
If your package needs some executable to be able
to run correctly and if there's 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 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. Both
ONLY_FOR_PLATFORM and
NOT_FOR_PLATFORM are OS
triples (OS-version-platform) that can use glob-style
wildcards.
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.
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 committing that file, use make upload in the same directory
to update the file on ftp.NetBSD.org.
After fixing the vulnerability by a patch, its
PKGREVISION should be
increased (this is of course not necessary if the problem
is fixed by using a newer release of the software). In
addition, if a buildlink3.mk file exists for an affected
package, a corresponding BUILDLINK_RECOMMENDED. entry should be
added or updated in it.pkg
Also, if the fix should be applied to the stable pkgsrc branch, be sure to submit a pullup request!
Binary packages already on ftp.NetBSD.org will be handled semi-automatically by a weekly cron job.
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: cad/simian, devel/ipv6socket, emulators/vmware-module, fonts/acroread-jpnfont, multimedia/realplayer, 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
checksum will no longer match. The contents of the new
distfile should be compared against the old one before
changing anything, to make sure the distfile was really
updated on purpose, and that no trojan horse or so crept
in. Then, the correct way to work around this is to set
DIST_SUBDIR to a unique
directory name, usually based on PKGNAME_NOREV. In case this happens more
often, PKGNAME can be used
(thus including the nbX suffix) or a date stamp can be
appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget
regenerating the distinfo file after that, since it
contains the DIST_SUBDIR path
in the filenames. Furthermore, a mail to the package's
authors seems appropriate telling them that changing
distfiles after releases without changing the file names is
not good practice.
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 only the
.la file, the other files
will be added automatically.
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 only the
.la file (this is a change
from 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 devel/libltdl/buildlink3.mk.
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.
For packages that need only autoconf:
AUTOCONF_REQD= 2.50 # if default version is not good enough
USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13
...
pre-configure:
cd ${WRKSRC}; autoconf
...
and for packages that need automake and autoconf:
AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
USE_TOOLS+= automake # use "automake14" for automake-1.4
...
pre-configure:
cd ${WRKSRC}; \
aclocal; autoheader; \
automake -a --foreign -i; autoconf
...
Packages which use GNU Automake will almost certainly require GNU Make.
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.
Sometimes you need to compile different code depending
on the target platform. The C preprocessor has a set of
predefined macros that can be queried by using #ifdef FOO or #if
defined(FOO). Among these macros are usually ones
that describe the target CPU and operating system.
Depending of which of the macros are defined, you can write
code that uses features unique to a specific platform.
Generally you should rather use the GNU autotools
(automake, autoconf, etc.) to check for specific features
(like the existence of a header file, a function or a
library), but sometimes this is not possible or
desired.
In that case you can use the predefined macros below to
configure your code to the platform it runs on. Almost
every operating system, hardware architecture and compiler
has its own macro. For example, if the macros __GNUC__, __i386__ and __NetBSD__ are all defined, you know that
you are using NetBSD on an i386 compatible CPU, and your
compiler is GCC.
To distinguish between 4.4 BSD-derived systems and the rest of the world, you should use the following code.
#include <sys/param.h>
#if (defined(BSD) && BSD >= 199306)
/* BSD-specific code goes here */
#else
/* non-BSD-specific code goes here */
#endif
If this distinction is not fine enough, you can also use the following defines.
FreeBSD __FreeBSD__
DragonFly __DragonFly__
Interix __INTERIX
Linux linux, __linux, __linux__
NetBSD __NetBSD__
OpenBSD __OpenBSD__
Solaris sun, __sun
The list of the CPP identification macros for hardware
and operating system may depend on the compiler that is
used. The following list contains some examples that may
help you to choose the right ones. For example, if you want
to conditionally compile code on Solaris, don't use
__sun__, as the SunPro
compiler does not define it. Use __sun instead.
__ELF__, __gnu_linux__, __i386, __i386__, __linux, __linux__, __unix, __unix__, i386, linux, unix.
__ELF__, __NetBSD__, __i386, __i386__, i386.
__ELF__, __NetBSD__, __i386, __i386__, i386.
__ELF__, __sparc, __sparc__, __sun, __sun__, __SVR4, __svr4__, __unix, __unix__, sparc, sun, unix.
__SVR4, __sparc, __sun, __unix, sparc, sun, unix.
If your system uses the GNU C Compiler, you can get a list of symbols that are defined by default, e.g. to identify the platform, with the following command:
gcc -E -dM - < /dev/null
On other systems you may get the list by using the system's syscall trace utility (ktrace, truss, strace) to have a look which arguments are passed to the actual compiler.
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 be covered by a license which the user has or has not agreed to accept. For these cases, pkgsrc contains a mechanism to note that a package is covered by a particular license, and the package cannot be built unless the user has accepted the license. (Installation of binary packages are not currently subject to this mechanism.) Packages with licenses that are either Open Source according to the Open Source Initiative or Free according to the Free Software Foundation will not be marked with a license tag. Packages with licenses that have not been determined to meet either definition will be marked with a license tag referring to the license. This will prevent building unless pkgsrc is informed that the license is acceptable, and enables displaying the license.
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 RESTRICTED and
NO_SRC_ON_FTP, etc.). However,
the above definition of licenses for which tags are not
needed implies that packages with redistribution
restrictions should have tags.
Denoting that a package is covered by a particular
license is done by placing the license in pkgsrc/licenses and setting the
LICENSE variable to a string
identifying the license, e.g. in graphics/xv:
LICENSE= xv-license
When trying to build, the user will get a notice that the package is covered by a license which has not been accepted:
% make
===> 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
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+=xv-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.
The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar
language is deprecated because it does not crisply refer to
a particular license text. Another problem with such usage
is that it does not enable a user to denote acceptance of
the license for a single package without accepting the same
license text for another package. In particular, this can
be inappropriate when e.g. one accepts a particular license
to indicate to pkgsrc that a fee has been paid.
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 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.
Many packages install manual pages. The man pages are
installed under ${PREFIX}/${PKGMANDIR} which is
/usr/pkg/man by default.
PKGMANDIR defaults to
“man”. For example,
you can set PKGMANDIR to
“share/man” to have
man pages install under /usr/pkg/share/man/ by default.
The support for a custom PKGMANDIR is not complete.
The PLIST files can just use man/ as the top level directory for the
man page file entries and the pkgsrc framework will convert
as needed.
Packages that are configured with GNU_CONFIGURE set as “yes”, by default will use the
./configure --mandir switch to set
where the man pages should be installed. The path is
GNU_CONFIGURE_MANDIR which
defaults to ${PREFIX}/${PKGMANDIR}.
Packages that use GNU_CONFIGURE but do not use --mandir, can
set CONFIGURE_HAS_MANDIR to
“no”. Or if the
./configure script uses a
non-standard use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed.
See Section 10.5, “Man page compression” for information on installation of compressed manual pages.
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 7.14, “How do I change the location of configuration files?” 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 the pkginstall framework.
You can list the directories where fonts are installed
in the FONTS_DIRS. variables,
where typetype 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 latter 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 a package contains a rc.d script, it won't be copied
into the startup directory by default, but you can enable
it, by adding the option PKG_RCD_SCRIPTS=YES in /etc/mk.conf. This option will copy the
scripts into /etc/rc.d when a package is installed,
and it will automatically remove the scripts when the
package is deinstalled.
If a package installs TeX packages into the texmf tree,
the ls-R database of the tree needs to
be updated.
Except the main TeX packages such as teTeX-texmf,
packages should install files into PKG_LOCALTEXMFPREFIX, not PKG_TEXMFPREFIX.
Include ../../print/teTeX/module.mk instead
of ../../mk/tex.buildlink3.mk. This
takes care of rebuilding the ls-R database at installation and
deinstallation time.
If your package installs files into a texmf tree
other than the one at PKG_LOCALTEXMFPREFIX, set
TEXMFDIRS to the list of
all texmf trees that need database update.
If your package also installs font map files that
need to be registered using updmap, set TEX_FONTMAPS to the list of all such
font map files. Then updmap will be run
automatically at installation/deinstallation to
enable/disable font map files for TeX output
drivers.
Make sure that none of ls-R databases are included in
PLIST, as they will be removed only
by the teTeX-bin package.
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!