3 Documentation on the NetBSD packages system
15 Copyright 1994-2007 The NetBSD Foundation, Inc
17 $NetBSD: pkgsrc.xml,v 1.26 2007/09/18 08:17:21 rillig Exp $
21 pkgsrc is a centralized package management system for Unix-like operating
22 systems. This guide provides information for users and developers of pkgsrc. It
23 covers installation of binary and source packages, creation of binary and
24 source packages and a high-level overview about the infrastructure.
26 -------------------------------------------------------------------------------
35 1.1.2. Supported platforms
40 1.3.1. Roles involved in pkgsrc
44 I. The pkgsrc user's guide
46 2. Where to get pkgsrc and how to keep it up-to-date
48 2.1. Getting pkgsrc for the first time
52 2.1.3. Via anonymous CVS
54 2.2. Keeping pkgsrc up-to-date
59 3. Using pkgsrc on systems other than NetBSD
61 3.1. Binary distribution
62 3.2. Bootstrapping pkgsrc
63 3.3. Platform-specific notes
65 3.3.1. Darwin (Mac OS X)
75 4.1. Using binary packages
77 4.1.1. Finding binary packages
78 4.1.2. Installing binary packages
79 4.1.3. Deinstalling packages
80 4.1.4. Getting information about installed packages
81 4.1.5. Checking for security vulnerabilities in installed packages
82 4.1.6. Finding if newer versions of your installed packages are in
84 4.1.7. Other administrative functions
85 4.1.8. A word of warning
87 4.2. Building packages from source
90 4.2.2. Fetching distfiles
91 4.2.3. How to build and install
95 5.1. General configuration
96 5.2. Variables affecting the build process
97 5.3. Variables affecting the installation process
98 5.4. Selecting and configuring the compiler
100 5.4.1. Selecting the compiler
101 5.4.2. Additional flags to the compiler (CFLAGS)
102 5.4.3. Additional flags to the linker (LDFLAGS)
104 5.5. Developer/advanced settings
105 5.6. Selecting Build Options
107 6. Creating binary packages
109 6.1. Building a single binary package
110 6.2. Settings for creation of binary packages
112 7. Creating binary packages for everything in pkgsrc (bulk builds)
114 7.1. Think first, build later
115 7.2. Requirements of a bulk build
116 7.3. Running an old-style bulk build
119 7.3.2. Other environmental considerations
122 7.3.5. Disk space requirements
123 7.3.6. Setting up a sandbox for chrooted builds
124 7.3.7. Building a partial set of packages
125 7.3.8. Uploading results of a bulk build
127 7.4. Running a pbulk-style bulk build
132 7.5. Creating a multiple CD-ROM packages collection
134 7.5.1. Example of cdpack
136 8. Directory layout of the installed files
138 8.1. File system layout in ${LOCALBASE}
139 8.2. File system layout in ${VARBASE}
141 9. Frequently Asked Questions
143 9.1. Are there any mailing lists for pkg-related discussion?
144 9.2. Where's the pkgviews documentation?
145 9.3. Utilities for package management (pkgtools)
146 9.4. How to use pkgsrc as non-root
147 9.5. How to resume transfers when fetching distfiles?
148 9.6. How can I install/use modular X.org from pkgsrc?
149 9.7. How to fetch files from behind a firewall
150 9.8. How do I tell make fetch to do passive FTP?
151 9.9. How to fetch all distfiles at once
152 9.10. What does Don't know how to make /usr/share/tmac/tmac.andoc mean?
153 9.11. What does Could not find bsd.own.mk mean?
154 9.12. Using 'sudo' with pkgsrc
155 9.13. How do I change the location of configuration files?
156 9.14. Automated security checks
157 9.15. Why do some packages ignore my CFLAGS?
158 9.16. A package does not build. What shall I do?
159 9.17. What does Makefile appears to contain unresolved cvs/rcs/???
160 merge conflicts mean?
162 II. The pkgsrc developer's guide
164 10. Creating a new pkgsrc package from scratch
166 10.1. Common types of packages
169 10.1.2. KDE applications
170 10.1.3. Python modules and programs
174 10.2.1. How the www/nvu package came into pkgsrc
176 11. Package components - files, directories and contents
182 11.3.1. Structure of a single patch file
183 11.3.2. Creating patch files
184 11.3.3. Sources where the patch files come from
185 11.3.4. Patching guidelines
186 11.3.5. Feedback to the author
188 11.4. Other mandatory files
191 11.5.1. Files affecting the binary package
192 11.5.2. Files affecting the build process
193 11.5.3. Files affecting nothing at all
198 12. Programming in Makefiles
201 12.2. Makefile variables
203 12.2.1. Naming conventions
207 12.3.1. Adding things to a list
208 12.3.2. Converting an internal list into an external list
209 12.3.3. Passing variables to a shell command
210 12.3.4. Quoting guideline
211 12.3.5. Workaround for a bug in BSD Make
216 13.2. Semi-automatic PLIST generation
217 13.3. Tweaking output of make print-PLIST
218 13.4. Variable substitution in PLIST
219 13.5. Man page compression
220 13.6. Changing PLIST source with PLIST_SRC
221 13.7. Platform-specific and differing PLISTs
222 13.8. Sharing directories between packages
224 14. Buildlink methodology
226 14.1. Converting packages to use buildlink3
227 14.2. Writing buildlink3.mk files
229 14.2.1. Anatomy of a buildlink3.mk file
230 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
232 14.3. Writing builtin.mk files
234 14.3.1. Anatomy of a builtin.mk file
235 14.3.2. Global preferences for native or pkgsrc software
237 15. The pkginstall framework
239 15.1. Files and directories outside the installation prefix
241 15.1.1. Directory manipulation
242 15.1.2. File manipulation
244 15.2. Configuration files
246 15.2.1. How PKG_SYSCONFDIR is set
247 15.2.2. Telling the software where configuration files are
248 15.2.3. Patching installations
249 15.2.4. Disabling handling of configuration files
251 15.3. System startup scripts
253 15.3.1. Disabling handling of system startup scripts
255 15.4. System users and groups
258 15.5.1. Disabling shell registration
262 15.6.1. Disabling automatic update of the fonts databases
266 16.1. Global default options
267 16.2. Converting packages to use bsd.options.mk
269 16.4. Determining the options of dependencies
271 17. The build process
274 17.2. Program location
275 17.3. Directories used during the build process
276 17.4. Running a phase
277 17.5. The fetch phase
279 17.5.1. What to fetch and where to get it from
280 17.5.2. How are the files fetched?
282 17.6. The checksum phase
283 17.7. The extract phase
284 17.8. The patch phase
285 17.9. The tools phase
286 17.10. The wrapper phase
287 17.11. The configure phase
288 17.12. The build phase
289 17.13. The test phase
290 17.14. The install phase
291 17.15. The package phase
293 17.17. Other helpful targets
295 18. Tools needed for building or running
297 18.1. Tools for pkgsrc builds
298 18.2. Tools needed by packages
299 18.3. Tools provided by platforms
300 18.4. Questions regarding the tools
302 19. Making your package work
304 19.1. General operation
306 19.1.1. Portability of packages
307 19.1.2. How to pull in user-settable variables from ???
308 19.1.3. User interaction
309 19.1.4. Handling licenses
310 19.1.5. Restricted packages
311 19.1.6. Handling dependencies
312 19.1.7. Handling conflicts with other packages
313 19.1.8. Packages that cannot or should not be built
314 19.1.9. Packages which should not be deleted, once installed
315 19.1.10. Handling packages with security problems
316 19.1.11. How to handle incrementing versions when fixing an
318 19.1.12. Substituting variable text in the package files (the SUBST
321 19.2. Fixing problems in the fetch phase
323 19.2.1. Packages whose distfiles aren't available for plain
325 19.2.2. How to handle modified distfiles with the 'old' name
327 19.3. Fixing problems in the configure phase
329 19.3.1. Shared libraries - libtool
330 19.3.2. Using libtool on GNU packages that already support libtool
331 19.3.3. GNU Autoconf/Automake
333 19.4. Programming languages
335 19.4.1. C, C++, and Fortran
337 19.4.3. Packages containing perl scripts
338 19.4.4. Other programming languages
340 19.5. Fixing problems in the build phase
342 19.5.1. Compiling C and C++ code conditionally
343 19.5.2. How to handle compiler bugs
344 19.5.3. Undefined reference to ...
345 19.5.4. Running out of memory
347 19.6. Fixing problems in the install phase
349 19.6.1. Creating needed directories
350 19.6.2. Where to install documentation
351 19.6.3. Installing highscore files
352 19.6.4. Adding DESTDIR support to packages
353 19.6.5. Packages with hardcoded paths to other interpreters
354 19.6.6. Packages installing perl modules
355 19.6.7. Packages installing info files
356 19.6.8. Packages installing man pages
357 19.6.9. Packages installing GConf data files
358 19.6.10. Packages installing scrollkeeper/rarian data files
359 19.6.11. Packages installing X11 fonts
360 19.6.12. Packages installing GTK2 modules
361 19.6.13. Packages installing SGML or XML data
362 19.6.14. Packages installing extensions to the MIME database
363 19.6.15. Packages using intltool
364 19.6.16. Packages installing startup scripts
365 19.6.17. Packages installing TeX modules
366 19.6.18. Packages supporting running binaries in emulation
367 19.6.19. Packages installing hicolor theme icons
368 19.6.20. Packages installing desktop files
370 19.7. Marking packages as having problems
373 21. Submitting and Committing
375 21.1. Submitting binary packages
376 21.2. Submitting source packages (for non-NetBSD-developers)
377 21.3. General notes when adding, updating, or removing packages
378 21.4. Committing: Importing a package into CVS
379 21.5. Updating a package to a newer version
380 21.6. Renaming a package in pkgsrc
381 21.7. Moving a package in pkgsrc
383 22. Frequently Asked Questions
384 23. GNOME packaging and porting
387 23.2. Packaging a GNOME application
388 23.3. Updating GNOME to a newer version
389 23.4. Patching guidelines
391 III. The pkgsrc infrastructure internals
393 24. Design of the pkgsrc infrastructure
395 24.1. The meaning of variable definitions
396 24.2. Avoiding problems before they arise
397 24.3. Variable evaluation
402 24.4. How can variables be specified?
403 24.5. Designing interfaces for Makefile fragments
405 24.5.1. Procedures with parameters
406 24.5.2. Actions taken on behalf of parameters
408 24.6. The order in which files are loaded
410 24.6.1. The order in bsd.prefs.mk
411 24.6.2. The order in bsd.pkg.mk
415 25.1. The regression tests framework
416 25.2. Running the regression tests
417 25.3. Adding a new regression test
419 25.3.1. Overridable functions
420 25.3.2. Helper functions
424 26.1. Porting pkgsrc to a new operating system
425 26.2. Adding support for a new compiler
427 A. A simple example package: bison
434 A.1.4. Checking a package with pkglint
436 A.2. Steps for building, installing, packaging
441 B.2. Packaging figlet
443 C. Directory layout of the pkgsrc FTP server
445 C.1. distfiles: The distributed source files
446 C.2. misc: Miscellaneous things
447 C.3. packages: Binary packages
448 C.4. reports: Bulk build reports
449 C.5. current, pkgsrc-20xxQy: source packages
451 D. Editing guidelines for the pkgsrc guide
458 1.1. Platforms supported by pkgsrc
459 11.1. Patching examples
460 23.1. PLIST handling for GNOME packages
462 Chapter 1. What is pkgsrc?
469 1.1.2. Supported platforms
474 1.3.1. Roles involved in pkgsrc
480 There is a lot of software freely available for Unix-based systems, which is
481 usually available in form of the source code. Before such software can be used,
482 it needs to be configured to the local system, compiled and installed, and this
483 is exactly what The NetBSD Packages Collection (pkgsrc) does. pkgsrc also has
484 some basic commands to handle binary packages, so that not every user has to
485 build the packages for himself, which is a time-costly task.
487 pkgsrc currently contains several thousand packages, including:
489 * www/apache - The Apache web server
491 * www/firefox - The Firefox web browser
493 * meta-pkgs/gnome - The GNOME Desktop Environment
495 * meta-pkgs/kde3 - The K Desktop Environment
497 ...just to name a few.
499 pkgsrc has built-in support for handling varying dependencies, such as pthreads
500 and X11, and extended features such as IPv6 support on a range of platforms.
504 pkgsrc provides the following key features:
506 * Easy building of software from source as well as the creation and
507 installation of binary packages. The source and latest patches are
508 retrieved from a master or mirror download site, checksum verified, then
509 built on your system. Support for binary-only distributions is available
510 for both native platforms and NetBSD emulated platforms.
512 * All packages are installed in a consistent directory tree, including
513 binaries, libraries, man pages and other documentation.
515 * Package dependencies, including when performing package updates, are
516 handled automatically. The configuration files of various packages are
517 handled automatically during updates, so local changes are preserved.
519 * Like NetBSD, pkgsrc is designed with portability in mind and consists of
520 highly portable code. This allows the greatest speed of development when
521 porting to new a platform. This portability also ensures that pkgsrc is
522 consistent across all platforms.
524 * The installation prefix, acceptable software licenses, international
525 encryption requirements and build-time options for a large number of
526 packages are all set in a simple, central configuration file.
528 * The entire source (not including the distribution files) is freely
529 available under a BSD license, so you may extend and adapt pkgsrc to your
530 needs. Support for local packages and patches is available right out of the
531 box, so you can configure it specifically for your environment.
533 The following principles are basic to pkgsrc:
535 * "It should only work if it's right." ? That means, if a package contains
536 bugs, it's better to find them and to complain about them rather than to
537 just install the package and hope that it works. There are numerous checks
538 in pkgsrc that try to find such bugs: Static analysis tools (pkgtools/
539 pkglint), build-time checks (portability of shell scripts), and
540 post-installation checks (installed files, references to shared libraries,
541 script interpreters).
543 * "If it works, it should work everywhere" ? Like NetBSD has been ported to
544 many hardware architectures, pkgsrc has been ported to many operating
545 systems. Care is taken that packages behave the same on all platforms.
547 1.1.2. Supported platforms
549 pkgsrc consists of both a source distribution and a binary distribution for
550 these operating systems. After retrieving the required source or binaries, you
551 can be up and running with pkgsrc in just minutes!
553 pkgsrc was derived from FreeBSD's ports system, and initially developed for
554 NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
557 Table 1.1. Platforms supported by pkgsrc
559 +----------------------------------------------------------------+
560 | Platform |Date Support Added|
561 |---------------------------------------------+------------------|
563 |---------------------------------------------+------------------|
564 |Solaris | Mar 1999 |
565 |---------------------------------------------+------------------|
567 |---------------------------------------------+------------------|
568 |Darwin (Mac OS X) | Oct 2001 |
569 |---------------------------------------------+------------------|
570 |FreeBSD | Nov 2002 |
571 |---------------------------------------------+------------------|
572 |OpenBSD | Nov 2002 |
573 |---------------------------------------------+------------------|
575 |---------------------------------------------+------------------|
577 |---------------------------------------------+------------------|
579 |---------------------------------------------+------------------|
580 |Interix (Microsoft Windows Services for Unix)| Mar 2004 |
581 |---------------------------------------------+------------------|
582 |DragonFlyBSD | Oct 2004 |
583 |---------------------------------------------+------------------|
585 |---------------------------------------------+------------------|
587 +----------------------------------------------------------------+
592 This document is divided into three parts. The first, The pkgsrc user's guide,
593 describes how one can use one of the packages in the Package Collection, either
594 by installing a precompiled binary package, or by building one's own copy using
595 the NetBSD package system. The second part, The pkgsrc developer's guide,
596 explains how to prepare a package so it can be easily built by other NetBSD
597 users without knowing about the package's building details. The third part, The
598 pkgsrc infrastructure internals is intended for those who want to understand
599 how pkgsrc is implemented.
601 This document is available in various formats: HTML, PDF, PS, TXT.
605 There has been a lot of talk about "ports", "packages", etc. so far. Here is a
606 description of all the terminology used within this document.
610 A set of files and building instructions that describe what's necessary to
611 build a certain piece of software using pkgsrc. Packages are traditionally
612 stored under /usr/pkgsrc.
614 The NetBSD package system
616 This is the former name of "pkgsrc". It is part of the NetBSD operating
617 system and can be bootstrapped to run on non-NetBSD operating systems as
618 well. It handles building (compiling), installing, and removing of
623 This term describes the file or files that are provided by the author of
624 the piece of software to distribute his work. All the changes necessary to
625 build on NetBSD are reflected in the corresponding package. Usually the
626 distfile is in the form of a compressed tar-archive, but other types are
627 possible, too. Distfiles are usually stored below /usr/pkgsrc/distfiles.
631 This is the term used by FreeBSD and OpenBSD people for what we call a
632 package. In NetBSD terminology, "port" refers to a different architecture.
634 Precompiled/binary package
636 A set of binaries built with pkgsrc from a distfile and stuffed together in
637 a single .tgz file so it can be installed on machines of the same machine
638 architecture without the need to recompile. Packages are usually generated
639 in /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.
641 Sometimes, this is referred to by the term "package" too, especially in the
642 context of precompiled packages.
646 The piece of software to be installed which will be constructed from all
647 the files in the distfile by the actions defined in the corresponding
650 1.3.1. Roles involved in pkgsrc
654 The pkgsrc users are people who use the packages provided by pkgsrc.
655 Typically they are system administrators. The people using the software
656 that is inside the packages (maybe called "end users") are not covered by
659 There are two kinds of pkgsrc users: Some only want to install pre-built
660 binary packages. Others build the pkgsrc packages from source, either for
661 installing them directly or for building binary packages themselves. For
662 pkgsrc users Part I, "The pkgsrc user's guide" should provide all necessary
667 A package maintainer creates packages as described in Part II, "The pkgsrc
670 infrastructure developers
672 These people are involved in all those files that live in the mk/ directory
673 and below. Only these people should need to read through Part III, "The
674 pkgsrc infrastructure internals", though others might be curious, too.
678 When giving examples for commands, shell prompts are used to show if the
679 command should/can be issued as root, or if "normal" user privileges are
680 sufficient. We use a # for root's shell prompt, and a % for users' shell
681 prompt, assuming they use the C-shell or tcsh.
683 Part I. The pkgsrc user's guide
687 2. Where to get pkgsrc and how to keep it up-to-date
689 2.1. Getting pkgsrc for the first time
693 2.1.3. Via anonymous CVS
695 2.2. Keeping pkgsrc up-to-date
700 3. Using pkgsrc on systems other than NetBSD
702 3.1. Binary distribution
703 3.2. Bootstrapping pkgsrc
704 3.3. Platform-specific notes
706 3.3.1. Darwin (Mac OS X)
716 4.1. Using binary packages
718 4.1.1. Finding binary packages
719 4.1.2. Installing binary packages
720 4.1.3. Deinstalling packages
721 4.1.4. Getting information about installed packages
722 4.1.5. Checking for security vulnerabilities in installed packages
723 4.1.6. Finding if newer versions of your installed packages are in
725 4.1.7. Other administrative functions
726 4.1.8. A word of warning
728 4.2. Building packages from source
731 4.2.2. Fetching distfiles
732 4.2.3. How to build and install
734 5. Configuring pkgsrc
736 5.1. General configuration
737 5.2. Variables affecting the build process
738 5.3. Variables affecting the installation process
739 5.4. Selecting and configuring the compiler
741 5.4.1. Selecting the compiler
742 5.4.2. Additional flags to the compiler (CFLAGS)
743 5.4.3. Additional flags to the linker (LDFLAGS)
745 5.5. Developer/advanced settings
746 5.6. Selecting Build Options
748 6. Creating binary packages
750 6.1. Building a single binary package
751 6.2. Settings for creation of binary packages
753 7. Creating binary packages for everything in pkgsrc (bulk builds)
755 7.1. Think first, build later
756 7.2. Requirements of a bulk build
757 7.3. Running an old-style bulk build
760 7.3.2. Other environmental considerations
763 7.3.5. Disk space requirements
764 7.3.6. Setting up a sandbox for chrooted builds
765 7.3.7. Building a partial set of packages
766 7.3.8. Uploading results of a bulk build
768 7.4. Running a pbulk-style bulk build
773 7.5. Creating a multiple CD-ROM packages collection
775 7.5.1. Example of cdpack
777 8. Directory layout of the installed files
779 8.1. File system layout in ${LOCALBASE}
780 8.2. File system layout in ${VARBASE}
782 9. Frequently Asked Questions
784 9.1. Are there any mailing lists for pkg-related discussion?
785 9.2. Where's the pkgviews documentation?
786 9.3. Utilities for package management (pkgtools)
787 9.4. How to use pkgsrc as non-root
788 9.5. How to resume transfers when fetching distfiles?
789 9.6. How can I install/use modular X.org from pkgsrc?
790 9.7. How to fetch files from behind a firewall
791 9.8. How do I tell make fetch to do passive FTP?
792 9.9. How to fetch all distfiles at once
793 9.10. What does Don't know how to make /usr/share/tmac/tmac.andoc mean?
794 9.11. What does Could not find bsd.own.mk mean?
795 9.12. Using 'sudo' with pkgsrc
796 9.13. How do I change the location of configuration files?
797 9.14. Automated security checks
798 9.15. Why do some packages ignore my CFLAGS?
799 9.16. A package does not build. What shall I do?
800 9.17. What does Makefile appears to contain unresolved cvs/rcs/??? merge
803 Chapter 2. Where to get pkgsrc and how to keep it up-to-date
807 2.1. Getting pkgsrc for the first time
811 2.1.3. Via anonymous CVS
813 2.2. Keeping pkgsrc up-to-date
818 Before you download and extract the files, you need to decide where you want to
819 extract them. When using pkgsrc as root user, pkgsrc is usually installed in /
820 usr/pkgsrc. You are though free to install the sources and binary packages
821 wherever you want in your filesystem, provided that the pathname does not
822 contain white-space or other characters that are interpreted specially by the
823 shell and some other programs. A safe bet is to use only letters, digits,
824 underscores and dashes.
826 2.1. Getting pkgsrc for the first time
828 Before you download any pkgsrc files, you should decide whether you want the
829 current branch or the stable branch. The latter is forked on a quarterly basis
830 from the current branch and only gets modified for security updates. The names
831 of the stable branches are built from the year and the quarter, for example
834 The second step is to decide how you want to download pkgsrc. You can get it as
835 a tar file, via SUP, or via CVS. All three ways are described here.
839 The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/
840 pkgsrc/. There are a number of subdirectories for different purposes, which are
841 described in detail in Appendix C, Directory layout of the pkgsrc FTP server.
843 The tar file for the current branch is in the directory current and is called
844 pkgsrc.tar.gz. It is autogenerated daily.
846 The tar file for the stable branch 2009Q1 is in the directory pkgsrc-2009Q1 and
847 is also called pkgsrc-2009Q1.tar.gz.
849 To download a pkgsrc stable tarball, run:
851 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-20xxQy/pkgsrc-20xxQy.tar.gz
853 Where pkgsrc-20xxQy is the stable branch to be downloaded, for example,
856 Then, extract it with:
858 $ tar -xzf pkgsrc-20xxQy.tar.gz -C /usr
860 This will create the directory pkgsrc/ in /usr/ and all the package source will
861 be stored under /usr/pkgsrc/.
863 To download pkgsrc-current, run:
865 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
869 As an alternative to the tar file, you can get pkgsrc via the Software Update
870 Protocol, SUP. To do so, make sure your supfile has a line
874 in it, see the examples in /usr/share/examples/supfiles, and that the /usr/
875 pkgsrc directory exists. Then, simply run:
877 $ sup -v /path/to/your/supfile.
879 2.1.3. Via anonymous CVS
881 To do an initial (full) checkout of pkgsrc, you first have to set some
882 environment variables. For the C-Shell, type:
884 % setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot
887 Or, the same for the bourne shell:
889 $ export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"
890 $ export CVS_RSH="ssh"
892 By default, CVS doesn't do things like most people would expect it to do. But
893 there is a way to convince CVS, by creating a file called .cvsrc in your home
894 directory and saving the following lines to it. This file will save you lots of
895 headache and some bug reports, so we strongly recommend it. You can find an
896 explanation of this file in the CVS documentation.
898 # recommended CVS configuration file from the pkgsrc guide
906 To fetch a specific pkgsrc stable branch from scratch, run:
909 $ cvs checkout -r pkgsrc-20xxQy -P pkgsrc
911 Where pkgsrc-20xxQy is the stable branch to be checked out, for example,
914 This will create the directory pkgsrc/ in your /usr/ directory and all the
915 package source will be stored under /usr/pkgsrc/.
917 To fetch the pkgsrc current branch, run:
920 $ cvs checkout -P pkgsrc
922 2.2. Keeping pkgsrc up-to-date
924 The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you
925 have first installed it via a tar file). It saves bandwidth and hard disk
926 activity, compared to downloading the tar file again.
932 When updating from a tar file, you first need to completely remove the old
933 pkgsrc directory. Otherwise those files that have been removed from pkgsrc in
934 the mean time will not be removed on your local disk, resulting in
935 inconsistencies. When removing the old files, any changes that you have done to
936 the pkgsrc files will be lost after updating. Therefore updating via CVS is
937 strongly recommended.
939 Note that by default the distfiles and the binary packages are saved in the
940 pkgsrc tree, so don't forget to rescue them before updating. You can also
941 configure pkgsrc to use other than the default directories by setting the
942 DISTDIR and PACKAGES variables. See Chapter 5, Configuring pkgsrc for the
945 To update pkgsrc from a tar file, download the tar file as explained above.
946 Then, make sure that you have not made any changes to the files in the pkgsrc
947 directory. Remove the pkgsrc directory and extract the new tar file. Done.
951 To update pkgsrc via CVS, make sure the environment variable CVS_RSH is set as
952 above. Then, change to the pkgsrc directory and run cvs:
957 2.2.2.1. Switching between different pkgsrc branches
959 When updating pkgsrc, the CVS program keeps track of the branch you selected.
960 But if you, for whatever reason, want to switch from the stable branch to the
961 current one, you can do it by adding the option "-A" after the "update"
962 keyword. To switch from the current branch back to the stable branch, add the
963 "-rpkgsrc-2009Q3" option.
965 2.2.2.2. What happens to my changes when updating?
967 When you update pkgsrc, the CVS program will only touch those files that are
968 registered in the CVS repository. That means that any packages that you created
969 on your own will stay unmodified. If you change files that are managed by CVS,
970 later updates will try to merge your changes with those that have been done by
971 others. See the CVS manual, chapter "update" for details.
973 Chapter 3. Using pkgsrc on systems other than NetBSD
977 3.1. Binary distribution
978 3.2. Bootstrapping pkgsrc
979 3.3. Platform-specific notes
981 3.3.1. Darwin (Mac OS X)
989 3.1. Binary distribution
991 See Section 4.1, "Using binary packages".
993 3.2. Bootstrapping pkgsrc
995 Installing the bootstrap kit from source should be as simple as:
997 # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
998 # cd pkgsrc/bootstrap
1002 See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways
1003 to get pkgsrc before bootstrapping. The given bootstrap command will use the
1004 defaults of /usr/pkg for the prefix where programs will be installed in, and /
1005 var/db/pkg for the package database directory where pkgsrc will do its internal
1006 bookkeeping. However, these can also be set using command-line arguments.
1010 The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
1011 For examples in this guide, use bmake instead of "make".
1013 3.3. Platform-specific notes
1015 Here are some platform-specific notes you should be aware of.
1017 3.3.1. Darwin (Mac OS X)
1019 Darwin 5.x and up are supported. Before you start, you will need to download
1020 and install the Mac OS X Developer Tools from Apple's Developer Connection. See
1021 http://developer.apple.com/macosx/ for details. Also, make sure you install X11
1022 (an optional package included with the Developer Tools) if you intend to build
1023 packages that use the X11 Window System.
1027 FreeBSD 4.7 and 5.0 have been tested and are supported, other versions may
1030 Care should be taken so that the tools that this kit installs do not conflict
1031 with the FreeBSD userland tools. There are several steps:
1033 1. FreeBSD stores its ports pkg database in /var/db/pkg. It is therefore
1034 recommended that you choose a different location (e.g. /usr/pkgdb) by using
1035 the --pkgdbdir option to the bootstrap script.
1037 2. If you do not intend to use the FreeBSD ports tools, it's probably a good
1038 idea to move them out of the way to avoid confusion, e.g.
1041 # mv pkg_add pkg_add.orig
1042 # mv pkg_create pkg_create.orig
1043 # mv pkg_delete pkg_delete.orig
1044 # mv pkg_info pkg_info.orig
1047 3. An example mk.conf file will be placed in /etc/mk.conf.example file when
1048 you use the bootstrap script.
1052 Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a
1053 Unix-like environment with a tighter kernel integration than available with
1054 Cygwin. It is part of the Windows Services for Unix package, available for free
1055 for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU
1056 can be downloaded from http://www.microsoft.com/windows/sfu/.
1058 Services for Unix 3.5 has been tested. 3.0 or 3.1 may work, but are not
1059 officially supported. (The main difference in 3.0/3.1 is lack of pthreads, but
1060 other parts of libc may also be lacking.)
1062 Services for Unix Applications (aka SUA) is an integrated component of Windows
1063 Server 2003 R2 and Windows Vista. As of this writing, SUA's Interix 5.x
1064 subsystem has not yet been tested with pkgsrc.
1066 3.3.3.1. When installing Interix/SFU
1068 At an absolute minimum, the following packages must be installed from the
1069 Windows Services for Unix 3.5 distribution in order to use pkgsrc:
1071 * Utilities -> Base Utilities
1073 * Interix GNU Components -> (all)
1075 * Remote Connectivity
1079 When using pkgsrc on Interix, DO NOT install the Utilities subcomponent "UNIX
1080 Perl". That is Perl 5.6 without shared module support, installed to /usr/local,
1081 and will only cause confusion. Instead, install Perl 5.8 from pkgsrc (or from a
1084 The Remote Connectivity subcomponent "Windows Remote Shell Service" does not
1085 need to be installed, but Remote Connectivity itself should be installed in
1086 order to have a working inetd.
1088 During installation you may be asked whether to enable setuid behavior for
1089 Interix programs, and whether to make pathnames default to case-sensitive.
1090 Setuid should be enabled, and case-sensitivity MUST be enabled. (Without
1091 case-sensitivity, a large number of packages including perl will not build.)
1093 NOTE: Newer Windows service packs change the way binary execution works (via
1094 the Data Execution Prevention feature). In order to use pkgsrc and other
1095 gcc-compiled binaries reliably, a hotfix containing POSIX.EXE, PSXDLL.DLL,
1096 PSXRUN.EXE, and PSXSS.EXE (899522 or newer) must be installed. Hotfixes are
1097 available from Microsoft through a support contract; however, Debian Interix
1098 Port has made most Interix hotfixes available for personal use from http://
1099 www.debian-interix.net/hotfixes/.
1101 In addition to the hotfix noted above, it may be necessary to disable Data
1102 Execution Prevention entirely to make Interix functional. This may happen only
1103 with certain types of CPUs; the cause is not fully understood at this time. If
1104 gcc or other applications still segfault repeatedly after installing one of the
1105 hotfixes note above, the following option can be added to the appropriate
1106 "boot.ini" line on the Windows boot drive: /NoExecute=AlwaysOff (WARNING, this
1107 will disable DEP completely, which may be a security risk if applications are
1108 often run as a user in the Administrators group!)
1110 3.3.3.2. What to do if Interix/SFU is already installed
1112 If SFU is already installed and you wish to alter these settings to work with
1113 pkgsrc, note the following things.
1115 * To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft Windows
1116 Services for UNIX, then click Change. In the installer, choose Add or
1117 Remove, then uncheck Utilities->UNIX Perl.
1119 * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change
1120 the following registry key:
1122 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
1124 Set the DWORD value "obcaseinsensitive" to 0; then reboot.
1126 * To enable setuid binaries (optional), run REGEDIT.EXE, and change the
1127 following registry key:
1129 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX
1131 Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.
1133 3.3.3.3. Important notes for using pkgsrc
1135 The package manager (either the pkgsrc "su" user, or the user running
1136 "pkg_add") must be a member of the local Administrators group. Such a user must
1137 also be used to run the bootstrap. This is slightly relaxed from the normal
1138 pkgsrc requirement of "root".
1140 The package manager should use a umask of 002. "make install" will
1141 automatically complain if this is not the case. This ensures that directories
1142 written in /var/db/pkg are Administrators-group writeable.
1144 The popular Interix binary packages from http://www.interopsystems.com/ use an
1145 older version of pkgsrc's pkg_* tools. Ideally, these should NOT be used in
1146 conjunction with pkgsrc. If you choose to use them at the same time as the
1147 pkgsrc packages, ensure that you use the proper pkg_* tools for each type of
1150 The TERM setting used for DOS-type console windows (including those invoked by
1151 the csh and ksh startup shortcuts) is "interix". Most systems don't have a
1152 termcap/terminfo entry for it, but the following .termcap entry provides
1153 adequate emulation in most cases:
1155 interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
1158 3.3.3.4. Limitations of the Interix platform
1160 Though Interix suffices as a familiar and flexible substitute for a full
1161 Unix-like platform, it has some drawbacks that should be noted for those
1162 desiring to make the most of Interix.
1166 Interix comes with the standard set of X11R6 client libraries, and can run
1167 X11 based applications, but it does not come with an X server. Some options
1168 are StarNet X-Win32, Hummingbird Exceed (available in a trimmed version for
1169 Interix from Interop Systems as the Interop X Server), and the free X11
1170 server included with Cygwin.
1174 Because Interix runs in a completely different NT subsystem from Win32
1175 applications, it does not currently support various X11 protocol extensions
1176 for acceleration (such as MIT-SHM or DGA). Most interactive applications to
1177 a local X server will run reasonably fast, but full motion video and other
1178 graphics intensive applications may require a faster-than-expected CPU.
1182 Interix has no native support for audio output. For audio support, pkgsrc
1183 uses the esound client/server audio system on Interix. Unlike on most
1184 platforms, the audio/esound package does not contain the esd server
1185 component. To output audio via an Interix host, the emulators/cygwin_esound
1186 package must also be installed.
1188 * CD/DVDs, USB, and SCSI:
1190 Direct device access is not currently supported in Interix, so it is not
1191 currently possible to access CD/DVD drives, USB devices, or SCSI devices
1192 through non-filesystem means. Among other things, this makes it impossible
1193 to use Interix directly for CD/DVD burning.
1197 Due to the same limitations as for CD-ROMs and SCSI devices, tape drives
1198 are also not directly accessible in Interix. However, support is in work to
1199 make tape drive access possible by using Cygwin as a bridge (similarly to
1200 audio bridged via Cygwin's esound server).
1202 3.3.3.5. Known issues for pkgsrc on Interix
1204 It is not necessary, in general, to have a "root" user on the Windows system;
1205 any member of the local Administrators group will suffice. However, some
1206 packages currently assume that the user named "root" is the privileged user. To
1207 accommodate these, you may create such a user; make sure it is in the local
1208 group Administrators (or your language equivalent).
1210 pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time
1211 being, install packages as the local Administrator (or your language
1212 equivalent), or run the following command after installing a package to work
1215 # chmod -R g+w $PKG_DBDIR
1220 You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro
1221 compiler (cc/c89). Please set the CC environment variable according to your
1222 preference. If you do not have a license for the MIPSpro compiler suite, you
1223 can download a gcc tardist file from http://freeware.sgi.com/.
1225 Please note that you will need IRIX 6.5.17 or higher, as this is the earliest
1226 version of IRIX providing support for if_indextoname(3), if_nametoindex(3),
1229 At this point in time, pkgsrc only supports one ABI at a time. That is, you
1230 cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit
1231 ABI. If you start out using "abi=n32", that's what all your packages will be
1234 Therefore, please make sure that you have no conflicting CFLAGS in your
1235 environment or the mk.conf. Particularly, make sure that you do not try to link
1236 n32 object files with lib64 or vice versa. Check your /etc/compiler.defaults!
1238 If you have the actual pkgsrc tree mounted via NFS from a different host,
1239 please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX
1240 linker occasionally runs into issues when trying to link over a network-mounted
1243 The bootstrapping process should set all the right options for programs such as
1244 imake(1), but you may want to set some options depending on your local setup.
1245 Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages
1248 If you are using SGI's MIPSPro compiler, please set
1250 PKGSRC_COMPILER= mipspro
1253 in mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up
1254 passing invalid flags to the compiler. Note that bootstrap should create an
1255 appropriate mk.conf.example by default.
1257 If you have both the MIPSPro compiler chain installed as well as gcc, but want
1258 to make sure that MIPSPro is used, please set your PATH to not include the
1259 location of gcc (often /usr/freeware/bin), and (important) pass the
1260 '--preserve-path' flag.
1264 Some versions of Linux (for example Debian GNU/Linux) need either libtermcap or
1265 libcurses (libncurses). Installing the distributions libncurses-dev package (or
1266 equivalent) should fix the problem.
1268 pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++
1269 Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested.
1271 To bootstrap using icc, assuming the default icc installation directory:
1273 env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \
1274 ac_cv___attribute__=yes ./bootstrap
1279 icc 8.1 needs the `-i-static' argument instead of -static-libcxa.
1281 icc supports __attribute__, but the GNU configure test uses a nested function,
1282 which icc does not support. #undef'ing __attribute__ has the unfortunate
1283 side-effect of breaking many of the Linux header files, which cannot be
1284 compiled properly without __attribute__. The test must be overridden so that
1285 __attribute__ is assumed supported by the compiler.
1287 After bootstrapping, you should set PKGSRC_COMPILER in mk.conf:
1289 PKGSRC_COMPILER= icc
1292 The default installation directory for icc is /opt/intel_cc_80, which is also
1293 the pkgsrc default. If you have installed it into a different directory, set
1299 pkgsrc uses the static linking method of the runtime libraries provided by icc,
1300 so binaries can be run on other systems which do not have the shared libraries
1303 Libtool, however, extracts a list of libraries from the ld(1) command run when
1304 linking a C++ shared library and records it, throwing away the -Bstatic and
1305 -Bdynamic options interspersed between the libraries. This means that
1306 libtool-linked C++ shared libraries will have a runtime dependency on the icc
1307 libraries until this is fixed in libtool.
1311 OpenBSD 3.0 and 3.2 are tested and supported.
1313 Care should be taken so that the tools that this kit installs do not conflict
1314 with the OpenBSD userland tools. There are several steps:
1316 1. OpenBSD stores its ports pkg database in /var/db/pkg. It is therefore
1317 recommended that you choose a different location (e.g. /usr/pkgdb) by using
1318 the --pkgdbdir option to the bootstrap script.
1320 2. If you do not intend to use the OpenBSD ports tools, it's probably a good
1321 idea to move them out of the way to avoid confusion, e.g.
1324 # mv pkg_add pkg_add.orig
1325 # mv pkg_create pkg_create.orig
1326 # mv pkg_delete pkg_delete.orig
1327 # mv pkg_info pkg_info.orig
1330 3. An example mk.conf file will be placed in /etc/mk.conf.example file when
1331 you use the bootstrap script. OpenBSD's make program uses mk.conf as well.
1332 You can work around this by enclosing all the pkgsrc-specific parts of the
1336 # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
1344 Solaris 2.6 through 9 are supported on both x86 and sparc. You will need a
1345 working C compiler. Both gcc 2.95.3 and Sun WorkShop 5 have been tested.
1347 The following packages are required on Solaris 8 for the bootstrap process and
1360 Please note that the use of GNU binutils on Solaris is not supported, as of
1363 Whichever compiler you use, please ensure the compiler tools and your $prefix
1364 are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/
1367 3.3.7.1. If you are using gcc
1369 It makes life much simpler if you only use the same gcc consistently for
1370 building all packages.
1372 It is recommended that an external gcc be used only for bootstrapping, then
1373 either build gcc from lang/gcc or install a binary gcc package, then remove gcc
1374 used during bootstrapping.
1376 Binary packages of gcc can be found through http://www.sunfreeware.com/.
1378 3.3.7.2. If you are using Sun WorkShop
1380 You will need at least the following packages installed (from WorkShop 5.0)
1382 * SPROcc - Sun WorkShop Compiler C 5.0
1384 * SPROcpl - Sun WorkShop Compiler C++ 5.0
1386 * SPROild - Sun WorkShop Incremental Linker
1388 * SPROlang - Sun WorkShop Compilers common components
1390 You should set the following variables in your mk.conf file:
1399 The CPP setting might break some packages that use the C preprocessor for
1400 processing things other than C source code.
1402 3.3.7.3. Building 64-bit binaries with SunPro
1404 To build 64-bit packages, you just need to have the following lines in your
1407 PKGSRC_COMPILER= sunpro
1412 This setting has been tested for the SPARC architecture. Intel and AMD machines
1413 need some more work.
1415 3.3.7.4. Common problems
1417 Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The
1418 workaround is to use another shell for the configure scripts, for example by
1419 installing shells/bash and adding the following lines to your mk.conf:
1421 CONFIG_SHELL= ${LOCALBASE}/bin/bash
1422 WRAPPER_SHELL= ${LOCALBASE}/bin/bash
1425 Then, rebuild the devel/libtool-base package.
1427 Chapter 4. Using pkgsrc
1431 4.1. Using binary packages
1433 4.1.1. Finding binary packages
1434 4.1.2. Installing binary packages
1435 4.1.3. Deinstalling packages
1436 4.1.4. Getting information about installed packages
1437 4.1.5. Checking for security vulnerabilities in installed packages
1438 4.1.6. Finding if newer versions of your installed packages are in pkgsrc
1439 4.1.7. Other administrative functions
1440 4.1.8. A word of warning
1442 4.2. Building packages from source
1445 4.2.2. Fetching distfiles
1446 4.2.3. How to build and install
1448 Basically, there are two ways of using pkgsrc. The first is to only install the
1449 package tools and to use binary packages that someone else has prepared. This
1450 is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
1451 Then you are able to build your own packages, and you can still use binary
1452 packages from someone else.
1454 4.1. Using binary packages
1456 On the ftp.NetBSD.org server and its mirrors, there are collections of binary
1457 packages, ready to be installed. These binary packages have been built using
1458 the default settings for the directories, that is:
1460 * /usr/pkg for LOCALBASE, where most of the files are installed,
1462 * /usr/pkg/etc for configuration files,
1464 * /var for VARBASE, where those files are installed that may change after
1467 If you cannot use these directories for whatever reasons (maybe because you're
1468 not root), you cannot use these binary packages, but have to build the packages
1469 yourself, which is explained in Section 3.2, "Bootstrapping pkgsrc".
1471 4.1.1. Finding binary packages
1473 To install binary packages, you first need to know from where to get them. The
1474 first place where you should look is on the main pkgsrc FTP server in the
1475 directory /pub/pkgsrc/packages.
1477 This directory contains binary packages for multiple platforms. First, select
1478 your operating system. (Ignore the directories with version numbers attached to
1479 it, they just exist for legacy reasons.) Then, select your hardware
1480 architecture, and in the third step, the OS version and the "version" of
1483 In this directory, you often find a file called bootstrap.tar.gz which contains
1484 the package management tools. If the file is missing, it is likely that your
1485 operating system already provides those tools. Download the file and extract it
1486 in the / directory. It will create the directories /usr/pkg (containing the
1487 tools for managing binary packages) and /var/db/pkg (the database of installed
1490 4.1.2. Installing binary packages
1492 In the directory from the last section, there is a subdirectory called All,
1493 which contains all the binary packages that are available for the platform,
1494 excluding those that may not be distributed via FTP or CDROM (depending on
1495 which medium you are using). There may be an extra directory for packages
1496 that have vulnerabilities and therefore are considered insecure to install
1497 without checking the implications first. This method has been replaced by
1498 setting CHECK_VULNERABILITIES=yes in pkg_install.conf so pkg_add will
1499 complain about vulnerabilities, instead.
1501 To install packages directly from an FTP or HTTP server, run the following
1502 commands in a Bourne-compatible shell (be sure to su to root first):
1504 # PATH="/usr/pkg/sbin:$PATH"
1505 # PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All"
1506 # export PATH PKG_PATH
1508 Instead of URLs, you can also use local paths, for example if you are
1509 installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want
1510 to install packages from multiple sources, you can separate them by a semicolon
1513 After these preparations, installing a package is very easy:
1515 # pkg_add openoffice2
1517 # pkg_add ap2-php5-*
1519 Note that any prerequisite packages needed to run the package in question will
1520 be installed, too, assuming they are present where you install from.
1522 After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
1523 in your PATH so you can actually start the just installed program.
1525 4.1.3. Deinstalling packages
1527 To deinstall a package, it does not matter whether it was installed from source
1528 code or from a binary package. The pkg_delete command does not know it anyway.
1529 To delete a package, you can just run pkg_delete package-name. The package name
1530 can be given with or without version number. Wildcards can also be used to
1531 deinstall a set of packages, for example *emacs*. Be sure to include them in
1532 quotes, so that the shell does not expand them before pkg_delete sees them.
1534 The -r option is very powerful: it removes all the packages that require the
1535 package in question and then removes the package itself. For example:
1537 # pkg_delete -r jpeg
1540 will remove jpeg and all the packages that used it; this allows upgrading the
1543 4.1.4. Getting information about installed packages
1545 The pkg_info shows information about installed packages or binary package
1548 4.1.5. Checking for security vulnerabilities in installed packages
1550 The NetBSD Security-Officer and Packages Groups maintain a list of known
1551 security vulnerabilities to packages which are (or have been) included in
1552 pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/
1553 pub/pkgsrc/distfiles/vulnerabilities.
1555 Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded
1556 automatically, and a security audit of all packages installed on a system can
1559 There are two components to auditing. The first step, pkg_admin
1560 fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
1561 the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of
1562 your installed packages are vulnerable. If a package is vulnerable, you will
1563 see output similar to the following:
1565 Package samba-2.0.9 has a local-root-shell vulnerability, see
1566 http://www.samba.org/samba/whatsnew/macroexploit.html
1568 You may wish to have the vulnerabilities file downloaded daily so that it
1569 remains current. This may be done by adding an appropriate entry to the root
1570 users crontab(5) entry. For example the entry
1572 # download vulnerabilities file
1573 0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
1576 will update the vulnerability list every day at 3AM. You may wish to do this
1577 more often than once a day. In addition, you may wish to run the package audit
1578 from the daily security script. This may be accomplished by adding the
1579 following line to /etc/security.local:
1581 /usr/sbin/pkg_admin audit
1584 4.1.6. Finding if newer versions of your installed packages are in pkgsrc
1586 Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
1587 if your packages are up-to-date, e.g.
1591 Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
1594 You can then use make update to update the package on your system and rebuild
1597 4.1.7. Other administrative functions
1599 The pkg_admin executes various administrative functions on the package system.
1601 4.1.8. A word of warning
1603 Please pay very careful attention to the warnings expressed in the pkg_add(1)
1604 manual page about the inherent dangers of installing binary packages which you
1605 did not create yourself, and the security holes that can be introduced onto
1606 your system by indiscriminate adding of such files.
1608 The same warning of course applies to every package you install from source
1609 when you haven't completely read and understood the source code of the package,
1610 the compiler that is used to build the package and all the other tools that are
1613 4.2. Building packages from source
1615 After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
1616 organized into categories. You can browse the online index of packages, or run
1617 make readme from the pkgsrc directory to build local README.html files for all
1618 packages, viewable with any web browser such as www/lynx or www/firefox.
1620 The default prefix for installed packages is /usr/pkg. If you wish to change
1621 this, you should do so by setting LOCALBASE in mk.conf. You should not try to
1622 use multiple different LOCALBASE definitions on the same system (inside a
1623 chroot is an exception).
1625 The rest of this chapter assumes that the package is already in pkgsrc. If it
1626 is not, see Part II, "The pkgsrc developer's guide" for instructions how to
1627 create your own packages.
1631 To build packages from source, you need a working C compiler. On NetBSD, you
1632 need to install the "comp" and the "text" distribution sets. If you want to
1633 build X11-related packages, the "xbase" and "xcomp" distribution sets are
1636 4.2.2. Fetching distfiles
1638 The first step for building a package is downloading the distfiles (i.e. the
1639 unmodified source). If they have not yet been downloaded, pkgsrc will fetch
1642 If you have all files that you need in the distfiles directory, you don't need
1643 to connect. If the distfiles are on CD-ROM, you can mount the CD-ROM on /cdrom
1646 DISTDIR=/cdrom/pkgsrc/distfiles
1650 By default a list of distribution sites will be randomly intermixed to prevent
1651 huge load on servers which holding popular packages (for example,
1652 SourceForge.net mirrors). Thus, every time when you need to fetch yet another
1653 distfile all the mirrors will be tried in new (random) order. You can turn this
1654 feature off by setting MASTER_SORT_RANDOM=NO (for PKG_DEVELOPERs it's already
1657 You can overwrite some of the major distribution sites to fit to sites that are
1658 close to your own. By setting one or two variables you can modify the order in
1659 which the master sites are accessed. MASTER_SORT contains a whitespace
1660 delimited list of domain suffixes. MASTER_SORT_REGEX is even more flexible, it
1661 contains a whitespace delimited list of regular expressions. It has higher
1662 priority than MASTER_SORT. Have a look at pkgsrc/mk/defaults/mk.conf to find
1663 some examples. This may save some of your bandwidth and time.
1665 You can change these settings either in your shell's environment, or, if you
1666 want to keep the settings, by editing the mk.conf file, and adding the
1669 If a package depends on many other packages (such as meta-pkgs/kde3), the build
1670 process may alternate between periods of downloading source, and compiling. To
1671 ensure you have all the source downloaded initially you can run the command:
1673 % make fetch-list | sh
1675 which will output and run a set of shell commands to fetch the necessary files
1676 into the distfiles directory. You can also choose to download the files
1679 4.2.3. How to build and install
1681 Once the software has downloaded, any patches will be applied, then it will be
1682 compiled for you. This may take some time depending on your computer, and how
1683 many other packages the software depends on and their compile time.
1687 If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
1688 command instead of "make" in the examples in this guide.
1696 at the shell prompt to build the various components of the package.
1698 The next stage is to actually install the newly compiled program onto your
1699 system. Do this by entering:
1704 while you are still in the directory for whatever package you are installing.
1706 Installing the package on your system may require you to be root. However,
1707 pkgsrc has a just-in-time-su feature, which allows you to only become root for
1708 the actual installation step.
1710 That's it, the software should now be installed and setup for use. You can now
1716 to remove the compiled files in the work directory, as you shouldn't need them
1717 any more. If other packages were also added to your system (dependencies) to
1718 allow your program to compile, you can tidy these up also with the command:
1720 % make clean-depends
1723 Taking the figlet utility as an example, we can install it on our system by
1724 building as shown in Appendix B, Build logs.
1726 The program is installed under the default root of the packages tree - /usr/
1727 pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
1728 environment, and it will use that value as the root of your packages tree. So,
1729 to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
1730 that you should use a directory which is dedicated to packages and not shared
1731 with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
1732 not try to add any of your own files or directories (such as src/, obj/, or
1733 pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
1734 between programs and other files installed by the package system and whatever
1735 else may have been installed there.
1737 Some packages look in mk.conf to alter some configuration options at build
1738 time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will
1739 be set there by default. Environment variables such as LOCALBASE can be set in
1740 mk.conf to save having to remember to set them each time you want to use
1743 Occasionally, people want to "look under the covers" to see what is going on
1744 when a package is building or being installed. This may be for debugging
1745 purposes, or out of simple curiosity. A number of utility values have been
1746 added to help with this.
1748 1. If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a huge
1749 amount of information will be displayed. For example,
1751 make patch PKG_DEBUG_LEVEL=2
1753 will show all the commands that are invoked, up to and including the
1756 2. If you want to know the value of a certain make(1) definition, then the
1757 VARNAME definition should be used, in conjunction with the show-var target.
1758 e.g. to show the expansion of the make(1) variable LOCALBASE:
1760 % make show-var VARNAME=LOCALBASE
1765 If you want to install a binary package that you've either created yourself
1766 (see next section), that you put into pkgsrc/packages manually or that is
1767 located on a remote FTP server, you can use the "bin-install" target. This
1768 target will install a binary package - if available - via pkg_add(1), else do a
1769 make package. The list of remote FTP sites searched is kept in the variable
1770 BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
1771 to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
1774 A final word of warning: If you set up a system that has a non-standard setting
1775 for LOCALBASE, be sure to set that before any packages are installed, as you
1776 cannot use several directories for the same purpose. Doing so will result in
1777 pkgsrc not being able to properly detect your installed packages, and fail
1778 miserably. Note also that precompiled binary packages are usually built with
1779 the default LOCALBASE of /usr/pkg, and that you should not install any if you
1780 use a non-standard LOCALBASE.
1782 Chapter 5. Configuring pkgsrc
1786 5.1. General configuration
1787 5.2. Variables affecting the build process
1788 5.3. Variables affecting the installation process
1789 5.4. Selecting and configuring the compiler
1791 5.4.1. Selecting the compiler
1792 5.4.2. Additional flags to the compiler (CFLAGS)
1793 5.4.3. Additional flags to the linker (LDFLAGS)
1795 5.5. Developer/advanced settings
1796 5.6. Selecting Build Options
1798 The whole pkgsrc system is configured in a single file, usually called mk.conf.
1799 In which directory pkgsrc looks for that file depends on the installation. On
1800 NetBSD, when you use make(1) from the base system, it is in the directory /etc
1801 /. In all other cases the default location is ${PREFIX}/etc/, depending on
1802 where you told the bootstrap program to install the binary packages.
1804 During the bootstrap, an example configuration file is created. To use that,
1805 you have to create the directory ${PREFIX}/etc and copy the example file there.
1807 The format of the configuration file is that of the usual BSD-style Makefiles.
1808 The whole pkgsrc configuration is done by setting variables in this file. Note
1809 that you can define all kinds of variables, and no special error checking (for
1810 example for spelling mistakes) takes place, so you have to try it out to see if
1813 5.1. General configuration
1815 In this section, you can find some variables that apply to all pkgsrc packages.
1816 A complete list of the variables that can be configured by the user is
1817 available in mk/defaults/mk.conf, together with some comments that describe
1818 each variable's intent.
1820 * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
1821 not mix binary packages with different LOCALBASEs!
1823 * CROSSBASE: Where "cross" category packages will be installed. The default
1824 is ${LOCALBASE}/cross.
1826 * X11BASE: Where X11 is installed on the system. The default is /usr/X11R6.
1828 * DISTDIR: Where to store the downloaded copies of the original source
1829 distributions used for building pkgsrc packages. The default is $
1830 {PKGSRCDIR}/distfiles.
1832 * PKG_DBDIR: Where the database about installed packages is stored. The
1833 default is /var/db/pkg.
1835 * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
1838 * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
1839 files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
1840 respectively. The defaults are ftp://ftp.NetBSD.org/pub/NetBSD/packages/
1841 distfiles/${DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$
1844 * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
1845 with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
1847 * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
1848 case-sensitive. Whenever you try to build a package whose license is not in
1849 this list, you will get an error message. If the license condition is
1850 simple enough, the error message will include specific instructions on how
1851 to change this variable.
1853 5.2. Variables affecting the build process
1857 * PACKAGES: The top level directory for the binary packages. The default is $
1858 {PKGSRCDIR}/packages.
1860 * WRKOBJDIR: The top level directory where, if defined, the separate working
1861 directories will get created, and symbolically linked to from ${WRKDIR}
1862 (see below). This is useful for building packages on several architectures,
1863 then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
1864 architecture. (It should be noted that PKGSRCDIR should not be set by the
1865 user ? it is an internal definition which refers to the root of the pkgsrc
1866 tree. It is possible to have many pkgsrc tree instances.)
1868 * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
1869 Section 11.3, "patches/*" for more information.
1871 * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
1872 Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
1873 up settings used by builds in /usr/src.
1875 * DEPENDS_TARGET: By default, dependencies are only installed, and no binary
1876 package is created for them. You can set this variable to package to
1877 automatically create binary packages after installing dependencies.
1879 5.3. Variables affecting the installation process
1881 A growing number of packages support installation into a subdirectory of
1882 WRKDIR. This allows a package to be built, before the actual filesystem is
1883 touched. DESTDIR support exists in two variations:
1885 * Basic DESTDIR support means that the package installation and packaging is
1888 * Full DESTDIR support can run the complete build, installation and packaging
1889 as normal user. Root privileges are only needed to add packages.
1891 To use the DESTDIR support, set USE_DESTDIR=yes to get the full support for
1892 packages that support it and with fallback to basic support.
1894 DESTDIR support changes the behaviour of various targets slightly. To install a
1895 package after building it, use package-install. package and install don't do
1896 that any longer. package-install can be used as DEPENDS_TARGET. bin-install
1897 will ask for the root password to install the package and fail, package-install
1900 With basic DESTDIR support, make clean needs to be run as root.
1902 Considering the foo/bar package, DESTDIR full support can be tested using the
1906 uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
1907 $ mkdir $HOME/packages
1908 $ cd $PKGSRCDIR/foo/bar
1910 Verify DESTDIR full support, no root privileges should be needed
1912 $ make USE_DESTDIR=yes install
1914 Create a package without root privileges
1916 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package
1918 For the following command, you must be able to gain root privileges using su(1)
1920 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install
1922 Then, as a simple user
1926 5.4. Selecting and configuring the compiler
1928 5.4.1. Selecting the compiler
1930 By default, pkgsrc will use GCC to build packages. This may be overridden by
1931 setting the following variables in /etc/mk.conf:
1935 This is a list of values specifying the chain of compilers to invoke when
1936 building packages. Valid values are:
1938 * distcc: distributed C/C++ (chainable)
1940 * ccache: compiler cache (chainable)
1942 * gcc: GNU C/C++ Compiler
1944 * mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)
1946 * mipspro: Silicon Graphics, Inc. MIPSpro (o32)
1948 * sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio
1950 The default is "gcc". You can use ccache and/or distcc with an appropriate
1951 PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
1952 terminated with a value for a real compiler. Note that only one real
1953 compiler should be listed (e.g. "sunpro gcc" is not allowed).
1957 This specifies the minimum version of GCC to use when building packages. If
1958 the system GCC doesn't satisfy this requirement, then pkgsrc will build and
1959 install one of the GCC packages to use instead.
1961 5.4.2. Additional flags to the compiler (CFLAGS)
1963 If you wish to set the CFLAGS variable, please make sure to use the += operator
1964 instead of the = operator:
1966 CFLAGS+= -your -flags
1968 Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
1969 need to add their own flags. You may want to take a look at the devel/cpuflags
1970 package if you're interested in optimization for the current CPU. Setting
1971 USE_CPUFLAGS to yes in mk.conf will cause pkgsrc to automatically use cpuflags.
1973 5.4.3. Additional flags to the linker (LDFLAGS)
1975 If you want to pass flags to the linker, both in the configure step and the
1976 build step, you can do this in two ways. Either set LDFLAGS or LIBS. The
1977 difference between the two is that LIBS will be appended to the command line,
1978 while LDFLAGS come earlier. LDFLAGS is pre-loaded with rpath settings for ELF
1979 machines depending on the setting of USE_IMAKE or the inclusion of mk/
1980 x11.buildlink3.mk. As with CFLAGS, if you do not wish to override these
1981 settings, use the += operator:
1983 LDFLAGS+= -your -linkerflags
1985 5.5. Developer/advanced settings
1989 * PKG_DEVELOPER: Run some sanity checks that package developers want:
1991 o make sure patches apply with zero fuzz
1993 o run check-shlibs to see that all binaries will find their shared libs.
1995 * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst
1996 making and installing the package. The default value for this is 0, which
1997 will not display the commands as they are executed (normal, default, quiet
1998 operation); the value 1 will display all shell commands before their
1999 invocation, and the value 2 will display both the shell commands before
2000 their invocation, and their actual execution progress with set -x will be
2003 5.6. Selecting Build Options
2005 Some packages have build time options, usually to select between different
2006 dependencies, enable optional support for big dependencies or enable
2007 experimental features.
2009 To see which options, if any, a package supports, and which options are
2010 mutually exclusive, run make show-options, for example:
2012 The following options are supported by this package:
2013 ssl Enable SSL support.
2014 Exactly one of the following gecko options is required:
2015 firefox Use firefox as gecko rendering engine.
2016 mozilla Use mozilla as gecko rendering engine.
2017 At most one of the following database options may be selected:
2018 mysql Enable support for MySQL database.
2019 pgsql Enable support for PostgreSQL database.
2021 These options are enabled by default: firefox
2022 These options are currently enabled: mozilla ssl
2024 The following variables can be defined in mk.conf to select which options to
2025 enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
2026 disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
2027 which can be used to select or disable options specifically for package pkgbase
2028 . Options listed in these variables are selected, options preceded by "-" are
2029 disabled. A few examples:
2031 $ grep "PKG.*OPTION" mk.conf
2032 PKG_DEFAULT_OPTIONS= -arts -dvdread -esound
2033 PKG_OPTIONS.kdebase= debug -sasl
2034 PKG_OPTIONS.apache= suexec
2036 It is important to note that options that were specifically suggested by the
2037 package maintainer must be explicitly removed if you do not wish to include the
2038 option. If you are unsure you can view the current state with make show-options
2041 The following settings are consulted in the order given, and the last setting
2042 that selects or disables an option is used:
2044 1. the default options as suggested by the package maintainer
2046 2. the options implied by the settings of legacy variables (see below)
2048 3. PKG_DEFAULT_OPTIONS
2050 4. PKG_OPTIONS.pkgbase
2052 For groups of mutually exclusive options, the last option selected is used, all
2053 others are automatically disabled. If an option of the group is explicitly
2054 disabled, the previously selected option, if any, is used. It is an error if no
2055 option from a required group of options is selected, and building the package
2058 Before the options framework was introduced, build options were selected by
2059 setting a variable (often named USE_FOO) in mk.conf for each option. To ease
2060 transition to the options framework for the user, these legacy variables are
2061 converted to the appropriate options setting (PKG_OPTIONS.pkgbase)
2062 automatically. A warning is issued to prompt the user to update mk.conf to use
2063 the options framework directly. Support for the legacy variables will be
2066 Chapter 6. Creating binary packages
2070 6.1. Building a single binary package
2071 6.2. Settings for creation of binary packages
2073 6.1. Building a single binary package
2075 Once you have built and installed a package, you can create a binary package
2076 which can be installed on another system with pkg_add(1). This saves having to
2077 build the same package on a group of hosts and wasting CPU time. It also
2078 provides a simple means for others to install your package, should you
2081 To create a binary package, change into the appropriate directory in pkgsrc,
2082 and run make package:
2088 This will build and install your package (if not already done), and then build
2089 a binary package from what was installed. You can then use the pkg_* tools to
2090 manipulate it. Binary packages are created by default in /usr/pkgsrc/packages,
2091 in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a
2092 continuation of the above misc/figlet example.
2094 See Chapter 21, Submitting and Committing for information on how to submit such
2097 6.2. Settings for creation of binary packages
2099 See Section 17.17, "Other helpful targets".
2101 Chapter 7. Creating binary packages for everything in pkgsrc (bulk builds)
2105 7.1. Think first, build later
2106 7.2. Requirements of a bulk build
2107 7.3. Running an old-style bulk build
2109 7.3.1. Configuration
2110 7.3.2. Other environmental considerations
2113 7.3.5. Disk space requirements
2114 7.3.6. Setting up a sandbox for chrooted builds
2115 7.3.7. Building a partial set of packages
2116 7.3.8. Uploading results of a bulk build
2118 7.4. Running a pbulk-style bulk build
2121 7.4.2. Configuration
2123 7.5. Creating a multiple CD-ROM packages collection
2125 7.5.1. Example of cdpack
2127 When you have multiple machines that should run the same packages, it is wasted
2128 time if they all build their packages themselves from source. There are two
2129 ways of getting a set of binary packages: The old bulk build system, or the new
2130 (as of 2007) parallel bulk build (pbulk) system. This chapter describes how to
2131 set them up so that the packages are most likely to be usable later.
2133 7.1. Think first, build later
2135 Since a bulk build takes several days or even weeks to finish, you should think
2136 about the setup before you start everything. Pay attention to at least the
2139 * If you want to upload the binary packages to ftp.NetBSD.org, make sure the
2140 setup complies to the requirements for binary packages:
2142 o To end up on ftp.NetBSD.org, the packages must be built by a NetBSD
2143 developer on a trusted machine (that is, where you and only you have
2146 o Packages on ftp.NetBSD.org should only be created from the stable
2147 branches (like 2009Q1), so that users browsing the available
2148 collections can see at a glance how old the packages are.
2150 o The packages must be built as root, since some packages require set-uid
2151 binaries at runtime, and creating those packages as unprivileged user
2152 doesn't work well at the moment.
2154 * Make sure that the bulk build cannot break anything in your system. Most
2155 bulk builds run as root, so they should be run at least in a chroot
2156 environment or something even more restrictive, depending on what the
2157 operating system provides. There have been numerous cases where certain
2158 packages tried to install files outside the LOCALBASE or wanted to edit
2159 some files in /etc. Furthermore, the bulk builds install and deinstall
2160 packages in /usr/pkg (or whatever LOCALBASE is) during their operation, so
2161 be sure that you don't need any package during the build.
2163 7.2. Requirements of a bulk build
2165 A complete bulk build requires lots of disk space. Some of the disk space can
2166 be read-only, some other must be writable. Some can be on remote filesystems
2167 (such as NFS) and some should be local. Some can be temporary filesystems,
2168 others must survive a sudden reboot.
2170 * 10 GB for the distfiles (read-write, remote, temporary)
2172 * 10 GB for the binary packages (read-write, remote, permanent)
2174 * 400 MB for the pkgsrc tree (read-only, remote, permanent)
2176 * 5 GB for LOCALBASE (read-write, local, temporary for pbulk, permanent for
2179 * 5 GB for the log files (read-write, remote, permanent)
2181 * 5 GB for temporary files (read-write, local, temporary)
2183 7.3. Running an old-style bulk build
2187 There are two ways of doing a bulk build. The old-style one and the new-style
2188 "pbulk". The latter is the recommended way.
2190 7.3.1. Configuration
2194 The build.conf file is the main configuration file for bulk builds. You can
2195 configure how your copy of pkgsrc is kept up to date, how the distfiles are
2196 downloaded, how the packages are built and how the report is generated. You can
2197 find an annotated example file in pkgsrc/mk/bulk/build.conf-example. To use it,
2198 copy build.conf-example to build.conf and edit it, following the comments in
2203 You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf
2204 for details of the default settings. You will want to ensure that
2205 ACCEPTABLE_LICENSES meet your local policy. As used in this example,
2206 SKIP_LICENSE_CHECK=yes completely bypasses the license check.
2208 PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
2209 WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
2211 BSDXSRCDIR= /usr/xsrc # for x11/xservers
2212 OBJHOSTNAME?= yes # use work.`hostname`
2213 FAILOVER_FETCH= yes # insist on the correct checksum
2215 SKIP_LICENSE_CHECK= yes
2217 Some options that are especially useful for bulk builds can be found at the top
2218 lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are
2219 briefly described here.
2221 * If you are on a slow machine, you may want to set USE_BULK_BROKEN_CHECK to
2224 * If you are doing bulk builds from a read-only copy of pkgsrc, you have to
2225 set BULKFILESDIR to the directory where all log files are created.
2226 Otherwise the log files are created in the pkgsrc directory.
2228 * Another important variable is BULK_PREREQ, which is a list of packages that
2229 should be always available while building other packages.
2231 Some other options are scattered in the pkgsrc infrastructure:
2233 * ALLOW_VULNERABLE_PACKAGES should be set to yes. The purpose of the bulk
2234 builds is creating binary packages, no matter if they are vulnerable or
2235 not. Leaving this variable unset would prevent the bulk build system
2236 from even trying to build them, so possible building errors would not
2239 * CHECK_FILES (pkgsrc/mk/check/check-files.mk) can be set to "yes" to check
2240 that the installed set of files matches the PLIST.
2242 * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to
2243 "yes" to check that the installed "#!"-scripts will find their interpreter.
2245 * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before
2246 installing it. Note that some packages make heavy use of "good" random
2247 numbers, so you need to assure that the machine on which you are doing the
2248 bulk builds is not completely idle. Otherwise some test programs will seem
2249 to hang, while they are just waiting for new random data to be available.
2251 7.3.1.3. pre-build.local
2253 It is possible to configure the bulk build to perform certain site-specific
2254 tasks at the end of the pre-build stage. If the file pre-build.local exists in
2255 /usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the
2256 usual pre-build stage. An example use of pre-build.local is to have the line:
2258 echo "I do not have enough disk space to build this pig." \
2259 > misc/openoffice/$BROKENF
2261 to prevent the system from trying to build a particular package which requires
2262 nearly 3 GB of disk space.
2264 7.3.2. Other environmental considerations
2266 As /usr/pkg will be completely deleted at the start of bulk builds, make sure
2267 your login shell is placed somewhere else. Either drop it into /usr/local/bin
2268 (and adjust your login shell in the passwd file), or (re-)install it via
2269 pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that
2270 your current process won't die if the package is removed, you just can't start
2271 any new instances of the shell any more). Also, if you use NetBSD earlier than
2272 1.5, or you still want to use the pkgsrc version of ssh for some reason, be
2273 sure to install ssh before starting it from rc.local:
2275 (cd /usr/pkgsrc/security/ssh && make bulk-install)
2276 if [ -f /usr/pkg/etc/rc.d/sshd ]; then
2277 /usr/pkg/etc/rc.d/sshd
2280 Not doing so will result in you being not able to log in via ssh after the bulk
2281 build is finished or if the machine gets rebooted or crashes. You have been
2286 Make sure you don't need any of the packages still installed.
2290 During the bulk build, all packages, their configuration files and some more
2291 files from /var, /home and possibly other locations will be removed! So don't
2292 run a bulk build with privileges that might harm your system.
2294 Be sure to remove all other things that might interfere with builds, like some
2295 libs installed in /usr/local, etc. then become root and type:
2301 If for some reason your last build didn't complete (power failure, system
2302 panic, ...), you can continue it by running:
2304 # sh mk/bulk/build restart
2306 At the end of the bulk build, you will get a summary via mail, and find build
2307 logs in the directory specified by FTP in the build.conf file.
2311 The bulk builds consist of three steps:
2315 The script updates your pkgsrc tree via (anon)cvs, then cleans out any
2316 broken distfiles, and removes all packages installed.
2320 This is basically "make bulk-package" with an optimised order in which
2321 packages will be built. Packages that don't require other packages will be
2322 built first, and packages with many dependencies will be built later.
2326 Generates a report that's placed in the directory specified in the
2327 build.conf file named broken.html, a short version of that report will also
2328 be mailed to the build's admin.
2330 During the build, a list of broken packages will be compiled in /usr/pkgsrc
2331 /.broken (or .../.broken.${MACHINE} if OBJMACHINE is set), individual build
2332 logs of broken builds can be found in the package's directory. These files are
2333 used by the bulk-targets to mark broken builds to not waste time trying to
2334 rebuild them, and they can be used to debug these broken package builds later.
2336 7.3.5. Disk space requirements
2338 Currently, roughly the following requirements are valid for NetBSD 2.0/i386:
2340 * 10 GB - distfiles (NFS ok)
2342 * 8 GB - full set of all binaries (NFS ok)
2344 * 5 GB - temp space for compiling (local disk recommended)
2346 Note that all pkgs will be de-installed as soon as they are turned into a
2347 binary package, and that sources are removed, so there is no excessively huge
2348 demand to disk space. Afterwards, if the package is needed again, it will be
2349 installed via pkg_add(1) instead of building again, so there are no cycles
2350 wasted by recompiling.
2352 7.3.6. Setting up a sandbox for chrooted builds
2354 If you don't want all the packages nuked from a machine (rendering it useless
2355 for anything but pkg compiling), there is the possibility of doing the package
2356 bulk build inside a chroot environment.
2358 The first step is to set up a chroot sandbox, e.g. /usr/sandbox. This can be
2359 done by using null mounts, or manually.
2361 There is a shell script called pkgsrc/mk/bulk/mksandbox which will set up the
2362 sandbox environment using null mounts. It will also create a script called
2363 sandbox in the root of the sandbox environment, which will allow the null
2364 mounts to be activated using the sandbox mount command and deactivated using
2365 the sandbox umount command.
2367 To set up a sandbox environment by hand, after extracting all the sets from a
2368 NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in /usr/
2369 src/etc, be sure the following items are present and properly configured:
2373 # cp /netbsd /usr/sandbox
2377 # cd /usr/sandbox/dev ; sh MAKEDEV all
2379 3. /etc/resolv.conf (for security/smtpd and mail):
2381 # cp /etc/resolv.conf /usr/sandbox/etc
2383 4. Working(!) mail config (hostname, sendmail.cf):
2385 # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
2387 5. /etc/localtime (for security/smtpd):
2389 # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
2391 6. /usr/src (system sources, e. g. for sysutils/aperture):
2393 # ln -s ../disk1/cvs .
2394 # ln -s cvs/src-2.0 src
2396 7. Create /var/db/pkg (not part of default install):
2398 # mkdir /usr/sandbox/var/db/pkg
2400 8. Create /usr/pkg (not part of default install):
2402 # mkdir /usr/sandbox/usr/pkg
2404 9. Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:
2406 # cd /usr/sandbox/usr
2407 # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
2410 Do not mount/link this to the copy of your pkgsrc tree you do development
2411 in, as this will likely cause problems!
2413 10. Make /usr/sandbox/usr/pkgsrc/packages and .../distfiles point somewhere
2414 appropriate. NFS- and/or nullfs-mounts may come in handy!
2416 11. Edit mk.conf, see Section 7.3.1.2, "???".
2418 12. Adjust mk/bulk/build.conf to suit your needs.
2420 When the chroot sandbox is set up, you can start the build with the following
2423 # cd /usr/sandbox/usr/pkgsrc
2424 # sh mk/bulk/do-sandbox-build
2427 This will just jump inside the sandbox and start building. At the end of the
2428 build, mail will be sent with the results of the build. Created binary pkgs
2429 will be in /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/
2432 7.3.7. Building a partial set of packages
2434 In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk
2435 /bulk/build script may be used to build a subset of the packages contained in
2436 pkgsrc. By setting SPECIFIC_PKGS in mk.conf, the variables
2438 * SITE_SPECIFIC_PKGS
2440 * HOST_SPECIFIC_PKGS
2442 * GROUP_SPECIFIC_PKGS
2444 * USER_SPECIFIC_PKGS
2446 will define the set of packages which should be built. The bulk build code will
2447 also include any packages which are needed as dependencies for the explicitly
2450 One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
2451 periodically to have a complete set of the binary packages needed for your site
2452 available without the overhead of building extra packages that are not needed.
2454 7.3.8. Uploading results of a bulk build
2456 This section describes how pkgsrc developers can upload binary pkgs built by
2457 bulk builds to ftp.NetBSD.org.
2459 If you would like to automatically create checksum files for the binary
2460 packages you intend to upload, remember to set MKSUMS=yes in your mk/bulk/
2463 If you would like to PGP sign the checksum files (highly recommended!),
2464 remember to set SIGN_AS=username@NetBSD.org in your mk/bulk/build.conf. This
2465 will prompt you for your GPG password to sign the files before uploading
2468 Then, make sure that you have RSYNC_DST set properly in your mk/bulk/build.conf
2469 file, i.e. adjust it to something like one of the following:
2471 RSYNC_DST=ftp.NetBSD.org:/pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch/upload
2473 Please use appropriate values for "packages-20xxQy", "NetBSD-a.b.c" and "arch"
2474 here. If your login on ftp.NetBSD.org is different from your local login, write
2475 your login directly into the variable, e.g. my local account is "feyrer", but
2476 for my login "hubertf", I use:
2478 RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch/upload
2480 A separate upload directory is used here to allow "closing" the directory
2481 during upload. To do so, run the following command on ftp.NetBSD.org next:
2483 nbftp% mkdir -p -m 750 /pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch/upload
2485 Please note that /pub/NetBSD/packages is only appropriate for packages for the
2486 NetBSD operating system. Binary packages for other operating systems should go
2489 Before uploading the binary pkgs, ssh authentication needs to be set up. This
2490 example shows how to set up temporary keys for the root account inside the
2491 sandbox (assuming that no keys should be present there usually):
2493 # chroot /usr/sandbox
2494 chroot-# rm $HOME/.ssh/id-dsa*
2495 chroot-# ssh-keygen -t dsa
2496 chroot-# cat $HOME/.ssh/id-dsa.pub
2499 Now take the output of id-dsa.pub and append it to your ~/.ssh/authorized_keys
2500 file on ftp.NetBSD.org. You can remove the key after the upload is done!
2502 Next, test if your ssh connection really works:
2504 chroot-# ssh ftp.NetBSD.org date
2506 Use "-l yourNetBSDlogin" here as appropriate!
2508 Now after all this works, you can exit the sandbox and start the upload:
2511 # cd /usr/sandbox/usr/pkgsrc
2512 # sh mk/bulk/do-sandbox-upload
2515 The upload process may take quite some time. Use ls(1) or du(1) on the FTP
2516 server to monitor progress of the upload. The upload script will take care of
2517 not uploading restricted packages.
2519 After the upload has ended, first thing is to revoke ssh access:
2521 nbftp% vi ~/.ssh/authorized_keys
2524 Use whatever is needed to remove the key you've entered before! Last, move the
2525 uploaded packages out of the upload directory to have them accessible to
2528 nbftp% cd /pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch
2529 nbftp% mv upload/* .
2534 7.4. Running a pbulk-style bulk build
2536 Running a pbulk-style bulk build works roughly as follows:
2538 * First, build the pbulk infrastructure in a fresh pkgsrc location.
2540 * Then, build each of the packages from a clean installation directory using
2545 First, you need to create a pkgsrc installation for the pbulk infrastructure.
2546 No matter on which platform you are (even on NetBSD), you should bootstrap into
2547 its own directory. Let's take the directory /usr/pbulk or $HOME/pbulk for it.
2548 This installation will be bootstrapped and all the tools that are required for
2549 the bulk build will be installed there.
2552 $ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap
2553 $ rm -rf /tmp/pbulk-bootstrap
2555 Now the basic environment for the pbulk infrastructure is installed. The
2556 specific tools are still missing. This is a good time to edit the pkgsrc
2557 configuration file /usr/pbulk/etc/mk.conf to fit your needs. Typical things you
2560 * PKG_DEVELOPER=yes, to enable many consistency checks,
2562 * WRKOBJDIR=/tmp/pbulk-outer, to keep /usr/pkgsrc free from any
2565 * DISTDIR=/distfiles, to have only one directory in which all distfiles (for
2566 the infrastructure and for the actual packages) are downloaded,
2568 * ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual
2569 Free/Open Source licenses that are acceptable to you,
2571 * SKIP_LICENSE_CHECK=yes, to bypass the license checks.
2573 Now you are ready to build the rest of the pbulk infrastructure.
2576 $ /usr/pbulk/bin/bmake install
2577 $ rm -rf /tmp/pbulk-outer
2579 Now the pbulk infrastructure is built and installed. It still needs to be
2580 configured, and after some more preparation, we will be able to start the real
2583 7.4.2. Configuration
2585 TODO; see pkgsrc/doc/HOWTO-pbulk for more information.
2587 TODO: continue writing
2589 7.5. Creating a multiple CD-ROM packages collection
2591 After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
2592 of the resulting binary packages to assist in installing packages on other
2593 machines. The pkgtools/cdpack package provides a simple tool for creating the
2594 ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
2595 keeps all the dependencies for a given package on the same CD as that package.
2597 7.5.1. Example of cdpack
2599 Complete documentation for cdpack is found in the cdpack(1) man page. The
2600 following short example assumes that the binary packages are left in /usr/
2601 pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
2605 # pkg_add /usr/pkgsrc/packages/All/cdpack
2606 # cdpack /usr/pkgsrc/packages/All /u2/images
2609 If you wish to include a common set of files (COPYRIGHT, README, etc.) on each
2610 CD in the collection, then you need to create a directory which contains these
2614 # echo "This is a README" > /tmp/common/README
2615 # echo "Another file" > /tmp/common/COPYING
2616 # mkdir /tmp/common/bin
2617 # echo "#!/bin/sh" > /tmp/common/bin/myscript
2618 # echo "echo Hello world" >> /tmp/common/bin/myscript
2619 # chmod 755 /tmp/common/bin/myscript
2622 Now create the images:
2624 # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
2626 Each image will contain README, COPYING, and bin/myscript in their root
2629 Chapter 8. Directory layout of the installed files
2633 8.1. File system layout in ${LOCALBASE}
2634 8.2. File system layout in ${VARBASE}
2636 The files that are installed by pkgsrc are organized in a way that is similar
2637 to what you find in the /usr directory of the base system. But some details are
2638 different. This is because pkgsrc initially came from FreeBSD and had adopted
2639 its file system hierarchy. Later it was largely influenced by NetBSD. But no
2640 matter which operating system you are using pkgsrc with, you can expect the
2641 same layout for pkgsrc.
2643 There are mainly four root directories for pkgsrc, which are all configurable
2644 in the bootstrap/bootstrap script. When pkgsrc has been installed as root, the
2645 default locations are:
2648 PKG_SYSCONFBASE= /usr/pkg/etc
2650 PKG_DBDIR= /var/db/pkg
2652 In unprivileged mode (when pkgsrc has been installed as any other user), the
2653 default locations are:
2655 LOCALBASE= ${HOME}/pkg
2656 PKG_SYSCONFBASE= ${HOME}/pkg/etc
2657 VARBASE= ${HOME}/pkg/var
2658 PKG_DBDIR= ${HOME}/pkg/var/db/pkg
2660 What these four directories are for, and what they look like is explained
2663 * LOCALBASE corresponds to the /usr directory in the base system. It is the
2664 "main" directory where the files are installed and contains the well-known
2665 subdirectories like bin, include, lib, share and sbin.
2667 * VARBASE corresponds to /var in the base system. Some programs (especially
2668 games, network daemons) need write access to it during normal operation.
2670 * PKG_SYSCONFDIR corresponds to /etc in the base system. It contains
2671 configuration files of the packages, as well as pkgsrc's mk.conf itself.
2673 8.1. File system layout in ${LOCALBASE}
2675 The following directories exist in a typical pkgsrc installation in $
2680 Contains executable programs that are intended to be directly used by the
2685 Contains files for the emulation layers of various other operating systems,
2686 especially for NetBSD.
2688 etc (the usual location of ${PKG_SYSCONFDIR})
2690 Contains the configuration files.
2694 Contains headers for the C and C++ programming languages.
2698 Contains GNU info files of various packages.
2702 Contains shared and static libraries.
2706 Contains data files that don't change after installation. Other data files
2707 belong into ${VARBASE}.
2711 Contains programs that are not intended to be used by end users, such as
2712 helper programs or network daemons.
2716 Contains programs that are intended to be executed as CGI scripts by a web
2719 man (the usual value of ${PKGMANDIR})
2721 Contains brief documentation in form of manual pages.
2725 Contains programs that are intended to be used only by the super-user.
2729 Contains platform-independent data files that don't change after
2734 Contains documentation files provided by the packages.
2738 Contains example files provided by the packages. Among others, the original
2739 configuration files are saved here and copied to ${PKG_SYSCONFDIR} during
2744 Contains the original files for rc.d scripts.
2746 var (the usual location of ${VARBASE})
2748 Contains files that may be modified after installation.
2750 8.2. File system layout in ${VARBASE}
2752 db/pkg (the usual location of ${PKG_DBDIR})
2754 Contains information about the currently installed packages.
2758 Contains highscore files.
2766 Contains informational files about daemons that are currently running.
2768 Chapter 9. Frequently Asked Questions
2772 9.1. Are there any mailing lists for pkg-related discussion?
2773 9.2. Where's the pkgviews documentation?
2774 9.3. Utilities for package management (pkgtools)
2775 9.4. How to use pkgsrc as non-root
2776 9.5. How to resume transfers when fetching distfiles?
2777 9.6. How can I install/use modular X.org from pkgsrc?
2778 9.7. How to fetch files from behind a firewall
2779 9.8. How do I tell make fetch to do passive FTP?
2780 9.9. How to fetch all distfiles at once
2781 9.10. What does Don't know how to make /usr/share/tmac/tmac.andoc mean?
2782 9.11. What does Could not find bsd.own.mk mean?
2783 9.12. Using 'sudo' with pkgsrc
2784 9.13. How do I change the location of configuration files?
2785 9.14. Automated security checks
2786 9.15. Why do some packages ignore my CFLAGS?
2787 9.16. A package does not build. What shall I do?
2788 9.17. What does Makefile appears to contain unresolved cvs/rcs/??? merge
2791 This section contains hints, tips & tricks on special things in pkgsrc that we
2792 didn't find a better place for in the previous chapters, and it contains items
2793 for both pkgsrc users and developers.
2795 9.1. Are there any mailing lists for pkg-related discussion?
2797 The following mailing lists may be of interest to pkgsrc users:
2799 * pkgsrc-users: This is a general purpose list for most issues regarding
2800 pkgsrc, regardless of platform, e.g. soliciting user help for pkgsrc
2801 configuration, unexpected build failures, using particular packages,
2802 upgrading pkgsrc installations, questions regarding the pkgsrc release
2803 branches, etc. General announcements or proposals for changes that impact
2804 the pkgsrc user community, e.g. major infrastructure changes, new features,
2805 package removals, etc., may also be posted.
2807 * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and
2810 * pkgsrc-changes: This list is for those who are interested in getting a
2811 commit message for every change committed to pkgsrc. It is also available
2812 in digest form, meaning one daily message containing all commit messages
2813 for changes to the package source tree in that 24 hour period.
2817 % echo subscribe listname | mail majordomo@NetBSD.org
2819 Archives for all these mailing lists are available from http://
2820 mail-index.NetBSD.org/.
2822 9.2. Where's the pkgviews documentation?
2824 Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's
2825 guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.
2827 9.3. Utilities for package management (pkgtools)
2829 The directory pkgsrc/pkgtools contains a number of useful utilities for both
2830 users and developers of pkgsrc. This section attempts only to make the reader
2831 aware of the utilities and when they might be useful, and not to duplicate the
2832 documentation that comes with each package.
2834 Utilities used by pkgsrc (automatically installed when needed):
2836 * pkgtools/x11-links: Symlinks for use by buildlink.
2838 OS tool augmentation (automatically installed when needed):
2840 * pkgtools/digest: Calculates various kinds of checksums (including SHA1).
2842 * pkgtools/libnbcompat: Compatibility library for pkgsrc tools.
2844 * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree.
2846 * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or
2847 for use on operating systems where pkg_install is not present.
2849 Utilities used by pkgsrc (not automatically installed):
2851 * pkgtools/pkg_tarup: Create a binary package from an already-installed
2852 package. Used by make replace to save the old package.
2854 * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch
2855 distfiles from multiple locations. It currently supports the following
2856 methods: multiple CD-ROMs and network FTP/HTTP connections.
2858 * pkgtools/xpkgwedge: Put X11 packages someplace else (enabled by default).
2860 * devel/cpuflags: Determine the best compiler flags to optimise code for your
2861 current CPU and compiler. Setting USE_CPUFLAGS to yes in mk.conf will cause
2862 pkgsrc to automatically use cpuflags.
2864 Utilities for keeping track of installed packages, being up to date, etc:
2866 * pkgtools/pkg_chk: Reports on packages whose installed versions do not match
2867 the latest pkgsrc entries.
2869 * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a
2870 strategy for updating.
2872 * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses
2875 * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors.
2877 * pkgtools/lintpkgsrc: The lintpkgsrc(1) program does various checks on the
2878 complete pkgsrc system.
2880 * pkgtools/pkgsurvey: Report what packages you have installed.
2882 Utilities for people maintaining or creating individual packages:
2884 * pkgtools/pkgdiff: Automate making and maintaining patches for a package
2885 (includes pkgdiff, pkgvi, mkpatches, etc.).
2887 * pkgtools/rpm2pkg, pkgtools/url2pkg: Aids in converting to pkgsrc.
2889 * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package.
2891 Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
2893 * pkgtools/pkg_comp: Build packages in a chrooted area.
2895 * pkgtools/libkver: Spoof kernel version for chrooted cross builds.
2897 9.4. How to use pkgsrc as non-root
2899 If you want to use pkgsrc as non-root user, you can set some variables to make
2900 pkgsrc work under these conditions. At the very least, you need to set
2901 UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple
2902 related variables to allow installation of packages as non-root.
2904 In case the defaults are not enough, you may want to tune some other variables
2905 used. For example, if the automatic user/group detection leads to incorrect
2906 values (or not the ones you would like to use), you can change them by setting
2907 UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively.
2909 As regards bootstrapping, please note that the bootstrap script will ease
2910 non-root configuration when given the "--ignore-user-check" flag, as it will
2911 choose and use multiple default directories under ~/pkg as the installation
2912 targets. These directories can be overridden by the "--prefix" flag provided by
2913 the script, as well as some others that allow finer tuning of the tree layout.
2915 9.5. How to resume transfers when fetching distfiles?
2917 By default, resuming transfers in pkgsrc is disabled, but you can enable this
2918 feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
2919 a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.
2921 You can also use a different program than the default ftp(1) by changing the
2922 FETCH_USING variable. You can specify the program by using of ftp, fetch, wget
2923 or curl. Alternatively, fetching can be disabled by using the value manual. A
2924 value of custom disables the system defaults and dependency tracking for the
2925 fetch program. In that case you have to provide FETCH_CMD, FETCH_BEFORE_ARGS,
2926 FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.
2928 For example, if you want to use wget to download, you'll have to use something
2933 9.6. How can I install/use modular X.org from pkgsrc?
2935 If you want to use modular X.org from pkgsrc instead of your system's own X11
2936 (/usr/X11R6, /usr/openwin, ...) you will have to add the following line into
2943 The DragonFly operating system defaults to using modular X.org from pkgsrc.
2945 9.7. How to fetch files from behind a firewall
2947 If you are sitting behind a firewall which does not allow direct connections to
2948 Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
2949 is done using an environment variable in the form of a URL, e.g. in Amdahl, the
2950 machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
2951 the proxy port number. So the proxy environment variables are:
2953 ftp_proxy=ftp://orpheus.amdahl.com:80/
2954 http_proxy=http://orpheus.amdahl.com:80/
2956 9.8. How do I tell make fetch to do passive FTP?
2958 This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
2959 FETCH_CMD is assigned the first available command from the following list:
2961 * ${LOCALBASE}/bin/ftp
2965 On a default NetBSD installation, this will be /usr/bin/ftp, which
2966 automatically tries passive connections first, and falls back to active
2967 connections if the server refuses to do passive. For the other tools, add the
2968 following to your mk.conf file: PASSIVE_FETCH=1.
2970 Having that option present will prevent /usr/bin/ftp from falling back to
2973 9.9. How to fetch all distfiles at once
2975 You would like to download all the distfiles in a single batch from work or
2976 university, where you can't run a make fetch. There is an archive of distfiles
2977 on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
2979 The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
2980 subdirectories, carry the resulting list to your machine at work/school and use
2981 it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work,
2982 don't forget to set FETCH_CMD to something that fetches a URL:
2987 % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
2988 % scp /tmp/fetch.sh work:/tmp
2994 then tar up /tmp/distfiles and take it home.
2996 If you have a machine running NetBSD, and you want to get all distfiles (even
2997 ones that aren't for your machine architecture), you can do so by using the
2998 above-mentioned make fetch-list approach, or fetch the distfiles directly by
3001 % make mirror-distfiles
3003 If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can get
3004 everything by running:
3006 % make fetch NO_SKIP=yes
3008 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
3010 When compiling the pkgtools/pkg_install package, you get the error from make
3011 that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
3012 that you don't have installed the "text" set (nroff, ...) from the NetBSD base
3013 distribution on your machine. It is recommended to do that to format man pages.
3015 In the case of the pkgtools/pkg_install package, you can get away with setting
3016 NOMAN=YES either in the environment or in mk.conf.
3018 9.11. What does "Could not find bsd.own.mk" mean?
3020 You didn't install the compiler set, comp.tgz, when you installed your NetBSD
3021 machine. Please get and install it, by extracting it in /:
3024 # tar --unlink -zxvpf .../comp.tgz
3026 comp.tgz is part of every NetBSD release. Get the one that corresponds to your
3027 release (determine via uname -r).
3029 9.12. Using 'sudo' with pkgsrc
3031 When installing packages as non-root user and using the just-in-time su(1)
3032 feature of pkgsrc, it can become annoying to type in the root password for each
3033 required package installed. To avoid this, the sudo package can be used, which
3034 does password caching over a limited time. To use it, install sudo (either as
3035 binary package or from security/sudo) and then put the following into your
3036 mk.conf, somewhere after the definition of the LOCALBASE variable:
3038 .if exists(${LOCALBASE}/bin/sudo)
3039 SU_CMD= ${LOCALBASE}/bin/sudo /bin/sh -c
3042 9.13. How do I change the location of configuration files?
3044 As the system administrator, you can choose where configuration files are
3045 installed. The default settings make all these files go into ${PREFIX}/etc or
3046 some of its subdirectories; this may be suboptimal depending on your
3047 expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine
3048 configuration of the provided packages).
3050 In order to change the defaults, you can modify the PKG_SYSCONFBASE variable
3051 (in mk.conf) to point to your preferred configuration directory; some common
3052 examples include /etc or /etc/pkg.
3054 Furthermore, you can change this value on a per-package basis by setting the
3055 PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
3056 matches the name of the package you would like to modify, that is, the contents
3059 Note that after changing these settings, you must rebuild and reinstall any
3062 9.14. Automated security checks
3064 Please be aware that there can often be bugs in third-party software, and some
3065 of these bugs can leave a machine vulnerable to exploitation by attackers. In
3066 an effort to lessen the exposure, the NetBSD packages team maintains a database
3067 of known-exploits to packages which have at one time been included in pkgsrc.
3068 The database can be downloaded automatically, and a security audit of all
3069 packages installed on a system can take place. To do this, refer to the
3070 following two tools (installed as part of the pkgtools/pkg_install package):
3072 1. pkg_admin fetch-pkg-vulnerabilities, an easy way to download a list of the
3073 security vulnerabilities information. This list is kept up to date by the
3074 NetBSD security officer and the NetBSD packages team, and is distributed
3075 from the NetBSD ftp server:
3077 ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities
3079 2. pkg_admin audit, an easy way to audit the current machine, checking each
3080 vulnerability which is known. If a vulnerable package is installed, it will
3081 be shown by output to stdout, including a description of the type of
3082 vulnerability, and a URL containing more information.
3084 Use of these tools is strongly recommended! After "pkg_install" is installed,
3085 please read the package's message, which you can get by running pkg_info -D
3088 If this package is installed, pkgsrc builds will use it to perform a security
3089 check before building any package. See Section 5.2, "Variables affecting the
3090 build process" for ways to control this check.
3092 9.15. Why do some packages ignore my CFLAGS?
3094 When you add your own preferences to the CFLAGS variable in your mk.conf, these
3095 flags are passed in environment variables to the ./configure scripts and to
3096 make(1). Some package authors ignore the CFLAGS from the environment variable
3097 by overriding them in the Makefiles of their package.
3099 Currently there is no solution to this problem. If you really need the package
3100 to use your CFLAGS you should run make patch in the package directory and then
3101 inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly.
3102 Usually you can remove these lines. But be aware that some "smart" programmers
3103 write so bad code that it only works for the specific combination of CFLAGS
3106 9.16. A package does not build. What shall I do?
3108 1. Make sure that your copy of pkgsrc is consistent. A case that occurs often
3109 is that people only update pkgsrc in parts, because of performance reasons.
3110 Since pkgsrc is one large system, not a collection of many small systems,
3111 there are sometimes changes that only work when the whole pkgsrc tree is
3114 2. Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or
3115 ">>>>>>" in all your pkgsrc files.
3117 3. Make sure that you don't have old copies of the packages extracted. Run
3118 make clean clean-depends to verify this.
3120 4. If the problem still exists, write a mail to the pkgsrc-users mailing list.
3122 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
3125 You have modified a file from pkgsrc, and someone else has modified that same
3126 file afterwards in the CVS repository. Both changes are in the same region of
3127 the file, so when you updated pkgsrc, the cvs command marked the conflicting
3128 changes in the file. Because of these markers, the file is no longer a valid
3131 Have a look at that file, and if you don't need your local changes anymore, you
3132 can remove that file and run cvs -q update -dP in that directory to download
3133 the current version.
3135 Part II. The pkgsrc developer's guide
3137 This part of the book deals with creating and modifying packages. It starts
3138 with a "HOWTO"-like guide on creating a new package. The remaining chapters are
3139 more like a reference manual for pkgsrc.
3143 10. Creating a new pkgsrc package from scratch
3145 10.1. Common types of packages
3147 10.1.1. Perl modules
3148 10.1.2. KDE applications
3149 10.1.3. Python modules and programs
3153 10.2.1. How the www/nvu package came into pkgsrc
3155 11. Package components - files, directories and contents
3161 11.3.1. Structure of a single patch file
3162 11.3.2. Creating patch files
3163 11.3.3. Sources where the patch files come from
3164 11.3.4. Patching guidelines
3165 11.3.5. Feedback to the author
3167 11.4. Other mandatory files
3168 11.5. Optional files
3170 11.5.1. Files affecting the binary package
3171 11.5.2. Files affecting the build process
3172 11.5.3. Files affecting nothing at all
3177 12. Programming in Makefiles
3180 12.2. Makefile variables
3182 12.2.1. Naming conventions
3186 12.3.1. Adding things to a list
3187 12.3.2. Converting an internal list into an external list
3188 12.3.3. Passing variables to a shell command
3189 12.3.4. Quoting guideline
3190 12.3.5. Workaround for a bug in BSD Make
3195 13.2. Semi-automatic PLIST generation
3196 13.3. Tweaking output of make print-PLIST
3197 13.4. Variable substitution in PLIST
3198 13.5. Man page compression
3199 13.6. Changing PLIST source with PLIST_SRC
3200 13.7. Platform-specific and differing PLISTs
3201 13.8. Sharing directories between packages
3203 14. Buildlink methodology
3205 14.1. Converting packages to use buildlink3
3206 14.2. Writing buildlink3.mk files
3208 14.2.1. Anatomy of a buildlink3.mk file
3209 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
3211 14.3. Writing builtin.mk files
3213 14.3.1. Anatomy of a builtin.mk file
3214 14.3.2. Global preferences for native or pkgsrc software
3216 15. The pkginstall framework
3218 15.1. Files and directories outside the installation prefix
3220 15.1.1. Directory manipulation
3221 15.1.2. File manipulation
3223 15.2. Configuration files
3225 15.2.1. How PKG_SYSCONFDIR is set
3226 15.2.2. Telling the software where configuration files are
3227 15.2.3. Patching installations
3228 15.2.4. Disabling handling of configuration files
3230 15.3. System startup scripts
3232 15.3.1. Disabling handling of system startup scripts
3234 15.4. System users and groups
3237 15.5.1. Disabling shell registration
3241 15.6.1. Disabling automatic update of the fonts databases
3243 16. Options handling
3245 16.1. Global default options
3246 16.2. Converting packages to use bsd.options.mk
3248 16.4. Determining the options of dependencies
3250 17. The build process
3253 17.2. Program location
3254 17.3. Directories used during the build process
3255 17.4. Running a phase
3256 17.5. The fetch phase
3258 17.5.1. What to fetch and where to get it from
3259 17.5.2. How are the files fetched?
3261 17.6. The checksum phase
3262 17.7. The extract phase
3263 17.8. The patch phase
3264 17.9. The tools phase
3265 17.10. The wrapper phase
3266 17.11. The configure phase
3267 17.12. The build phase
3268 17.13. The test phase
3269 17.14. The install phase
3270 17.15. The package phase
3272 17.17. Other helpful targets
3274 18. Tools needed for building or running
3276 18.1. Tools for pkgsrc builds
3277 18.2. Tools needed by packages
3278 18.3. Tools provided by platforms
3279 18.4. Questions regarding the tools
3281 19. Making your package work
3283 19.1. General operation
3285 19.1.1. Portability of packages
3286 19.1.2. How to pull in user-settable variables from ???
3287 19.1.3. User interaction
3288 19.1.4. Handling licenses
3289 19.1.5. Restricted packages
3290 19.1.6. Handling dependencies
3291 19.1.7. Handling conflicts with other packages
3292 19.1.8. Packages that cannot or should not be built
3293 19.1.9. Packages which should not be deleted, once installed
3294 19.1.10. Handling packages with security problems
3295 19.1.11. How to handle incrementing versions when fixing an existing
3297 19.1.12. Substituting variable text in the package files (the SUBST
3300 19.2. Fixing problems in the fetch phase
3302 19.2.1. Packages whose distfiles aren't available for plain downloading
3303 19.2.2. How to handle modified distfiles with the 'old' name
3305 19.3. Fixing problems in the configure phase
3307 19.3.1. Shared libraries - libtool
3308 19.3.2. Using libtool on GNU packages that already support libtool
3309 19.3.3. GNU Autoconf/Automake
3311 19.4. Programming languages
3313 19.4.1. C, C++, and Fortran
3315 19.4.3. Packages containing perl scripts
3316 19.4.4. Other programming languages
3318 19.5. Fixing problems in the build phase
3320 19.5.1. Compiling C and C++ code conditionally
3321 19.5.2. How to handle compiler bugs
3322 19.5.3. Undefined reference to ...
3323 19.5.4. Running out of memory
3325 19.6. Fixing problems in the install phase
3327 19.6.1. Creating needed directories
3328 19.6.2. Where to install documentation
3329 19.6.3. Installing highscore files
3330 19.6.4. Adding DESTDIR support to packages
3331 19.6.5. Packages with hardcoded paths to other interpreters
3332 19.6.6. Packages installing perl modules
3333 19.6.7. Packages installing info files
3334 19.6.8. Packages installing man pages
3335 19.6.9. Packages installing GConf data files
3336 19.6.10. Packages installing scrollkeeper/rarian data files
3337 19.6.11. Packages installing X11 fonts
3338 19.6.12. Packages installing GTK2 modules
3339 19.6.13. Packages installing SGML or XML data
3340 19.6.14. Packages installing extensions to the MIME database
3341 19.6.15. Packages using intltool
3342 19.6.16. Packages installing startup scripts
3343 19.6.17. Packages installing TeX modules
3344 19.6.18. Packages supporting running binaries in emulation
3345 19.6.19. Packages installing hicolor theme icons
3346 19.6.20. Packages installing desktop files
3348 19.7. Marking packages as having problems
3351 21. Submitting and Committing
3353 21.1. Submitting binary packages
3354 21.2. Submitting source packages (for non-NetBSD-developers)
3355 21.3. General notes when adding, updating, or removing packages
3356 21.4. Committing: Importing a package into CVS
3357 21.5. Updating a package to a newer version
3358 21.6. Renaming a package in pkgsrc
3359 21.7. Moving a package in pkgsrc
3361 22. Frequently Asked Questions
3362 23. GNOME packaging and porting
3365 23.2. Packaging a GNOME application
3366 23.3. Updating GNOME to a newer version
3367 23.4. Patching guidelines
3369 Chapter 10. Creating a new pkgsrc package from scratch
3373 10.1. Common types of packages
3375 10.1.1. Perl modules
3376 10.1.2. KDE applications
3377 10.1.3. Python modules and programs
3381 10.2.1. How the www/nvu package came into pkgsrc
3383 When you find a package that is not yet in pkgsrc, you most likely have a URL
3384 from where you can download the source code. Starting with this URL, creating a
3385 package involves only a few steps.
3387 1. First, install the packages pkgtools/url2pkg and pkgtools/pkglint.
3389 2. Then, choose one of the top-level directories as the category in which you
3390 want to place your package. You can also create a directory of your own
3391 (maybe called local). In that category directory, create another directory
3392 for your package and change into it.
3394 3. Run the program url2pkg, which will ask you for a URL. Enter the URL of the
3395 distribution file (in most cases a .tar.gz file) and watch how the basic
3396 ingredients of your package are created automatically. The distribution
3397 file is extracted automatically to fill in some details in the Makefile
3398 that would otherwise have to be done manually.
3400 4. Examine the extracted files to determine the dependencies of your package.
3401 Ideally, this is mentioned in some README file, but things may differ. For
3402 each of these dependencies, look where it exists in pkgsrc, and if there is
3403 a file called buildlink3.mk in that directory, add a line to your package
3404 Makefile which includes that file just before the last line. If the
3405 buildlink3.mk file does not exist, add a DEPENDS line to the Makefile,
3406 which specifies the version of the dependency and where it can be found in
3407 pkgsrc. This line should be placed in the third paragraph. If the
3408 dependency is only needed for building the package, but not when using it,
3409 use BUILD_DEPENDS instead of DEPENDS. Your package may then look like this:
3413 BUILD_DEPENDS+= lua>=5.0:../../lang/lua
3414 DEPENDS+= screen-[0-9]*:../../misc/screen
3415 DEPENDS+= screen>=4.0:../../misc/screen
3419 .include "../../category/package/buildlink3.mk"
3420 .include "../../devel/glib2/buildlink3.mk"
3421 .include "../../mk/bsd.pkg.mk"
3423 5. Run pkglint to see what things still need to be done to make your package a
3424 "good" one. If you don't know what pkglint's warnings want to tell you, try
3425 pkglint --explain or pkglint -e, which outputs additional explanations.
3427 6. In many cases the package is not yet ready to build. You can find
3428 instructions for the most common cases in the next section, Section 10.1,
3429 "Common types of packages". After you have followed the instructions over
3430 there, you can hopefully continue here.
3432 7. Run bmake clean to clean the working directory from the extracted files.
3433 Besides these files, a lot of cache files and other system information has
3434 been saved in the working directory, which may become wrong after you
3435 edited the Makefile.
3437 8. Now, run bmake to build the package. For the various things that can go
3438 wrong in this phase, consult Chapter 19, Making your package work.
3440 9. When the package builds fine, the next step is to install the package. Run
3441 bmake install and hope that everything works.
3443 10. Up to now, the file PLIST, which contains a list of the files that are
3444 installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to
3445 generate a probably correct list. Check the file using your preferred text
3446 editor to see if the list of files looks plausible.
3448 11. Run pkglint again to see if the generated PLIST contains garbage or not.
3450 12. When you ran bmake install, the package has been registered in the database
3451 of installed files, but with an empty list of files. To fix this, run bmake
3452 deinstall and bmake install again. Now the package is registered with the
3453 list of files from PLIST.
3455 13. Run bmake package to create a binary package from the set of installed
3458 10.1. Common types of packages
3460 10.1.1. Perl modules
3462 Simple Perl modules are handled automatically by url2pkg, including
3465 10.1.2. KDE applications
3467 KDE applications should always include meta-pkgs/kde3/kde3.mk, which contains
3468 numerous settings that are typical of KDE packages.
3470 10.1.3. Python modules and programs
3472 Python modules and programs packages are easily created using a set of
3473 predefined variables.
3475 Most Python packages use either "distutils" or easy-setup ("eggs"). If the
3476 software uses "distutils", set the PYDISTUTILSPKG variable to "yes" so pkgsrc
3477 will make use of this framework. "distutils" uses a script called setup.py, if
3478 the "distutils" driver is not called setup.py, set the PYSETUP variable to the
3481 If the default Python versions are not supported by the software, set the
3482 PYTHON_VERSIONS_ACCEPTED variable to the Python versions the software is known
3483 to work with, from the most recent to the older one, e.g.
3485 PYTHON_VERSIONS_ACCEPTED= 25 24
3487 If the packaged software is a Python module, include "../../lang/python/
3488 extension.mk". In this case, the package directory should be called
3489 "py-software" and PKGNAME should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.
3491 DISTNAME= foopymodule-1.2.10
3492 PKGNAME= ${PYPKGPREFIX}-${DISTNAME}
3494 If it is an application, also include "../../lang/python/application.mk" before
3497 If the packaged software, either it is an application or a module, is
3498 egg-aware, you only need to include "../../lang/python/egg.mk".
3500 In order to correctly set the path to the Python interpreter, use the
3501 REPLACE_PYTHON variable and set it to the list of files that must be corrected.
3504 REPLACE_PYTHON= ${WRKSRC}/*.py
3508 10.2.1. How the www/nvu package came into pkgsrc
3510 10.2.1.1. The initial package
3512 Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet
3513 been imported into pkgsrc. As the description says it has to do with the web,
3514 the obvious choice for the category is "www".
3519 The web site says that the sources are available as a tar file, so I fed that
3520 URL to the url2pkg program:
3522 $ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
3524 My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the
3525 package name should not have the word "sources" in it. I also filled in the
3526 MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like
3532 DISTNAME= nvu-1.0-sources
3535 MASTER_SITES= http://cvs.nvu.com/download/
3536 EXTRACT_SUFX= .tar.bz2
3538 MAINTAINER= rillig@NetBSD.org
3539 HOMEPAGE= http://cvs.nvu.com/
3540 COMMENT= Web Authoring System
3542 # url2pkg-marker (please do not remove this line.)
3543 .include "../../mk/bsd.pkg.mk"
3545 Then, I quit the editor and watched pkgsrc downloading a large source archive:
3547 url2pkg> Running "make makesum" ...
3548 => Required installed package digest>=20010302: digest-20060826 found
3549 => Fetching nvu-1.0-sources.tar.bz2
3550 Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
3551 100% |*************************************| 28992 KB 150.77 KB/s00:00 ETA
3552 29687976 bytes retrieved in 03:12 (150.77 KB/s)
3553 url2pkg> Running "make extract" ...
3554 => Required installed package digest>=20010302: digest-20060826 found
3555 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
3556 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
3557 work.bacc -> /tmp/roland/pkgsrc/www/nvu/work.bacc
3558 ===> Installing dependencies for nvu-1.0
3559 ===> Overriding tools for nvu-1.0
3560 ===> Extracting for nvu-1.0
3561 url2pkg> Adjusting the Makefile.
3563 Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done!
3565 Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)
3567 10.2.1.2. Fixing all kinds of problems to make the package work
3569 Now that the package has been extracted, let's see what's inside it. The
3570 package has a README.txt, but that only says something about mozilla, so it's
3571 probably useless for seeing what dependencies this package has. But since there
3572 is a GNU configure script in the package, let's hope that it will complain
3573 about everything it needs.
3576 => Required installed package digest>=20010302: digest-20060826 found
3577 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
3578 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
3579 ===> Patching for nvu-1.0
3580 ===> Creating toolchain wrappers for nvu-1.0
3581 ===> Configuring for nvu-1.0
3583 configure: error: Perl 5.004 or higher is required.
3585 WARNING: Please add USE_TOOLS+=perl to the package Makefile.
3588 That worked quite well. So I opened the package Makefile in my editor, and
3589 since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
3590 dependencies of the package have changed now, and since a perl wrapper is
3591 automatically installed in the "tools" phase, I need to build the package from
3595 ===> Cleaning for nvu-1.0
3598 *** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \
3599 GNU Make. You will not be able to build Mozilla without GNU Make.
3602 So I added "gmake" to the USE_TOOLS line and tried again (from scratch).
3605 checking for GTK - version >= 1.2.0... no
3606 *** Could not run GTK test program, checking why...
3609 Now to the other dependencies. The first question is: Where is the GTK package
3618 $ echo ../../*/gtk2/bui*
3619 ../../x11/gtk2/buildlink3.mk
3621 The first try was definitely too broad. The second one had exactly one result,
3622 which is very good. But there is one pitfall with GNOME packages. Before GNOME
3623 2 had been released, there were already many GNOME 1 packages in pkgsrc. To be
3624 able to continue to use these packages, the GNOME 2 packages were imported as
3625 separate packages, and their names usually have a "2" appended. So I checked
3626 whether this was the case here, and indeed it was.
3628 Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
3629 easy. I just inserted an .include line before the last line of the package
3630 Makefile, so that it now looks like this:
3633 .include "../../x11/gtk2/buildlink3.mk"
3634 .include "../../mk/bsd.pkg.mk
3636 After another bmake clean && bmake, the answer was:
3639 checking for gtk-config... /home/roland/pkg/bin/gtk-config
3640 checking for GTK - version >= 1.2.0... no
3641 *** Could not run GTK test program, checking why...
3642 *** The test program failed to compile or link. See the file config.log for the
3643 *** exact error that occured. This usually means GTK was incorrectly installed
3644 *** or that you have moved GTK since it was installed. In the latter case, you
3645 *** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config
3646 configure: error: Test for GTK failed.
3649 In this particular case, the assumption that "every package prefers GNOME 2"
3650 had been wrong. The first of the lines above told me that this package really
3651 wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
3652 it would have looked for pkg-config instead of gtk-config. So I changed the x11
3653 /gtk2 to x11/gtk in the package Makefile, and tried again.
3656 cc -o xpidl.o -c -DOSTYPE=\"NetBSD3\" -DOSARCH=\"NetBSD\" -I../../../dist/include/xpcom -I../../../dist/include -I/tmp/roland/pkgsrc/www/nvu/work.bacc/mozilla/dist/include/nspr -I/usr/X11R6/include -fPIC -DPIC -I/home/roland/pkg/include -I/usr/include -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -O2 -I/home/roland/pkg/include -I/usr/include -Dunix -pthread -pipe -DDEBUG -D_DEBUG -DDEBUG_roland -DTRACING -g -I/home/roland/pkg/include/glib/glib-1.2 -I/home/roland/pkg/lib/glib/include -I/usr/pkg/include/orbit-1.0 -I/home/roland/pkg/include -I/usr/include -I/usr/X11R6/include -include ../../../mozilla-config.h -DMOZILLA_CLIENT -Wp,-MD,.deps/xpidl.pp xpidl.c
3657 In file included from xpidl.c:42:
3658 xpidl.h:53:24: libIDL/IDL.h: No such file or directory
3659 In file included from xpidl.c:42:
3660 xpidl.h:132: error: parse error before "IDL_ns"
3663 The package still does not find all of its dependencies. Now the question is:
3664 Which package provides the libIDL/IDL.h header file?
3666 $ echo ../../*/*idl*
3667 ../../devel/py-idle ../../wip/idled ../../x11/acidlaunch
3668 $ echo ../../*/*IDL*
3671 Let's take the one from the second try. So I included the ../../net/libIDL/
3672 buildlink3.mk file and tried again. But the error didn't change. After digging
3673 through some of the code, I concluded that the build process of the package was
3674 broken and couldn't have ever worked, but since the Mozilla source tree is
3675 quite large, I didn't want to fix it. So I added the following to the package
3676 Makefile and tried again:
3678 CPPFLAGS+= -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0
3679 BUILDLINK_TRANSFORM+= -l:IDL:IDL-2
3681 The latter line is needed because the package expects the library libIDL.so,
3682 but only libIDL-2.so is available. So I told the compiler wrapper to rewrite
3685 The next problem was related to a recent change of the FreeType interface. I
3686 looked up in www/seamonkey which patch files were relevant for this issue and
3687 copied them to the patches directory. Then I retried, fixed the patches so that
3688 they applied cleanly and retried again. This time, everything worked.
3690 10.2.1.3. Installing the package
3692 $ bmake CHECK_FILES=no install
3694 $ bmake print-PLIST >PLIST
3698 Chapter 11. Package components - files, directories and contents
3706 11.3.1. Structure of a single patch file
3707 11.3.2. Creating patch files
3708 11.3.3. Sources where the patch files come from
3709 11.3.4. Patching guidelines
3710 11.3.5. Feedback to the author
3712 11.4. Other mandatory files
3713 11.5. Optional files
3715 11.5.1. Files affecting the binary package
3716 11.5.2. Files affecting the build process
3717 11.5.3. Files affecting nothing at all
3722 Whenever you're preparing a package, there are a number of files involved which
3723 are described in the following sections.
3727 Building, installation and creation of a binary package are all controlled by
3728 the package's Makefile. The Makefile describes various things about a package,
3729 for example from where to get it, how to configure, build, and install it.
3731 A package Makefile contains several sections that describe the package.
3733 In the first section there are the following variables, which should appear
3734 exactly in the order given here. The order and grouping of the variables is
3735 mostly historical and has no further meaning.
3737 * DISTNAME is the basename of the distribution file to be downloaded from the
3740 * PKGNAME is the name of the package, as used by pkgsrc. You only need to
3741 provide it if DISTNAME (which is the default) is not a good name for the
3742 package in pkgsrc. Usually it is the pkgsrc directory name together with
3743 the version number. It must match the regular expression ^[A-Za-z0-9]
3744 [A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains
3745 only letters, digits, dashes, underscores, dots and plus signs.
3747 * SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't
3748 unique on a SVR4 system. The default is PKGNAME, which may be shortened
3749 when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not
3750 produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME
3751 is limited to 5 characters.
3753 * CATEGORIES is a list of categories which the package fits in. You can
3754 choose any of the top-level directories of pkgsrc for it.
3756 Currently the following values are available for CATEGORIES. If more than
3757 one is used, they need to be separated by spaces:
3759 archivers cross geography meta-pkgs security
3760 audio databases graphics misc shells
3761 benchmarks devel ham multimedia sysutils
3762 biology editors inputmethod net textproc
3763 cad emulators lang news time
3764 chat finance mail parallel wm
3765 comms fonts math pkgtools www
3766 converters games mbone print x11
3768 * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
3769 are discussed in detail in Section 17.5, "The fetch phase".
3771 The second section contains information about separately downloaded patches, if
3774 * PATCHFILES: Name(s) of additional files that contain distribution patches.
3775 There is no default. pkgsrc will look for them at PATCH_SITES. They will
3776 automatically be uncompressed before patching if the names end with .gz or
3779 * PATCH_SITES: Primary location(s) for distribution patch files (see
3780 PATCHFILES below) if not found locally.
3782 The third section contains the following variables.
3784 * MAINTAINER is the email address of the person who feels responsible for
3785 this package, and who is most likely to look at problems or questions
3786 regarding this package which have been reported with send-pr(1). Other
3787 developers may contact the MAINTAINER before making changes to the package,
3788 but are not required to do so. When packaging a new program, set MAINTAINER
3789 to yourself. If you really can't maintain the package for future updates,
3790 set it to <pkgsrc-users@NetBSD.org>.
3792 * OWNER should be used instead of MAINTAINER when you do not want other
3793 developers to update or change the package without contacting you first. A
3794 package Makefile should contain one of MAINTAINER or OWNER, but not both.
3796 * HOMEPAGE is a URL where users can find more information about the package.
3798 * COMMENT is a one-line description of the package (should not include the
3801 Other variables that affect the build:
3803 * WRKSRC: The directory where the interesting distribution files of the
3804 package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
3807 If a package doesn't create a subdirectory for itself (most GNU software
3808 does, for instance), but extracts itself in the current directory, you
3809 should set WRKSRC=${WRKDIR}.
3811 If a package doesn't create a subdirectory with the name of DISTNAME but
3812 some different name, set WRKSRC to point to the proper name in ${WRKDIR},
3813 for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
3816 The name of the working directory created by pkgsrc is taken from the
3817 WRKDIR_BASENAME variable. By default, its value is work. If you want to use
3818 the same pkgsrc tree for building different kinds of binary packages, you
3819 can change the variable according to your needs. Two other variables handle
3820 common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
3821 defined in mk.conf, the first component of the host's name is attached to
3822 the directory name. If OBJMACHINE is defined, the platform name is
3823 attached, which might look like work.i386 or work.sparc.
3825 Please pay attention to the following gotchas:
3827 * Add MANCOMPRESSED if man pages are installed in compressed form by the
3828 package. For packages using BSD-style makefiles which honor MANZ, there is
3829 MANCOMPRESSED_IF_MANZ.
3831 * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
3833 * If the package installs any info files, see Section 19.6.7, "Packages
3834 installing info files".
3838 The distinfo file contains the message digest, or checksum, of each distfile
3839 needed for the package. This ensures that the distfiles retrieved from the
3840 Internet have not been corrupted during transfer or altered by a malign force
3841 to introduce a security hole. Due to recent rumor about weaknesses of digest
3842 algorithms, all distfiles are protected using both SHA1 and RMD160 message
3843 digests, as well as the file size.
3845 The distinfo file also contains the checksums for all the patches found in the
3846 patches directory (see Section 11.3, "patches/*").
3848 To regenerate the distinfo file, use the make makedistinfo or make mdi command.
3850 Some packages have different sets of distfiles depending on the platform, for
3851 example www/navigator). These are kept in the same distinfo file and care
3852 should be taken when upgrading such a package to ensure distfile information is
3857 Many packages still don't work out-of-the box on the various platforms that are
3858 supported by pkgsrc. Therefore, a number of custom patch files are needed to
3859 make the package work. These patch files are found in the patches/ directory.
3861 In the patch phase, these patches are applied to the files in WRKSRC directory
3862 after extracting them, in alphabetic order, so patch-aa is applied before
3865 11.3.1. Structure of a single patch file
3867 The patch-* files should be in diff -bu format, and apply without a fuzz to
3868 avoid problems. (To force patches to apply with fuzz you can set
3869 PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
3870 a single file, and no file should be patched by more than one patch file. This
3871 helps to keep future modifications simple.
3873 Each patch file is structured as follows: In the first line, there is the RCS
3874 Id of the patch itself. The second line should be empty for aesthetic reasons.
3875 After that, there should be a comment for each change that the patch does.
3876 There are a number of standard cases:
3878 * Patches that replace the == operator for test(1) with = in shell scripts
3879 are so common that they don't need a comment at all.
3881 * Patches for commonly known vulnerabilities should mention the vulnerability
3884 * Patches that change source code should mention the platform and other
3885 environment (for example, the compiler) that the patch is needed for.
3887 In all other cases, the patch should be commented so that any developer who
3888 knows the code of the application can make some use of the patch. Special care
3889 should be taken for the upstream developers, since we generally want that they
3890 accept our patches, so we have less work in the future.
3892 11.3.2. Creating patch files
3894 One important thing to mention is to pay attention that no RCS IDs get stored
3895 in the patch files, as these will cause problems when later checked into the
3896 NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
3897 avoid these problems.
3899 For even more automation, we recommend using mkpatches from the same package to
3900 make a whole set of patches. You just have to backup files before you edit them
3901 to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using
3902 pkgvi again from the same package. If you upgrade a package this way, you can
3903 easily compare the new set of patches with the previously existing one with
3904 patchdiff. Copy the patches you want to use or update from the work/.newpatches
3905 directory to patches/.
3907 When you have finished a package, remember to generate the checksums for the
3908 patch files by using the make makepatchsum command, see Section 11.2,
3911 When adding a patch that corrects a problem in the distfile (rather than e.g.
3912 enforcing pkgsrc's view of where man pages should go), send the patch as a bug
3913 report to the maintainer. This benefits non-pkgsrc users of the package, and
3914 usually makes it possible to remove the patch in future version.
3916 The file names of the patch files are usually of the form patch-[a-z][a-z].
3918 11.3.3. Sources where the patch files come from
3920 If you want to share patches between multiple packages in pkgsrc, e.g. because
3921 they use the same distfiles, set PATCHDIR to the path where the patch files can
3924 PATCHDIR= ${.CURDIR}/../xemacs/patches
3926 Patch files that are distributed by the author or other maintainers can be
3927 listed in PATCHFILES.
3929 If it is desired to store any patches that should not be committed into pkgsrc,
3930 they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
3931 directory tree there is expected to have the same "category/package" structure
3932 as pkgsrc, and patches are expected to be stored inside these dirs (also known
3933 as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
3934 for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
3935 files in the named directory are expected to be patch files, and they are
3936 applied after pkgsrc patches are applied.
3938 11.3.4. Patching guidelines
3940 When fixing a portability issue in the code do not use preprocessor magic to
3941 check for the current operating system nor platform. Doing so hurts portability
3942 to other platforms because the OS-specific details are not abstracted
3945 The general rule to follow is: instead of checking for the operating system the
3946 application is being built on, check for the specific features you need. For
3947 example, instead of assuming that kqueue is available under NetBSD and using
3948 the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
3949 kqueue itself ? yes, this generally involves patching the configure script.
3950 There is absolutely nothing that prevents some OSes from adopting interfaces
3951 from other OSes (e.g. Linux implementing kqueue), something that the above
3952 checks cannot take into account.
3954 Of course, checking for features generally involves more work on the
3955 developer's side, but the resulting changes are cleaner and there are chances
3956 they will work on many other platforms. Not to mention that there are higher
3957 chances of being later integrated into the mainstream sources. Remember: It
3958 doesn't work unless it is right!
3960 Some typical examples:
3962 Table 11.1. Patching examples
3964 +-------------------------------------------------------------------------------------------+
3965 | Where | Incorrect | Correct |
3966 |---------+--------------------------+------------------------------------------------------|
3967 | |case ${target_os} in | |
3968 |configure|netbsd*) have_kvm=yes ;; |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)|
3969 |script |*) have_kvm=no ;; | |
3971 |---------+--------------------------+------------------------------------------------------|
3972 |C source |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) |
3973 |file |# include <sys/event.h> |# include <sys/event.h> |
3975 |---------+--------------------------+------------------------------------------------------|
3977 | |monitor_file(...) |monitor_file(...) |
3979 | |#if defined(__NetBSD__) |#if defined(HAVE_KQUEUE) |
3980 |C source | int fd = kqueue();| int fd = kqueue(); |
3986 +-------------------------------------------------------------------------------------------+
3989 For more information, please read the Making packager-friendly software article
3990 (part 1, part 2). It summarizes multiple details on how to make software easier
3991 to package; all the suggestions in it were collected from our experience in
3992 pkgsrc work, so they are possibly helpful when creating patches too.
3994 11.3.5. Feedback to the author
3996 Always, always, always feed back any portability fixes or improvements you do
3997 to a package to the mainstream developers. This is the only way to get their
3998 attention on portability issues and to ensure that future versions can be built
3999 out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will
4000 get the fixes straight from the packaged code.
4002 This generally involves cleaning up the patches (because sometimes the patches
4003 that are added to pkgsrc are quick hacks), filling bug reports in the
4004 appropriate trackers for the projects and working with the mainstream authors
4005 to accept your changes. It is extremely important that you do it so that the
4006 packages in pkgsrc are kept simple and thus further changes can be done without
4009 Support the idea of free software!
4011 11.4. Other mandatory files
4015 A multi-line description of the piece of software. This should include any
4016 credits where they are due. Please bear in mind that others do not share
4017 your sense of humour (or spelling idiosyncrasies), and that others will
4018 read everything that you write here.
4022 This file governs the files that are installed on your system: all the
4023 binaries, manual pages, etc. There are other directives which may be
4024 entered in this file, to control the creation and deletion of directories,
4025 and the location of inserted files. See Chapter 13, PLIST issues for more
4028 11.5. Optional files
4030 11.5.1. Files affecting the binary package
4034 This shell script is invoked twice by pkg_add(1). First time after package
4035 extraction and before files are moved in place, the second time after the
4036 files to install are moved in place. This can be used to do any custom
4037 procedures not possible with @exec commands in PLIST. See pkg_add(1) and
4038 pkg_create(1) for more information. See also Section 15.1, "Files and
4039 directories outside the installation prefix".
4043 This script is executed before and after any files are removed. It is this
4044 script's responsibility to clean up any additional messy details around the
4045 package's installation, since all pkg_delete knows is how to delete the
4046 files created in the original distribution. See pkg_delete(1) and
4047 pkg_create(1) for more information.
4051 This file is displayed after installation of the package. Useful for things
4052 like legal notices on almost-free software and hints for updating config
4053 files after installing modules for apache, PHP etc. Please note that you
4054 can modify variables in it easily by using MESSAGE_SUBST in the package's
4057 MESSAGE_SUBST+= SOMEVAR="somevalue"
4059 replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
4060 is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE,
4061 PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.
4063 You can display a different or additional files by setting the MESSAGE_SRC
4064 variable. Its default is MESSAGE, if the file exists.
4068 FIXME: There is no documentation on the alternatives framework.
4070 11.5.2. Files affecting the build process
4074 This file contains arbitrary things that could also go into a Makefile, but
4075 its purpose is to be used by more than one package. This file should only
4076 be used when the packages that will use the file are known in advance. For
4077 other purposes it is often better to write a *.mk file and give it a good
4078 name that describes what it does.
4082 This file contains the dependency information for the buildlink3 framework
4083 (see Chapter 14, Buildlink methodology).
4087 This file contains workarounds for compiler bugs and similar things. It is
4088 included automatically by the pkgsrc infrastructure, so you don't need an
4089 extra .include line for it.
4093 This file contains the code for the package-specific options (see
4094 Chapter 16, Options handling) that can be selected by the user. If a
4095 package has only one or two options, it is equally acceptable to put the
4096 code directly into the Makefile.
4098 11.5.3. Files affecting nothing at all
4102 These files do not take place in the creation of a package and thus are
4103 purely informative to the package developer.
4107 This file contains things that need to be done to make the package even
4112 When you type make, the distribution files are unpacked into the directory
4113 denoted by WRKDIR. It can be removed by running make clean. Besides the
4114 sources, this directory is also used to keep various timestamp files. The
4115 directory gets removed completely on clean. The default is ${.CURDIR}/work or $
4116 {.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
4120 If you have any files that you wish to be placed in the package prior to
4121 configuration or building, you could place these files here and use a ${CP}
4122 command in the "pre-configure" target to achieve this. Alternatively, you could
4123 simply diff the file against /dev/null and use the patch mechanism to manage
4124 the creation of this file.
4126 If you want to share files in this way with other packages, set the FILESDIR
4127 variable to point to the other package's files directory, e.g.:
4129 FILESDIR=${.CURDIR}/../xemacs/files
4131 Chapter 12. Programming in Makefiles
4136 12.2. Makefile variables
4138 12.2.1. Naming conventions
4142 12.3.1. Adding things to a list
4143 12.3.2. Converting an internal list into an external list
4144 12.3.3. Passing variables to a shell command
4145 12.3.4. Quoting guideline
4146 12.3.5. Workaround for a bug in BSD Make
4148 Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
4149 part of the pkgsrc system. Using the make(1) system as a programming language
4150 for a big system like pkgsrc requires some discipline to keep the code correct
4153 The basic ingredients for Makefile programming are variables (which are
4154 actually macros) and shell commands. Among these shell commands may even be
4155 more complex ones like awk(1) programs. To make sure that every shell command
4156 runs as intended it is necessary to quote all variables correctly when they are
4159 This chapter describes some patterns, that appear quite often in Makefiles,
4160 including the pitfalls that come along with them.
4164 * When you are creating a file as a target of a rule, always write the data
4165 to a temporary file first and finally rename that file. Otherwise there
4166 might occur an error in the middle of generating the file, and when the
4167 user runs make(1) for the second time, the file exists and will not be
4168 regenerated properly. Example:
4171 @echo "line 1" > ${.TARGET}
4172 @echo "line 2" >> ${.TARGET}
4176 @echo "line 1" > ${.TARGET}.tmp
4177 @echo "line 2" >> ${.TARGET}.tmp
4179 @mv ${.TARGET}.tmp ${.TARGET}
4181 When you run make wrong twice, the file wrong will exist, although there
4182 was an error message in the first run. On the other hand, running make
4183 correct gives an error message twice, as expected.
4185 You might remember that make(1) sometimes removes ${.TARGET} in case of
4186 error, but this only happens when it is interrupted, for example by
4187 pressing ^C. This does not happen when one of the commands fails (like
4190 12.2. Makefile variables
4192 Makefile variables contain strings that can be processed using the five
4193 operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
4196 When a variable's value is parsed from a Makefile, the hash character ``#'' and
4197 the backslash character ``\'' are handled specially. If a backslash is followed
4198 by a newline, any whitespace immediately in front of the backslash, the
4199 backslash, the newline, and any whitespace immediately behind the newline are
4200 replaced with a single space. A backslash character and an immediately
4201 following hash character are replaced with a single hash character. Otherwise,
4202 the backslash is passed as is. In a variable assignment, any hash character
4203 that is not preceded by a backslash starts a comment that continues upto the
4204 end of the logical line.
4206 Note: Because of this parsing algorithm the only way to create a variable
4207 consisting of a single backslash is using the ``!='' operator, for example:
4208 BACKSLASH!=echo "\\".
4210 So far for defining variables. The other thing you can do with variables is
4211 evaluating them. A variable is evaluated when it is part of the right side of
4212 the ``:='' or the ``!='' operator, or directly before executing a shell command
4213 which the variable is part of. In all other cases, make(1) performs lazy
4214 evaluation, that is, variables are not evaluated until there's no other way.
4215 The ``modifiers'' mentioned in the man page also evaluate the variable.
4217 Some of the modifiers split the string into words and then operate on the
4218 words, others operate on the string as a whole. When a string is split into
4219 words, it is split as you would expect it from sh(1).
4221 No rule without exception?the .for loop does not follow the shell quoting rules
4222 but splits at sequences of whitespace.
4224 There are several types of variables that should be handled differently.
4225 Strings and two types of lists.
4227 * Strings can contain arbitrary characters. Nevertheless, you should restrict
4228 yourself to only using printable characters. Examples are PREFIX and
4231 * Internal lists are lists that are never exported to any shell command.
4232 Their elements are separated by whitespace. Therefore, the elements
4233 themselves cannot have embedded whitespace. Any other characters are
4234 allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
4237 * External lists are lists that may be exported to a shell command. Their
4238 elements can contain any characters, including whitespace. That's why they
4239 cannot be used in .for loops. Examples are DISTFILES and MASTER_SITES.
4241 12.2.1. Naming conventions
4243 * All variable names starting with an underscore are reserved for use by the
4244 pkgsrc infrastructure. They shall not be used by package Makefiles.
4246 * In .for loops you should use lowercase variable names for the iteration
4249 * All list variables should have a ``plural'' name, e.g. PKG_OPTIONS or
4254 This section presents you with some code snippets you should use in your own
4255 code. If you don't find anything appropriate here, you should test your code
4258 12.3.1. Adding things to a list
4260 STRING= foo * bar `date`
4262 ANOTHER_INT_LIST= apache-[0-9]*:../../www/apache
4264 ANOTHER_EXT_LIST= a=b c=d
4266 INT_LIST+= ${STRING} # 1
4267 INT_LIST+= ${ANOTHER_INT_LIST} # 2
4268 EXT_LIST+= ${STRING:Q} # 3
4269 EXT_LIST+= ${ANOTHER_EXT_LIST} # 4
4271 When you add a string to an external list (example 3), it must be quoted. In
4272 all other cases, you must not add a quoting level. You must not merge internal
4273 and external lists, unless you are sure that all entries are correctly
4274 interpreted in both lists.
4276 12.3.2. Converting an internal list into an external list
4279 .for i in ${INT_LIST}
4283 This code converts the internal list INT_LIST into the external list EXT_LIST.
4284 As the elements of an internal list are unquoted they must be quoted here. The
4285 reason for appending "" is explained below.
4287 12.3.3. Passing variables to a shell command
4289 Sometimes you may want to print an arbitrary string. There are many ways to get
4290 it wrong and only few that can handle every nastiness.
4292 STRING= foo bar < > * `date` $$HOME ' "
4293 EXT_LIST= string=${STRING:Q} x=second\ item
4297 echo "${STRING}" # 2
4298 echo "${STRING:Q}" # 3
4299 echo ${STRING:Q} # 4
4300 echo x${STRING:Q} | sed 1s,.,, # 5
4301 printf "%s\\n" ${STRING:Q}"" # 6
4302 env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
4304 Example 1 leads to a syntax error in the shell, as the characters are just
4307 Example 2 leads to a syntax error too, and if you leave out the last "
4308 character from ${STRING}, date(1) will be executed. The $HOME shell variable
4309 would be evaluated, too.
4311 Example 3 outputs each space character preceded by a backslash (or not),
4312 depending on the implementation of the echo(1) command.
4314 Example 4 handles correctly every string that does not start with a dash. In
4315 that case, the result depends on the implementation of the echo(1) command. As
4316 long as you can guarantee that your input does not start with a dash, this form
4319 Example 5 handles even the case of a leading dash correctly.
4321 Example 6 also works with every string and is the light-weight solution, since
4322 it does not involve a pipe, which has its own problems.
4324 The EXT_LIST does not need to be quoted because the quoting has already been
4325 done when adding elements to the list.
4327 As internal lists shall not be passed to the shell, there is no example for it.
4329 12.3.4. Quoting guideline
4331 There are many possible sources of wrongly quoted variables. This section lists
4332 some of the commonly known ones.
4334 * Whenever you use the value of a list, think about what happens to leading
4335 or trailing whitespace. If the list is a well-formed shell expression, you
4336 can apply the :M* modifier to strip leading and trailing whitespace from
4337 each word. The :M operator first splits its argument according to the rules
4338 of the shell, and then creates a new list consisting of all words that
4339 match the shell glob expression *, that is: all. One class of situations
4340 where this is needed is when adding a variable like CPPFLAGS to
4341 CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
4342 strips the leading and trailing whitespace from the variable and then
4343 passes it to the other configure scripts. But these configure scripts
4344 expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
4345 That's why we better pass the CPPFLAGS value properly trimmed. And here is
4349 CPPFLAGS+= -Wundef -DPREFIX=\"${PREFIX:Q}\"
4350 CPPFLAGS+= ${MY_CPPFLAGS}
4352 CONFIGURE_ARGS+= CPPFLAGS=${CPPFLAGS:M*:Q}
4355 echo x${CPPFLAGS:Q}x # leading and trailing whitespace
4356 echo x${CONFIGURE_ARGS}x # properly trimmed
4358 * The example above contains one bug: The ${PREFIX} is a properly quoted
4359 shell expression, but there is the C compiler after it, which also expects
4360 a properly quoted string (this time in C syntax). The version above is
4361 therefore only correct if ${PREFIX} does not have embedded backslashes or
4362 double quotes. If you want to allow these, you have to add another layer of
4363 quoting to each variable that is used as a C string literal. You cannot use
4364 the :Q operator for it, as this operator only works for the shell.
4366 * Whenever a variable can be empty, the :Q operator can have surprising
4367 results. Here are two completely different cases which can be solved with
4372 for i in a ${EMPTY:Q} c; do \
4377 .for i in a:\ a:\test.txt
4382 The first example will only print two of the three lines we might have
4383 expected. This is because ${EMPTY:Q} expands to the empty string, which the
4384 shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
4385 be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
4388 The second example will only print three lines instead of four. The first
4389 line looks like a:\ echo foo. This is because the backslash of the value a:
4390 \ is interpreted as a line-continuation by make(1), which makes the second
4391 line the arguments of the echo(1) command from the first line. To avoid
4392 this, write ${i:Q}"".
4394 12.3.5. Workaround for a bug in BSD Make
4396 The pkgsrc bmake program does not handle the following assignment correctly. In
4397 case _othervar_ contains a ``-'' character, one of the closing braces is
4398 included in ${VAR} after this code executes.
4400 VAR:= ${VAR:N${_othervar_:C/-//}}
4402 For a more complex code snippet and a workaround, see the package regress/
4403 make-quoting, testcase bug1.
4405 Chapter 13. PLIST issues
4410 13.2. Semi-automatic PLIST generation
4411 13.3. Tweaking output of make print-PLIST
4412 13.4. Variable substitution in PLIST
4413 13.5. Man page compression
4414 13.6. Changing PLIST source with PLIST_SRC
4415 13.7. Platform-specific and differing PLISTs
4416 13.8. Sharing directories between packages
4418 The PLIST file contains a package's "packing list", i.e. a list of files that
4419 belong to the package (relative to the ${PREFIX} directory it's been installed
4420 in) plus some additional statements - see the pkg_create(1) man page for a full
4421 list. This chapter addresses some issues that need attention when dealing with
4422 the PLIST file (or files, see below!).
4426 Be sure to add a RCS ID line as the first thing in any PLIST file you write:
4431 13.2. Semi-automatic PLIST generation
4433 You can use the make print-PLIST command to output a PLIST that matches any new
4434 files since the package was extracted. See Section 17.17, "Other helpful
4435 targets" for more information on this target.
4437 13.3. Tweaking output of make print-PLIST
4439 If you have used any of the *-dirs packages, as explained in Section 13.8,
4440 "Sharing directories between packages", you may have noticed that make
4441 print-PLIST outputs a set of @comments instead of real @dirrm lines. You can
4442 also do this for specific directories and files, so that the results of that
4443 command are very close to reality. This helps a lot during the update of
4446 The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
4447 used to filter the output of print-PLIST. You can append any chunk of AWK
4448 scripting you like to it, but be careful with quoting.
4450 For example, to get all files inside the libdata/foo directory removed from the
4453 PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }
4456 And to get all the @dirrm lines referring to a specific (shared) directory
4457 converted to @comments:
4459 PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; }
4462 13.4. Variable substitution in PLIST
4464 A number of variables are substituted automatically in PLISTs when a package is
4465 installed on a system. This includes the following variables:
4467 ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
4469 Some packages like emacs and perl embed information about which
4470 architecture they were built on into the pathnames where they install their
4471 files. To handle this case, PLIST will be preprocessed before actually
4472 used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
4473 gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
4474 PLIST somewhere - use this on packages that have GNU autoconf-created
4479 There used to be a symbol "$ARCH" that was replaced by the output of uname
4480 -m, but that's no longer supported and has been removed.
4482 ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
4484 Some packages want to embed the OS name and version into some paths. To do
4485 this, use these variables in the PLIST:
4487 * ${OPSYS} - output of "uname -s"
4489 * ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
4491 * ${OS_VERSION} - "uname -r"
4493 For a complete list of values which are replaced by default, please look in
4494 bsd.pkg.mk (and search for PLIST_SUBST).
4496 If you want to change other variables not listed above, you can add variables
4497 and their expansions to this variable in the following way, similar to
4498 MESSAGE_SUBST (see Section 11.5, "Optional files"):
4500 PLIST_SUBST+= SOMEVAR="somevalue"
4503 This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".
4505 The PLIST_VARS variable can be used to simplify the common case of
4506 conditionally including some PLIST entries. It can be done by adding
4507 PLIST_VARS+=foo and setting the corresponding PLIST.foo variable to yes if the
4508 entry should be included. This will substitute "${PLIST.foo}" in the PLIST with
4509 either """" or ""@comment "". For example, in Makefile:
4523 ${PLIST.foo}man/man1/foo.1
4524 ${PLIST.foo}share/bar/foo.data
4525 ${PLIST.foo}@dirrm share/bar
4528 13.5. Man page compression
4530 Man pages should be installed in compressed form if MANZ is set (in
4531 bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
4532 suffix ".gz" is appended/removed automatically for man pages according to MANZ
4533 and MANCOMPRESSED being set or not, see above for details. This modification of
4534 the PLIST file is done on a copy of it, not PLIST itself.
4536 13.6. Changing PLIST source with PLIST_SRC
4538 To use one or more files as source for the PLIST used in generating the binary
4539 package, set the variable PLIST_SRC to the names of that file(s). The files are
4540 later concatenated using cat(1), and the order of things is important. The
4541 default for PLIST_SRC is ${PKGDIR}/PLIST.
4543 13.7. Platform-specific and differing PLISTs
4545 Some packages decide to install a different set of files based on the operating
4546 system being used. These differences can be automatically handled by using the
4553 * PLIST.${MACHINE_ARCH}
4555 * PLIST.${OPSYS}-${MACHINE_ARCH}
4559 13.8. Sharing directories between packages
4561 A "shared directory" is a directory where multiple (and unrelated) packages
4562 install files. These directories were problematic because you had to add
4563 special tricks in the PLIST to conditionally remove them, or have some
4564 centralized package handle them.
4566 In pkgsrc, it is now easy: Each package should create directories and install
4567 files as needed; pkg_delete will remove any directories left empty after
4568 uninstalling a package.
4570 If a package needs an empty directory to work, create the directory during
4571 installation as usual, and also add an entry to the PLIST:
4573 @pkgdir path/to/empty/directory
4576 Chapter 14. Buildlink methodology
4580 14.1. Converting packages to use buildlink3
4581 14.2. Writing buildlink3.mk files
4583 14.2.1. Anatomy of a buildlink3.mk file
4584 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
4586 14.3. Writing builtin.mk files
4588 14.3.1. Anatomy of a builtin.mk file
4589 14.3.2. Global preferences for native or pkgsrc software
4591 Buildlink is a framework in pkgsrc that controls what headers and libraries are
4592 seen by a package's configure and build processes. This is implemented in a two
4595 1. Symlink headers and libraries for dependencies into BUILDLINK_DIR, which by
4596 default is a subdirectory of WRKDIR.
4598 2. Create wrapper scripts that are used in place of the normal compiler tools
4599 that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib into
4600 references to BUILDLINK_DIR. The wrapper scripts also make native compiler
4601 on some operating systems look like GCC, so that packages that expect GCC
4602 won't require modifications to build with those native compilers.
4604 This normalizes the environment in which a package is built so that the package
4605 may be built consistently despite what other software may be installed. Please
4606 note that the normal system header and library paths, e.g. /usr/include, /usr/
4607 lib, etc., are always searched -- buildlink3 is designed to insulate the
4608 package build from non-system-supplied software.
4610 14.1. Converting packages to use buildlink3
4612 The process of converting packages to use the buildlink3 framework
4613 ("bl3ifying") is fairly straightforward. The things to keep in mind are:
4615 1. Ensure that the build always calls the wrapper scripts instead of the
4616 actual toolchain. Some packages are tricky, and the only way to know for
4617 sure is the check ${WRKDIR}/.work.log to see if the wrappers are being
4620 2. Don't override PREFIX from within the package Makefile, e.g. Java VMs,
4621 standalone shells, etc., because the code to symlink files into $
4622 {BUILDLINK_DIR} looks for files relative to "pkg_info -qp pkgname".
4624 3. Remember that only the buildlink3.mk files that you list in a package's
4625 Makefile are added as dependencies for that package.
4627 If a dependency on a particular package is required for its libraries and
4628 headers, then we replace:
4630 DEPENDS+= foo>=1.1.0:../../category/foo
4634 .include "../../category/foo/buildlink3.mk"
4636 The buildlink3.mk files usually define the required dependencies. If you need a
4637 newer version of the dependency when using buildlink3.mk files, then you can
4638 define it in your Makefile; for example:
4640 BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0
4641 .include "../../category/foo/buildlink3.mk"
4643 There are several buildlink3.mk files in pkgsrc/mk that handle special package
4646 * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
4647 implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.
4649 * curses.buildlink3.mk: If the system comes with neither Curses nor NCurses,
4650 this will take care to install the devel/ncurses package.
4652 * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding
4653 a dependency on Heimdal or MIT-krb5 for packages that require a Kerberos 5
4656 * motif.buildlink3.mk checks for a system-provided Motif installation or adds
4657 a dependency on x11/lesstif or x11/openmotif. The user can set MOTIF_TYPE
4658 to "dt", "lesstif", or "openmotif" to choose which Motif version will be
4661 * oss.buildlink3.mk defines several variables that may be used by packages
4662 that use the Open Sound System (OSS) API.
4664 * pgsql.buildlink3.mk will accept either Postgres 8.0, 8.1, or 8.2, whichever
4665 is found installed. See the file for more information.
4667 * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native
4668 pthreads or adds a dependency on devel/pth as needed.
4670 * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena
4673 The comments in those buildlink3.mk files provide a more complete description
4674 of how to use them properly.
4676 14.2. Writing buildlink3.mk files
4678 A package's buildlink3.mk file is included by Makefiles to indicate the need to
4679 compile and link against header files and libraries provided by the package. A
4680 buildlink3.mk file should always provide enough information to add the correct
4681 type of dependency relationship and include any other buildlink3.mk files that
4682 it needs to find headers and libraries that it needs in turn.
4684 To generate an initial buildlink3.mk file for further editing, Rene Hexel's
4685 pkgtools/createbuildlink package is highly recommended. For most packages, the
4686 following command will generate a good starting point for buildlink3.mk files:
4688 % cd pkgsrc/category/pkgdir
4689 % createbuildlink >buildlink3.mk
4692 14.2.1. Anatomy of a buildlink3.mk file
4694 The following real-life example buildlink3.mk is taken from pkgsrc/graphics/
4697 # $NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp $
4699 BUILDLINK_TREE+= tiff
4701 .if !defined(TIFF_BUILDLINK3_MK)
4702 TIFF_BUILDLINK3_MK:=
4704 BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1
4705 BUILDLINK_ABI_DEPENDS.tiff+= tiff>=3.7.2nb1
4706 BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff
4708 .include "../../devel/zlib/buildlink3.mk"
4709 .include "../../graphics/jpeg/buildlink3.mk"
4710 .endif # TIFF_BUILDLINK3_MK
4712 BUILDLINK_TREE+= -tiff
4714 The header and footer manipulate BUILDLINK_TREE, which is common across all
4715 buildlink3.mk files and is used to track the dependency tree.
4717 The main section is protected from multiple inclusion and controls how the
4718 dependency on pkg is added. Several important variables are set in the section:
4720 * BUILDLINK_API_DEPENDS.pkg is the actual dependency recorded in the
4721 installed package; this should always be set using += to ensure that we're
4722 appending to any pre-existing list of values. This variable should be set
4723 to the first version of the package that had an API change.
4725 * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory.
4727 * BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
4728 BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
4729 is selected by setting BUILDLINK_DEPMETHOD.pkg to "build". By default, the
4730 full dependency is used.
4732 * BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS.pkg (not shown above) are lists
4733 of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and
4734 library search paths. These default to "include" and "lib" respectively.
4736 * BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags
4737 to add to CPPFLAGS, which are passed on to the configure and build phases.
4738 The "-I" option should be avoided and instead be handled using
4739 BUILDLINK_INCDIRS.pkg as above.
4741 The following variables are all optionally defined within this second section
4742 (protected against multiple inclusion) and control which package files are
4743 symlinked into ${BUILDLINK_DIR} and how their names are transformed during the
4746 * BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to $
4747 {BUILDLINK_PREFIX.pkg} to be symlinked into ${BUILDLINK_DIR}, e.g. include/
4750 * BUILDLINK_FILES_CMD.pkg (not shown above) is a shell pipeline that outputs
4751 to stdout a list of files relative to ${BUILDLINK_PREFIX.pkg}. The
4752 resulting files are to be symlinked into ${BUILDLINK_DIR}. By default, this
4753 takes the +CONTENTS of a pkg and filters it through $
4754 {BUILDLINK_CONTENTS_FILTER.pkg}.
4756 * BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that
4757 filters +CONTENTS input into a list of files relative to $
4758 {BUILDLINK_PREFIX.pkg} on stdout. By default for overwrite packages,
4759 BUILDLINK_CONTENTS_FILTER.pkg outputs the contents of the include and lib
4760 directories in the package +CONTENTS, and for pkgviews packages, it outputs
4761 any libtool archives in lib directories.
4763 * BUILDLINK_FNAME_TRANSFORM.pkg (not shown above) is a list of sed arguments
4764 used to transform the name of the source filename into a destination
4765 filename, e.g. -e "s|/curses.h|/ncurses.h|g".
4767 This section can additionally include any buildlink3.mk needed for pkg's
4768 library dependencies. Including these buildlink3.mk files means that the
4769 headers and libraries for these dependencies are also symlinked into $
4770 {BUILDLINK_DIR} whenever the pkg buildlink3.mk file is included. Dependencies
4771 are only added for directly include buildlink3.mk files.
4773 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
4775 The situation that requires increasing the dependency listed in
4776 BUILDLINK_API_DEPENDS.pkg after a package update is when the API or interface
4777 to the header files change.
4779 In this case, BUILDLINK_API_DEPENDS.pkg should be adjusted to require at least
4780 the new package version. In some cases, the packages that depend on this new
4781 version may need their PKGREVISIONs increased and, if they have buildlink3.mk
4782 files, their BUILDLINK_API_DEPENDS.pkg adjusted, too. This is needed so pkgsrc
4783 will require the correct package dependency and not settle for an older one
4784 when building the source.
4786 BUILDLINK_ABI_DEPENDS.pkg should be increased when the binary interface or
4787 sonames (major number of the library version) of any installed shared libraries
4788 change. This is needed so that binary packages made using it will require the
4789 correct package dependency and not settle for an older one which will not
4790 contain the necessary shared libraries.
4792 See Section 19.1.6, "Handling dependencies" for more information about
4793 dependencies on other packages, including the BUILDLINK_ABI_DEPENDS and
4794 ABI_DEPENDS definitions.
4796 Please take careful consideration before adjusting BUILDLINK_API_DEPENDS.pkg or
4797 BUILDLINK_ABI_DEPENDS.pkg as we don't want to cause unneeded package deletions
4798 and rebuilds. In many cases, new versions of packages work just fine with older
4801 Also it is not needed to set BUILDLINK_ABI_DEPENDS.pkg when it is identical to
4802 BUILDLINK_API_DEPENDS.pkg.
4804 14.3. Writing builtin.mk files
4806 Some packages in pkgsrc install headers and libraries that coincide with
4807 headers and libraries present in the base system. Aside from a buildlink3.mk
4808 file, these packages should also include a builtin.mk file that includes the
4809 necessary checks to decide whether using the built-in software or the pkgsrc
4810 software is appropriate.
4812 The only requirements of a builtin.mk file for pkg are:
4814 1. It should set USE_BUILTIN.pkg to either "yes" or "no" after it is included.
4816 2. It should not override any USE_BUILTIN.pkg which is already set before the
4817 builtin.mk file is included.
4819 3. It should be written to allow multiple inclusion. This is very important
4820 and takes careful attention to Makefile coding.
4822 14.3.1. Anatomy of a builtin.mk file
4824 The following is the recommended template for builtin.mk files:
4826 .if !defined(IS_BUILTIN.foo)
4828 # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
4829 # genuinely exists in the system or not.
4833 # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
4834 # version can be determined.
4836 . if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
4837 BUILTIN_PKG.foo?= foo-1.0
4839 .endif # IS_BUILTIN.foo
4841 .if !defined(USE_BUILTIN.foo)
4842 USE_BUILTIN.foo?= ${IS_BUILTIN.foo}
4843 . if defined(BUILTIN_PKG.foo)
4844 . for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
4845 . if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
4847 ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo} \
4848 && ${ECHO} "yes" || ${ECHO} "no"
4852 .endif # USE_BUILTIN.foo
4854 CHECK_BUILTIN.foo?= no
4855 .if !empty(CHECK_BUILTIN.foo:M[nN][oO])
4857 # Here we place code that depends on whether USE_BUILTIN.foo is set to
4860 .endif # CHECK_BUILTIN.foo
4862 The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the
4863 base system. This should not be a base system software with similar
4864 functionality to pkg; it should only be "yes" if the actual package is included
4865 as part of the base system. This variable is only used internally within the
4868 The second section sets BUILTIN_PKG.pkg to the version of pkg in the base
4869 system if it exists (if IS_BUILTIN.pkg is "yes"). This variable is only used
4870 internally within the builtin.mk file.
4872 The third section sets USE_BUILTIN.pkg and is required in all builtin.mk files.
4873 The code in this section must make the determination whether the built-in
4874 software is adequate to satisfy the dependencies listed in
4875 BUILDLINK_API_DEPENDS.pkg. This is typically done by comparing BUILTIN_PKG.pkg
4876 against each of the dependencies in BUILDLINK_API_DEPENDS.pkg. USE_BUILTIN.pkg
4877 must be set to the correct value by the end of the builtin.mk file. Note that
4878 USE_BUILTIN.pkg may be "yes" even if IS_BUILTIN.pkg is "no" because we may make
4879 the determination that the built-in version of the software is similar enough
4880 to be used as a replacement.
4882 The last section is guarded by CHECK_BUILTIN.pkg, and includes code that uses
4883 the value of USE_BUILTIN.pkg set in the previous section. This typically
4884 includes, e.g., adding additional dependency restrictions and listing
4885 additional files to symlink into ${BUILDLINK_DIR} (via BUILDLINK_FILES.pkg).
4887 14.3.2. Global preferences for native or pkgsrc software
4889 When building packages, it's possible to choose whether to set a global
4890 preference for using either the built-in (native) version or the pkgsrc version
4891 of software to satisfy a dependency. This is controlled by setting
4892 PREFER_PKGSRC and PREFER_NATIVE. These variables take values of either "yes",
4893 "no", or a list of packages. PREFER_PKGSRC tells pkgsrc to use the pkgsrc
4894 versions of software, while PREFER_NATIVE tells pkgsrc to use the built-in
4895 versions. Preferences are determined by the most specific instance of the
4896 package in either PREFER_PKGSRC or PREFER_NATIVE. If a package is specified in
4897 neither or in both variables, then PREFER_PKGSRC has precedence over
4898 PREFER_NATIVE. For example, to require using pkgsrc versions of software for
4899 all but the most basic bits on a NetBSD system, you can set:
4902 PREFER_NATIVE= getopt skey tcp_wrappers
4904 A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise
4905 it is simply ignored in that list.
4907 Chapter 15. The pkginstall framework
4911 15.1. Files and directories outside the installation prefix
4913 15.1.1. Directory manipulation
4914 15.1.2. File manipulation
4916 15.2. Configuration files
4918 15.2.1. How PKG_SYSCONFDIR is set
4919 15.2.2. Telling the software where configuration files are
4920 15.2.3. Patching installations
4921 15.2.4. Disabling handling of configuration files
4923 15.3. System startup scripts
4925 15.3.1. Disabling handling of system startup scripts
4927 15.4. System users and groups
4930 15.5.1. Disabling shell registration
4934 15.6.1. Disabling automatic update of the fonts databases
4936 This chapter describes the framework known as pkginstall, whose key features
4939 * Generic installation and manipulation of directories and files outside the
4940 pkgsrc-handled tree, LOCALBASE.
4942 * Automatic handling of configuration files during installation, provided
4943 that packages are correctly designed.
4945 * Generation and installation of system startup scripts.
4947 * Registration of system users and groups.
4949 * Registration of system shells.
4951 * Automatic updating of fonts databases.
4953 The following sections inspect each of the above points in detail.
4955 You may be thinking that many of the things described here could be easily done
4956 with simple code in the package's post-installation target (post-install). This
4957 is incorrect, as the code in them is only executed when building from source.
4958 Machines using binary packages could not benefit from it at all (as the code
4959 itself could be unavailable). Therefore, the only way to achieve any of the
4960 items described above is by means of the installation scripts, which are
4961 automatically generated by pkginstall.
4963 15.1. Files and directories outside the installation prefix
4965 As you already know, the PLIST file holds a list of files and directories that
4966 belong to a package. The names used in it are relative to the installation
4967 prefix (${PREFIX}), which means that it cannot register files outside this
4968 directory (absolute path names are not allowed). Despite this restriction, some
4969 packages need to install files outside this location; e.g., under ${VARBASE} or
4970 ${PKG_SYSCONFDIR}. The only way to achieve this is to create such files during
4971 installation time by using installation scripts.
4973 The generic installation scripts are shell scripts that can contain arbitrary
4974 code. The list of scripts to execute is taken from the INSTALL_FILE variable,
4975 which defaults to INSTALL. A similar variable exists for package removal
4976 (DEINSTALL_FILE, whose default is DEINSTALL). These scripts can run arbitrary
4977 commands, so they have the potential to create and manage files anywhere in the
4980 Using these general installation files is not recommended, but may be needed in
4981 some special cases. One reason for avoiding them is that the user has to trust
4982 the packager that there is no unwanted or simply erroneous code included in the
4983 installation script. Also, previously there were many similar scripts for the
4984 same functionality, and fixing a common error involved finding and changing all
4987 The pkginstall framework offers another, standardized way. It provides generic
4988 scripts to abstract the manipulation of such files and directories based on
4989 variables set in the package's Makefile. The rest of this section describes
4992 15.1.1. Directory manipulation
4994 The following variables can be set to request the creation of directories
4995 anywhere in the file system:
4997 * MAKE_DIRS and OWN_DIRS contain a list of directories that should be created
4998 and should attempt to be destroyed by the installation scripts. The
4999 difference between the two is that the latter prompts the administrator to
5000 remove any directories that may be left after deinstallation (because they
5001 were not empty), while the former does not.
5003 * MAKE_DIRS_PERMS and OWN_DIRS_PERMS contain a list of tuples describing
5004 which directories should be created and should attempt to be destroyed by
5005 the installation scripts. Each tuple holds the following values, separated
5006 by spaces: the directory name, its owner, its group and its numerical mode.
5009 MAKE_DIRS_PERMS+= ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
5011 The difference between the two is exactly the same as their non-PERMS
5014 15.1.2. File manipulation
5016 Creating non-empty files outside the installation prefix is tricky because the
5017 PLIST forces all files to be inside it. To overcome this problem, the only
5018 solution is to extract the file in the known place (i.e., inside the
5019 installation prefix) and copy it to the appropriate location during
5020 installation (done by the installation scripts generated by pkginstall). We
5021 will call the former the master file in the following paragraphs, which
5022 describe the variables that can be used to automatically and consistently
5023 handle files outside the installation prefix:
5025 * CONF_FILES and SUPPORT_FILES are pairs of master and target files. During
5026 installation time, the master file is copied to the target one if and only
5027 if the latter does not exist. Upon deinstallation, the target file is
5028 removed provided that it was not modified by the installation.
5030 The difference between the two is that the latter prompts the administrator
5031 to remove any files that may be left after deinstallation (because they
5032 were not empty), while the former does not.
5034 * CONF_FILES_PERMS and SUPPORT_FILES_PERMS contain tuples describing master
5035 files as well as their target locations. For each of them, it also
5036 specifies their owner, their group and their numeric permissions, in this
5039 SUPPORT_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
5041 The difference between the two is exactly the same as their non-PERMS
5044 15.2. Configuration files
5046 Configuration files are special in the sense that they are installed in their
5047 own specific directory, PKG_SYSCONFDIR, and need special treatment during
5048 installation (most of which is automated by pkginstall). The main concept you
5049 must bear in mind is that files marked as configuration files are automatically
5050 copied to the right place (somewhere inside PKG_SYSCONFDIR) during installation
5051 if and only if they didn't exist before. Similarly, they will not be removed if
5052 they have local modifications. This ensures that administrators never lose any
5053 custom changes they may have made.
5055 15.2.1. How PKG_SYSCONFDIR is set
5057 As said before, the PKG_SYSCONFDIR variable specifies where configuration files
5058 shall be installed. Its contents are set based upon the following variables:
5060 * PKG_SYSCONFBASE: The configuration's root directory. Defaults to ${PREFIX}/
5061 etc although it may be overridden by the user to point to his preferred
5062 location (e.g., /etc, /etc/pkg, etc.). Packages must not use it directly.
5064 * PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the
5065 configuration files for the package being built shall be installed. The
5066 definition of this variable only makes sense in the package's Makefile
5067 (i.e., it is not user-customizable).
5069 As an example, consider the Apache package, www/apache2, which places its
5070 configuration files under the httpd/ subdirectory of PKG_SYSCONFBASE. This
5071 should be set in the package Makefile.
5073 * PKG_SYSCONFVAR: Specifies the name of the variable that holds this
5074 package's configuration directory (if different from PKG_SYSCONFBASE). It
5075 defaults to PKGBASE's value, and is always prefixed with PKG_SYSCONFDIR.
5077 * PKG_SYSCONFDIR.${PKG_SYSCONFVAR}: Holds the directory where the
5078 configuration files for the package identified by PKG_SYSCONFVAR's shall be
5081 Based on the above variables, pkginstall determines the value of
5082 PKG_SYSCONFDIR, which is the only variable that can be used within a package to
5083 refer to its configuration directory. The algorithm used to set its value is
5084 basically the following:
5086 1. If PKG_SYSCONFDIR.${PKG_SYSCONFVAR} is set, its value is used.
5088 2. If the previous variable is not defined but PKG_SYSCONFSUBDIR is set in the
5089 package's Makefile, the resulting value is ${PKG_SYSCONFBASE}/$
5090 {PKG_SYSCONFSUBDIR}.
5092 3. Otherwise, it is set to ${PKG_SYSCONFBASE}.
5094 It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
5095 OWN_DIRS. See Section 15.1.1, "Directory manipulation" what this means. This
5096 does not apply to subdirectories of ${PKG_SYSCONFDIR}, they still have to be
5097 created with OWN_DIRS or MAKE_DIRS.
5099 15.2.2. Telling the software where configuration files are
5101 Given that pkgsrc (and users!) expect configuration files to be in a known
5102 place, you need to teach each package where it shall install its files. In some
5103 cases you will have to patch the package Makefiles to achieve it. If you are
5104 lucky, though, it may be as easy as passing an extra flag to the configuration
5105 script; this is the case of GNU Autoconf- generated files:
5107 CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
5109 Note that this specifies where the package has to look for its configuration
5110 files, not where they will be originally installed (although the difference is
5111 never explicit, unfortunately).
5113 15.2.3. Patching installations
5115 As said before, pkginstall automatically handles configuration files. This
5116 means that the packages themselves must not touch the contents of $
5117 {PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts
5118 will, out of the box, mess with the contents of that directory. So what is the
5119 correct procedure to fix this issue?
5121 You must teach the package (usually by manually patching it) to install any
5122 configuration files under the examples hierarchy, share/examples/${PKGBASE}/.
5123 This way, the PLIST registers them and the administrator always has the
5124 original copies available.
5126 Once the required configuration files are in place (i.e., under the examples
5127 hierarchy), the pkginstall framework can use them as master copies during the
5128 package installation to update what is in ${PKG_SYSCONFDIR}. To achieve this,
5129 the variables CONF_FILES and CONF_FILES_PERMS are used. Check out
5130 Section 15.1.2, "File manipulation" for information about their syntax and
5131 their purpose. Here is an example, taken from the mail/mutt package:
5133 EGDIR= ${PREFIX}/share/doc/mutt/samples
5134 CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
5136 Note that the EGDIR variable is specific to that package and has no meaning
5139 15.2.4. Disabling handling of configuration files
5141 The automatic copying of config files can be toggled by setting the environment
5142 variable PKG_CONFIG prior to package installation.
5144 15.3. System startup scripts
5146 System startup scripts are special files because they must be installed in a
5147 place known by the underlying OS, usually outside the installation prefix.
5148 Therefore, the same rules described in Section 15.1, "Files and directories
5149 outside the installation prefix" apply, and the same solutions can be used.
5150 However, pkginstall provides a special mechanism to handle these files.
5152 In order to provide system startup scripts, the package has to:
5154 1. Store the script inside ${FILESDIR}, with the .sh suffix appended.
5155 Considering the print/cups package as an example, it has a cupsd.sh in its
5158 2. Tell pkginstall to handle it, appending the name of the script, without its
5159 extension, to the RCD_SCRIPTS variable. Continuing the previous example:
5163 Once this is done, pkginstall will do the following steps for each script in an
5166 1. Process the file found in the files directory applying all the
5167 substitutions described in the FILES_SUBST variable.
5169 2. Copy the script from the files directory to the examples hierarchy, $
5170 {PREFIX}/share/examples/rc.d/. Note that this master file must be
5171 explicitly registered in the PLIST.
5173 3. Add code to the installation scripts to copy the startup script from the
5174 examples hierarchy into the system-wide startup scripts directory.
5176 15.3.1. Disabling handling of system startup scripts
5178 The automatic copying of config files can be toggled by setting the environment
5179 variable PKG_RCD_SCRIPTS prior to package installation. Note that the scripts
5180 will be always copied inside the examples hierarchy, ${PREFIX}/share/examples/
5181 rc.d/, no matter what the value of this variable is.
5183 15.4. System users and groups
5185 If a package needs to create special users and/or groups during installation,
5186 it can do so by using the pkginstall framework.
5188 Users can be created by adding entries to the PKG_USERS variable. Each entry
5189 has the following syntax:
5193 Further specification of user details may be done by setting per-user
5194 variables. PKG_UID.user is the numeric UID for the user. PKG_GECOS.user is the
5195 user's description or comment. PKG_HOME.user is the user's home directory, and
5196 defaults to /nonexistent if not specified. PKG_SHELL.user is the user's shell,
5197 and defaults to /sbin/nologin if not specified.
5199 Similarly, groups can be created by adding entries to the PKG_GROUPS variable,
5204 The numeric GID of the group may be set by defining PKG_GID.group.
5206 If a package needs to create the users and groups at an earlier stage, then it
5207 can set USERGROUP_PHASE to either configure or build to indicate the phase
5208 before which the users and groups are created. In this case, the numeric UIDs
5209 and GIDs of the created users and groups are automatically hardcoded into the
5210 final installation scripts.
5214 Packages that install system shells should register them in the shell database,
5215 /etc/shells, to make things easier to the administrator. This must be done from
5216 the installation scripts to keep binary packages working on any system.
5217 pkginstall provides an easy way to accomplish this task.
5219 When a package provides a shell interpreter, it has to set the PKG_SHELL
5220 variable to its absolute file name. This will add some hooks to the
5221 installation scripts to handle it. Consider the following example, taken from
5224 PKG_SHELL= ${PREFIX}/bin/zsh
5226 15.5.1. Disabling shell registration
5228 The automatic registration of shell interpreters can be disabled by the
5229 administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.
5233 Packages that install X11 fonts should update the database files that index the
5234 fonts within each fonts directory. This can easily be accomplished within the
5235 pkginstall framework.
5237 When a package installs X11 fonts, it must list the directories in which fonts
5238 are installed in the FONTS_DIRS.type variables, where type can be one of "ttf",
5239 "type1" or "x11". This will add hooks to the installation scripts to run the
5240 appropriate commands to update the fonts database files within each of those
5241 directories. For convenience, if the directory path is relative, it is taken to
5242 be relative to the package's installation prefix. Consider the following
5243 example, taken from fonts/dbz-ttf:
5245 FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF
5247 15.6.1. Disabling automatic update of the fonts databases
5249 The automatic update of fonts databases can be disabled by the administrator by
5250 setting the PKG_UPDATE_FONTS_DB environment variable to NO.
5252 Chapter 16. Options handling
5256 16.1. Global default options
5257 16.2. Converting packages to use bsd.options.mk
5259 16.4. Determining the options of dependencies
5261 Many packages have the ability to be built to support different sets of
5262 features. bsd.options.mk is a framework in pkgsrc that provides generic
5263 handling of those options that determine different ways in which the packages
5264 can be built. It's possible for the user to specify exactly which sets of
5265 options will be built into a package or to allow a set of global default
5268 There are two broad classes of behaviors that one might want to control via
5269 options. One is whether some particular feature is enabled in a program that
5270 will be built anyway, often by including or not including a dependency on some
5271 other package. The other is whether or not an additional program will be built
5272 as part of the package. Generally, it is better to make a split package for
5273 such additional programs instead of using options, because it enables binary
5274 packages to be built which can then be added separately. For example, the foo
5275 package might have minimal dependencies (those packages without which foo
5276 doesn't make sense), and then the foo-gfoo package might include the GTK
5277 frontend program gfoo. This is better than including a gtk option to foo that
5278 adds gfoo, because either that option is default, in which case binary users
5279 can't get foo without gfoo, or not default, in which case they can't get gfoo.
5280 With split packages, they can install foo without having GTK, and later decide
5281 to install gfoo (pulling in GTK at that time). This is an advantage to source
5282 users too, avoiding the need for rebuilds.
5284 Plugins with widely varying dependencies should usually be split instead of
5287 It is often more work to maintain split packages, especially if the upstream
5288 package does not support this. The decision of split vs. option should be made
5289 based on the likelihood that users will want or object to the various pieces,
5290 the size of the dependencies that are included, and the amount of work.
5292 A further consideration is licensing. Non-free parts, or parts that depend on
5293 non-free dependencies (especially plugins) should almost always be split if
5296 16.1. Global default options
5298 Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of
5299 the options that should be built into every package if that option is
5300 supported. This variable should be set in mk.conf.
5302 16.2. Converting packages to use bsd.options.mk
5304 The following example shows how bsd.options.mk should be used by the
5305 hypothetical ``wibble'' package, either in the package Makefile, or in a file,
5306 e.g. options.mk, that is included by the main package Makefile.
5308 PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
5309 PKG_SUPPORTED_OPTIONS= wibble-foo ldap
5310 PKG_OPTIONS_OPTIONAL_GROUPS= database
5311 PKG_OPTIONS_GROUP.database= mysql pgsql
5312 PKG_SUGGESTED_OPTIONS= wibble-foo
5313 PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
5314 PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo
5316 .include "../../mk/bsd.prefs.mk"
5318 # this package was previously named wibble2
5319 .if defined(PKG_OPTIONS.wibble2)
5320 PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
5321 PKG_OPTIONS_DEPRECATED_WARNINGS+= \
5322 "Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR} instead."
5325 .include "../../mk/bsd.options.mk"
5327 # Package-specific option-handling
5332 .if !empty(PKG_OPTIONS:Mwibble-foo)
5333 CONFIGURE_ARGS+= --enable-foo
5339 .if !empty(PKG_OPTIONS:Mldap)
5340 . include "../../databases/openldap-client/buildlink3.mk"
5341 CONFIGURE_ARGS+= --enable-ldap=${BUILDLINK_PREFIX.openldap-client}
5345 ### database support
5347 .if !empty(PKG_OPTIONS:Mmysql)
5348 . include "../../mk/mysql.buildlink3.mk"
5350 .if !empty(PKG_OPTIONS:Mpgsql)
5351 . include "../../mk/pgsql.buildlink3.mk"
5354 The first section contains the information about which build options are
5355 supported by the package, and any default options settings if needed.
5357 1. PKG_OPTIONS_VAR is the name of the make(1) variable that the user can set
5358 to override the default options. It should be set to PKG_OPTIONS.pkgbase.
5359 Do not set it to PKG_OPTIONS.${PKGBASE}, since PKGBASE is not defined at
5360 the point where the options are processed.
5362 2. PKG_SUPPORTED_OPTIONS is a list of build options supported by the package.
5364 3. PKG_OPTIONS_OPTIONAL_GROUPS is a list of names of groups of mutually
5365 exclusive options. The options in each group are listed in
5366 PKG_OPTIONS_GROUP.groupname. The most specific setting of any option from
5367 the group takes precedence over all other options in the group. Options
5368 from the groups will be automatically added to PKG_SUPPORTED_OPTIONS.
5370 4. PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, but
5371 building the packages will fail if no option from the group is selected.
5373 5. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of options. At least
5374 one option from each set must be selected. The options in each set are
5375 listed in PKG_OPTIONS_SET.setname. Options from the sets will be
5376 automatically added to PKG_SUPPORTED_OPTIONS. Building the package will
5377 fail if no option from the set is selected.
5379 6. PKG_SUGGESTED_OPTIONS is a list of build options which are enabled by
5382 7. PKG_OPTIONS_LEGACY_VARS is a list of "USE_VARIABLE:option" pairs that map
5383 legacy mk.conf variables to their option counterparts. Pairs should be
5384 added with "+=" to keep the listing of global legacy variables. A warning
5385 will be issued if the user uses a legacy variable.
5387 8. PKG_OPTIONS_LEGACY_OPTS is a list of "old-option:new-option" pairs that map
5388 options that have been renamed to their new counterparts. Pairs should be
5389 added with "+=" to keep the listing of global legacy options. A warning
5390 will be issued if the user uses a legacy option.
5392 9. PKG_LEGACY_OPTIONS is a list of options implied by deprecated variables
5393 used. This can be used for cases that neither PKG_OPTIONS_LEGACY_VARS nor
5394 PKG_OPTIONS_LEGACY_OPTS can handle, e. g. when PKG_OPTIONS_VAR is renamed.
5396 10. PKG_OPTIONS_DEPRECATED_WARNINGS is a list of warnings about deprecated
5397 variables or options used, and what to use instead.
5399 A package should never modify PKG_DEFAULT_OPTIONS or the variable named in
5400 PKG_OPTIONS_VAR. These are strictly user-settable. To suggest a default set of
5401 options, use PKG_SUGGESTED_OPTIONS.
5403 PKG_OPTIONS_VAR must be defined before including bsd.options.mk. If none of
5404 PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, and
5405 PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform-specific
5406 options if none of them is supported on the current platform), PKG_OPTIONS is
5407 set to the empty list and the package is otherwise treated as not using the
5410 After the inclusion of bsd.options.mk, the variable PKG_OPTIONS contains the
5411 list of selected build options, properly filtered to remove unsupported and
5414 The remaining sections contain the logic that is specific to each option. The
5415 correct way to check for an option is to check whether it is listed in
5418 .if !empty(PKG_OPTIONS:Moption)
5422 Options that enable similar features in different packages (like optional
5423 support for a library) should use a common name in all packages that support it
5424 (like the name of the library). If another package already has an option with
5425 the same meaning, use the same name.
5427 Options that enable features specific to one package, where it's unlikely that
5428 another (unrelated) package has the same (or a similar) optional feature,
5429 should use a name prefixed with pkgname-.
5431 If a group of related packages share an optional feature specific to that
5432 group, prefix it with the name of the "main" package (e. g.
5433 djbware-errno-hack).
5435 For new options, add a line to mk/defaults/options.description. Lines have two
5436 fields, separated by tab. The first field is the option name, the second its
5437 description. The description should be a whole sentence (starting with an
5438 uppercase letter and ending with a period) that describes what enabling the
5439 option does. E. g. "Enable ispell support." The file is sorted by option names.
5441 16.4. Determining the options of dependencies
5443 When writing buildlink3.mk files, it is often necessary to list different
5444 dependencies based on the options with which the package was built. For
5445 querying these options, the file pkgsrc/mk/pkg-build-options.mk should be used.
5446 A typical example looks like this:
5448 pkgbase := libpurple
5449 .include "../../mk/pkg-build-options.mk"
5451 .if !empty(PKG_BUILD_OPTIONS.libpurple:Mdbus)
5455 Including pkg-build-options.mk here will set the variable
5456 PKG_BUILD_OPTIONS.libpurple to the build options of the libpurple package,
5457 which can then be queried like PKG_OPTIONS in the options.mk file. See the file
5458 pkg-build-options.mk for more details.
5460 Chapter 17. The build process
5465 17.2. Program location
5466 17.3. Directories used during the build process
5467 17.4. Running a phase
5468 17.5. The fetch phase
5470 17.5.1. What to fetch and where to get it from
5471 17.5.2. How are the files fetched?
5473 17.6. The checksum phase
5474 17.7. The extract phase
5475 17.8. The patch phase
5476 17.9. The tools phase
5477 17.10. The wrapper phase
5478 17.11. The configure phase
5479 17.12. The build phase
5480 17.13. The test phase
5481 17.14. The install phase
5482 17.15. The package phase
5484 17.17. Other helpful targets
5488 This chapter gives a detailed description on how a package is built. Building a
5489 package is separated into different phases (for example fetch, build, install),
5490 all of which are described in the following sections. Each phase is split into
5491 so-called stages, which take the name of the containing phase, prefixed by one
5492 of pre-, do- or post-. (Examples are pre-configure, post-build.) Most of the
5493 actual work is done in the do-* stages.
5495 Never override the regular targets (like fetch), if you have to, override the
5498 The basic steps for building a program are always the same. First the program's
5499 source (distfile) must be brought to the local system and then extracted. After
5500 any pkgsrc-specific patches to compile properly are applied, the software can
5501 be configured, then built (usually by compiling), and finally the generated
5502 binaries, etc. can be put into place on the system.
5504 To get more details about what is happening at each step, you can set the
5505 PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in
5506 more details about the patch step.
5508 17.2. Program location
5510 Before outlining the process performed by the NetBSD package system in the next
5511 section, here's a brief discussion on where programs are installed, and which
5512 variables influence this.
5514 The automatic variable PREFIX indicates where all files of the final program
5515 shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
5516 pkgs in the cross category. The value of PREFIX needs to be put into the
5517 various places in the program's source where paths to these files are encoded.
5518 See Section 11.3, "patches/*" and Section 19.3.1, "Shared libraries - libtool"
5521 When choosing which of these variables to use, follow the following rules:
5523 * PREFIX always points to the location where the current pkg will be
5524 installed. When referring to a pkg's own installation path, use "${PREFIX}
5527 * LOCALBASE is where all non-X11 pkgs are installed. If you need to construct
5528 a -I or -L argument to the compiler to find includes and libraries
5529 installed by another non-X11 pkg, use "${LOCALBASE}". The name LOCALBASE
5530 stems from FreeBSD, which installed all packages in /usr/local. As pkgsrc
5531 leaves /usr/local for the system administrator, this variable is a
5534 * X11BASE is where the actual X11 distribution (from xsrc, etc.) is
5535 installed. When looking for standard X11 includes (not those installed by a
5536 package), use "${X11BASE}".
5538 * X11-based packages are special in that they may be installed in either
5539 X11BASE or LOCALBASE.
5541 Usually, X11 packages should be installed under LOCALBASE whenever
5542 possible. Note that you will need to include ../../mk/x11.buildlink3.mk in
5543 them to request the presence of X11 and to get the right compilation flags.
5545 Even though, there are some packages that cannot be installed under
5546 LOCALBASE: those that come with app-defaults files. These packages are
5547 special and they must be placed under X11BASE. To accomplish this, set
5548 either USE_X11BASE or USE_IMAKE in your package.
5550 Some notes: If you need to find includes or libraries installed by a pkg
5551 that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in
5552 both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages
5553 in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default.
5555 * X11PREFIX should be used to refer to the installed location of an X11
5556 package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed,
5557 and to LOCALBASE if xpkgwedge is installed.
5559 * If xpkgwedge is installed, it is possible to have some packages installed
5560 in X11BASE and some in LOCALBASE. To determine the prefix of an installed
5561 package, the EVAL_PREFIX definition can be used. It takes pairs in the
5562 format "DIRNAME=<package>", and the make(1) variable DIRNAME will be set to
5563 the prefix of the installed package <package>, or "${X11PREFIX}" if the
5564 package is not installed.
5566 This is best illustrated by example.
5568 The following lines are taken from pkgsrc/wm/scwm/Makefile:
5570 EVAL_PREFIX+= GTKDIR=gtk+
5571 CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q}
5572 CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q}
5573 CONFIGURE_ARGS+= --enable-multibyte
5575 Specific defaults can be defined for the packages evaluated using
5576 EVAL_PREFIX, by using a definition of the form:
5578 GTKDIR_DEFAULT= ${LOCALBASE}
5580 where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair.
5582 * Within ${PREFIX}, packages should install files according to hier(7), with
5583 the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
5586 17.3. Directories used during the build process
5588 When building a package, various directories are used to store source files,
5589 temporary files, pkgsrc-internal files, and so on. These directories are
5592 Some of the directory variables contain relative pathnames. There are two
5593 common base directories for these relative directories: PKGSRCDIR/PKGPATH is
5594 used for directories that are pkgsrc-specific. WRKSRC is used for directories
5595 inside the package itself.
5599 This is an absolute pathname that points to the pkgsrc root directory.
5600 Generally, you don't need it.
5604 This is an absolute pathname that points to the current package.
5608 This is a pathname relative to PKGSRCDIR that points to the current
5613 This is an absolute pathname pointing to the directory where all work takes
5614 place. The distfiles are extracted to this directory. It also contains
5615 temporary directories and log files used by the various pkgsrc frameworks,
5616 like buildlink or the wrappers.
5620 This is an absolute pathname pointing to the directory where the distfiles
5621 are extracted. It is usually a direct subdirectory of WRKDIR, and often
5622 it's the only directory entry that isn't hidden. This variable may be
5623 changed by a package Makefile.
5625 The CREATE_WRKDIR_SYMLINK definition takes either the value yes or no and
5626 defaults to no. It indicates whether a symbolic link to the WRKDIR is to be
5627 created in the pkgsrc entry's directory. If users would like to have their
5628 pkgsrc trees behave in a read-only manner, then the value of
5629 CREATE_WRKDIR_SYMLINK should be set to no.
5631 17.4. Running a phase
5633 You can run a particular phase by typing make phase, where phase is the name of
5634 the phase. This will automatically run all phases that are required for this
5635 phase. The default phase is build, that is, when you run make without
5636 parameters in a package directory, the package will be built, but not
5639 17.5. The fetch phase
5641 The first step in building a package is to fetch the distribution files
5642 (distfiles) from the sites that are providing them. This is the task of the
5645 17.5.1. What to fetch and where to get it from
5647 In simple cases, MASTER_SITES defines all URLs from where the distfile, whose
5648 name is derived from the DISTNAME variable, is fetched. The more complicated
5649 cases are described below.
5651 The variable DISTFILES specifies the list of distfiles that have to be fetched.
5652 Its value defaults to ${DISTNAME}${EXTRACT_SUFX}, so that most packages don't
5653 need to define it at all. EXTRACT_SUFX is .tar.gz by default, but can be
5654 changed freely. Note that if your package requires additional distfiles to the
5655 default one, you cannot just append the additional filenames using the +=
5656 operator, but you have write for example:
5658 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
5660 Each distfile is fetched from a list of sites, usually MASTER_SITES. If the
5661 package has multiple DISTFILES or multiple PATCHFILES from different sites, you
5662 can set SITES.distfile to the list of URLs where the file distfile (including
5663 the suffix) can be found.
5665 DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
5666 DISTFILES+= foo-file.tar.gz
5667 SITES.foo-file.tar.gz= \
5668 http://www.somewhere.com/somehow/ \
5669 http://www.somewhereelse.com/mirror/somehow/
5671 When actually fetching the distfiles, each item from MASTER_SITES or SITES.*
5672 gets the name of each distfile appended to it, without an intermediate slash.
5673 Therefore, all site values have to end with a slash or other separator
5674 character. This allows for example to set MASTER_SITES to a URL of a CGI script
5675 that gets the name of the distfile as a parameter. In this case, the definition
5678 MASTER_SITES= http://www.example.com/download.cgi?file=
5680 The exception to this rule are URLs starting with a dash. In that case the URL
5681 is taken as is, fetched and the result stored under the name of the distfile.
5683 There are some predefined values for MASTER_SITES, which can be used in
5684 packages. The names of the variables should speak for themselves.
5686 ${MASTER_SITE_APACHE}
5687 ${MASTER_SITE_BACKUP}
5688 ${MASTER_SITE_CYGWIN}
5689 ${MASTER_SITE_DEBIAN}
5690 ${MASTER_SITE_FREEBSD}
5691 ${MASTER_SITE_FREEBSD_LOCAL}
5692 ${MASTER_SITE_GENTOO}
5693 ${MASTER_SITE_GNOME}
5695 ${MASTER_SITE_GNUSTEP}
5696 ${MASTER_SITE_IFARCHIVE}
5698 ${MASTER_SITE_MOZILLA}
5699 ${MASTER_SITE_MYSQL}
5700 ${MASTER_SITE_OPENOFFICE}
5701 ${MASTER_SITE_PERL_CPAN}
5702 ${MASTER_SITE_PGSQL}
5703 ${MASTER_SITE_R_CRAN}
5704 ${MASTER_SITE_SOURCEFORGE}
5705 ${MASTER_SITE_SOURCEFORGE_JP}
5706 ${MASTER_SITE_SUNSITE}
5708 ${MASTER_SITE_TEX_CTAN}
5709 ${MASTER_SITE_XCONTRIB}
5710 ${MASTER_SITE_XEMACS}
5712 Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP
5713 contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org/
5714 pub/NetBSD/packages/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local
5715 package source distributions that are maintained in ftp://ftp.NetBSD.org/pub/
5716 NetBSD/packages/distfiles/LOCAL_PORTS/.
5718 If you choose one of these predefined sites, you may want to specify a
5719 subdirectory of that site. Since these macros may expand to more than one
5720 actual site, you must use the following construct to specify a subdirectory:
5722 MASTER_SITES= ${MASTER_SITE_GNU:=subdirectory/name/}
5723 MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=project_name/}
5725 Note the trailing slash after the subdirectory name.
5727 17.5.2. How are the files fetched?
5729 The fetch phase makes sure that all the distfiles exist in a local directory
5730 (DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they
5731 are fetched using commands of the form
5733 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
5735 where ${site} varies through several possibilities in turn: first,
5736 MASTER_SITE_OVERRIDE is tried, then the sites specified in either SITES.file if
5737 defined, else MASTER_SITES or PATCH_SITES, as applies, then finally the value
5738 of MASTER_SITE_BACKUP. The order of all except the first and the last can be
5739 optionally sorted by the user, via setting either MASTER_SORT_RANDOM, and
5740 MASTER_SORT_AWK or MASTER_SORT_REGEX.
5742 The specific command and arguments used depend on the FETCH_USING parameter.
5743 The example above is for FETCH_USING=custom.
5745 The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles
5746 target to mirror the distfiles, if they are freely distributable. Packages
5747 setting NO_SRC_ON_FTP (usually to "${RESTRICTED}") will not have their
5750 17.6. The checksum phase
5752 After the distfile(s) are fetched, their checksum is generated and compared
5753 with the checksums stored in the distinfo file. If the checksums don't match,
5754 the build is aborted. This is to ensure the same distfile is used for building,
5755 and that the distfile wasn't changed, e.g. by some malign force, deliberately
5756 changed distfiles on the master distribution site or network lossage.
5758 17.7. The extract phase
5760 When the distfiles are present on the local system, they need to be extracted,
5761 as they usually come in the form of some compressed archive format.
5763 By default, all DISTFILES are extracted. If you only need some of them, you can
5764 set the EXTRACT_ONLY variable to the list of those files.
5766 Extracting the files is usually done by a little program, mk/extract/extract,
5767 which already knows how to extract various archive formats, so most likely you
5768 will not need to change anything here. But if you need, the following variables
5771 EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}
5773 Use these variables to override the default options for an extract command,
5774 which are defined in mk/extract/extract.
5778 This variable can be set to bsdtar, gtar, nbtar (which is the default
5779 value), pax, or an absolute pathname pointing to the command with which tar
5780 archives should be extracted. It is preferred to choose bsdtar over gtar if
5781 NetBSD's pax-as-tar is not good enough.
5783 If the extract program doesn't serve your needs, you can also override the
5784 EXTRACT_CMD variable, which holds the command used for extracting the files.
5785 This command is executed in the ${WRKSRC} directory. During execution of this
5786 command, the shell variable extract_file holds the absolute pathname of the
5787 file that is going to be extracted.
5789 And if that still does not suffice, you can override the do-extract target in
5790 the package Makefile.
5792 17.8. The patch phase
5794 After extraction, all the patches named by the PATCHFILES, those present in the
5795 patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
5796 /usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz
5797 are uncompressed before they are applied, files ending in .orig or .rej are
5798 ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See
5799 Section 11.3, "patches/*" for more details.
5801 By default patch(1) is given special args to make it fail if the patches apply
5802 with some lines of fuzz. Please fix (regen) the patches so that they apply
5803 cleanly. The rationale behind this is that patches that don't apply cleanly may
5804 end up being applied in the wrong place, and cause severe harm there.
5806 17.9. The tools phase
5808 This is covered in Chapter 18, Tools needed for building or running.
5810 17.10. The wrapper phase
5812 This phase creates wrapper programs for the compilers and linkers. The
5813 following variables can be used to tweak the wrappers.
5817 The command used to print progress messages. Does nothing by default. Set
5818 to ${ECHO} to see the progress messages.
5822 This variable can be set to yes (default) or no, depending on whether you
5823 want additional information in the wrapper log file.
5825 WRAPPER_UPDATE_CACHE
5827 This variable can be set to yes or no, depending on whether the wrapper
5828 should use its cache, which will improve the speed. The default value is
5829 yes, but is forced to no if the platform does not support it.
5831 WRAPPER_REORDER_CMDS
5833 A list of reordering commands. A reordering command has the form reorder:l:
5834 lib1:lib2. It ensures that that -llib1 occurs before -llib2.
5836 WRAPPER_TRANSFORM_CMDS
5838 A list of transformation commands. [TODO: investigate further]
5840 17.11. The configure phase
5842 Most pieces of software need information on the header files, system calls, and
5843 library routines which are available on the platform they run on. The process
5844 of determining this information is known as configuration, and is usually
5845 automated. In most cases, a script is supplied with the distfiles, and its
5846 invocation results in generation of header files, Makefiles, etc.
5848 If the package contains a configure script, this can be invoked by setting
5849 HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you
5850 should set GNU_CONFIGURE to "yes" instead. What happens in the configure phase
5853 .for d in ${CONFIGURE_DIRS}
5856 && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
5859 CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In
5860 each of these directories, the configure script is run with the environment
5861 CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV,
5862 CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed
5865 If the program uses an Imakefile for configuration, the appropriate steps can
5866 be invoked by setting USE_IMAKE to "yes". (If you only want the package
5867 installed in ${X11PREFIX} but xmkmf not being run, set USE_X11BASE instead.)
5868 You can add variables to xmkmf's environment by adding them to the SCRIPTS_ENV
5871 If the program uses cmake for configuration, the appropriate steps can be
5872 invoked by setting USE_CMAKE to "yes". You can add variables to cmake's
5873 environment by adding them to the CONFIGURE_ENV variable and arguments to cmake
5874 by adding them to the CMAKE_ARGS variable. The top directory argument is given
5875 by the CMAKE_ARG_PATH variable, that defaults to "." (relative to
5878 If there is no configure step at all, set NO_CONFIGURE to "yes".
5880 17.12. The build phase
5882 For building a package, a rough equivalent of the following code is executed.
5884 .for d in ${BUILD_DIRS}
5887 && env ${MAKE_ENV} \
5888 ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \
5893 BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of
5894 these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and
5895 arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE
5896 and BUILD_TARGET may all be changed by the package.
5898 The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake",
5899 "make" otherwise. The default value of MAKE_FILE is "Makefile", and
5900 BUILD_TARGET defaults to "all".
5902 If there is no build step at all, set NO_BUILD to "yes".
5904 17.13. The test phase
5908 17.14. The install phase
5910 Once the build stage has completed, the final step is to install the software
5911 in public directories, so users can access the programs and files.
5913 In the install phase, a rough equivalent of the following code is executed.
5914 Additionally, before and after this code, much magic is performed to do
5915 consistency checks, registering the package, and so on.
5917 .for d in ${INSTALL_DIRS}
5920 && env ${MAKE_ENV} \
5921 ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \
5926 The variable's meanings are analogous to the ones in the build phase.
5927 INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is "install" by default,
5928 plus "install.man" if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
5931 In the install phase, the following variables are useful. They are all
5932 variations of the install(1) command that have the owner, group and permissions
5933 preset. INSTALL is the plain install command. The specialized variants,
5934 together with their intended use, are:
5938 directories that contain binaries
5942 directories that contain scripts
5946 directories that contain shared and static libraries
5950 directories that contain data files
5954 directories that contain man pages
5958 binaries that can be stripped from debugging symbols
5962 binaries that cannot be stripped
5970 shared and static libraries
5978 data files for games
5984 Some other variables are:
5988 A list of directories relative to PREFIX that are created by pkgsrc at the
5989 beginning of the install phase. The package is supposed to create all
5990 needed directories itself before installing files to it and list all other
5993 In the rare cases that a package shouldn't install anything, set NO_INSTALL to
5994 "yes". This is mostly relevant for packages in the regress category.
5996 17.15. The package phase
5998 Once the install stage has completed, a binary package of the installed files
5999 can be built. These binary packages can be used for quick installation without
6000 previous compilation, e.g. by the make bin-install or by using pkg_add.
6002 By default, the binary packages are created in ${PACKAGES}/All and symlinks are
6003 created in ${PACKAGES}/category, one for each category in the CATEGORIES
6004 variable. PACKAGES defaults to pkgsrc/packages.
6008 Once you're finished with a package, you can clean the work directory by
6009 running make clean. If you want to clean the work directories of all
6010 dependencies too, use make clean-depends.
6012 17.17. Other helpful targets
6016 For any of the main targets described in the previous section, two
6017 auxiliary targets exist with "pre-" and "post-" used as a prefix for the
6018 main target's name. These targets are invoked before and after the main
6019 target is called, allowing extra configuration or installation steps be
6020 performed from a package's Makefile, for example, which a program's
6021 configure script or install target omitted.
6025 Should one of the main targets do the wrong thing, and should there be no
6026 variable to fix this, you can redefine it with the do-* target. (Note that
6027 redefining the target itself instead of the do-* target is a bad idea, as
6028 the pre-* and post-* targets won't be called anymore, etc.) You will not
6029 usually need to do this.
6033 If you did a make install and you noticed some file was not installed
6034 properly, you can repeat the installation with this target, which will
6035 ignore the "already installed" flag.
6037 This is the default value of DEPENDS_TARGET except in the case of make
6038 update and make package, where the defaults are "package" and "update",
6043 This target does a pkg_delete(1) in the current directory, effectively
6044 de-installing the package. The following variables can be used to tune the
6049 Add a "-v" to the pkg_delete(1) command.
6053 Remove all packages that require (depend on) the given package. This
6054 can be used to remove any packages that may have been pulled in by a
6055 given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
6056 pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding
6057 "-R" to the pkg_delete(1) command line.
6061 Install a binary package from local disk and via FTP from a list of sites
6062 (see the BINPKG_SITES variable), and do a make package if no binary package
6063 is available anywhere. The arguments given to pkg_add can be set via
6064 BIN_INSTALL_FLAGS e.g., to do verbose operation, etc.
6068 This target causes the current package to be updated to the latest version.
6069 The package and all depending packages first get de-installed, then current
6070 versions of the corresponding packages get compiled and installed. This is
6071 similar to manually noting which packages are currently installed, then
6072 performing a series of make deinstall and make install (or whatever
6073 UPDATE_TARGET is set to) for these packages.
6075 You can use the "update" target to resume package updating in case a
6076 previous make update was interrupted for some reason. However, in this
6077 case, make sure you don't call make clean or otherwise remove the list of
6078 dependent packages in WRKDIR. Otherwise, you lose the ability to
6079 automatically update the current package along with the dependent packages
6082 Resuming an interrupted make update will only work as long as the package
6083 tree remains unchanged. If the source code for one of the packages to be
6084 updated has been changed, resuming make update will most certainly fail!
6086 The following variables can be used either on the command line or in
6087 mk.conf to alter the behaviour of make update:
6091 Install target to recursively use for the updated package and the
6092 dependent packages. Defaults to DEPENDS_TARGET if set, "install"
6093 otherwise for make update. Other good targets are "package" or
6094 "bin-install". Do not set this to "update" or you will get stuck in an
6099 Don't clean up after updating. Useful if you want to leave the work
6100 sources of the updated packages around for inspection or other
6101 purposes. Be sure you eventually clean up the source tree (see the
6102 "clean-update" target below) or you may run into troubles with old
6103 source code still lying around on your next make or make update.
6107 Deinstall each package before installing (making DEPENDS_TARGET). This
6108 may be necessary if the "clean-update" target (see below) was called
6109 after interrupting a running make update.
6113 Allows you to disable recursion and hardcode the target for packages.
6114 The default is "update" for the update target, facilitating a recursive
6115 update of prerequisite packages. Only set DEPENDS_TARGET if you want to
6116 disable recursive updates. Use UPDATE_TARGET instead to just set a
6117 specific target for each package to be installed during make update
6122 Clean the source tree for all packages that would get updated if make
6123 update was called from the current directory. This target should not be
6124 used if the current package (or any of its depending packages) have already
6125 been de-installed (e.g., after calling make update) or you may lose some
6126 packages you intended to update. As a rule of thumb: only use this target
6127 before the first time you run make update and only if you have a dirty
6128 package tree (e.g., if you used NOCLEAN).
6130 If you are unsure about whether your tree is clean, you can either perform
6131 a make clean at the top of the tree, or use the following sequence of
6132 commands from the directory of the package you want to update (before
6133 running make update for the first time, otherwise you lose all the packages
6134 you wanted to update!):
6137 # make clean CLEANDEPENDS=YES
6141 The following variables can be used either on the command line or in
6142 mk.conf to alter the behaviour of make clean-update:
6146 After make clean, do not reconstruct the list of directories to update
6147 for this package. Only use this if make update successfully installed
6148 all packages you wanted to update. Normally, this is done automatically
6149 on make update, but may have been suppressed by the NOCLEAN variable
6154 Update the installation of the current package. This differs from update in
6155 that it does not replace dependent packages. You will need to install
6156 pkgtools/pkg_tarup for this target to work.
6158 Be careful when using this target! There are no guarantees that dependent
6159 packages will still work, in particular they will most certainly break if
6160 you make replace a library package whose shared library major version
6161 changed between your installed version and the new one. For this reason,
6162 this target is not officially supported and only recommended for advanced
6167 This target invokes pkg_info(1) for the current package. You can use this
6168 to check which version of a package is installed.
6172 This is a top-level command, i.e. it should be used in the pkgsrc
6173 directory. It creates a database of all packages in the local pkgsrc tree,
6174 including dependencies, comment, maintainer, and some other useful
6175 information. Individual entries are created by running make describe in the
6176 packages' directories. This index file is saved as pkgsrc/INDEX. It can be
6177 displayed in verbose format by running make print-index. You can search in
6178 it with make search key=something. You can extract a list of all packages
6179 that depend on a particular one by running make show-deps PKG=somepackage.
6181 Running this command takes a very long time, some hours even on fast
6186 This target generates a README.html file, which can be viewed using a
6187 browser such as www/firefox or www/links. The generated files contain
6188 references to any packages which are in the PACKAGES directory on the local
6189 host. The generated files can be made to refer to URLs based on
6190 FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate
6191 README.html files which pointed to binary packages on the local machine, in
6192 the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
6193 FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
6194 subdirectories will be searched for all the binary packages.
6196 The target can be run at the toplevel or in category directories, in which
6197 case it descends recursively.
6201 This is a top-level command, run it in pkgsrc. Use this target to create a
6202 file README-all.html which contains a list of all packages currently
6203 available in the NetBSD Packages Collection, together with the category
6204 they belong to and a short description. This file is compiled from the
6205 pkgsrc/*/README.html files, so be sure to run this after a make readme.
6209 This is very much the same as the "readme" target (see above), but is to be
6210 used when generating a pkgsrc tree to be written to a CD-ROM. This target
6211 also produces README.html files, and can be made to refer to URLs based on
6212 CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
6216 This target shows which distfiles and patchfiles are needed to build the
6217 package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not
6222 This target shows nothing if the package is not installed. If a version of
6223 this package is installed, but is not the version provided in this version
6224 of pkgsrc, then a warning message is displayed. This target can be used to
6225 show which of your installed packages are downlevel, and so the old
6226 versions can be deleted, and the current ones added.
6230 This target shows the directory in the pkgsrc hierarchy from which the
6231 package can be built and installed. This may not be the same directory as
6232 the one from which the package was installed. This target is intended to be
6233 used by people who may wish to upgrade many packages on a single host, and
6234 can be invoked from the top-level pkgsrc Makefile by using the
6235 "show-host-specific-pkgs" target.
6237 show-installed-depends
6239 This target shows which installed packages match the current package's
6240 DEPENDS. Useful if out of date dependencies are causing build problems.
6244 After a package is installed, check all its binaries and (on ELF platforms)
6245 shared libraries to see if they find the shared libs they need. Run by
6246 default if PKG_DEVELOPER is set in mk.conf.
6250 After a "make install" from a new or upgraded pkg, this prints out an
6251 attempt to generate a new PLIST from a find -newer work/.extract_done. An
6252 attempt is made to care for shared libs etc., but it is strongly
6253 recommended to review the result before putting it into PLIST. On upgrades,
6254 it's useful to diff the output of this command against an already existing
6257 If the package installs files via tar(1) or other methods that don't update
6258 file access times, be sure to add these files manually to your PLIST, as
6259 the "find -newer" command used by this target won't catch them!
6261 See Section 13.3, "Tweaking output of make print-PLIST" for more
6262 information on this target.
6266 Used to do bulk builds. If an appropriate binary package already exists, no
6267 action is taken. If not, this target will compile, install and package it
6268 (and its depends, if PKG_DEPENDS is set properly. See Section 7.3.1,
6269 "Configuration"). After creating the binary package, the sources, the
6270 just-installed package and its required packages are removed, preserving
6273 Beware that this target may deinstall all packages installed on a system!
6277 Used during bulk-installs to install required packages. If an up-to-date
6278 binary package is available, it will be installed via pkg_add(1). If not,
6279 make bulk-package will be executed, but the installed binary won't be
6282 A binary package is considered "up-to-date" to be installed via pkg_add(1)
6285 * None of the package's files (Makefile, ...) were modified since it was
6288 * None of the package's required (binary) packages were modified since it
6291 Beware that this target may deinstall all packages installed on a system!
6293 Chapter 18. Tools needed for building or running
6297 18.1. Tools for pkgsrc builds
6298 18.2. Tools needed by packages
6299 18.3. Tools provided by platforms
6300 18.4. Questions regarding the tools
6302 The USE_TOOLS definition is used both internally by pkgsrc and also for
6303 individual packages to define what commands are needed for building a package
6304 (like BUILD_DEPENDS) or for later run-time of an installed packaged (such as
6305 DEPENDS). If the native system provides an adequate tool, then in many cases, a
6306 pkgsrc package will not be used.
6308 When building a package, the replacement tools are made available in a
6309 directory (as symlinks or wrapper scripts) that is early in the executable
6310 search path. Just like the buildlink system, this helps with consistent builds.
6312 A tool may be needed to help build a specific package. For example, perl, GNU
6313 make (gmake) or yacc may be needed.
6315 Also a tool may be needed, for example, because the native system's supplied
6316 tool may be inefficient for building a package with pkgsrc. For example, a
6317 package may need GNU awk, bison (instead of yacc) or a better sed.
6319 The tools used by a package can be listed by running make show-tools.
6321 18.1. Tools for pkgsrc builds
6323 The default set of tools used by pkgsrc is defined in bsd.pkg.mk. This includes
6324 standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be
6325 seen by running: make show-var VARNAME=USE_TOOLS.
6327 If a package needs a specific program to build then the USE_TOOLS variable can
6328 be used to define the tools needed.
6330 18.2. Tools needed by packages
6332 In the following examples, the :pkgsrc means to use the pkgsrc version and not
6333 the native version for a build dependency. And the :run means that it is used
6334 for a run-time dependencies also (and becomes a DEPENDS). The default is a
6335 build dependency which can be set with :build. (So in this example, it is the
6336 same as gmake:build and pkg-config:build.)
6338 USE_TOOLS+= mktemp:pkgsrc
6339 USE_TOOLS+= gmake perl:run pkg-config
6341 When using the tools framework, a TOOLS_PATH.foo variable is defined which
6342 contains the full path to the appropriate tool. For example, TOOLS_PATH.bash
6343 could be "/bin/bash" on Linux systems.
6345 If you always need a pkgsrc version of the tool at run-time, then just use
6348 18.3. Tools provided by platforms
6350 When improving or porting pkgsrc to a new platform, have a look at (or create)
6351 the corresponding platform specific make file fragment under pkgsrc/mk/tools/
6352 tools.${OPSYS}.mk which defines the name of the common tools. For example:
6354 .if exists(/usr/bin/bzcat)
6355 TOOLS_PLATFORM.bzcat?= /usr/bin/bzcat
6356 .elif exists(/usr/bin/bzip2)
6357 TOOLS_PLATFORM.bzcat?= /usr/bin/bzip2 -cd
6360 TOOLS_PLATFORM.true?= true # shell builtin
6362 18.4. Questions regarding the tools
6364 18.4.1. How do I add a new tool?
6365 18.4.2. How do I get a list of all available tools?
6366 18.4.3. How can I get a list of all the tools that a package is using while
6367 being built? I want to know whether it uses sed or not.
6369 18.4.1. How do I add a new tool?
6373 18.4.2. How do I get a list of all available tools?
6377 18.4.3. How can I get a list of all the tools that a package is using while
6378 being built? I want to know whether it uses sed or not.
6380 Currently, you can't. (TODO: But I want to be able to do it.)
6382 Chapter 19. Making your package work
6386 19.1. General operation
6388 19.1.1. Portability of packages
6389 19.1.2. How to pull in user-settable variables from ???
6390 19.1.3. User interaction
6391 19.1.4. Handling licenses
6392 19.1.5. Restricted packages
6393 19.1.6. Handling dependencies
6394 19.1.7. Handling conflicts with other packages
6395 19.1.8. Packages that cannot or should not be built
6396 19.1.9. Packages which should not be deleted, once installed
6397 19.1.10. Handling packages with security problems
6398 19.1.11. How to handle incrementing versions when fixing an existing
6400 19.1.12. Substituting variable text in the package files (the SUBST
6403 19.2. Fixing problems in the fetch phase
6405 19.2.1. Packages whose distfiles aren't available for plain downloading
6406 19.2.2. How to handle modified distfiles with the 'old' name
6408 19.3. Fixing problems in the configure phase
6410 19.3.1. Shared libraries - libtool
6411 19.3.2. Using libtool on GNU packages that already support libtool
6412 19.3.3. GNU Autoconf/Automake
6414 19.4. Programming languages
6416 19.4.1. C, C++, and Fortran
6418 19.4.3. Packages containing perl scripts
6419 19.4.4. Other programming languages
6421 19.5. Fixing problems in the build phase
6423 19.5.1. Compiling C and C++ code conditionally
6424 19.5.2. How to handle compiler bugs
6425 19.5.3. Undefined reference to ...
6426 19.5.4. Running out of memory
6428 19.6. Fixing problems in the install phase
6430 19.6.1. Creating needed directories
6431 19.6.2. Where to install documentation
6432 19.6.3. Installing highscore files
6433 19.6.4. Adding DESTDIR support to packages
6434 19.6.5. Packages with hardcoded paths to other interpreters
6435 19.6.6. Packages installing perl modules
6436 19.6.7. Packages installing info files
6437 19.6.8. Packages installing man pages
6438 19.6.9. Packages installing GConf data files
6439 19.6.10. Packages installing scrollkeeper/rarian data files
6440 19.6.11. Packages installing X11 fonts
6441 19.6.12. Packages installing GTK2 modules
6442 19.6.13. Packages installing SGML or XML data
6443 19.6.14. Packages installing extensions to the MIME database
6444 19.6.15. Packages using intltool
6445 19.6.16. Packages installing startup scripts
6446 19.6.17. Packages installing TeX modules
6447 19.6.18. Packages supporting running binaries in emulation
6448 19.6.19. Packages installing hicolor theme icons
6449 19.6.20. Packages installing desktop files
6451 19.7. Marking packages as having problems
6453 19.1. General operation
6455 19.1.1. Portability of packages
6457 One appealing feature of pkgsrc is that it runs on many different platforms. As
6458 a result, it is important to ensure, where possible, that packages in pkgsrc
6459 are portable. This chapter mentions some particular details you should pay
6460 attention to while working on pkgsrc.
6462 19.1.2. How to pull in user-settable variables from mk.conf
6464 The pkgsrc user can configure pkgsrc by overriding several variables in the
6465 file pointed to by MAKECONF, which is mk.conf by default. When you want to use
6466 those variables in the preprocessor directives of make(1) (for example .if or
6467 .for), you need to include the file ../../mk/bsd.prefs.mk before, which in turn
6468 loads the user preferences.
6470 But note that some variables may not be completely defined after ../../mk/
6471 bsd.prefs.mk has been included, as they may contain references to variables
6472 that are not yet defined. In shell commands this is no problem, since variables
6473 are actually macros, which are only expanded when they are used. But in the
6474 preprocessor directives mentioned above and in dependency lines (of the form
6475 target: dependencies) the variables are expanded at load time.
6479 Currently there is no exhaustive list of all variables that tells you whether
6480 they can be used at load time or only at run time, but it is in preparation.
6482 19.1.3. User interaction
6484 Occasionally, packages require interaction from the user, and this can be in a
6487 * When fetching the distfiles, some packages require user interaction such as
6488 entering username/password or accepting a license on a web page.
6490 * When extracting the distfiles, some packages may ask for passwords.
6492 * help to configure the package before it is built
6494 * help during the build process
6496 * help during the installation of a package
6498 The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of
6499 an interactive stage which will be needed, and this should be set in the
6500 package's Makefile, e.g.:
6502 INTERACTIVE_STAGE= build
6505 Multiple interactive stages can be specified:
6507 INTERACTIVE_STAGE= configure install
6510 The user can then decide to skip this package by setting the BATCH variable.
6512 19.1.4. Handling licenses
6514 Authors of software can choose the licence under which software can be copied.
6515 This is due to copyright law, and reasons for license choices are outside the
6516 scope of pkgsrc. The pkgsrc system recognizes that there are a number of
6517 licenses which some users may find objectionable or difficult or impossible to
6518 comply with. The Free Software Foundation has declared some licenses "Free",
6519 and the Open Source Initiative has a definition of "Open Source". The pkgsrc
6520 system, as a policy choice, does not label packages which have licenses that
6521 are Free or Open Source. However, packages without a license meeting either of
6522 those tests are labeled with a license tag denoting the license. Note that a
6523 package with no license to copy trivially does not meet either the Free or Open
6526 For packages which are not Free or Open Source, pkgsrc will not build the
6527 package unless the user has indicated to pkgsrc that packages with that
6528 particular license may be built. Note that this documentation avoids the term
6529 "accepted the license". The pkgsrc system is merely providing a mechanism to
6530 avoid accidentally building a package with a non-free license; judgement and
6531 responsibility remain with the user. (Installation of binary packages are not
6532 currently subject to this mechanism; this is a bug.)
6534 One might want to only install packages with a BSD license, or the GPL, and not
6535 the other. The free licenses are added to the default ACCEPTABLE_LICENSES
6536 variable. The user can override the default by setting the ACCEPTABLE_LICENSES
6537 variable with "=" instead of "+=". The licenses accepted by default are:
6540 gnu-gpl-v2 gnu-lgpl-v2
6541 gnu-gpl-v3 gnu-lgpl-v3
6542 original-bsd modified-bsd
6549 The license tag mechanism is intended to address copyright-related issues
6550 surrounding building, installing and using a package, and not to address
6551 redistribution issues (see RESTRICTED and NO_SRC_ON_FTP, etc.). Packages with
6552 redistribution restrictions should set these tags.
6554 Denoting that a package may be copied according to a particular license is done
6555 by placing the license in pkgsrc/licenses and setting the LICENSE variable to a
6556 string identifying the license, e.g. in graphics/xv:
6561 When trying to build, the user will get a notice that the package is covered by
6562 a license which has not been placed in the ACCEPTABLE_LICENSES variable:
6565 ===> xv-3.10anb9 has an unacceptable license: xv-license.
6566 ===> To view the license, enter "/usr/bin/make show-license".
6567 ===> To indicate acceptance, add this line to your /etc/mk.conf:
6568 ===> ACCEPTABLE_LICENSES+=xv-license
6572 The license can be viewed with make show-license, and if the user so chooses,
6573 the line printed above can be added to mk.conf to convey to pkgsrc that it
6574 should not in the future fail because of that license:
6576 ACCEPTABLE_LICENSES+=xv-license
6579 When adding a package with a new license, the license text should be added to
6580 pkgsrc/licenses for displaying. A list of known licenses can be seen in this
6583 When the license changes (in a way other than formatting), please make sure
6584 that the new license has a different name (e.g., append the version number if
6585 it exists, or the date). Just because a user told pkgsrc to build programs
6586 under a previous version of a license does not mean that pkgsrc should build
6587 programs under the new licenses. The higher-level point is that pkgsrc does not
6588 evaluate licenses for reasonableness; the only test is a mechanistic test of
6589 whether a particular text has been approved by either of two bodies.
6591 The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar language
6592 is deprecated because it does not crisply refer to a particular license text.
6593 Another problem with such usage is that it does not enable a user to tell
6594 pkgsrc to proceed for a single package without also telling pkgsrc to proceed
6595 for all packages with that tag.
6597 19.1.5. Restricted packages
6599 Some licenses restrict how software may be re-distributed. Because a license
6600 tag is required unless the package is Free or Open Source, all packages with
6601 restrictions should have license tags. By declaring the restrictions, package
6602 tools can automatically refrain from e.g. placing binary packages on FTP sites.
6604 There are four restrictions that may be encoded, which are the cross product of
6605 sources (distfiles) and binaries not being placed on FTP sites and CD-ROMs.
6606 Because this is rarely the exact language in any license, and because non-Free
6607 licenses tend to be different from each other, pkgsrc adopts a definition of
6608 FTP and CD-ROM. Pkgsrc uses "FTP" to mean that the source or binary file should
6609 not be made available over the Internet at no charge. Pkgsrc uses "CD-ROM" to
6610 mean that the source or binary may not be made available on some kind of media,
6611 together with other source and binary packages, and which is sold for a
6612 distribution charge.
6614 In order to encode these restrictions, the package system defines five make
6615 variables that can be set to note these restrictions:
6619 This variable should be set whenever a restriction exists (regardless of
6620 its kind). Set this variable to a string containing the reason for the
6621 restriction. It should be understood that those wanting to understand the
6622 restriction will have to read the license, and perhaps seek advice of
6627 Binaries may not be placed on CD-ROM containing other binary packages, for
6628 which a distribution charge may be made. In this case, set this variable to
6633 Binaries may not made available on the Internet without charge. In this
6634 case, set this variable to ${RESTRICTED}. If this variable is set, binary
6635 packages will not be included on ftp.NetBSD.org.
6639 Distfiles may not be placed on CD-ROM, together with other distfiles, for
6640 which a fee may be charged. In this case, set this variable to $
6645 Distfiles may not made available via FTP at no charge. In this case, set
6646 this variable to ${RESTRICTED}. If this variable is set, the distfile(s)
6647 will not be mirrored on ftp.NetBSD.org.
6649 19.1.6. Handling dependencies
6651 Your package may depend on some other package being present - and there are
6652 various ways of expressing this dependency. pkgsrc supports the BUILD_DEPENDS
6653 and DEPENDS definitions, the USE_TOOLS definition, as well as dependencies via
6654 buildlink3.mk, which is the preferred way to handle dependencies, and which
6655 uses the variables named above. See Chapter 14, Buildlink methodology for more
6658 The basic difference between the two variables is as follows: The DEPENDS
6659 definition registers that pre-requisite in the binary package so it will be
6660 pulled in when the binary package is later installed, whilst the BUILD_DEPENDS
6661 definition does not, marking a dependency that is only needed for building the
6664 This means that if you only need a package present whilst you are building, it
6665 should be noted as a BUILD_DEPENDS.
6667 The format for a BUILD_DEPENDS and a DEPENDS definition is:
6669 <pre-req-package-name>:../../<category>/<pre-req-package>
6672 Please note that the "pre-req-package-name" may include any of the wildcard
6673 version numbers recognized by pkg_info(1).
6675 1. If your package needs another package's binaries or libraries to build or
6676 run, and if that package has a buildlink3.mk file available, use it:
6678 .include "../../graphics/jpeg/buildlink3.mk"
6681 2. If your package needs to use another package to build itself and there is
6682 no buildlink3.mk file available, use the BUILD_DEPENDS definition:
6684 BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
6687 3. If your package needs a library with which to link and again there is no
6688 buildlink3.mk file available, this is specified using the DEPENDS
6689 definition. For example:
6691 DEPENDS+= xpm-3.4j:../../graphics/xpm
6694 You can also use wildcards in package dependencies:
6696 DEPENDS+= xpm-[0-9]*:../../graphics/xpm
6699 Note that such wildcard dependencies are retained when creating binary
6700 packages. The dependency is checked when installing the binary package and
6701 any package which matches the pattern will be used. Wildcard dependencies
6702 should be used with care.
6704 The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
6705 matches such as "tk-postgresql" matching a "tk-*" DEPENDS.
6707 Wildcards can also be used to specify that a package will only build
6708 against a certain minimum version of a pre-requisite:
6710 DEPENDS+= tiff>=3.5.4:../../graphics/tiff
6713 This means that the package will build against version 3.5.4 of the tiff
6714 library or newer. Such a dependency may be warranted if, for example, the
6715 API of the library has changed with version 3.5.4 and a package would not
6716 compile against an earlier version of tiff.
6718 Please note that such dependencies should only be updated if a package
6719 requires a newer pre-requisite, but not to denote recommendations such as
6720 ABI changes that do not prevent a package from building correctly. Such
6721 recommendations can be expressed using ABI_DEPENDS:
6723 ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff
6726 In addition to the above DEPENDS line, this denotes that while a package
6727 will build against tiff>=3.5.4, at least version 3.6.1 is recommended.
6728 ABI_DEPENDS entries will be turned into dependencies unless explicitly
6729 ignored (in which case a warning will be printed).
6731 To ignore these ABI dependency recommendations and just use the required
6732 DEPENDS, set USE_ABI_DEPENDS=NO. This may make it easier and faster to
6733 update packages built using pkgsrc, since older compatible dependencies can
6734 continue to be used. This is useful for people who watch their rebuilds
6735 very carefully; it is not very good as a general-purpose hammer. If you use
6736 it, you need to be mindful of possible ABI changes, including those from
6739 Packages that are built with recommendations ignored may not be uploaded to
6740 ftp.NetBSD.org by developers and should not be used across different
6741 systems that may have different versions of binary packages installed.
6743 For security fixes, please update the package vulnerabilities file. See
6744 Section 19.1.10, "Handling packages with security problems" for more
6747 4. If your package needs some executable to be able to run correctly and if
6748 there's no buildlink3.mk file, this is specified using the DEPENDS
6749 variable. The print/lyx package needs to be able to execute the latex
6750 binary from the teTeX package when it runs, and that is specified:
6752 DEPENDS+= teTeX-[0-9]*:../../print/teTeX
6755 The comment about wildcard dependencies from previous paragraph applies
6758 If your package needs files from another package to build, add the relevant
6759 distribution files to DISTFILES, so they will be extracted automatically. See
6760 the print/ghostscript package for an example. (It relies on the jpeg sources
6761 being present in source form during the build.)
6763 19.1.7. Handling conflicts with other packages
6765 Your package may conflict with other packages a user might already have
6766 installed on his system, e.g. if your package installs the same set of files as
6767 another package in the pkgsrc tree.
6769 In this case you can set CONFLICTS to a space-separated list of packages
6770 (including version string) your package conflicts with.
6772 For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus
6773 you set in pkgsrc/x11/Xaw3d/Makefile:
6775 CONFLICTS= Xaw-Xpm-[0-9]*
6778 and in pkgsrc/x11/Xaw-Xpm/Makefile:
6780 CONFLICTS= Xaw3d-[0-9]*
6783 Packages will automatically conflict with other packages with the name prefix
6784 and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
6785 with the older version "Xaw3d-1.3".
6787 19.1.8. Packages that cannot or should not be built
6789 There are several reasons why a package might be instructed to not build under
6790 certain circumstances. If the package builds and runs on most platforms, the
6791 exceptions should be noted with NOT_FOR_PLATFORM. If the package builds and
6792 runs on a small handful of platforms, set ONLY_FOR_PLATFORM instead. Both
6793 ONLY_FOR_PLATFORM and NOT_FOR_PLATFORM are OS triples (OS-version-platform)
6794 that can use glob-style wildcards.
6796 Some packages are tightly bound to a specific version of an operating system,
6797 e.g. LKMs or sysutils/lsof. Such binary packages are not backwards compatible
6798 with other versions of the OS, and should be uploaded to a version specific
6799 directory on the FTP server. Mark these packages by setting OSVERSION_SPECIFIC
6800 to "yes". This variable is not currently used by any of the package system
6801 internals, but may be used in the future.
6803 If the package should be skipped (for example, because it provides
6804 functionality already provided by the system), set PKG_SKIP_REASON to a
6805 descriptive message. If the package should fail because some preconditions are
6806 not met, set PKG_FAIL_REASON to a descriptive message.
6808 19.1.9. Packages which should not be deleted, once installed
6810 To ensure that a package may not be deleted, once it has been installed, the
6811 PKG_PRESERVE definition should be set in the package Makefile. This will be
6812 carried into any binary package that is made from this pkgsrc entry. A
6813 "preserved" package will not be deleted using pkg_delete(1) unless the "-f"
6816 19.1.10. Handling packages with security problems
6818 When a vulnerability is found, this should be noted in localsrc/security/
6819 advisories/pkg-vulnerabilities, and after committing that file, use make upload
6820 in the same directory to update the file on ftp.NetBSD.org.
6822 After fixing the vulnerability by a patch, its PKGREVISION should be increased
6823 (this is of course not necessary if the problem is fixed by using a newer
6824 release of the software).
6826 Also, if the fix should be applied to the stable pkgsrc branch, be sure to
6827 submit a pullup request!
6829 Binary packages already on ftp.NetBSD.org will be handled semi-automatically by
6832 19.1.11. How to handle incrementing versions when fixing an existing package
6834 When making fixes to an existing package it can be useful to change the version
6835 number in PKGNAME. To avoid conflicting with future versions by the original
6836 author, a "nb1", "nb2", ... suffix can be used on package versions by setting
6837 PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools.
6844 will result in a PKGNAME of "foo-17.42nb9". If you want to use the original
6845 value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use
6848 When a new release of the package is released, the PKGREVISION should be
6849 removed, e.g. on a new minor release of the above package, things should be
6855 PKGREVISION should be incremented for any non-trivial change in the resulting
6856 binary package. Without a PKGREVISION bump, someone with the previous version
6857 installed has no way of knowing that their package is out of date. Thus,
6858 changes without increasing PKGREVISION are essentially labeled "this is so
6859 trivial that no reasonable person would want to upgrade", and this is the rough
6860 test for when increasing PKGREVISION is appropriate. Examples of changes that
6861 do not merit increasing PKGREVISION are:
6863 * Changing HOMEPAGE, MAINTAINER, OWNER, or comments in Makefile.
6865 * Changing build variables if the resulting binary package is the same.
6869 * Adding PKG_OPTIONS if the default options don't change.
6871 Examples of changes that do merit an increase to PKGREVISION include:
6875 * Changes or additions to a patch file
6877 * Changes to the PLIST
6879 * A dependency is changed or renamed.
6881 PKGREVISION must also be incremented when dependencies have ABI changes.
6883 19.1.12. Substituting variable text in the package files (the SUBST framework)
6885 When you want to replace the same text in multiple files or when the
6886 replacement text varies, patches alone cannot help. This is where the SUBST
6887 framework comes in. It provides an easy-to-use interface for replacing text in
6890 SUBST_CLASSES+= fix-paths
6891 SUBST_STAGE.fix-paths= pre-configure
6892 SUBST_MESSAGE.fix-paths= Fixing absolute paths.
6893 SUBST_FILES.fix-paths= src/*.c
6894 SUBST_FILES.fix-paths+= scripts/*.sh
6895 SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g'
6896 SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g'
6899 SUBST_CLASSES is a list of identifiers that are used to identify the different
6900 SUBST blocks that are defined. The SUBST framework is heavily used by pkgsrc,
6901 so it is important to always use the += operator with this variable. Otherwise
6902 some substitutions may be skipped.
6904 The remaining variables of each SUBST block are parameterized with the
6905 identifier from the first line (fix-paths in this case.) They can be seen as
6906 parameters to a function call.
6908 SUBST_STAGE.* specifies the stage at which the replacement will take place. All
6909 combinations of pre-, do- and post- together with a phase name are possible,
6910 though only few are actually used. Most commonly used are post-patch and
6911 pre-configure. Of these two, pre-configure should be preferred because then it
6912 is possible to run bmake patch and have the state after applying the patches
6913 but before making any other changes. This is especially useful when you are
6914 debugging a package in order to create new patches for it. Similarly,
6915 post-build is preferred over pre-install, because the install phase should
6916 generally be kept as simple as possible. When you use post-build, you have the
6917 same files in the working directory that will be installed later, so you can
6918 check if the substitution has succeeded.
6920 SUBST_MESSAGE.* is an optional text that is printed just before the
6921 substitution is done.
6923 SUBST_FILES.* is the list of shell globbing patterns that specifies the files
6924 in which the substitution will take place. The patterns are interpreted
6925 relatively to the WRKSRC directory.
6927 SUBST_SED.* is a list of arguments to sed(1) that specify the actual
6928 substitution. Every sed command should be prefixed with -e, so that all SUBST
6929 blocks look uniform.
6931 There are some more variables, but they are so seldomly used that they are only
6932 documented in the mk/subst.mk file.
6934 19.2. Fixing problems in the fetch phase
6936 19.2.1. Packages whose distfiles aren't available for plain downloading
6938 If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
6939 a make fetch will call files/getsite.sh with the name of each file to download
6940 as an argument, expecting it to output the URL of the directory from which to
6941 download it. graphics/ns-cult3d is an example of this usage.
6943 If the download can't be automated, because the user must submit personal
6944 information to apply for a password, or must pay for the source, or whatever,
6945 you can set FETCH_MESSAGE to a list of lines that are displayed to the user
6946 before aborting the build. Example:
6948 FETCH_MESSAGE= "Please download the files"
6949 FETCH_MESSAGE+= " "${DISTFILES:Q}
6950 FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
6953 19.2.2. How to handle modified distfiles with the 'old' name
6955 Sometimes authors of a software package make some modifications after the
6956 software was released, and they put up a new distfile without changing the
6957 package's version number. If a package is already in pkgsrc at that time, the
6958 checksum will no longer match. The contents of the new distfile should be
6959 compared against the old one before changing anything, to make sure the
6960 distfile was really updated on purpose, and that no trojan horse or so crept
6961 in. Please mention that the distfiles were compared and what was found in your
6962 commit message. Then, the correct way to work around this is to set DIST_SUBDIR
6963 to a unique directory name, usually based on PKGNAME_NOREV. All DISTFILES and
6964 PATCHFILES for this package will be put in that subdirectory of the local
6965 distfiles directory. (See Section 19.1.11, "How to handle incrementing versions
6966 when fixing an existing package" for more details.) In case this happens more
6967 often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can
6968 be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget regenerating the
6969 distinfo file after that, since it contains the DIST_SUBDIR path in the
6970 filenames. Also increase the PKGREVISION if the installed package is different.
6971 Furthermore, a mail to the package's authors seems appropriate telling them
6972 that changing distfiles after releases without changing the file names is not
6975 19.3. Fixing problems in the configure phase
6977 19.3.1. Shared libraries - libtool
6979 pkgsrc supports many different machines, with different object formats like
6980 a.out and ELF, and varying abilities to do shared library and dynamic loading
6981 at all. To accompany this, varying commands and options have to be passed to
6982 the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
6983 especially if you don't have all the machines at your hand to test things. The
6984 devel/libtool pkg can help here, as it just "knows" how to build both static
6985 and dynamic libraries from a set of source files, thus being
6986 platform-independent.
6988 Here's how to use libtool in a package in seven simple steps:
6990 1. Add USE_LIBTOOL=yes to the package Makefile.
6992 2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
6993 {CC}". You could even add it to the definition of CC, if only libraries are
6994 being built in a given Makefile. This one command will build both PIC and
6995 non-PIC library objects, so you need not have separate shared and
6996 non-shared library rules.
6998 3. For the linking of the library, remove any "ar", "ranlib", and "ld
6999 -Bshareable" commands, and instead use:
7001 ${LIBTOOL} --mode=link \
7002 ${CC} -o ${.TARGET:.a=.la} \
7004 -rpath ${PREFIX}/lib \
7005 -version-info major:minor
7008 Note that the library is changed to have a .la extension, and the objects
7009 are changed to have a .lo extension. Change OBJS as necessary. This
7010 automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
7011 necessary) in the build directory. Be sure to include "-version-info",
7012 especially when major and minor are zero, as libtool will otherwise strip
7013 off the shared library version.
7015 From the libtool manual:
7017 So, libtool library versions are described by three integers:
7020 The most recent interface number that this library implements.
7023 The implementation number of the CURRENT interface.
7026 The difference between the newest and oldest interfaces that
7027 this library implements. In other words, the library implements
7028 all the interface numbers in the range from number `CURRENT -
7031 If two libraries have identical CURRENT and AGE numbers, then the
7032 dynamic linker chooses the library with the greater REVISION number.
7035 The "-release" option will produce different results for a.out and ELF
7036 (excluding symlinks) in only one case. An ELF library of the form
7037 "libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
7038 platform. This is handled automatically.
7040 The "-rpath argument" is the install directory of the library being built.
7042 In the PLIST, include only the .la file, the other files will be added
7045 4. When linking shared object (.so) files, i.e. files that are loaded via
7046 dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
7047 them getting version tacked on.
7049 The PLIST file gets the foo.so entry.
7051 5. When linking programs that depend on these libraries before they are
7052 installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
7053 and it will find the correct libraries (static or shared), but please be
7054 aware that libtool will not allow you to specify a relative path in -L
7055 (such as "-L../somelib"), because it expects you to change that argument to
7056 be the .la file. e.g.
7058 ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
7061 should be changed to:
7063 ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
7066 and it will do the right thing with the libraries.
7068 6. When installing libraries, preface the install(1) or cp(1) command with "$
7069 {LIBTOOL} --mode=install", and change the library name to .la. e.g.
7071 ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
7074 This will install the static .a, shared library, any needed symlinks, and
7077 7. In your PLIST, include only the .la file (this is a change from previous
7080 19.3.2. Using libtool on GNU packages that already support libtool
7082 Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
7083 own libtool in most cases. For older libtool using packages, libtool is made by
7084 ltconfig script during the do-configure step; you can check the libtool script
7085 location by doing make configure; find work*/ -name libtool.
7087 LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
7088 override. By default, it is set to "libtool */libtool */*/libtool". If this
7089 does not match the location of the package's libtool script(s), set it as
7092 If you do not need *.a static libraries built and installed, then use
7093 SHLIBTOOL_OVERRIDE instead.
7095 If your package makes use of the platform-independent library for loading
7096 dynamic shared objects, that comes with libtool (libltdl), you should include
7097 devel/libltdl/buildlink3.mk.
7099 Some packages use libtool incorrectly so that the package may not work or build
7100 in some circumstances. Some of the more common errors are:
7102 * The inclusion of a shared object (-module) as a dependent library in an
7103 executable or library. This in itself isn't a problem if one of two things
7106 1. The shared object is named correctly, i.e. libfoo.la, not foo.la
7108 2. The -dlopen option is used when linking an executable.
7110 * The use of libltdl without the correct calls to initialisation routines.
7111 The function lt_dlinit() should be called and the macro
7112 LTDL_SET_PRELOADED_SYMBOLS included in executables.
7114 19.3.3. GNU Autoconf/Automake
7116 If a package needs GNU autoconf or automake to be executed to regenerate the
7117 configure script and Makefile.in makefile templates, then they should be
7118 executed in a pre-configure target.
7120 For packages that need only autoconf:
7122 AUTOCONF_REQD= 2.50 # if default version is not good enough
7123 USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13
7127 cd ${WRKSRC} && autoconf
7132 and for packages that need automake and autoconf:
7134 AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
7135 USE_TOOLS+= automake # use "automake14" for automake-1.4
7139 set -e; cd ${WRKSRC}; \
7140 aclocal; autoheader; automake -a --foreign -i; autoconf
7145 Packages which use GNU Automake will almost certainly require GNU Make.
7147 There are times when the configure process makes additional changes to the
7148 generated files, which then causes the build process to try to re-execute the
7149 automake sequence. This is prevented by touching various files in the configure
7150 stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
7151 NO in the package Makefile.
7153 19.4. Programming languages
7155 19.4.1. C, C++, and Fortran
7157 Compilers for the C, C++, and Fortran languages comes with the NetBSD base
7158 system. By default, pkgsrc assumes that a package is written in C and will hide
7159 all other compilers (via the wrapper framework, see Chapter 14, Buildlink
7162 To declare which language's compiler a package needs, set the USE_LANGUAGES
7163 variable. Allowed values currently are "c", "c++", and "fortran" (and any
7164 combination). The default is "c". Packages using GNU configure scripts, even if
7165 written in C++, usually need a C compiler for the configure phase.
7169 If a program is written in Java, use the Java framework in pkgsrc. The package
7170 must include ../../mk/java-vm.mk. This Makefile fragment provides the following
7173 * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is
7174 set to "run", then there is only a runtime dependency on the JDK. The
7175 default is "yes", which also adds a build dependency on the JDK.
7177 * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The
7178 supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2
7179 implementation, "1.4" insists on versions 1.4 or above, and "1.5" only
7180 accepts versions 1.5 or above. This variable is not set by default.
7182 19.4.3. Packages containing perl scripts
7184 If your package contains interpreted perl scripts, add "perl" to the USE_TOOLS
7185 variable and set REPLACE_PERL to ensure that the proper interpreter path is
7186 set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that
7187 you want adjusted. Every occurrence of */bin/perl will be replaced with the
7188 full path to the perl executable.
7190 If a particular version of perl is needed, set the PERL5_REQD variable to the
7191 version number. The default is "5.0".
7193 See Section 19.6.6, "Packages installing perl modules" for information about
7194 handling perl modules.
7196 19.4.4. Other programming languages
7198 Currently, there is no special handling for other languages in pkgsrc. If a
7199 compiler package provides a buildlink3.mk file, include that, otherwise just
7200 add a (build) dependency on the appropriate compiler package.
7202 19.5. Fixing problems in the build phase
7204 The most common failures when building a package are that some platforms do not
7205 provide certain header files, functions or libraries, or they provide the
7206 functions in a library that the original package author didn't know. To work
7207 around this, you can rewrite the source code in most cases so that it does not
7208 use the missing functions or provides a replacement function.
7210 19.5.1. Compiling C and C++ code conditionally
7212 If a package already comes with a GNU configure script, the preferred way to
7213 fix the build failure is to change the configure script, not the code. In the
7214 other cases, you can utilize the C preprocessor, which defines certain macros
7215 depending on the operating system and hardware architecture it compiles for.
7216 These macros can be queried using for example #if defined(__i386). Almost every
7217 operating system, hardware architecture and compiler has its own macro. For
7218 example, if the macros __GNUC__, __i386__ and __NetBSD__ are all defined, you
7219 know that you are using NetBSD on an i386 compatible CPU, and your compiler is
7222 The list of the following macros for hardware and operating system depends on
7223 the compiler that is used. For example, if you want to conditionally compile
7224 code on Solaris, don't use __sun__, as the SunPro compiler does not define it.
7227 19.5.1.1. C preprocessor macros to identify the operating system
7229 To distinguish between 4.4 BSD-derived systems and the rest of the world, you
7230 should use the following code.
7232 #include <sys/param.h>
7233 #if (defined(BSD) && BSD >= 199306)
7234 /* BSD-specific code goes here */
7236 /* non-BSD-specific code goes here */
7239 If this distinction is not fine enough, you can also test for the following
7243 DragonFly __DragonFly__
7245 IRIX __sgi (TODO: get a definite source for this)
7246 Linux linux, __linux, __linux__
7251 19.5.1.2. C preprocessor macros to identify the hardware architecture
7253 i386 i386, __i386, __i386__
7255 SPARC sparc, __sparc
7257 19.5.1.3. C preprocessor macros to identify the compiler
7259 GCC __GNUC__ (major version), __GNUC_MINOR__
7260 MIPSpro _COMPILER_VERSION (0x741 for MIPSpro 7.41)
7261 SunPro __SUNPRO_C (0x570 for Sun C 5.7)
7262 SunPro C++ __SUNPRO_CC (0x580 for Sun C++ 5.8)
7264 19.5.2. How to handle compiler bugs
7266 Some source files trigger bugs in the compiler, based on combinations of
7267 compiler version and architecture and almost always relation to optimisation
7268 being enabled. Common symptoms are gcc internal errors or never finishing
7271 Typically, a workaround involves testing the MACHINE_ARCH and compiler version,
7272 disabling optimisation for that combination of file, MACHINE_ARCH and compiler,
7273 and documenting it in pkgsrc/doc/HACKS. See that file for a number of examples.
7275 19.5.3. Undefined reference to "..."
7277 This error message often means that a package did not link to a shared library
7278 it needs. The following functions are known to cause this error message over
7281 +-----------------------------------------------------+
7282 | Function |Library |Affected platforms|
7283 |-------------------------+--------+------------------|
7284 |accept, bind, connect |-lsocket|Solaris |
7285 |-------------------------+--------+------------------|
7286 |crypt |-lcrypt |DragonFly, NetBSD |
7287 |-------------------------+--------+------------------|
7288 |dlopen, dlsym |-ldl |Linux |
7289 |-------------------------+--------+------------------|
7290 |gethost* |-lnsl |Solaris |
7291 |-------------------------+--------+------------------|
7292 |inet_aton |-lresolv|Solaris |
7293 |-------------------------+--------+------------------|
7294 |nanosleep, sem_*, timer_*|-lrt |Solaris |
7295 |-------------------------+--------+------------------|
7296 |openpty |-lutil |Linux |
7297 +-----------------------------------------------------+
7299 To fix these linker errors, it is often sufficient to say LIBS.OperatingSystem+
7300 = -lfoo to the package Makefile and then say bmake clean; bmake.
7302 19.5.3.1. Special issue: The SunPro compiler
7304 When you are using the SunPro compiler, there is another possibility. That
7305 compiler cannot handle the following code:
7307 extern int extern_func(int);
7312 return extern_func(x);
7320 It generates the code for inline_func even if that function is never used. This
7321 code then refers to extern_func, which can usually not be resolved. To solve
7322 this problem you can try to tell the package to disable inlining of functions.
7324 19.5.4. Running out of memory
7326 Sometimes packages fail to build because the compiler runs into an operating
7327 system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be
7328 told to unlimit the resources. Currently, the allowed values are "datasize" and
7329 "stacksize" (or both). Setting this variable is similar to running the shell
7330 builtin ulimit command to raise the maximum data segment size or maximum stack
7331 size of a process, respectively, to their hard limits.
7333 19.6. Fixing problems in the install phase
7335 19.6.1. Creating needed directories
7337 The BSD-compatible install supplied with some operating systems cannot create
7338 more than one directory at a time. As such, you should call ${INSTALL_*_DIR}
7341 ${INSTALL_DATA_DIR} ${PREFIX}/dir1
7342 ${INSTALL_DATA_DIR} ${PREFIX}/dir2
7345 You can also just append "dir1 dir2" to the INSTALLATION_DIRS variable, which
7346 will automatically do the right thing.
7348 19.6.2. Where to install documentation
7350 In general, documentation should be installed into ${PREFIX}/share/doc/$
7351 {PKGBASE} or ${PREFIX}/share/doc/${PKGNAME} (the latter includes the version
7352 number of the package).
7354 Many modern packages using GNU autoconf allow to set the directory where HTML
7355 documentation is installed with the "--with-html-dir" option. Sometimes using
7356 this flag is needed because otherwise the documentation ends up in ${PREFIX}/
7357 share/doc/html or other places.
7359 An exception to the above is that library API documentation generated with the
7360 textproc/gtk-doc tools, for use by special browsers (devhelp) should be left at
7361 their default location, which is ${PREFIX}/share/gtk-doc. Such documentation
7362 can be recognized from files ending in .devhelp or .devhelp2. (It is also
7363 acceptable to install such files in ${PREFIX}/share/doc/${PKGBASE} or ${PREFIX}
7364 /share/doc/${PKGNAME}; the .devhelp* file must be directly in that directory
7365 then, no additional subdirectory level is allowed in this case. This is usually
7366 achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/
7367 gtk-doc is preferred though.)
7369 19.6.3. Installing highscore files
7371 Certain packages, most of them in the games category, install a score file that
7372 allows all users on the system to record their highscores. In order for this to
7373 work, the binaries need to be installed setgid and the score files owned by the
7374 appropriate group and/or owner (traditionally the "games" user/group). The
7375 following variables, documented in more detail in mk/defaults/mk.conf, control
7376 this behaviour: SETGIDGAME, GAMEDATAMODE, GAMEGRP, GAMEMODE, GAMEOWN.
7378 Note that per default, setgid installation of games is disabled; setting
7379 SETGIDGAME=YES will set all the other variables accordingly.
7381 A package should therefore never hard code file ownership or access permissions
7382 but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly.
7384 19.6.4. Adding DESTDIR support to packages
7386 DESTDIR support means that a package installs into a staging directory, not the
7387 final location of the files. Then a binary package is created which can be used
7388 for installation as usual. There are two ways: Either the package must install
7389 as root ("destdir") or the package can install as non-root user
7392 * PKG_DESTDIR_SUPPORT has to be set to "destdir" or "user-destdir". If
7393 bsd.prefs.mk is included in the Makefile, PKG_DESTDIR_SUPPORT needs to be
7394 set before the inclusion.
7396 * All installation operations have to be prefixed with ${DESTDIR}.
7398 * automake gets this DESTDIR mostly right automatically. Many manual rules
7399 and pre/post-install often are incorrect; fix them.
7401 * If files are installed with special owner/group use SPECIAL_PERMS.
7403 * In general, packages should support UNPRIVILEGED to be able to use DESTDIR.
7405 19.6.5. Packages with hardcoded paths to other interpreters
7407 Your package may also contain scripts with hardcoded paths to other
7408 interpreters besides (or as well as) perl. To correct the full pathname to the
7409 script interpreter, you need to set the following definitions in your Makefile
7410 (we shall use tclsh in this example):
7412 REPLACE_INTERPRETER+= tcl
7413 REPLACE.tcl.old= .*/bin/tclsh
7414 REPLACE.tcl.new= ${PREFIX}/bin/tclsh
7415 REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed,
7416 # relative to ${WRKSRC}, just as in REPLACE_PERL
7421 Before March 2006, these variables were called _REPLACE.* and _REPLACE_FILES.*.
7423 19.6.6. Packages installing perl modules
7425 Makefiles of packages providing perl5 modules should include the Makefile
7426 fragment ../../lang/perl5/module.mk. It provides a do-configure target for the
7427 standard perl configuration for such modules as well as various hooks to tune
7428 this configuration. See comments in this file for details.
7430 Perl5 modules will install into different places depending on the version of
7431 perl used during the build process. To address this, pkgsrc will append lines
7432 to the PLIST corresponding to the files listed in the installed .packlist file
7433 generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to
7434 a space-separated list of paths to packlist files, e.g.:
7436 PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
7439 The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent the
7440 three locations in which perl5 modules may be installed, and may be used by
7441 perl5 packages that don't have a packlist. These three variables are also
7442 substituted for in the PLIST.
7444 19.6.7. Packages installing info files
7446 Some packages install info files or use the "makeinfo" or "install-info"
7447 commands. INFO_FILES should be defined in the package Makefile so that INSTALL
7448 and DEINSTALL scripts will be generated to handle registration of the info
7449 files in the Info directory file. The "install-info" command used for the info
7450 files registration is either provided by the system, or by a special purpose
7451 package automatically added as dependency if needed.
7453 PKGINFODIR is the directory under ${PREFIX} where info files are primarily
7454 located. PKGINFODIR defaults to "info" and can be overridden by the user.
7456 The info files for the package should be listed in the package PLIST; however
7457 any split info files need not be listed.
7459 A package which needs the "makeinfo" command at build time must add "makeinfo"
7460 to USE_TOOLS in its Makefile. If a minimum version of the "makeinfo" command is
7461 needed it should be noted with the TEXINFO_REQD variable in the package
7462 Makefile. By default, a minimum version of 3.12 is required. If the system does
7463 not provide a makeinfo command or if it does not match the required minimum, a
7464 build dependency on the devel/gtexinfo package will be added automatically.
7466 The build and installation process of the software provided by the package
7467 should not use the install-info command as the registration of info files is
7468 the task of the package INSTALL script, and it must use the appropriate
7471 To achieve this goal, the pkgsrc infrastructure creates overriding scripts for
7472 the install-info and makeinfo commands in a directory listed early in PATH.
7474 The script overriding install-info has no effect except the logging of a
7475 message. The script overriding makeinfo logs a message and according to the
7476 value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on
7479 19.6.8. Packages installing man pages
7481 All packages that install manual pages should install them into the same
7482 directory, so that there is one common place to look for them. In pkgsrc, this
7483 place is ${PREFIX}/${PKGMANDIR}, and this expression should be used in
7484 packages. The default for PKGMANDIR is "man". Another often-used value is
7489 The support for a custom PKGMANDIR is far from complete.
7491 The PLIST files can just use man/ as the top level directory for the man page
7492 file entries, and the pkgsrc framework will convert as needed. In all other
7493 places, the correct PKGMANDIR must be used.
7495 Packages that are configured with GNU_CONFIGURE set as "yes", by default will
7496 use the ./configure --mandir switch to set where the man pages should be
7497 installed. The path is GNU_CONFIGURE_MANDIR which defaults to ${PREFIX}/$
7500 Packages that use GNU_CONFIGURE but do not use --mandir, can set
7501 CONFIGURE_HAS_MANDIR to "no". Or if the ./configure script uses a non-standard
7502 use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed.
7504 See Section 13.5, "Man page compression" for information on installation of
7505 compressed manual pages.
7507 19.6.9. Packages installing GConf data files
7509 If a package installs .schemas or .entries files, used by GConf, you need to
7510 take some extra steps to make sure they get registered in the database:
7512 1. Include ../../devel/GConf/schemas.mk instead of its buildlink3.mk file.
7513 This takes care of rebuilding the GConf database at installation and
7514 deinstallation time, and tells the package where to install GConf data
7515 files using some standard configure arguments. It also disallows any access
7516 to the database directly from the package.
7518 2. Ensure that the package installs its .schemas files under ${PREFIX}/share/
7519 gconf/schemas. If they get installed under ${PREFIX}/etc, you will need to
7520 manually patch the package.
7522 3. Check the PLIST and remove any entries under the etc/gconf directory, as
7523 they will be handled automatically. See Section 9.13, "How do I change the
7524 location of configuration files?" for more information.
7526 4. Define the GCONF_SCHEMAS variable in your Makefile with a list of all
7527 .schemas files installed by the package, if any. Names must not contain any
7528 directories in them.
7530 5. Define the GCONF_ENTRIES variable in your Makefile with a list of all
7531 .entries files installed by the package, if any. Names must not contain any
7532 directories in them.
7534 19.6.10. Packages installing scrollkeeper/rarian data files
7536 If a package installs .omf files, used by scrollkeeper/rarian, you need to take
7537 some extra steps to make sure they get registered in the database:
7539 1. Include ../../mk/omf-scrollkeeper.mk instead of rarian's buildlink3.mk
7540 file. This takes care of rebuilding the scrollkeeper database at
7541 installation and deinstallation time, and disallows any access to it
7542 directly from the package.
7544 2. Check the PLIST and remove any entries under the libdata/scrollkeeper
7545 directory, as they will be handled automatically.
7547 3. Remove the share/omf directory from the PLIST. It will be handled by
7548 rarian. (make print-PLIST does this automatically.)
7550 19.6.11. Packages installing X11 fonts
7552 If a package installs font files, you will need to rebuild the fonts database
7553 in the directory where they get installed at installation and deinstallation
7554 time. This can be automatically done by using the pkginstall framework.
7556 You can list the directories where fonts are installed in the FONTS_DIRS.type
7557 variables, where type can be one of "ttf", "type1" or "x11". Also make sure
7558 that the database file fonts.dir is not listed in the PLIST.
7560 Note that you should not create new directories for fonts; instead use the
7561 standard ones to avoid that the user needs to manually configure his X server
7564 19.6.12. Packages installing GTK2 modules
7566 If a package installs GTK2 immodules or loaders, you need to take some extra
7567 steps to get them registered in the GTK2 database properly:
7569 1. Include ../../x11/gtk2/modules.mk instead of its buildlink3.mk file. This
7570 takes care of rebuilding the database at installation and deinstallation
7573 2. Set GTK2_IMMODULES=YES if your package installs GTK2 immodules.
7575 3. Set GTK2_LOADERS=YES if your package installs GTK2 loaders.
7577 4. Patch the package to not touch any of the GTK2 databases directly. These
7580 * libdata/gtk-2.0/gdk-pixbuf.loaders
7582 * libdata/gtk-2.0/gtk.immodules
7584 5. Check the PLIST and remove any entries under the libdata/gtk-2.0 directory,
7585 as they will be handled automatically.
7587 19.6.13. Packages installing SGML or XML data
7589 If a package installs SGML or XML data files that need to be registered in
7590 system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
7593 1. Include ../../textproc/xmlcatmgr/catalogs.mk in your Makefile, which takes
7594 care of registering those files in system-wide catalogs at installation and
7595 deinstallation time.
7597 2. Set SGML_CATALOGS to the full path of any SGML catalogs installed by the
7600 3. Set XML_CATALOGS to the full path of any XML catalogs installed by the
7603 4. Set SGML_ENTRIES to individual entries to be added to the SGML catalog.
7604 These come in groups of three strings; see xmlcatmgr(1) for more
7605 information (specifically, arguments recognized by the 'add' action). Note
7606 that you will normally not use this variable.
7608 5. Set XML_ENTRIES to individual entries to be added to the XML catalog. These
7609 come in groups of three strings; see xmlcatmgr(1) for more information
7610 (specifically, arguments recognized by the 'add' action). Note that you
7611 will normally not use this variable.
7613 19.6.14. Packages installing extensions to the MIME database
7615 If a package provides extensions to the MIME database by installing .xml files
7616 inside ${PREFIX}/share/mime/packages, you need to take some extra steps to
7617 ensure that the database is kept consistent with respect to these new files:
7619 1. Include ../../databases/shared-mime-info/mimedb.mk (avoid using the
7620 buildlink3.mk file from this same directory, which is reserved for
7621 inclusion from other buildlink3.mk files). It takes care of rebuilding the
7622 MIME database at installation and deinstallation time, and disallows any
7623 access to it directly from the package.
7625 2. Check the PLIST and remove any entries under the share/mime directory,
7626 except for files saved under share/mime/packages. The former are handled
7627 automatically by the update-mime-database program, but the latter are
7628 package-dependent and must be removed by the package that installed them in
7631 3. Remove any share/mime/* directories from the PLIST. They will be handled by
7632 the shared-mime-info package.
7634 19.6.15. Packages using intltool
7636 If a package uses intltool during its build, add intltool to the USE_TOOLS,
7637 which forces it to use the intltool package provided by pkgsrc, instead of the
7638 one bundled with the distribution file.
7640 This tracks intltool's build-time dependencies and uses the latest available
7641 version; this way, the package benefits of any bug fixes that may have appeared
7642 since it was released.
7644 19.6.16. Packages installing startup scripts
7646 If a package contains a rc.d script, it won't be copied into the startup
7647 directory by default, but you can enable it, by adding the option
7648 PKG_RCD_SCRIPTS=YES in mk.conf. This option will copy the scripts into /etc/
7649 rc.d when a package is installed, and it will automatically remove the scripts
7650 when the package is deinstalled.
7652 19.6.17. Packages installing TeX modules
7654 If a package installs TeX packages into the texmf tree, the ls-R database of
7655 the tree needs to be updated.
7659 Except the main TeX packages such as kpathsea, packages should install files
7660 into ${PREFIX}/share/texmf-dist, not ${PREFIX}/share/texmf.
7662 1. Include ../../print/kpathsea/texmf.mk. This takes care of rebuilding the
7663 ls-R database at installation and deinstallation time.
7665 2. If your package installs files into a texmf tree other than the one at $
7666 {PREFIX}/share/texmf-dist, set TEX_TEXMF_DIRS to the list of all texmf
7667 trees that need database update.
7669 If your package also installs font map files that need to be registered
7670 using updmap, include ../../print/texlive-tetex/map.mk and set
7671 TEX_MAP_FILES and/or TEX_MIXEDMAP_FILES to the list of all such font map
7672 files. Then updmap will be run automatically at installation/deinstallation
7673 to enable/disable font map files for TeX output drivers.
7675 3. Make sure that none of ls-R databases are included in PLIST, as they will
7676 be removed only by the teTeX-bin package.
7678 19.6.18. Packages supporting running binaries in emulation
7680 There are some packages that provide libraries and executables for running
7681 binaries from a one operating system on a different one (if the latter supports
7682 it). One example is running Linux binaries on NetBSD.
7684 The pkgtools/rpm2pkg helps in extracting and packaging Linux rpm packages.
7686 The CHECK_SHLIBS can be set to no to avoid the check-shlibs target, which tests
7687 if all libraries for each installed executable can be found by the dynamic
7688 linker. Since the standard dynamic linker is run, this fails for emulation
7689 packages, because the libraries used by the emulation are not in the standard
7692 19.6.19. Packages installing hicolor theme icons
7694 If a package installs images under the share/icons/hicolor and/or updates the
7695 share/icons/hicolor/icon-theme.cache database, you need to take some extra
7696 steps to make sure that the shared theme directory is handled appropriately and
7697 that the cache database is rebuilt:
7699 1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk.
7701 2. Check the PLIST and remove the entry that refers to the theme cache.
7703 3. Ensure that the PLIST does not remove the shared icon directories from the
7704 share/icons/hicolor hierarchy because they will be handled automatically.
7706 The best way to verify that the PLIST is correct with respect to the last two
7707 points is to regenerate it using make print-PLIST.
7709 19.6.20. Packages installing desktop files
7711 If a package installs .desktop files under share/applications and these include
7712 MIME information, you need to take extra steps to ensure that they are
7713 registered into the MIME database:
7715 1. Include ../../sysutils/desktop-file-utils/desktopdb.mk.
7717 2. Check the PLIST and remove the entry that refers to the share/applications/
7718 mimeinfo.cache file. It will be handled automatically.
7720 The best way to verify that the PLIST is correct with respect to the last point
7721 is to regenerate it using make print-PLIST.
7723 19.7. Marking packages as having problems
7725 In some cases one does not have the time to solve a problem immediately. In
7726 this case, one can plainly mark a package as broken. For this, one just sets
7727 the variable BROKEN to the reason why the package is broken (similar to the
7728 RESTRICTED variable). A user trying to build the package will immediately be
7729 shown this message, and the build will not be even tried.
7731 BROKEN packages are removed from pkgsrc in irregular intervals.
7733 Chapter 20. Debugging
7735 To check out all the gotchas when building a package, here are the steps that I
7736 do in order to get a package working. Please note this is basically the same as
7737 what was explained in the previous sections, only with some debugging aids.
7739 * Be sure to set PKG_DEVELOPER=yes in mk.conf.
7741 * Install pkgtools/url2pkg, create a directory for a new package, change into
7742 it, then run url2pkg:
7744 % mkdir /usr/pkgsrc/category/examplepkg
7745 % cd /usr/pkgsrc/category/examplepkg
7746 % url2pkg http://www.example.com/path/to/distfile.tar.gz
7748 * Edit the Makefile as requested.
7750 * Fill in the DESCR file
7752 * Run make configure
7754 * Add any dependencies glimpsed from documentation and the configure step to
7755 the package's Makefile.
7757 * Make the package compile, doing multiple rounds of
7760 % pkgvi ${WRKSRC}/some/file/that/does/not/compile
7763 % mv ${WRKDIR}/.newpatches/* patches
7767 Doing this step as non-root user will ensure that no files are modified
7768 that shouldn't be, especially during the build phase. mkpatches, patchdiff
7769 and pkgvi are from the pkgtools/pkgdiff package.
7771 * Look at the Makefile, fix if necessary; see Section 11.1, "Makefile".
7776 # make print-PLIST >PLIST
7781 You usually need to be root to do this. Look if there are any files left:
7785 If this reveals any files that are missing in PLIST, add them.
7787 * Now that the PLIST is OK, install the package again and make a binary
7793 * Delete the installed package:
7795 # pkg_delete examplepkg
7797 * Repeat the above make print-PLIST command, which shouldn't find anything
7802 * Reinstall the binary package:
7804 # pkg_add .../examplepkg.tgz
7806 * Play with it. Make sure everything works.
7808 * Run pkglint from pkgtools/pkglint, and fix the problems it reports:
7812 * Submit (or commit, if you have cvs access); see Chapter 21, Submitting and
7815 Chapter 21. Submitting and Committing
7819 21.1. Submitting binary packages
7820 21.2. Submitting source packages (for non-NetBSD-developers)
7821 21.3. General notes when adding, updating, or removing packages
7822 21.4. Committing: Importing a package into CVS
7823 21.5. Updating a package to a newer version
7824 21.6. Renaming a package in pkgsrc
7825 21.7. Moving a package in pkgsrc
7827 21.1. Submitting binary packages
7829 Our policy is that we accept binaries only from pkgsrc developers to guarantee
7830 that the packages don't contain any trojan horses etc. This is not to annoy
7831 anyone but rather to protect our users! You're still free to put up your
7832 home-made binary packages and tell the world where to get them. NetBSD
7833 developers doing bulk builds and wanting to upload them please see
7834 Section 7.3.8, "Uploading results of a bulk build".
7836 21.2. Submitting source packages (for non-NetBSD-developers)
7838 First, check that your package is complete, compiles and runs well; see
7839 Chapter 20, Debugging and the rest of this document. Next, generate an
7840 uuencoded gzipped tar(1) archive that contains all files that make up the
7841 package. Finally, send this package to the pkgsrc bug tracking system, either
7842 with the send-pr(1) command, or if you don't have that, go to the web page
7843 http://www.NetBSD.org/support/send-pr.html, which contains some instructions
7844 and a link to a form where you can submit packages. The sysutils/gtk-send-pr
7845 package is also available as a substitute for either of the above two tools.
7847 In the form of the problem report, the category should be "pkg", the synopsis
7848 should include the package name and version number, and the description field
7849 should contain a short description of your package (contents of the COMMENT
7850 variable or DESCR file are OK). The uuencoded package data should go into the
7853 If you want to submit several packages, please send a separate PR for each one,
7854 it's easier for us to track things that way.
7856 Alternatively, you can also import new packages into pkgsrc-wip ("pkgsrc
7857 work-in-progress"); see the homepage at http://pkgsrc-wip.sourceforge.net/ for
7860 21.3. General notes when adding, updating, or removing packages
7862 Please note all package additions, updates, moves, and removals in pkgsrc/doc/
7863 CHANGES-YYYY. It's very important to keep this file up to date and conforming
7864 to the existing format, because it will be used by scripts to automatically
7865 update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/
7866 doc/TODO file and remove the entry for the package you updated or removed, in
7867 case it was mentioned there.
7869 When the PKGREVISION of a package is bumped, the change should appear in pkgsrc
7870 /doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps
7871 that result from a dependency being updated should not be mentioned. In all
7872 other cases it's the developer's decision.
7874 There is a make target that helps in creating proper CHANGES-YYYY entries: make
7875 changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The
7876 general usage is to first make sure that your CHANGES-YYYY file is up-to-date
7877 (to avoid having to resolve conflicts later-on) and then to cd to the package
7878 directory. For package updates, make changes-entry is enough. For new packages,
7879 or package moves or removals, set the CTYPE variable on the command line to
7880 "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if
7881 your local login name is not the same as your NetBSD login name. The target
7882 also automatically removes possibly existing entries for the package in the
7883 TODO file. Don't forget to commit the changes, e.g. by using make
7884 changes-entry-commit! If you are not using a checkout directly from
7885 cvs.NetBSD.org, but e.g. a local copy of the repository, you can set
7886 USE_NETBSD_REPO=yes. This makes the cvs commands use the main repository.
7888 21.4. Committing: Importing a package into CVS
7890 This section is only of interest for pkgsrc developers with write access to the
7891 pkgsrc repository. Please remember that cvs imports files relative to the
7892 current working directory, and that the pathname that you give the cvs import
7893 command is so that it knows where to place the files in the repository. Newly
7894 created packages should be imported with a vendor tag of "TNF" and a release
7895 tag of "pkgsrc-base", e.g:
7897 $ cd .../pkgsrc/category/pkgname
7898 $ cvs import pkgsrc/category/pkgname TNF pkgsrc-base
7900 Remember to move the directory from which you imported out of the way, or cvs
7901 will complain the next time you "cvs update" your source tree. Also don't
7902 forget to add the new package to the category's Makefile.
7904 The commit message of the initial import should include part of the DESCR file,
7905 so people reading the mailing lists know what the package is/does.
7907 For new packages, "cvs import" is preferred to "cvs add" because the former
7908 gets everything with a single command, and provides a consistent tag.
7910 21.5. Updating a package to a newer version
7912 Please always put a concise, appropriate and relevant summary of the changes
7913 between old and new versions into the commit log when updating a package. There
7914 are various reasons for this:
7916 * A URL is volatile, and can change over time. It may go away completely or
7917 its information may be overwritten by newer information.
7919 * Having the change information between old and new versions in our CVS
7920 repository is very useful for people who use either cvs or anoncvs.
7922 * Having the change information between old and new versions in our CVS
7923 repository is very useful for people who read the pkgsrc-changes mailing
7924 list, so that they can make tactical decisions about when to upgrade the
7927 Please also recognize that, just because a new version of a package has been
7928 released, it should not automatically be upgraded in the CVS repository. We
7929 prefer to be conservative in the packages that are included in pkgsrc -
7930 development or beta packages are not really the best thing for most places in
7931 which pkgsrc is used. Please use your judgement about what should go into
7932 pkgsrc, and bear in mind that stability is to be preferred above new and
7933 possibly untested features.
7935 21.6. Renaming a package in pkgsrc
7937 Renaming packages is not recommended.
7939 When renaming packages, be sure to fix any references to old name in other
7940 Makefiles, options, buildlink files, etc.
7942 Also When renaming a package, please define SUPERSEDES to the package name and
7943 dewey version pattern(s) of the previous package name. This may be repeated for
7944 multiple renames. The new package would be an exact replacement.
7946 Note that "successor" in the CHANGES-YYYY file doesn't necessarily mean that it
7947 supersedes, as that successor may not be an exact replacement but is a
7948 suggestion for the replaced functionality.
7950 21.7. Moving a package in pkgsrc
7952 It is preferred that packages are not renamed or moved, but if needed please
7955 1. Make a copy of the directory somewhere else.
7957 2. Remove all CVS dirs.
7959 Alternatively to the first two steps you can also do:
7961 % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
7963 and use that for further work.
7965 3. Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of
7966 "../../category/package".
7968 4. In the modified package's Makefile, consider setting PREV_PKGPATH to the
7969 previous category/package pathname. The PREV_PKGPATH can be used by tools
7970 for doing an update using pkgsrc building; for example, it can search the
7971 pkg_summary(5) database for PREV_PKGPATH (if no SUPERSEDES) and then use
7972 the corresponding new PKGPATH for that moved package. Note that it may have
7973 multiple matches, so the tool should also check on the PKGBASE too. The
7974 PREV_PKGPATH probably has no value unless SUPERSEDES is not set, i.e.
7975 PKGBASE stays the same.
7977 5. cvs import the modified package in the new place.
7979 6. Check if any package depends on it:
7982 % grep /package */*/Makefile* */*/buildlink*
7984 7. Fix paths in packages from step 5 to point to new location.
7986 8. cvs rm (-f) the package at the old location.
7988 9. Remove from oldcategory/Makefile.
7990 10. Add to newcategory/Makefile.
7992 11. Commit the changed and removed files:
7994 % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
7996 (and any packages from step 5, of course).
7998 Chapter 22. Frequently Asked Questions
8000 This section contains the answers to questions that may arise when you are
8001 writing a package. If you don't find your question answered here, first have a
8002 look in the other chapters, and if you still don't have the answer, ask on the
8003 pkgsrc-users mailing list.
8005 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
8006 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
8007 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
8008 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
8010 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
8011 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
8013 22.7. Which mailing lists are there for package developers?
8014 22.8. Where is the pkgsrc documentation?
8015 22.9. I have a little time to kill. What shall I do?
8017 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
8019 MAKEFLAGS are the flags passed to the pkgsrc-internal invocations of make
8020 (1), while MAKE_FLAGS are the flags that are passed to the MAKE_PROGRAM
8021 when building the package. [FIXME: What is .MAKEFLAGS for?]
8023 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
8025 MAKE is the path to the make(1) program that is used in the pkgsrc
8026 infrastructure. GMAKE is the path to GNU Make, but you need to say
8027 USE_TOOLS+=gmake to use that. MAKE_PROGRAM is the path to the Make
8028 program that is used for building the package.
8030 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
8032 CC is the path to the real C compiler, which can be configured by the
8033 pkgsrc user. PKG_CC is the path to the compiler wrapper. PKGSRC_COMPILER
8034 is not a path to a compiler, but the type of compiler that should be
8035 used. See mk/compiler.mk for more information about the latter variable.
8037 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
8042 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
8044 For optimization reasons, some variables are only available in the
8045 "wrapper" phase and later. To "simulate" the wrapper phase, append
8046 PKG_PHASE=wrapper to the above command.
8048 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
8051 The := is not really an assignment operator, like you might expect at
8052 first sight. Instead, it is a degenerate form of ${LIST:old_string=
8053 new_string}, which is documented in the make(1) man page and which you
8054 may have seen as in ${SRCS:.c=.o}. In the case of MASTER_SITE_*,
8055 old_string is the empty string and new_string is package/. That's where
8056 the : and the = fall together.
8058 22.7. Which mailing lists are there for package developers?
8062 This is a list for technical discussions related to pkgsrc
8063 development, e.g. soliciting feedback for changes to pkgsrc
8064 infrastructure, proposed new features, questions related to porting
8065 pkgsrc to a new platform, advice for maintaining a package, patches
8066 that affect many packages, help requests moved from pkgsrc-users when
8067 an infrastructure bug is found, etc.
8071 All bug reports in category "pkg" sent with send-pr(1) appear here.
8072 Please do not report your bugs here directly; use one of the other
8075 22.8. Where is the pkgsrc documentation?
8077 There are many places where you can find documentation about pkgsrc:
8079 * The pkgsrc guide (this document) is a collection of chapters that
8080 explain large parts of pkgsrc, but some chapters tend to be outdated.
8081 Which ones they are is hard to say.
8083 * On the mailing list archives (see http://mail-index.NetBSD.org/), you
8084 can find discussions about certain features, announcements of new
8085 parts of the pkgsrc infrastructure and sometimes even announcements
8086 that a certain feature has been marked as obsolete. The benefit here
8087 is that each message has a date appended to it.
8089 * Many of the files in the mk/ directory start with a comment that
8090 describes the purpose of the file and how it can be used by the
8091 pkgsrc user and package authors. An easy way to find this
8092 documentation is to run bmake help.
8094 * The CVS log messages are a rich source of information, but they tend
8095 to be highly abbreviated, especially for actions that occur often.
8096 Some contain a detailed description of what has changed, but they are
8097 geared towards the other pkgsrc developers, not towards an average
8098 pkgsrc user. They also only document changes, so if you don't know
8099 what has been before, these messages may not be worth too much to
8102 * Some parts of pkgsrc are only "implicitly documented", that is the
8103 documentation exists only in the mind of the developer who wrote the
8104 code. To get this information, use the cvs annotate command to see
8105 who has written it and ask on the tech-pkg mailing list, so that
8106 others can find your questions later (see above). To be sure that the
8107 developer in charge reads the mail, you may CC him or her.
8109 22.9. I have a little time to kill. What shall I do?
8111 This is not really an FAQ yet, but here's the answer anyway.
8113 * Run pkg_chk -N (from the pkgtools/pkg_chk package). It will tell you
8114 about newer versions of installed packages that are available, but
8115 not yet updated in pkgsrc.
8117 * Browse pkgsrc/doc/TODO ? it contains a list of suggested new packages
8118 and a list of cleanups and enhancements for pkgsrc that would be nice
8121 * Review packages for which review was requested on the pkgsrc-wip
8122 review mailing list.
8124 Chapter 23. GNOME packaging and porting
8129 23.2. Packaging a GNOME application
8130 23.3. Updating GNOME to a newer version
8131 23.4. Patching guidelines
8133 Quoting GNOME's web site:
8135 The GNOME project provides two things: The GNOME desktop environment, an
8136 intuitive and attractive desktop for users, and the GNOME development
8137 platform, an extensive framework for building applications that integrate
8138 into the rest of the desktop.
8140 pkgsrc provides a seamless way to automatically build and install a complete
8141 GNOME environment under many different platforms. We can say with confidence
8142 that pkgsrc is one of the most advanced build and packaging systems for GNOME
8143 due to its included technologies buildlink3, the wrappers and tools framework
8144 and automatic configuration file management. Lots of efforts are put into
8145 achieving a completely clean deinstallation of installed software components.
8147 Given that pkgsrc is NetBSD's official packaging system, the above also means
8148 that great efforts are put into making GNOME work under this operating system.
8149 Recently, DragonFly BSD also adopted pkgsrc as its preferred packaging system,
8150 contributing lots of portability fixes to make GNOME build and install under
8153 This chapter is aimed at pkgsrc developers and other people interested in
8154 helping our GNOME porting and packaging efforts. It provides instructions on
8155 how to manage the existing packages and some important information regarding
8160 Should you have some spare cycles to devote to NetBSD, pkgsrc and GNOME and are
8161 willing to learn new exciting stuff, please jump straight to the pending work
8162 list! There is still a long way to go to get a fully-functional GNOME desktop
8163 under NetBSD and we need your help to achieve it!
8167 pkgsrc includes three GNOME-related meta packages:
8169 * meta-pkgs/gnome-base: Provides the core GNOME desktop environment. It only
8170 includes the necessary bits to get it to boot correctly, although it may
8171 lack important functionality for daily operation. The idea behind this
8172 package is to let end users build their own configurations on top of this
8173 one, first installing this meta package to achieve a functional setup and
8174 then adding individual applications.
8176 * meta-pkgs/gnome: Provides a complete installation of the GNOME platform and
8177 desktop as defined by the GNOME project; this is based on the components
8178 distributed in the platform/x.y/x.y.z/sources and desktop/x.y/x.y.z/sources
8179 directories of the official FTP server. Developer-only tools found in those
8180 directories are not installed unless required by some other component to
8181 work properly. Similarly, packages from the bindings set (bindings/x.y/
8182 x.y.z/sources) are not pulled in unless required as a dependency for an
8183 end-user component. This package "extends" meta-pkgs/gnome-base.
8185 * meta-pkgs/gnome-devel: Installs all the tools required to build a GNOME
8186 component when fetched from the CVS repository. These are required to let
8187 the autogen.sh scripts work appropriately.
8189 In all these packages, the DEPENDS lines are sorted in a way that eases
8190 updates: a package may depend on other packages listed before it but not on any
8191 listed after it. It is very important to keep this order to ease updates so...
8192 do not change it to alphabetical sorting!
8194 23.2. Packaging a GNOME application
8196 Almost all GNOME applications are written in C and use a common set of tools as
8197 their build system. Things get different with the new bindings to other
8198 languages (such as Python), but the following will give you a general idea on
8199 the minimum required tools:
8201 * Almost all GNOME applications use the GNU Autotools as their build system.
8202 As a general rule you will need to tell this to your package:
8208 * If the package uses pkg-config to detect dependencies, add this tool to the
8209 list of required utilities:
8211 USE_TOOLS+=pkg-config
8213 Also use pkgtools/verifypc at the end of the build process to ensure that
8214 you did not miss to specify any dependency in your package and that the
8215 version requirements are all correct.
8217 * If the package uses intltool, be sure to add intltool to the USE_TOOLS to
8218 handle dependencies and to force the package to use the latest available
8221 * If the package uses gtk-doc (a documentation generation utility), do not
8222 add a dependency on it. The tool is rather big and the distfile should come
8223 with pregenerated documentation anyway; if it does not, it is a bug that
8224 you ought to report. For such packages you should disable gtk-doc (unless
8227 CONFIGURE_ARGS+=--disable-gtk-doc
8229 The default location of installed HTML files (share/gtk-doc/<package-name>)
8230 is correct and should not be changed unless the package insists on
8231 installing them somewhere else. Otherwise programs as devhelp will not be
8232 able to open them. You can do that with an entry similar to:
8234 CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
8236 GNOME uses multiple shared directories and files under the installation prefix
8237 to maintain databases. In this context, shared means that those exact same
8238 directories and files are used among several different packages, leading to
8239 conflicts in the PLIST. pkgsrc currently includes functionality to handle the
8240 most common cases, so you have to forget about using @unexec ${RMDIR} lines in
8241 your file lists and omitting shared files from them. If you find yourself doing
8242 those, your package is most likely incorrect.
8244 The following table lists the common situations that result in using shared
8245 directories or files. For each of them, the appropriate solution is given.
8246 After applying the solution be sure to regenerate the package's file list with
8247 make print-PLIST and ensure it is correct.
8249 Table 23.1. PLIST handling for GNOME packages
8251 +-----------------------------------------------------------------------------+
8252 | If the package... | Then... |
8253 |-------------------------------------------+---------------------------------|
8254 | |See Section 19.6.10, "Packages |
8255 |Installs OMF files under share/omf. |installing scrollkeeper/rarian |
8257 |-------------------------------------------+---------------------------------|
8258 |Installs icons under the share/icons/ |See Section 19.6.19, "Packages |
8259 |hicolor hierarchy or updates share/icons/ |installing hicolor theme icons". |
8260 |hicolor/icon-theme.cache. | |
8261 |-------------------------------------------+---------------------------------|
8262 | |See Section 19.6.14, "Packages |
8263 |Installs files under share/mime/packages. |installing extensions to the MIME|
8265 |-------------------------------------------+---------------------------------|
8266 |Installs .desktop files under share/ |See Section 19.6.20, "Packages |
8267 |applications and these include MIME |installing desktop files". |
8269 +-----------------------------------------------------------------------------+
8272 23.3. Updating GNOME to a newer version
8274 When seeing GNOME as a whole, there are two kinds of updates:
8278 Given that there is still a very long way for GNOME 3 (if it ever appears),
8279 we consider a major update one that goes from a 2.X version to a 2.Y one,
8280 where Y is even and greater than X. These are hard to achieve because they
8281 introduce lots of changes in the components' code and almost all GNOME
8282 distfiles are updated to newer versions. Some of them can even break API
8283 and ABI compatibility with the previous major version series. As a result,
8284 the update needs to be done all at once to minimize breakage.
8286 A major update typically consists of around 80 package updates and the
8287 addition of some new ones.
8291 We consider a minor update one that goes from a 2.A.X version to a 2.A.Y
8292 one where Y is greater than X. These are easy to achieve because they do
8293 not update all GNOME components, can be done in an incremental way and do
8294 not break API nor ABI compatibility.
8296 A minor update typically consists of around 50 package updates, although
8297 the numbers here may vary a lot.
8299 In order to update the GNOME components in pkgsrc to a new stable release
8300 (either major or minor), the following steps should be followed:
8302 1. Get a list of all the tarballs that form the new release by using the
8303 following commands. These will leave the full list of the components'
8304 distfiles into the list.txt file:
8306 % echo ls "*.tar.bz2" | \
8307 ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
8308 awk '{ print $9 }' >list.txt
8309 % echo ls "*.tar.bz2" | \
8310 ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
8311 awk '{ print $9 }' >>list.txt
8313 2. Open each meta package's Makefile and bump their version to the release you
8314 are updating them to. The three meta packages should be always consistent
8315 with versioning. Obviously remove any PKGREVISIONs that might be in them.
8317 3. For each meta package, update all its DEPENDS lines to match the latest
8318 versions as shown by the above commands. Do not list any newer version
8319 (even if found in the FTP) because the meta packages are supposed to list
8320 the exact versions that form a specific GNOME release. Exceptions are
8321 permitted here if a newer version solves a serious issue in the overall
8322 desktop experience; these typically come in the form of a revision bump in
8323 pkgsrc, not in newer versions from the developers.
8325 Packages not listed in the list.txt file should be updated to the latest
8326 version available (if found in pkgsrc). This is the case, for example, of
8327 the dependencies on the GNU Autotools in the meta-pkgs/gnome-devel meta
8330 4. Generate a patch from the modified meta packages and extract the list of
8331 "new" lines. This will provide you an outline on what packages need to be
8332 updated in pkgsrc and in what order:
8334 % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt
8336 5. For major desktop updates it is recommended to zap all your installed
8337 packages and start over from scratch at this point.
8339 6. Now comes the longest step by far: iterate over the contents of todo.txt
8340 and update the packages listed in it in order. For major desktop updates
8341 none of these should be committed until the entire set is completed because
8342 there are chances of breaking not-yet-updated packages.
8344 7. Once the packages are up to date and working, commit them to the tree one
8345 by one with appropriate log messages. At the end, commit the three meta
8346 package updates and all the corresponding changes to the doc/CHANGES-<YEAR>
8347 and pkgsrc/doc/TODO files.
8349 23.4. Patching guidelines
8351 GNOME is a very big component in pkgsrc which approaches 100 packages. Please,
8352 it is very important that you always, always, always feed back any portability
8353 fixes you do to a GNOME package to the mainstream developers (see
8354 Section 11.3.5, "Feedback to the author"). This is the only way to get their
8355 attention on portability issues and to ensure that future versions can be built
8356 out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further
8357 updates are. Those developers in charge of issuing major GNOME updates will be
8358 grateful if you do that.
8360 The most common places to report bugs are the GNOME's Bugzilla and the
8361 freedesktop.org's Bugzilla. Not all components use these to track bugs, but
8362 most of them do. Do not be short on your reports: always provide detailed
8363 explanations of the current failure, how it can be improved to achieve maximum
8364 portability and, if at all possible, provide a patch against CVS head. The more
8365 verbose you are, the higher chances of your patch being accepted.
8367 Also, please avoid using preprocessor magic to fix portability issues. While
8368 the FreeBSD GNOME people are doing a great job in porting GNOME to their
8369 operating system, the official GNOME sources are now plagued by conditionals
8370 that check for __FreeBSD__ and similar macros. This hurts portability. Please
8371 see our patching guidelines (Section 11.3.4, "Patching guidelines") for more
8374 Part III. The pkgsrc infrastructure internals
8376 This part of the guide deals with everything from the infrastructure that is
8377 behind the interfaces described in the developer's guide. A casual package
8378 maintainer should not need anything from this part.
8382 24. Design of the pkgsrc infrastructure
8384 24.1. The meaning of variable definitions
8385 24.2. Avoiding problems before they arise
8386 24.3. Variable evaluation
8388 24.3.1. At load time
8391 24.4. How can variables be specified?
8392 24.5. Designing interfaces for Makefile fragments
8394 24.5.1. Procedures with parameters
8395 24.5.2. Actions taken on behalf of parameters
8397 24.6. The order in which files are loaded
8399 24.6.1. The order in bsd.prefs.mk
8400 24.6.2. The order in bsd.pkg.mk
8402 25. Regression tests
8404 25.1. The regression tests framework
8405 25.2. Running the regression tests
8406 25.3. Adding a new regression test
8408 25.3.1. Overridable functions
8409 25.3.2. Helper functions
8413 26.1. Porting pkgsrc to a new operating system
8414 26.2. Adding support for a new compiler
8416 Chapter 24. Design of the pkgsrc infrastructure
8420 24.1. The meaning of variable definitions
8421 24.2. Avoiding problems before they arise
8422 24.3. Variable evaluation
8424 24.3.1. At load time
8427 24.4. How can variables be specified?
8428 24.5. Designing interfaces for Makefile fragments
8430 24.5.1. Procedures with parameters
8431 24.5.2. Actions taken on behalf of parameters
8433 24.6. The order in which files are loaded
8435 24.6.1. The order in bsd.prefs.mk
8436 24.6.2. The order in bsd.pkg.mk
8438 The pkgsrc infrastructure consists of many small Makefile fragments. Each such
8439 fragment needs a properly specified interface. This chapter explains how such
8440 an interface looks like.
8442 24.1. The meaning of variable definitions
8444 Whenever a variable is defined in the pkgsrc infrastructure, the location and
8445 the way of definition provide much information about the intended use of that
8446 variable. Additionally, more documentation may be found in a header comment or
8447 in this pkgsrc guide.
8449 A special file is mk/defaults/mk.conf, which lists all variables that are
8450 intended to be user-defined. They are either defined using the ?= operator or
8451 they are left undefined because defining them to anything would effectively
8452 mean "yes". All these variables may be overridden by the pkgsrc user in the
8455 Outside this file, the following conventions apply: Variables that are defined
8456 using the ?= operator may be overridden by a package.
8458 Variables that are defined using the = operator may be used read-only at
8461 Variables whose name starts with an underscore must not be accessed outside the
8462 pkgsrc infrastructure at all. They may change without further notice.
8466 These conventions are currently not applied consistently to the complete pkgsrc
8469 24.2. Avoiding problems before they arise
8471 All variables that contain lists of things should default to being empty. Two
8472 examples that do not follow this rule are USE_LANGUAGES and DISTFILES. These
8473 variables cannot simply be modified using the += operator in package Makefiles
8474 (or other files included by them), since there is no guarantee whether the
8475 variable is already set or not, and what its value is. In the case of
8476 DISTFILES, the packages "know" the default value and just define it as in the
8479 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
8481 Because of the selection of this default value, the same value appears in many
8482 package Makefiles. Similarly for USE_LANGUAGES, but in this case the default
8483 value ("c") is so short that it doesn't stand out. Nevertheless it is mentioned
8486 24.3. Variable evaluation
8488 24.3.1. At load time
8490 Variable evaluation takes place either at load time or at runtime, depending on
8491 the context in which they occur. The contexts where variables are evaluated at
8494 * The right hand side of the := and != operators,
8496 * Make directives like .if or .for,
8500 A special exception are references to the iteration variables of .for loops,
8501 which are expanded inline, no matter in which context they appear.
8503 As the values of variables may change during load time, care must be taken not
8504 to evaluate them by accident. Typical examples for variables that should not be
8505 evaluated at load time are DEPENDS and CONFIGURE_ARGS. To make the effect more
8506 clear, here is an example:
8508 CONFIGURE_ARGS= # none
8510 CONFIGURE_ARGS+= CFLAGS=${CFLAGS:Q}
8512 CONFIGURE_ARGS:= ${CONFIGURE_ARGS}
8517 This code shows how the use of the := operator can quickly lead to unexpected
8518 results. The first paragraph is fairly common code. The second paragraph
8519 evaluates the CONFIGURE_ARGS variable, which results in CFLAGS=-O. In the third
8520 paragraph, the -Wall is appended to the CFLAGS, but this addition will not
8521 appear in CONFIGURE_ARGS. In actual code, the three paragraphs from above
8522 typically occur in completely unrelated files.
8526 After all the files have been loaded, the values of the variables cannot be
8527 changed anymore. Variables that are used in the shell commands are expanded at
8530 24.4. How can variables be specified?
8532 There are many ways in which the definition and use of a variable can be
8533 restricted in order to detect bugs and violations of the (mostly unwritten)
8534 policies. See the pkglint developer's documentation for further details.
8536 24.5. Designing interfaces for Makefile fragments
8538 Most of the .mk files fall into one of the following classes. Cases where a
8539 file falls into more than one class should be avoided as it often leads to
8542 24.5.1. Procedures with parameters
8544 In a traditional imperative programming language some of the .mk files could be
8545 described as procedures. They take some input parameters and?after
8546 inclusion?provide a result in output parameters. Since all variables in
8547 Makefiles have global scope care must be taken not to use parameter names that
8548 have already another meaning. For example, PKGNAME is a bad choice for a
8551 Procedures are completely evaluated at preprocessing time. That is, when
8552 calling a procedure all input parameters must be completely resolvable. For
8553 example, CONFIGURE_ARGS should never be an input parameter since it is very
8554 likely that further text will be added after calling the procedure, which would
8555 effectively apply the procedure to only a part of the variable. Also,
8556 references to other variables wit will be modified after calling the procedure.
8558 A procedure can declare its output parameters either as suitable for use in
8559 preprocessing directives or as only available at runtime. The latter
8560 alternative is for variables that contain references to other runtime
8563 Procedures shall be written such that it is possible to call the procedure more
8564 than once. That is, the file must not contain multiple-inclusion guards.
8566 Examples for procedures are mk/bsd.options.mk and mk/buildlink3/bsd.builtin.mk.
8567 To express that the parameters are evaluated at load time, they should be
8568 assigned using the := operator, which should be used only for this purpose.
8570 24.5.2. Actions taken on behalf of parameters
8572 Action files take some input parameters and may define runtime variables. They
8573 shall not define loadtime variables. There are action files that are included
8574 implicitly by the pkgsrc infrastructure, while other must be included
8577 An example for action files is mk/subst.mk.
8579 24.6. The order in which files are loaded
8581 Package Makefiles usually consist of a set of variable definitions, and include
8582 the file ../../mk/bsd.pkg.mk in the very last line. Before that, they may also
8583 include various other *.mk files if they need to query the availability of
8584 certain features like the type of compiler or the X11 implementation. Due to
8585 the heavy use of preprocessor directives like .if and .for, the order in which
8586 the files are loaded matters.
8588 This section describes at which point the various files are loaded and gives
8589 reasons for that order.
8591 24.6.1. The order in bsd.prefs.mk
8593 The very first action in bsd.prefs.mk is to define some essential variables
8594 like OPSYS, OS_VERSION and MACHINE_ARCH.
8596 Then, the user settings are loaded from the file specified in MAKECONF, which
8597 is usually mk.conf. After that, those variables that have not been overridden
8598 by the user are loaded from mk/defaults/mk.conf.
8600 After the user settings, the system settings and platform settings are loaded,
8601 which may override the user settings.
8603 Then, the tool definitions are loaded. The tool wrappers are not yet in effect.
8604 This only happens when building a package, so the proper variables must be used
8605 instead of the direct tool names.
8607 As the last steps, some essential variables from the wrapper and the package
8608 system flavor are loaded, as well as the variables that have been cached in
8609 earlier phases of a package build.
8611 24.6.2. The order in bsd.pkg.mk
8613 First, bsd.prefs.mk is loaded.
8615 Then, the various *-vars.mk files are loaded, which fill default values for
8616 those variables that have not been defined by the package. These variables may
8617 later be used even in unrelated files.
8619 Then, the file bsd.pkg.error.mk provides the target error-check that is added
8620 as a special dependency to all other targets that use DELAYED_ERROR_MSG or
8621 DELAYED_WARNING_MSG.
8623 Then, the package-specific hacks from hacks.mk are included.
8625 Then, various other files follow. Most of them don't have any dependencies on
8626 what they need to have included before or after them, though some do.
8628 The code to check PKG_FAIL_REASON and PKG_SKIP_REASON is then executed, which
8629 restricts the use of these variables to all the files that have been included
8630 before. Appearances in later files will be silently ignored.
8632 Then, the files for the main targets are included, in the order of later
8633 execution, though the actual order should not matter.
8635 At last, some more files are included that don't set any interesting variables
8636 but rather just define make targets to be executed.
8638 Chapter 25. Regression tests
8642 25.1. The regression tests framework
8643 25.2. Running the regression tests
8644 25.3. Adding a new regression test
8646 25.3.1. Overridable functions
8647 25.3.2. Helper functions
8649 The pkgsrc infrastructure consists of a large codebase, and there are many
8650 corners where every little bit of a file is well thought out, making pkgsrc
8651 likely to fail as soon as anything is changed near those parts. To prevent most
8652 changes from breaking anything, a suite of regression tests should go along
8653 with every important part of the pkgsrc infrastructure. This chapter describes
8654 how regression tests work in pkgsrc and how you can add new tests.
8656 25.1. The regression tests framework
8658 25.2. Running the regression tests
8660 You first need to install the pkgtools/pkg_regress package, which provides the
8661 pkg_regress command. Then you can simply run that command, which will run all
8662 tests in the regress category.
8664 25.3. Adding a new regression test
8666 Every directory in the regress category that contains a file called spec is
8667 considered a regression test. This file is a shell program that is included by
8668 the pkg_regress command. The following functions can be overridden to suit your
8671 25.3.1. Overridable functions
8673 These functions do not take any parameters. They are all called in "set -e"
8674 mode, so you should be careful to check the exitcodes of any commands you run
8679 This function prepares the environment for the test. By default it does
8684 This function runs the actual test. By default, it calls TEST_MAKE with the
8685 arguments MAKEARGS_TEST and writes its output including error messages into
8686 the file TEST_OUTFILE.
8690 This function is run after the test and is typically used to compare the
8691 actual output from the one that is expected. It can make use of the various
8692 helper functions from the next section.
8696 This function cleans everything up after the test has been run. By default
8699 25.3.2. Helper functions
8701 exit_status(expected)
8703 This function compares the exitcode of the do_test() function with its
8704 first parameter. If they differ, the test will fail.
8706 output_require(regex...)
8708 This function checks for each of its parameters if the output from do_test
8709 () matches the extended regular expression. If it does not, the test will
8712 output_prohibit(regex...)
8714 This function checks for each of its parameters if the output from do_test
8715 () does not match the extended regular expression. If any of the regular
8716 expressions matches, the test will fail.
8718 Chapter 26. Porting pkgsrc
8722 26.1. Porting pkgsrc to a new operating system
8723 26.2. Adding support for a new compiler
8725 The pkgsrc system has already been ported to many operating systems, hardware
8726 architectures and compilers. This chapter explains the necessary steps to make
8727 pkgsrc even more portable.
8729 26.1. Porting pkgsrc to a new operating system
8731 To port pkgsrc to a new operating system (called MyOS in this example), you
8732 need to touch the following files:
8734 pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk
8736 This file contains some basic definitions, for example the name of the C
8741 Insert code that defines the variables OPSYS, OS_VERSION, LOWER_OS_VERSION,
8742 LOWER_VENDOR, MACHINE_ARCH, OBJECT_FMT, APPEND_ELF, and the other variables
8743 that appear in this file.
8747 This file contains the platform-specific definitions that are used by
8748 pkgsrc. Start by copying one of the other files and edit it to your needs.
8750 mk/platform/MyOS.pkg.dist
8752 This file contains a list of directories, together with their permission
8753 bits and ownership. These directories will be created automatically with
8754 every package that explicitly sets USE_MTREE. This feature will be removed.
8756 mk/platform/MyOS.x11.dist
8758 Just copy one of the pre-existing x11.dist files to your MyOS.x11.dist.
8760 mk/tools/bootstrap.mk
8762 On some operating systems, the tools that are provided with the base system
8763 are not good enough for pkgsrc. For example, there are many versions of sed
8764 (1) that have a narrow limit on the line length they can process. Therefore
8765 pkgsrc brings its own tools, which can be enabled here.
8767 mk/tools/tools.MyOS.mk
8769 This file defines the paths to all the tools that are needed by one or the
8770 other package in pkgsrc, as well as by pkgsrc itself. Find out where these
8771 tools are on your platform and add them.
8773 Now, you should be able to build some basic packages, like lang/perl5, shells/
8776 26.2. Adding support for a new compiler
8780 Appendix A. A simple example package: bison
8789 A.1.4. Checking a package with pkglint
8791 A.2. Steps for building, installing, packaging
8793 We checked to find a piece of software that wasn't in the packages collection,
8794 and picked GNU bison. Quite why someone would want to have bison when Berkeley
8795 yacc is already present in the tree is beyond us, but it's useful for the
8796 purposes of this exercise.
8805 DISTNAME= bison-1.25
8807 MASTER_SITES= ${MASTER_SITE_GNU}
8809 MAINTAINER= thorpej@NetBSD.org
8810 HOMEPAGE= http://www.gnu.org/software/bison/bison.html
8811 COMMENT= GNU yacc clone
8814 INFO_FILES= bison.info
8816 .include "../../mk/bsd.pkg.mk"
8820 GNU version of yacc. Can make re-entrant parsers, and numerous other
8821 improvements. Why you would want this when Berkeley yacc(1) is part
8822 of the NetBSD source tree is beyond me.
8832 A.1.4. Checking a package with pkglint
8834 The NetBSD package system comes with pkgtools/pkglint which helps to check the
8835 contents of these files. After installation it is quite easy to use, just
8836 change to the directory of the package you wish to examine and execute pkglint:
8841 Depending on the supplied command line arguments (see pkglint(1)), more checks
8842 will be performed. Use e.g. pkglint -Call -Wall for a very thorough check.
8844 A.2. Steps for building, installing, packaging
8846 Create the directory where the package lives, plus any auxiliary directories:
8848 # cd /usr/pkgsrc/lang
8853 Create Makefile, DESCR and PLIST (see Chapter 11, Package components - files,
8854 directories and contents) then continue with fetching the distfile:
8857 >> bison-1.25.tar.gz doesn't seem to exist on this system.
8858 >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
8859 Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
8860 ftp: Error retrieving file: 500 Internal error
8862 >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
8863 Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
8864 ftp: Error retrieving file: 500 Internal error
8866 >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
8867 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
8868 Successfully retrieved file.
8870 Generate the checksum of the distfile into distinfo:
8877 >> Checksum OK for bison-1.25.tar.gz.
8878 ===> Extracting for bison-1.25
8879 ===> Patching for bison-1.25
8880 ===> Ignoring empty patch directory
8881 ===> Configuring for bison-1.25
8882 creating cache ./config.cache
8883 checking for gcc... cc
8884 checking whether we are using GNU C... yes
8885 checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
8886 checking how to run the C preprocessor... cc -E
8887 checking for minix/config.h... no
8888 checking for POSIXized ISC... no
8889 checking whether cross-compiling... no
8890 checking for ANSI C header files... yes
8891 checking for string.h... yes
8892 checking for stdlib.h... yes
8893 checking for memory.h... yes
8894 checking for working const... yes
8895 checking for working alloca.h... no
8896 checking for alloca... yes
8897 checking for strerror... yes
8898 updating cache ./config.cache
8899 creating ./config.status
8901 ===> Building for bison-1.25
8902 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g LR0.c
8903 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g allocate.c
8904 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g closure.c
8905 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g conflicts.c
8906 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g derives.c
8907 cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\" -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -g ./files.c
8908 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getargs.c
8909 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g gram.c
8910 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lalr.c
8911 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lex.c
8912 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g main.c
8913 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g nullable.c
8914 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g output.c
8915 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g print.c
8916 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reader.c
8917 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reduce.c
8918 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g symtab.c
8919 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g warshall.c
8920 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g version.c
8921 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt.c
8922 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt1.c
8923 cc -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o getargs.o gram.o lalr.o lex.o main.o nullable.o output.o print.o reader.o reduce.o symtab.o warshall.o version.o getopt.o getopt1.o
8924 ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
8926 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
8928 Everything seems OK, so install the files:
8931 >> Checksum OK for bison-1.25.tar.gz.
8932 ===> Installing for bison-1.25
8933 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
8934 rm -f /usr/pkg/bin/bison
8935 cd /usr/pkg/share; rm -f bison.simple bison.hairy
8936 rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
8937 install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison
8938 /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
8939 /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
8940 cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
8941 /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
8942 ===> Registering installation for bison-1.25
8944 You can now use bison, and also - if you decide so - remove it with pkg_delete
8945 bison. Should you decide that you want a binary package, do this now:
8948 >> Checksum OK for bison-1.25.tar.gz.
8949 ===> Building package for bison-1.25
8950 Creating package bison-1.25.tgz
8951 Registering depends:.
8952 Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
8954 Now that you don't need the source and object files any more, clean up:
8957 ===> Cleaning for bison-1.25
8959 Appendix B. Build logs
8963 B.1. Building figlet
8964 B.2. Packaging figlet
8966 B.1. Building figlet
8969 ===> Checking for vulnerabilities in figlet-2.2.1nb2
8970 => figlet221.tar.gz doesn't seem to exist on this system.
8971 => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
8973 Connected to ftp.plig.net.
8974 220 ftp.plig.org NcFTPd Server (licensed copy) ready.
8975 331 Guest login ok, send your complete e-mail address as password.
8976 230-You are user #5 of 500 simultaneous users allowed.
8979 230- | _| |_ ___ ___| |_|___ ___ ___ ___
8980 230- | _| _| . |_| . | | | . |_| . | _| . |
8981 230- |_| |_| | _|_| _|_|_|_ |_|___|_| |_ |
8982 230- |_| |_| |___| |___|
8984 230-** Welcome to ftp.plig.org **
8986 230-Please note that all transfers from this FTP site are logged. If you
8987 230-do not like this, please disconnect now.
8989 230-This archive is available via
8991 230-HTTP: http://ftp.plig.org/
8992 230-FTP: ftp://ftp.plig.org/ (max 500 connections)
8993 230-RSYNC: rsync://ftp.plig.org/ (max 30 connections)
8995 230-Please email comments, bug reports and requests for packages to be
8996 230-mirrored to ftp-admin@plig.org.
8999 230 Logged in anonymously.
9000 Remote system type is UNIX.
9001 Using binary mode to transfer files.
9003 250 "/pub" is new cwd.
9004 250-"/pub/figlet" is new cwd.
9006 250-Welcome to the figlet archive at ftp.figlet.org
9008 250- ftp://ftp.figlet.org/pub/figlet/
9010 250-The official FIGlet web page is:
9011 250- http://www.figlet.org/
9013 250-If you have questions, please mailto:info@figlet.org. If you want to
9014 250-contribute a font or something else, you can email us.
9016 250 "/pub/figlet/program" is new cwd.
9017 250 "/pub/figlet/program/unix" is new cwd.
9018 local: figlet221.tar.gz remote: figlet221.tar.gz
9019 502 Unimplemented command.
9020 227 Entering Passive Mode (195,40,6,41,246,104)
9021 150 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
9022 38% |************** | 65800 64.16 KB/s 00:01 ETA
9023 226 Transfer completed.
9024 172219 bytes received in 00:02 (75.99 KB/s)
9026 => Checksum OK for figlet221.tar.gz.
9027 ===> Extracting for figlet-2.2.1nb2
9028 ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found
9029 ===> Patching for figlet-2.2.1nb2
9030 ===> Applying pkgsrc patches for figlet-2.2.1nb2
9031 ===> Overriding tools for figlet-2.2.1nb2
9032 ===> Creating toolchain wrappers for figlet-2.2.1nb2
9033 ===> Configuring for figlet-2.2.1nb2
9034 ===> Building for figlet-2.2.1nb2
9035 gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\" -DDEFAULTFONTFILE=\"standard.flf\" figlet.c zipio.c crc.c inflate.c -o figlet
9037 gcc -O2 -o chkfont chkfont.c
9038 => Unwrapping files-to-be-installed.
9041 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9042 ===> Installing for figlet-2.2.1nb2
9043 install -d -o root -g wheel -m 755 /usr/pkg/bin
9044 install -d -o root -g wheel -m 755 /usr/pkg/man/man6
9045 mkdir -p /usr/pkg/share/figlet
9046 cp figlet /usr/pkg/bin
9047 cp chkfont /usr/pkg/bin
9048 chmod 555 figlist showfigfonts
9049 cp figlist /usr/pkg/bin
9050 cp showfigfonts /usr/pkg/bin
9051 cp fonts/*.flf /usr/pkg/share/figlet
9052 cp fonts/*.flc /usr/pkg/share/figlet
9053 cp figlet.6 /usr/pkg/man/man6
9054 ===> Registering installation for figlet-2.2.1nb2
9057 B.2. Packaging figlet
9060 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9061 ===> Packaging figlet-2.2.1nb2
9062 ===> Building binary package for figlet-2.2.1nb2
9063 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
9064 Using SrcDir value of /usr/pkg
9065 Registering depends:.
9068 Appendix C. Directory layout of the pkgsrc FTP server
9072 C.1. distfiles: The distributed source files
9073 C.2. misc: Miscellaneous things
9074 C.3. packages: Binary packages
9075 C.4. reports: Bulk build reports
9076 C.5. current, pkgsrc-20xxQy: source packages
9078 As in other big projects, the directory layout of pkgsrc is quite complex for
9079 newbies. This chapter explains where you find things on the FTP server. The
9080 base directory on ftp.NetBSD.org is /pub/pkgsrc/. On other servers it may be
9081 different, but inside this directory, everything should look the same, no
9082 matter on which server you are. This directory contains some subdirectories,
9083 which are explained below.
9085 C.1. distfiles: The distributed source files
9087 The directory distfiles contains lots of archive files from all pkgsrc
9088 packages, which are mirrored here. The subdirectories are called after their
9089 package names and are used when the distributed files have names that don't
9090 explicitly contain a version number or are otherwise too generic (for example
9093 C.2. misc: Miscellaneous things
9095 This directory contains things that individual pkgsrc developers find worth
9098 C.3. packages: Binary packages
9100 This directory contains binary packages for the various platforms that are
9101 supported by pkgsrc. Each subdirectory is of the form OPSYS/ARCH/OSVERSION_TAG.
9102 The meaning of these variables is:
9104 * OPSYS is the name of the operating system for which the packages have been
9105 built. The name is taken from the output of the uname command, so it may
9106 differ from the one you are used to hear.
9108 * ARCH is the hardware architecture of the platform for which the packages
9109 have been built. It also includes the ABI (Application Binary Interface)
9110 for platforms that have several of them.
9112 * OSVERSION is the version of the operating system. For version numbers that
9113 change often (for example NetBSD-current), the often-changing part should
9114 be replaced with an x, for example 4.99.x.
9116 * TAG is either 20xxQy for a stable branch, or head for packages built from
9117 the HEAD branch. The latter should only be used when the packages are
9118 updated on a regular basis. Otherwise the date from checking out pkgsrc
9119 should be appended, for example head_20071015.
9121 The rationale for exactly this scheme is that the pkgsrc users looking for
9122 binary packages can quickly click through the directories on the server and
9123 find the best binary packages for their machines. Since they usually know the
9124 operating system and the hardware architecture, OPSYS and ARCH are placed
9125 first. After these choices, they can select the best combination of OSVERSION
9126 and TAG together, since it is usually the case that packages stay compatible
9127 between different version of the operating system.
9129 In each of these directories, there is a whole binary packages collection for a
9130 specific platform. It has a directory called All which contains all binary
9131 packages. Besides that, there are various category directories that contain
9132 symbolic links to the real binary packages.
9134 C.4. reports: Bulk build reports
9136 Here are the reports from bulk builds, for those who want to fix packages that
9137 didn't build on some of the platforms. The structure of subdirectories should
9138 look like the one in Section C.3, "packages: Binary packages".
9140 C.5. current, pkgsrc-20xxQy: source packages
9142 These directories contain the "real" pkgsrc, that is the files that define how
9143 to create binary packages from source archives.
9145 The directory pkgsrc contains a snapshot of the CVS repository, which is
9146 updated regularly. The file pkgsrc.tar.gz contains the same as the directory,
9147 ready to be downloaded as a whole.
9149 In the directories for the quarterly branches, there is an additional file
9150 called pkgsrc-20xxQy.tar.gz, which contains the state of pkgsrc when it was
9153 Appendix D. Editing guidelines for the pkgsrc guide
9160 This section contains information on editing the pkgsrc guide itself.
9164 The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several
9165 files are created from it:
9167 * pkgsrc/doc/pkgsrc.txt
9169 * pkgsrc/doc/pkgsrc.html
9171 * http://www.NetBSD.org/docs/pkgsrc/
9173 * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.pdf: The PDF version of the pkgsrc
9176 * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps: PostScript version of the
9181 The procedure to edit the pkgsrc guide is:
9183 1. Make sure you have the packages needed to regenerate the pkgsrc guide (and
9184 other XML-based NetBSD documentation) installed. These are meta-pkgs/
9185 netbsd-doc for creating the ASCII and HTML versions, and meta-pkgs/
9186 netbsd-doc-print for the PostScript and PDF versions. You will need both
9187 packages installed, to make sure documentation is consistent across all
9190 2. Run cd doc/guide to get to the right directory. All further steps will take
9193 3. Edit the XML file(s) in files/.
9195 4. Run bmake to check the pkgsrc guide for valid XML and to build the final
9196 output files. If you get any errors at this stage, you can just edit the
9197 files, as there are only symbolic links in the working directory, pointing
9198 to the files in files/.
9200 5. (cd files && cvs commit)
9202 6. Run bmake clean && bmake to regenerate the output files with the proper RCS
9205 7. Run bmake regen to install and commit the files in both pkgsrc/doc and
9210 If you have added, removed or renamed some chapters, you need to
9211 synchronize them using cvs add or cvs delete in the htdocs directory.