The problem with package-defined variables that can be overridden via MAKECONF or /etc/mk.conf is that &man.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 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 &man.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 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 &man.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 &man.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.pkg entry should be added or updated in it. 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. The BSD-compatible install supplied with some operating systems will not perform more than one operation at a time. As such, you should call ${INSTALL}, etc. like this: ${INSTALL_DATA_DIR} ${PREFIX}/dir1 ${INSTALL_DATA_DIR} ${PREFIX}/dir2 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 &man.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 &man.cc.1; or &man.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 &man.install.1; or &man.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 &man.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. #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 i386 i386, __i386, __i386__ MIPS __mips SPARC sparc, __sparc GCC __GNUC__ (major version), __GNUC_MINOR__ SunPro __SUNPRO_C (0x570 for version 5.7) 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. GCC 3.3.3 + SuSE Linux 9.1 + i386 __ELF__, __gnu_linux__, __i386, __i386__, __linux, __linux__, __unix, __unix__, i386, linux, unix. GCC 2.95 + NetBSD 1.6.2 + i386 __ELF__, __NetBSD__, __i386, __i386__, i386. GCC 3.3.3 + NetBSD 2.0 + i386 __ELF__, __NetBSD__, __i386, __i386__, i386. GCC 4 + Solaris 8 + SPARC __ELF__, __sparc, __sparc__, __sun, __sun__, __SVR4, __svr4__, __unix, __unix__, sparc, sun, unix. SunPro 5.7 + Solaris 8 + SPARC __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: 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: &cprompt; 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 Before March 2006, these variables were called _REPLACE.* and _REPLACE_FILES.*. 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 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 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.type variables, where type 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!