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. bootstrap-pkgsrc: Bootstrap kits
446 C.2. distfiles: The distributed source files
447 C.3. iso: Currently empty
448 C.4. misc: Miscellaneous things
449 C.5. packages: Binary packages
450 C.6. reports: Bulk build reports
451 C.7. current, pkgsrc-200xQy: source packages
453 D. Editing guidelines for the pkgsrc guide
460 1.1. Platforms supported by pkgsrc
461 11.1. Patching examples
462 23.1. PLIST handling for GNOME packages
464 Chapter 1. What is pkgsrc?
471 1.1.2. Supported platforms
476 1.3.1. Roles involved in pkgsrc
482 There is a lot of software freely available for Unix-based systems, which is
483 usually available in form of the source code. Before such software can be used,
484 it needs to be configured to the local system, compiled and installed, and this
485 is exactly what The NetBSD Packages Collection (pkgsrc) does. pkgsrc also has
486 some basic commands to handle binary packages, so that not every user has to
487 build the packages for himself, which is a time-costly task.
489 pkgsrc currently contains several thousand packages, including:
491 * www/apache - The Apache web server
493 * www/firefox - The Firefox web browser
495 * meta-pkgs/gnome - The GNOME Desktop Environment
497 * meta-pkgs/kde3 - The K Desktop Environment
499 ...just to name a few.
501 pkgsrc has built-in support for handling varying dependencies, such as pthreads
502 and X11, and extended features such as IPv6 support on a range of platforms.
506 pkgsrc provides the following key features:
508 * Easy building of software from source as well as the creation and
509 installation of binary packages. The source and latest patches are
510 retrieved from a master or mirror download site, checksum verified, then
511 built on your system. Support for binary-only distributions is available
512 for both native platforms and NetBSD emulated platforms.
514 * All packages are installed in a consistent directory tree, including
515 binaries, libraries, man pages and other documentation.
517 * Package dependencies, including when performing package updates, are
518 handled automatically. The configuration files of various packages are
519 handled automatically during updates, so local changes are preserved.
521 * Like NetBSD, pkgsrc is designed with portability in mind and consists of
522 highly portable code. This allows the greatest speed of development when
523 porting to new a platform. This portability also ensures that pkgsrc is
524 consistent across all platforms.
526 * The installation prefix, acceptable software licenses, international
527 encryption requirements and build-time options for a large number of
528 packages are all set in a simple, central configuration file.
530 * The entire source (not including the distribution files) is freely
531 available under a BSD license, so you may extend and adapt pkgsrc to your
532 needs. Support for local packages and patches is available right out of the
533 box, so you can configure it specifically for your environment.
535 The following principles are basic to pkgsrc:
537 * "It should only work if it's right." ? That means, if a package contains
538 bugs, it's better to find them and to complain about them rather than to
539 just install the package and hope that it works. There are numerous checks
540 in pkgsrc that try to find such bugs: Static analysis tools (pkgtools/
541 pkglint), build-time checks (portability of shell scripts), and
542 post-installation checks (installed files, references to shared libraries,
543 script interpreters).
545 * "If it works, it should work everywhere" ? Like NetBSD has been ported to
546 many hardware architectures, pkgsrc has been ported to many operating
547 systems. Care is taken that packages behave the same on all platforms.
549 1.1.2. Supported platforms
551 pkgsrc consists of both a source distribution and a binary distribution for
552 these operating systems. After retrieving the required source or binaries, you
553 can be up and running with pkgsrc in just minutes!
555 pkgsrc was derived from FreeBSD's ports system, and initially developed for
556 NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
559 Table 1.1. Platforms supported by pkgsrc
561 +----------------------------------------------------------------+
562 | Platform |Date Support Added|
563 |---------------------------------------------+------------------|
565 |---------------------------------------------+------------------|
566 |Solaris | Mar 1999 |
567 |---------------------------------------------+------------------|
569 |---------------------------------------------+------------------|
570 |Darwin (Mac OS X) | Oct 2001 |
571 |---------------------------------------------+------------------|
572 |FreeBSD | Nov 2002 |
573 |---------------------------------------------+------------------|
574 |OpenBSD | Nov 2002 |
575 |---------------------------------------------+------------------|
577 |---------------------------------------------+------------------|
579 |---------------------------------------------+------------------|
581 |---------------------------------------------+------------------|
582 |Interix (Microsoft Windows Services for Unix)| Mar 2004 |
583 |---------------------------------------------+------------------|
584 |DragonFlyBSD | Oct 2004 |
585 |---------------------------------------------+------------------|
587 |---------------------------------------------+------------------|
589 +----------------------------------------------------------------+
594 This document is divided into three parts. The first, The pkgsrc user's guide,
595 describes how one can use one of the packages in the Package Collection, either
596 by installing a precompiled binary package, or by building one's own copy using
597 the NetBSD package system. The second part, The pkgsrc developer's guide,
598 explains how to prepare a package so it can be easily built by other NetBSD
599 users without knowing about the package's building details. The third part, The
600 pkgsrc infrastructure internals is intended for those who want to understand
601 how pkgsrc is implemented.
603 This document is available in various formats: HTML, PDF, PS, TXT.
607 There has been a lot of talk about "ports", "packages", etc. so far. Here is a
608 description of all the terminology used within this document.
612 A set of files and building instructions that describe what's necessary to
613 build a certain piece of software using pkgsrc. Packages are traditionally
614 stored under /usr/pkgsrc.
616 The NetBSD package system
618 This is the former name of "pkgsrc". It is part of the NetBSD operating
619 system and can be bootstrapped to run on non-NetBSD operating systems as
620 well. It handles building (compiling), installing, and removing of
625 This term describes the file or files that are provided by the author of
626 the piece of software to distribute his work. All the changes necessary to
627 build on NetBSD are reflected in the corresponding package. Usually the
628 distfile is in the form of a compressed tar-archive, but other types are
629 possible, too. Distfiles are usually stored below /usr/pkgsrc/distfiles.
633 This is the term used by FreeBSD and OpenBSD people for what we call a
634 package. In NetBSD terminology, "port" refers to a different architecture.
636 Precompiled/binary package
638 A set of binaries built with pkgsrc from a distfile and stuffed together in
639 a single .tgz file so it can be installed on machines of the same machine
640 architecture without the need to recompile. Packages are usually generated
641 in /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.
643 Sometimes, this is referred to by the term "package" too, especially in the
644 context of precompiled packages.
648 The piece of software to be installed which will be constructed from all
649 the files in the distfile by the actions defined in the corresponding
652 1.3.1. Roles involved in pkgsrc
656 The pkgsrc users are people who use the packages provided by pkgsrc.
657 Typically they are system administrators. The people using the software
658 that is inside the packages (maybe called "end users") are not covered by
661 There are two kinds of pkgsrc users: Some only want to install pre-built
662 binary packages. Others build the pkgsrc packages from source, either for
663 installing them directly or for building binary packages themselves. For
664 pkgsrc users Part I, "The pkgsrc user's guide" should provide all necessary
669 A package maintainer creates packages as described in Part II, "The pkgsrc
672 infrastructure developers
674 These people are involved in all those files that live in the mk/ directory
675 and below. Only these people should need to read through Part III, "The
676 pkgsrc infrastructure internals", though others might be curious, too.
680 When giving examples for commands, shell prompts are used to show if the
681 command should/can be issued as root, or if "normal" user privileges are
682 sufficient. We use a # for root's shell prompt, and a % for users' shell
683 prompt, assuming they use the C-shell or tcsh.
685 Part I. The pkgsrc user's guide
689 2. Where to get pkgsrc and how to keep it up-to-date
691 2.1. Getting pkgsrc for the first time
695 2.1.3. Via anonymous CVS
697 2.2. Keeping pkgsrc up-to-date
702 3. Using pkgsrc on systems other than NetBSD
704 3.1. Binary distribution
705 3.2. Bootstrapping pkgsrc
706 3.3. Platform-specific notes
708 3.3.1. Darwin (Mac OS X)
718 4.1. Using binary packages
720 4.1.1. Finding binary packages
721 4.1.2. Installing binary packages
722 4.1.3. Deinstalling packages
723 4.1.4. Getting information about installed packages
724 4.1.5. Checking for security vulnerabilities in installed packages
725 4.1.6. Finding if newer versions of your installed packages are in
727 4.1.7. Other administrative functions
728 4.1.8. A word of warning
730 4.2. Building packages from source
733 4.2.2. Fetching distfiles
734 4.2.3. How to build and install
736 5. Configuring pkgsrc
738 5.1. General configuration
739 5.2. Variables affecting the build process
740 5.3. Variables affecting the installation process
741 5.4. Selecting and configuring the compiler
743 5.4.1. Selecting the compiler
744 5.4.2. Additional flags to the compiler (CFLAGS)
745 5.4.3. Additional flags to the linker (LDFLAGS)
747 5.5. Developer/advanced settings
748 5.6. Selecting Build Options
750 6. Creating binary packages
752 6.1. Building a single binary package
753 6.2. Settings for creation of binary packages
755 7. Creating binary packages for everything in pkgsrc (bulk builds)
757 7.1. Think first, build later
758 7.2. Requirements of a bulk build
759 7.3. Running an old-style bulk build
762 7.3.2. Other environmental considerations
765 7.3.5. Disk space requirements
766 7.3.6. Setting up a sandbox for chrooted builds
767 7.3.7. Building a partial set of packages
768 7.3.8. Uploading results of a bulk build
770 7.4. Running a pbulk-style bulk build
775 7.5. Creating a multiple CD-ROM packages collection
777 7.5.1. Example of cdpack
779 8. Directory layout of the installed files
781 8.1. File system layout in ${LOCALBASE}
782 8.2. File system layout in ${VARBASE}
784 9. Frequently Asked Questions
786 9.1. Are there any mailing lists for pkg-related discussion?
787 9.2. Where's the pkgviews documentation?
788 9.3. Utilities for package management (pkgtools)
789 9.4. How to use pkgsrc as non-root
790 9.5. How to resume transfers when fetching distfiles?
791 9.6. How can I install/use modular X.org from pkgsrc?
792 9.7. How to fetch files from behind a firewall
793 9.8. How do I tell make fetch to do passive FTP?
794 9.9. How to fetch all distfiles at once
795 9.10. What does Don't know how to make /usr/share/tmac/tmac.andoc mean?
796 9.11. What does Could not find bsd.own.mk mean?
797 9.12. Using 'sudo' with pkgsrc
798 9.13. How do I change the location of configuration files?
799 9.14. Automated security checks
800 9.15. Why do some packages ignore my CFLAGS?
801 9.16. A package does not build. What shall I do?
802 9.17. What does Makefile appears to contain unresolved cvs/rcs/??? merge
805 Chapter 2. Where to get pkgsrc and how to keep it up-to-date
809 2.1. Getting pkgsrc for the first time
813 2.1.3. Via anonymous CVS
815 2.2. Keeping pkgsrc up-to-date
820 Before you download and extract the files, you need to decide where you want to
821 extract them. When using pkgsrc as root user, pkgsrc is usually installed in /
822 usr/pkgsrc. You are though free to install the sources and binary packages
823 wherever you want in your filesystem, provided that the pathname does not
824 contain white-space or other characters that are interpreted specially by the
825 shell and some other programs. A safe bet is to use only letters, digits,
826 underscores and dashes.
828 2.1. Getting pkgsrc for the first time
830 Before you download any pkgsrc files, you should decide whether you want the
831 current branch or the stable branch. The latter is forked on a quarterly basis
832 from the current branch and only gets modified for security updates. The names
833 of the stable branches are built from the year and the quarter, for example
836 The second step is to decide how you want to download pkgsrc. You can get it as
837 a tar file, via SUP, or via CVS. All three ways are described here.
841 The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/
842 pkgsrc/. There are a number of subdirectories for different purposes, which are
843 described in detail in Appendix C, Directory layout of the pkgsrc FTP server.
845 The tar file for the current branch is in the directory current and is called
846 pkgsrc.tar.gz. It is autogenerated daily.
848 The tar file for the stable branch 2009Q1 is in the directory pkgsrc-2009Q1 and
849 is also called pkgsrc-2009Q1.tar.gz.
851 To download a pkgsrc stable tarball, run:
853 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-200xQy/pkgsrc-200xQy.tar.gz
855 Where pkgsrc-200xQy is the stable branch to be downloaded, for example,
858 Then, extract it with:
860 $ tar -xzf pkgsrc-200xQy.tar.gz -C /usr
862 This will create the directory pkgsrc/ in /usr/ and all the package source will
863 be stored under /usr/pkgsrc/.
865 To download pkgsrc-current, run:
867 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
871 As an alternative to the tar file, you can get pkgsrc via the Software Update
872 Protocol, SUP. To do so, make sure your supfile has a line
876 in it, see the examples in /usr/share/examples/supfiles, and that the /usr/
877 pkgsrc directory exists. Then, simply run:
879 $ sup -v /path/to/your/supfile.
881 2.1.3. Via anonymous CVS
883 To do an initial (full) checkout of pkgsrc, you first have to set some
884 environment variables. For the C-Shell, type:
886 % setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot
889 Or, the same for the bourne shell:
891 $ export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"
892 $ export CVS_RSH="ssh"
894 By default, CVS doesn't do things like most people would expect it to do. But
895 there is a way to convince CVS, by creating a file called .cvsrc in your home
896 directory and saving the following lines to it. This file will save you lots of
897 headache and some bug reports, so we strongly recommend it. You can find an
898 explanation of this file in the CVS documentation.
900 # recommended CVS configuration file from the pkgsrc guide
908 To fetch a specific pkgsrc stable branch from scratch, run:
911 $ cvs checkout -r pkgsrc-200xQy -P pkgsrc
913 Where pkgsrc-200xQy is the stable branch to be checked out, for example,
916 This will create the directory pkgsrc/ in your /usr/ directory and all the
917 package source will be stored under /usr/pkgsrc/.
919 To fetch the pkgsrc current branch, run:
922 $ cvs checkout -P pkgsrc
924 2.2. Keeping pkgsrc up-to-date
926 The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you
927 have first installed it via a tar file). It saves bandwidth and hard disk
928 activity, compared to downloading the tar file again.
934 When updating from a tar file, you first need to completely remove the old
935 pkgsrc directory. Otherwise those files that have been removed from pkgsrc in
936 the mean time will not be removed on your local disk, resulting in
937 inconsistencies. When removing the old files, any changes that you have done to
938 the pkgsrc files will be lost after updating. Therefore updating via CVS is
939 strongly recommended.
941 Note that by default the distfiles and the binary packages are saved in the
942 pkgsrc tree, so don't forget to rescue them before updating. You can also
943 configure pkgsrc to use other than the default directories by setting the
944 DISTDIR and PACKAGES variables. See Chapter 5, Configuring pkgsrc for the
947 To update pkgsrc from a tar file, download the tar file as explained above.
948 Then, make sure that you have not made any changes to the files in the pkgsrc
949 directory. Remove the pkgsrc directory and extract the new tar file. Done.
953 To update pkgsrc via CVS, make sure the environment variable CVS_RSH is set as
954 above. Then, change to the pkgsrc directory and run cvs:
959 2.2.2.1. Switching between different pkgsrc branches
961 When updating pkgsrc, the CVS program keeps track of the branch you selected.
962 But if you, for whatever reason, want to switch from the stable branch to the
963 current one, you can do it by adding the option "-A" after the "update"
964 keyword. To switch from the current branch back to the stable branch, add the
965 "-rpkgsrc-2009Q1" option.
967 2.2.2.2. What happens to my changes when updating?
969 When you update pkgsrc, the CVS program will only touch those files that are
970 registered in the CVS repository. That means that any packages that you created
971 on your own will stay unmodified. If you change files that are managed by CVS,
972 later updates will try to merge your changes with those that have been done by
973 others. See the CVS manual, chapter "update" for details.
975 Chapter 3. Using pkgsrc on systems other than NetBSD
979 3.1. Binary distribution
980 3.2. Bootstrapping pkgsrc
981 3.3. Platform-specific notes
983 3.3.1. Darwin (Mac OS X)
991 3.1. Binary distribution
993 See Section 4.1, "Using binary packages".
995 3.2. Bootstrapping pkgsrc
997 Installing the bootstrap kit from source should be as simple as:
999 # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
1000 # cd pkgsrc/bootstrap
1004 See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways
1005 to get pkgsrc before bootstrapping. The given bootstrap command will use the
1006 defaults of /usr/pkg for the prefix where programs will be installed in, and /
1007 var/db/pkg for the package database directory where pkgsrc will do its internal
1008 bookkeeping. However, these can also be set using command-line arguments.
1012 The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
1013 For examples in this guide, use bmake instead of "make".
1015 3.3. Platform-specific notes
1017 Here are some platform-specific notes you should be aware of.
1019 3.3.1. Darwin (Mac OS X)
1021 Darwin 5.x and up are supported. There are two methods of using pkgsrc on Mac
1022 OS X, by using a disk image, or a UFS or HFSX partition.
1024 Before you start, you will need to download and install the Mac OS X Developer
1025 Tools from Apple's Developer Connection. See http://developer.apple.com/macosx/
1026 for details. Also, make sure you install X11 for Mac OS X and the X11 SDK from
1027 http://www.apple.com/macosx/x11/download/ if you intend to build packages that
1028 use the X11 Window System.
1030 If you already have a UFS or HFSX partition, or have a spare partition that you
1031 can format as UFS or HFSX, it is recommended to use that instead of the disk
1032 image. It'll be somewhat faster and will mount automatically at boot time,
1033 where you must manually mount a disk image.
1037 You cannot use an ordinary HFS+ file system for pkgsrc, because pkgsrc
1038 currently requires the file system to be case-sensitive. You can, however, use
1039 a case-sensitive HFS+ (aka HFSX) file system as found in Darwin 7.0 and newer.
1041 3.3.1.1. Using a disk image
1043 Create the disk image:
1045 # cd pkgsrc/bootstrap
1046 # ./darwindiskimage create ~/Documents/NetBSD 1024 # megabytes - season to taste
1047 # ./darwindiskimage mount ~/Documents/NetBSD
1048 # sudo chown `id -u`:`id -g` /Volumes/NetBSD
1052 darwindiskimage will mount the filesystem nosuid, which will cause problems for
1053 packages that depend on setgid. In the case of UFS, it will also mount the
1054 filesystem asynchronous, which is somewhat dangerous according to the mount(8)
1055 man page. In the case of HFSX, it will disable journaling.
1059 # sudo mount -u -o suid /Volumes/NetBSD
1061 Changing the build directory:
1063 After bootstrapping you need to change the default package build directory to
1064 somewhere outside the disk image so it doesn't get filled up in the process of
1065 building packages. Add something like that to mk.conf.
1067 WRKOBJDIR?= /tmp/pkgsrc # build here instead of in pkgsrc
1070 3.3.1.2. Using a UFS or HFSX partition
1072 By default, /usr will be on your root file system, normally HFS+. It is
1073 possible to use the default prefix of /usr/pkg by symlinking /usr/pkg to a
1074 directory on a UFS or HFSX file system. Obviously, another symlink is required
1075 if you want to place the package database directory outside the prefix. e.g.
1077 # ./bootstrap --pkgdbdir /usr/pkg/pkgdb
1079 If you created your partitions at the time of installing Mac OS X and formatted
1080 the target partition as UFS or HFSX, it should automatically mount on /Volumes/
1081 <volume name> when the machine boots. If you are (re)formatting a partition as
1082 UFS or HFSX, you need to ensure that the partition map correctly reflects
1083 "Apple_UFS" or "Apple_HFSX" and not "Apple_HFS".
1085 The problem is that none of the disk tools will let you touch a disk that is
1086 booted from. You can unmount the partition, but even if you newfs it, the
1087 partition type will be incorrect and the automounter won't mount it. It can be
1088 mounted manually, but it won't appear in Finder.
1090 You'll need to boot off of the OS X Installation (User) CD. When the
1091 Installation program starts, go up to the menu and select Disk Utility. Now,
1092 you will be able to select the partition you want to be UFS or HFSX, and Format
1093 it Apple UFS or HFSX. Quit the Disk Utility, quit the installer which will
1094 reboot your machine. The new UFS or HFSX file system will appear in Finder.
1096 Be aware that the permissions on the new file system will be writable by root
1099 This note is as of 10.2 (Jaguar) and applies to earlier versions. Hopefully
1100 Apple will fix Disk Utility in 10.3 (Panther).
1104 FreeBSD 4.7 and 5.0 have been tested and are supported, other versions may
1107 Care should be taken so that the tools that this kit installs do not conflict
1108 with the FreeBSD userland tools. There are several steps:
1110 1. FreeBSD stores its ports pkg database in /var/db/pkg. It is therefore
1111 recommended that you choose a different location (e.g. /usr/pkgdb) by using
1112 the --pkgdbdir option to the bootstrap script.
1114 2. If you do not intend to use the FreeBSD ports tools, it's probably a good
1115 idea to move them out of the way to avoid confusion, e.g.
1118 # mv pkg_add pkg_add.orig
1119 # mv pkg_create pkg_create.orig
1120 # mv pkg_delete pkg_delete.orig
1121 # mv pkg_info pkg_info.orig
1124 3. An example mk.conf file will be placed in /etc/mk.conf.example file when
1125 you use the bootstrap script.
1129 Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a
1130 Unix-like environment with a tighter kernel integration than available with
1131 Cygwin. It is part of the Windows Services for Unix package, available for free
1132 for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU
1133 can be downloaded from http://www.microsoft.com/windows/sfu/.
1135 Services for Unix 3.5 has been tested. 3.0 or 3.1 may work, but are not
1136 officially supported. (The main difference in 3.0/3.1 is lack of pthreads, but
1137 other parts of libc may also be lacking.)
1139 Services for Unix Applications (aka SUA) is an integrated component of Windows
1140 Server 2003 R2 and Windows Vista. As of this writing, SUA's Interix 5.x
1141 subsystem has not yet been tested with pkgsrc.
1143 3.3.3.1. When installing Interix/SFU
1145 At an absolute minimum, the following packages must be installed from the
1146 Windows Services for Unix 3.5 distribution in order to use pkgsrc:
1148 * Utilities -> Base Utilities
1150 * Interix GNU Components -> (all)
1152 * Remote Connectivity
1156 When using pkgsrc on Interix, DO NOT install the Utilities subcomponent "UNIX
1157 Perl". That is Perl 5.6 without shared module support, installed to /usr/local,
1158 and will only cause confusion. Instead, install Perl 5.8 from pkgsrc (or from a
1161 The Remote Connectivity subcomponent "Windows Remote Shell Service" does not
1162 need to be installed, but Remote Connectivity itself should be installed in
1163 order to have a working inetd.
1165 During installation you may be asked whether to enable setuid behavior for
1166 Interix programs, and whether to make pathnames default to case-sensitive.
1167 Setuid should be enabled, and case-sensitivity MUST be enabled. (Without
1168 case-sensitivity, a large number of packages including perl will not build.)
1170 NOTE: Newer Windows service packs change the way binary execution works (via
1171 the Data Execution Prevention feature). In order to use pkgsrc and other
1172 gcc-compiled binaries reliably, a hotfix containing POSIX.EXE, PSXDLL.DLL,
1173 PSXRUN.EXE, and PSXSS.EXE (899522 or newer) must be installed. Hotfixes are
1174 available from Microsoft through a support contract; however, Debian Interix
1175 Port has made most Interix hotfixes available for personal use from http://
1176 www.debian-interix.net/hotfixes/.
1178 In addition to the hotfix noted above, it may be necessary to disable Data
1179 Execution Prevention entirely to make Interix functional. This may happen only
1180 with certain types of CPUs; the cause is not fully understood at this time. If
1181 gcc or other applications still segfault repeatedly after installing one of the
1182 hotfixes note above, the following option can be added to the appropriate
1183 "boot.ini" line on the Windows boot drive: /NoExecute=AlwaysOff (WARNING, this
1184 will disable DEP completely, which may be a security risk if applications are
1185 often run as a user in the Administrators group!)
1187 3.3.3.2. What to do if Interix/SFU is already installed
1189 If SFU is already installed and you wish to alter these settings to work with
1190 pkgsrc, note the following things.
1192 * To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft Windows
1193 Services for UNIX, then click Change. In the installer, choose Add or
1194 Remove, then uncheck Utilities->UNIX Perl.
1196 * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change
1197 the following registry key:
1199 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
1201 Set the DWORD value "obcaseinsensitive" to 0; then reboot.
1203 * To enable setuid binaries (optional), run REGEDIT.EXE, and change the
1204 following registry key:
1206 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX
1208 Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.
1210 3.3.3.3. Important notes for using pkgsrc
1212 The package manager (either the pkgsrc "su" user, or the user running
1213 "pkg_add") must be a member of the local Administrators group. Such a user must
1214 also be used to run the bootstrap. This is slightly relaxed from the normal
1215 pkgsrc requirement of "root".
1217 The package manager should use a umask of 002. "make install" will
1218 automatically complain if this is not the case. This ensures that directories
1219 written in /var/db/pkg are Administrators-group writeable.
1221 The popular Interix binary packages from http://www.interopsystems.com/ use an
1222 older version of pkgsrc's pkg_* tools. Ideally, these should NOT be used in
1223 conjunction with pkgsrc. If you choose to use them at the same time as the
1224 pkgsrc packages, ensure that you use the proper pkg_* tools for each type of
1227 The TERM setting used for DOS-type console windows (including those invoked by
1228 the csh and ksh startup shortcuts) is "interix". Most systems don't have a
1229 termcap/terminfo entry for it, but the following .termcap entry provides
1230 adequate emulation in most cases:
1232 interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
1235 3.3.3.4. Limitations of the Interix platform
1237 Though Interix suffices as a familiar and flexible substitute for a full
1238 Unix-like platform, it has some drawbacks that should be noted for those
1239 desiring to make the most of Interix.
1243 Interix comes with the standard set of X11R6 client libraries, and can run
1244 X11 based applications, but it does not come with an X server. Some options
1245 are StarNet X-Win32, Hummingbird Exceed (available in a trimmed version for
1246 Interix from Interop Systems as the Interop X Server), and the free X11
1247 server included with Cygwin.
1251 Because Interix runs in a completely different NT subsystem from Win32
1252 applications, it does not currently support various X11 protocol extensions
1253 for acceleration (such as MIT-SHM or DGA). Most interactive applications to
1254 a local X server will run reasonably fast, but full motion video and other
1255 graphics intensive applications may require a faster-than-expected CPU.
1259 Interix has no native support for audio output. For audio support, pkgsrc
1260 uses the esound client/server audio system on Interix. Unlike on most
1261 platforms, the audio/esound package does not contain the esd server
1262 component. To output audio via an Interix host, the emulators/cygwin_esound
1263 package must also be installed.
1265 * CD/DVDs, USB, and SCSI:
1267 Direct device access is not currently supported in Interix, so it is not
1268 currently possible to access CD/DVD drives, USB devices, or SCSI devices
1269 through non-filesystem means. Among other things, this makes it impossible
1270 to use Interix directly for CD/DVD burning.
1274 Due to the same limitations as for CD-ROMs and SCSI devices, tape drives
1275 are also not directly accessible in Interix. However, support is in work to
1276 make tape drive access possible by using Cygwin as a bridge (similarly to
1277 audio bridged via Cygwin's esound server).
1279 3.3.3.5. Known issues for pkgsrc on Interix
1281 It is not necessary, in general, to have a "root" user on the Windows system;
1282 any member of the local Administrators group will suffice. However, some
1283 packages currently assume that the user named "root" is the privileged user. To
1284 accommodate these, you may create such a user; make sure it is in the local
1285 group Administrators (or your language equivalent).
1287 pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time
1288 being, install packages as the local Administrator (or your language
1289 equivalent), or run the following command after installing a package to work
1292 # chmod -R g+w $PKG_DBDIR
1297 You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro
1298 compiler (cc/c89). Please set the CC environment variable according to your
1299 preference. If you do not have a license for the MIPSpro compiler suite, you
1300 can download a gcc tardist file from http://freeware.sgi.com/.
1302 Please note that you will need IRIX 6.5.17 or higher, as this is the earliest
1303 version of IRIX providing support for if_indextoname(3), if_nametoindex(3),
1306 At this point in time, pkgsrc only supports one ABI at a time. That is, you
1307 cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit
1308 ABI. If you start out using "abi=n32", that's what all your packages will be
1311 Therefore, please make sure that you have no conflicting CFLAGS in your
1312 environment or the mk.conf. Particularly, make sure that you do not try to link
1313 n32 object files with lib64 or vice versa. Check your /etc/compiler.defaults!
1315 If you have the actual pkgsrc tree mounted via NFS from a different host,
1316 please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX
1317 linker occasionally runs into issues when trying to link over a network-mounted
1320 The bootstrapping process should set all the right options for programs such as
1321 imake(1), but you may want to set some options depending on your local setup.
1322 Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages
1325 If you are using SGI's MIPSPro compiler, please set
1327 PKGSRC_COMPILER= mipspro
1330 in mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up
1331 passing invalid flags to the compiler. Note that bootstrap should create an
1332 appropriate mk.conf.example by default.
1334 If you have both the MIPSPro compiler chain installed as well as gcc, but want
1335 to make sure that MIPSPro is used, please set your PATH to not include the
1336 location of gcc (often /usr/freeware/bin), and (important) pass the
1337 '--preserve-path' flag.
1341 Some versions of Linux (for example Debian GNU/Linux) need either libtermcap or
1342 libcurses (libncurses). Installing the distributions libncurses-dev package (or
1343 equivalent) should fix the problem.
1345 pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++
1346 Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested.
1348 To bootstrap using icc, assuming the default icc installation directory:
1350 env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \
1351 ac_cv___attribute__=yes ./bootstrap
1356 icc 8.1 needs the `-i-static' argument instead of -static-libcxa.
1358 icc supports __attribute__, but the GNU configure test uses a nested function,
1359 which icc does not support. #undef'ing __attribute__ has the unfortunate
1360 side-effect of breaking many of the Linux header files, which cannot be
1361 compiled properly without __attribute__. The test must be overridden so that
1362 __attribute__ is assumed supported by the compiler.
1364 After bootstrapping, you should set PKGSRC_COMPILER in mk.conf:
1366 PKGSRC_COMPILER= icc
1369 The default installation directory for icc is /opt/intel_cc_80, which is also
1370 the pkgsrc default. If you have installed it into a different directory, set
1376 pkgsrc uses the static linking method of the runtime libraries provided by icc,
1377 so binaries can be run on other systems which do not have the shared libraries
1380 Libtool, however, extracts a list of libraries from the ld(1) command run when
1381 linking a C++ shared library and records it, throwing away the -Bstatic and
1382 -Bdynamic options interspersed between the libraries. This means that
1383 libtool-linked C++ shared libraries will have a runtime dependency on the icc
1384 libraries until this is fixed in libtool.
1388 OpenBSD 3.0 and 3.2 are tested and supported.
1390 Care should be taken so that the tools that this kit installs do not conflict
1391 with the OpenBSD userland tools. There are several steps:
1393 1. OpenBSD stores its ports pkg database in /var/db/pkg. It is therefore
1394 recommended that you choose a different location (e.g. /usr/pkgdb) by using
1395 the --pkgdbdir option to the bootstrap script.
1397 2. If you do not intend to use the OpenBSD ports tools, it's probably a good
1398 idea to move them out of the way to avoid confusion, e.g.
1401 # mv pkg_add pkg_add.orig
1402 # mv pkg_create pkg_create.orig
1403 # mv pkg_delete pkg_delete.orig
1404 # mv pkg_info pkg_info.orig
1407 3. An example mk.conf file will be placed in /etc/mk.conf.example file when
1408 you use the bootstrap script. OpenBSD's make program uses mk.conf as well.
1409 You can work around this by enclosing all the pkgsrc-specific parts of the
1413 # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
1421 Solaris 2.6 through 9 are supported on both x86 and sparc. You will need a
1422 working C compiler. Both gcc 2.95.3 and Sun WorkShop 5 have been tested.
1424 The following packages are required on Solaris 8 for the bootstrap process and
1437 Please note that the use of GNU binutils on Solaris is not supported, as of
1440 Whichever compiler you use, please ensure the compiler tools and your $prefix
1441 are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/
1444 3.3.7.1. If you are using gcc
1446 It makes life much simpler if you only use the same gcc consistently for
1447 building all packages.
1449 It is recommended that an external gcc be used only for bootstrapping, then
1450 either build gcc from lang/gcc or install a binary gcc package, then remove gcc
1451 used during bootstrapping.
1453 Binary packages of gcc can be found through http://www.sunfreeware.com/.
1455 3.3.7.2. If you are using Sun WorkShop
1457 You will need at least the following packages installed (from WorkShop 5.0)
1459 * SPROcc - Sun WorkShop Compiler C 5.0
1461 * SPROcpl - Sun WorkShop Compiler C++ 5.0
1463 * SPROild - Sun WorkShop Incremental Linker
1465 * SPROlang - Sun WorkShop Compilers common components
1467 You should set the following variables in your mk.conf file:
1476 The CPP setting might break some packages that use the C preprocessor for
1477 processing things other than C source code.
1479 3.3.7.3. Building 64-bit binaries with SunPro
1481 To build 64-bit packages, you just need to have the following lines in your
1484 PKGSRC_COMPILER= sunpro
1489 This setting has been tested for the SPARC architecture. Intel and AMD machines
1490 need some more work.
1492 3.3.7.4. Common problems
1494 Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The
1495 workaround is to use another shell for the configure scripts, for example by
1496 installing shells/bash and adding the following lines to your mk.conf:
1498 CONFIG_SHELL= ${LOCALBASE}/bin/bash
1499 WRAPPER_SHELL= ${LOCALBASE}/bin/bash
1502 Then, rebuild the devel/libtool-base package.
1504 Chapter 4. Using pkgsrc
1508 4.1. Using binary packages
1510 4.1.1. Finding binary packages
1511 4.1.2. Installing binary packages
1512 4.1.3. Deinstalling packages
1513 4.1.4. Getting information about installed packages
1514 4.1.5. Checking for security vulnerabilities in installed packages
1515 4.1.6. Finding if newer versions of your installed packages are in pkgsrc
1516 4.1.7. Other administrative functions
1517 4.1.8. A word of warning
1519 4.2. Building packages from source
1522 4.2.2. Fetching distfiles
1523 4.2.3. How to build and install
1525 Basically, there are two ways of using pkgsrc. The first is to only install the
1526 package tools and to use binary packages that someone else has prepared. This
1527 is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
1528 Then you are able to build your own packages, and you can still use binary
1529 packages from someone else.
1531 4.1. Using binary packages
1533 On the ftp.NetBSD.org server and its mirrors, there are collections of binary
1534 packages, ready to be installed. These binary packages have been built using
1535 the default settings for the directories, that is:
1537 * /usr/pkg for LOCALBASE, where most of the files are installed,
1539 * /usr/pkg/etc for configuration files,
1541 * /var for VARBASE, where those files are installed that may change after
1544 If you cannot use these directories for whatever reasons (maybe because you're
1545 not root), you cannot use these binary packages, but have to build the packages
1546 yourself, which is explained in Section 3.2, "Bootstrapping pkgsrc".
1548 4.1.1. Finding binary packages
1550 To install binary packages, you first need to know from where to get them. The
1551 first place where you should look is on the main pkgsrc FTP server in the
1552 directory /pub/pkgsrc/packages.
1554 This directory contains binary packages for multiple platforms. First, select
1555 your operating system. (Ignore the directories with version numbers attached to
1556 it, they just exist for legacy reasons.) Then, select your hardware
1557 architecture, and in the third step, the OS version and the "version" of
1560 In this directory, you often find a file called bootstrap.tar.gz which contains
1561 the package management tools. If the file is missing, it is likely that your
1562 operating system already provides those tools. Download the file and extract it
1563 in the / directory. It will create the directories /usr/pkg (containing the
1564 tools for managing binary packages) and /var/db/pkg (the database of installed
1567 4.1.2. Installing binary packages
1569 In the directory from the last section, there is a subdirectory called All,
1570 which contains all the binary packages that are available for the platform,
1571 excluding those that may not be distributed via FTP or CDROM (depending on
1572 which medium you are using), and the ones that have vulnerabilities and
1573 therefore are considered insecure to install without thinking before.
1575 To install packages directly from an FTP or HTTP server, run the following
1576 commands in a Bourne-compatible shell (be sure to su to root first):
1578 # PATH="/usr/pkg/sbin:$PATH"
1579 # PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All"
1580 # export PATH PKG_PATH
1582 Instead of URLs, you can also use local paths, for example if you are
1583 installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want
1584 to install packages from multiple sources, you can separate them by a semicolon
1587 After these preparations, installing a package is very easy:
1589 # pkg_add openoffice2
1591 # pkg_add ap2-php5-*
1593 Note that any prerequisite packages needed to run the package in question will
1594 be installed, too, assuming they are present where you install from.
1596 As mentioned above, packages for which vulnerabilities get known are not stored
1597 in the All subdirectory. They don't get deleted since that could be very
1598 frustrating if many other packages depend on it. Instead, they are moved to the
1599 vulnerable subdirectory. So you may need to add this directory to the PKG_PATH
1600 variable. However, you should run pkg_admin audit regularly, especially after
1601 installing new packages, and verify that the vulnerabilities are acceptable for
1604 After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
1605 in your PATH so you can actually start the just installed program.
1607 4.1.3. Deinstalling packages
1609 To deinstall a package, it does not matter whether it was installed from source
1610 code or from a binary package. The pkg_delete command does not know it anyway.
1611 To delete a package, you can just run pkg_delete package-name. The package name
1612 can be given with or without version number. Wildcards can also be used to
1613 deinstall a set of packages, for example *emacs*. Be sure to include them in
1614 quotes, so that the shell does not expand them before pkg_delete sees them.
1616 The -r option is very powerful: it removes all the packages that require the
1617 package in question and then removes the package itself. For example:
1619 # pkg_delete -r jpeg
1622 will remove jpeg and all the packages that used it; this allows upgrading the
1625 4.1.4. Getting information about installed packages
1627 The pkg_info shows information about installed packages or binary package
1630 4.1.5. Checking for security vulnerabilities in installed packages
1632 The NetBSD Security-Officer and Packages Groups maintain a list of known
1633 security vulnerabilities to packages which are (or have been) included in
1634 pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/
1635 pub/pkgsrc/distfiles/vulnerabilities.
1637 Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded
1638 automatically, and a security audit of all packages installed on a system can
1641 There are two components to auditing. The first step, pkg_admin
1642 fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
1643 the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of
1644 your installed packages are vulnerable. If a package is vulnerable, you will
1645 see output similar to the following:
1647 Package samba-2.0.9 has a local-root-shell vulnerability, see
1648 http://www.samba.org/samba/whatsnew/macroexploit.html
1650 You may wish to have the vulnerabilities file downloaded daily so that it
1651 remains current. This may be done by adding an appropriate entry to the root
1652 users crontab(5) entry. For example the entry
1654 # download vulnerabilities file
1655 0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
1658 will update the vulnerability list every day at 3AM. You may wish to do this
1659 more often than once a day. In addition, you may wish to run the package audit
1660 from the daily security script. This may be accomplished by adding the
1661 following line to /etc/security.local:
1663 /usr/sbin/pkg_admin audit
1666 4.1.6. Finding if newer versions of your installed packages are in pkgsrc
1668 Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
1669 if your packages are up-to-date, e.g.
1673 Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
1676 You can then use make update to update the package on your system and rebuild
1679 4.1.7. Other administrative functions
1681 The pkg_admin executes various administrative functions on the package system.
1683 4.1.8. A word of warning
1685 Please pay very careful attention to the warnings expressed in the pkg_add(1)
1686 manual page about the inherent dangers of installing binary packages which you
1687 did not create yourself, and the security holes that can be introduced onto
1688 your system by indiscriminate adding of such files.
1690 The same warning of course applies to every package you install from source
1691 when you haven't completely read and understood the source code of the package,
1692 the compiler that is used to build the package and all the other tools that are
1695 4.2. Building packages from source
1697 After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
1698 organized into categories. You can browse the online index of packages, or run
1699 make readme from the pkgsrc directory to build local README.html files for all
1700 packages, viewable with any web browser such as www/lynx or www/firefox.
1702 The default prefix for installed packages is /usr/pkg. If you wish to change
1703 this, you should do so by setting LOCALBASE in mk.conf. You should not try to
1704 use multiple different LOCALBASE definitions on the same system (inside a
1705 chroot is an exception).
1707 The rest of this chapter assumes that the package is already in pkgsrc. If it
1708 is not, see Part II, "The pkgsrc developer's guide" for instructions how to
1709 create your own packages.
1713 To build packages from source, you need a working C compiler. On NetBSD, you
1714 need to install the "comp" and the "text" distribution sets. If you want to
1715 build X11-related packages, the "xbase" and "xcomp" distribution sets are
1718 4.2.2. Fetching distfiles
1720 The first step for building a package is downloading the distfiles (i.e. the
1721 unmodified source). If they have not yet been downloaded, pkgsrc will fetch
1724 If you have all files that you need in the distfiles directory, you don't need
1725 to connect. If the distfiles are on CD-ROM, you can mount the CD-ROM on /cdrom
1728 DISTDIR=/cdrom/pkgsrc/distfiles
1732 By default a list of distribution sites will be randomly intermixed to prevent
1733 huge load on servers which holding popular packages (for example,
1734 SourceForge.net mirrors). Thus, every time when you need to fetch yet another
1735 distfile all the mirrors will be tried in new (random) order. You can turn this
1736 feature off by setting MASTER_SORT_RANDOM=NO (for PKG_DEVELOPERs it's already
1739 You can overwrite some of the major distribution sites to fit to sites that are
1740 close to your own. By setting one or two variables you can modify the order in
1741 which the master sites are accessed. MASTER_SORT contains a whitespace
1742 delimited list of domain suffixes. MASTER_SORT_REGEX is even more flexible, it
1743 contains a whitespace delimited list of regular expressions. It has higher
1744 priority than MASTER_SORT. Have a look at pkgsrc/mk/defaults/mk.conf to find
1745 some examples. This may save some of your bandwidth and time.
1747 You can change these settings either in your shell's environment, or, if you
1748 want to keep the settings, by editing the mk.conf file, and adding the
1751 If a package depends on many other packages (such as meta-pkgs/kde3), the build
1752 process may alternate between periods of downloading source, and compiling. To
1753 ensure you have all the source downloaded initially you can run the command:
1755 % make fetch-list | sh
1757 which will output and run a set of shell commands to fetch the necessary files
1758 into the distfiles directory. You can also choose to download the files
1761 4.2.3. How to build and install
1763 Once the software has downloaded, any patches will be applied, then it will be
1764 compiled for you. This may take some time depending on your computer, and how
1765 many other packages the software depends on and their compile time.
1769 If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
1770 command instead of "make" in the examples in this guide.
1778 at the shell prompt to build the various components of the package.
1780 The next stage is to actually install the newly compiled program onto your
1781 system. Do this by entering:
1786 while you are still in the directory for whatever package you are installing.
1788 Installing the package on your system may require you to be root. However,
1789 pkgsrc has a just-in-time-su feature, which allows you to only become root for
1790 the actual installation step.
1792 That's it, the software should now be installed and setup for use. You can now
1798 to remove the compiled files in the work directory, as you shouldn't need them
1799 any more. If other packages were also added to your system (dependencies) to
1800 allow your program to compile, you can tidy these up also with the command:
1802 % make clean-depends
1805 Taking the figlet utility as an example, we can install it on our system by
1806 building as shown in Appendix B, Build logs.
1808 The program is installed under the default root of the packages tree - /usr/
1809 pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
1810 environment, and it will use that value as the root of your packages tree. So,
1811 to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
1812 that you should use a directory which is dedicated to packages and not shared
1813 with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
1814 not try to add any of your own files or directories (such as src/, obj/, or
1815 pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
1816 between programs and other files installed by the package system and whatever
1817 else may have been installed there.
1819 Some packages look in mk.conf to alter some configuration options at build
1820 time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will
1821 be set there by default. Environment variables such as LOCALBASE can be set in
1822 mk.conf to save having to remember to set them each time you want to use
1825 Occasionally, people want to "look under the covers" to see what is going on
1826 when a package is building or being installed. This may be for debugging
1827 purposes, or out of simple curiosity. A number of utility values have been
1828 added to help with this.
1830 1. If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a huge
1831 amount of information will be displayed. For example,
1833 make patch PKG_DEBUG_LEVEL=2
1835 will show all the commands that are invoked, up to and including the
1838 2. If you want to know the value of a certain make(1) definition, then the
1839 VARNAME definition should be used, in conjunction with the show-var target.
1840 e.g. to show the expansion of the make(1) variable LOCALBASE:
1842 % make show-var VARNAME=LOCALBASE
1847 If you want to install a binary package that you've either created yourself
1848 (see next section), that you put into pkgsrc/packages manually or that is
1849 located on a remote FTP server, you can use the "bin-install" target. This
1850 target will install a binary package - if available - via pkg_add(1), else do a
1851 make package. The list of remote FTP sites searched is kept in the variable
1852 BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
1853 to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
1856 A final word of warning: If you set up a system that has a non-standard setting
1857 for LOCALBASE, be sure to set that before any packages are installed, as you
1858 cannot use several directories for the same purpose. Doing so will result in
1859 pkgsrc not being able to properly detect your installed packages, and fail
1860 miserably. Note also that precompiled binary packages are usually built with
1861 the default LOCALBASE of /usr/pkg, and that you should not install any if you
1862 use a non-standard LOCALBASE.
1864 Chapter 5. Configuring pkgsrc
1868 5.1. General configuration
1869 5.2. Variables affecting the build process
1870 5.3. Variables affecting the installation process
1871 5.4. Selecting and configuring the compiler
1873 5.4.1. Selecting the compiler
1874 5.4.2. Additional flags to the compiler (CFLAGS)
1875 5.4.3. Additional flags to the linker (LDFLAGS)
1877 5.5. Developer/advanced settings
1878 5.6. Selecting Build Options
1880 The whole pkgsrc system is configured in a single file, usually called mk.conf.
1881 In which directory pkgsrc looks for that file depends on the installation. On
1882 NetBSD, when you use make(1) from the base system, it is in the directory /etc
1883 /. In all other cases the default location is ${PREFIX}/etc/, depending on
1884 where you told the bootstrap program to install the binary packages.
1886 During the bootstrap, an example configuration file is created. To use that,
1887 you have to create the directory ${PREFIX}/etc and copy the example file there.
1889 The format of the configuration file is that of the usual BSD-style Makefiles.
1890 The whole pkgsrc configuration is done by setting variables in this file. Note
1891 that you can define all kinds of variables, and no special error checking (for
1892 example for spelling mistakes) takes place, so you have to try it out to see if
1895 5.1. General configuration
1897 In this section, you can find some variables that apply to all pkgsrc packages.
1898 A complete list of the variables that can be configured by the user is
1899 available in mk/defaults/mk.conf, together with some comments that describe
1900 each variable's intent.
1902 * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
1903 not mix binary packages with different LOCALBASEs!
1905 * CROSSBASE: Where "cross" category packages will be installed. The default
1906 is ${LOCALBASE}/cross.
1908 * X11BASE: Where X11 is installed on the system. The default is /usr/X11R6.
1910 * DISTDIR: Where to store the downloaded copies of the original source
1911 distributions used for building pkgsrc packages. The default is $
1912 {PKGSRCDIR}/distfiles.
1914 * PKG_DBDIR: Where the database about installed packages is stored. The
1915 default is /var/db/pkg.
1917 * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
1920 * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
1921 files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
1922 respectively. The defaults are ftp://ftp.NetBSD.org/pub/NetBSD/packages/
1923 distfiles/${DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$
1926 * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
1927 with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
1929 * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
1930 case-sensitive. Whenever you try to build a package whose license is not in
1931 this list, you will get an error message. If the license condition is
1932 simple enough, the error message will include specific instructions on how
1933 to change this variable.
1935 5.2. Variables affecting the build process
1939 * PACKAGES: The top level directory for the binary packages. The default is $
1940 {PKGSRCDIR}/packages.
1942 * WRKOBJDIR: The top level directory where, if defined, the separate working
1943 directories will get created, and symbolically linked to from ${WRKDIR}
1944 (see below). This is useful for building packages on several architectures,
1945 then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
1946 architecture. (It should be noted that PKGSRCDIR should not be set by the
1947 user ? it is an internal definition which refers to the root of the pkgsrc
1948 tree. It is possible to have many pkgsrc tree instances.)
1950 * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
1951 Section 11.3, "patches/*" for more information.
1953 * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
1954 Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
1955 up settings used by builds in /usr/src.
1957 * DEPENDS_TARGET: By default, dependencies are only installed, and no binary
1958 package is created for them. You can set this variable to package to
1959 automatically create binary packages after installing dependencies.
1961 5.3. Variables affecting the installation process
1963 A growing number of packages support installation into a subdirectory of
1964 WRKDIR. This allows a package to be built, before the actual filesystem is
1965 touched. DESTDIR support exists in two variations:
1967 * Basic DESTDIR support means that the package installation and packaging is
1970 * Full DESTDIR support can run the complete build, installation and packaging
1971 as normal user. Root privileges are only needed to add packages.
1973 To use the DESTDIR support, set USE_DESTDIR=yes to get the full support for
1974 packages that support it and with fallback to basic support.
1976 DESTDIR support changes the behaviour of various targets slightly. To install a
1977 package after building it, use package-install. package and install don't do
1978 that any longer. package-install can be used as DEPENDS_TARGET. bin-install
1979 will ask for the root password to install the package and fail, package-install
1982 With basic DESTDIR support, make clean needs to be run as root.
1984 Considering the foo/bar package, DESTDIR full support can be tested using the
1988 uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
1989 $ mkdir $HOME/packages
1990 $ cd $PKGSRCDIR/foo/bar
1992 Verify DESTDIR full support, no root privileges should be needed
1994 $ make USE_DESTDIR=yes install
1996 Create a package without root privileges
1998 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package
2000 For the following command, you must be able to gain root privileges using su(1)
2002 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install
2004 Then, as a simple user
2008 5.4. Selecting and configuring the compiler
2010 5.4.1. Selecting the compiler
2012 By default, pkgsrc will use GCC to build packages. This may be overridden by
2013 setting the following variables in /etc/mk.conf:
2017 This is a list of values specifying the chain of compilers to invoke when
2018 building packages. Valid values are:
2020 * distcc: distributed C/C++ (chainable)
2022 * ccache: compiler cache (chainable)
2024 * gcc: GNU C/C++ Compiler
2026 * mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)
2028 * mipspro: Silicon Graphics, Inc. MIPSpro (o32)
2030 * sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio
2032 The default is "gcc". You can use ccache and/or distcc with an appropriate
2033 PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
2034 terminated with a value for a real compiler. Note that only one real
2035 compiler should be listed (e.g. "sunpro gcc" is not allowed).
2039 This specifies the minimum version of GCC to use when building packages. If
2040 the system GCC doesn't satisfy this requirement, then pkgsrc will build and
2041 install one of the GCC packages to use instead.
2043 5.4.2. Additional flags to the compiler (CFLAGS)
2045 If you wish to set the CFLAGS variable, please make sure to use the += operator
2046 instead of the = operator:
2048 CFLAGS+= -your -flags
2050 Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
2051 need to add their own flags. You may want to take a look at the devel/cpuflags
2052 package if you're interested in optimization for the current CPU. Setting
2053 USE_CPUFLAGS to yes in mk.conf will cause pkgsrc to automatically use cpuflags.
2055 5.4.3. Additional flags to the linker (LDFLAGS)
2057 If you want to pass flags to the linker, both in the configure step and the
2058 build step, you can do this in two ways. Either set LDFLAGS or LIBS. The
2059 difference between the two is that LIBS will be appended to the command line,
2060 while LDFLAGS come earlier. LDFLAGS is pre-loaded with rpath settings for ELF
2061 machines depending on the setting of USE_IMAKE or the inclusion of mk/
2062 x11.buildlink3.mk. As with CFLAGS, if you do not wish to override these
2063 settings, use the += operator:
2065 LDFLAGS+= -your -linkerflags
2067 5.5. Developer/advanced settings
2071 * PKG_DEVELOPER: Run some sanity checks that package developers want:
2073 o make sure patches apply with zero fuzz
2075 o run check-shlibs to see that all binaries will find their shared libs.
2077 * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst
2078 making and installing the package. The default value for this is 0, which
2079 will not display the commands as they are executed (normal, default, quiet
2080 operation); the value 1 will display all shell commands before their
2081 invocation, and the value 2 will display both the shell commands before
2082 their invocation, and their actual execution progress with set -x will be
2085 5.6. Selecting Build Options
2087 Some packages have build time options, usually to select between different
2088 dependencies, enable optional support for big dependencies or enable
2089 experimental features.
2091 To see which options, if any, a package supports, and which options are
2092 mutually exclusive, run make show-options, for example:
2094 The following options are supported by this package:
2095 ssl Enable SSL support.
2096 Exactly one of the following gecko options is required:
2097 firefox Use firefox as gecko rendering engine.
2098 mozilla Use mozilla as gecko rendering engine.
2099 At most one of the following database options may be selected:
2100 mysql Enable support for MySQL database.
2101 pgsql Enable support for PostgreSQL database.
2103 These options are enabled by default: firefox
2104 These options are currently enabled: mozilla ssl
2106 The following variables can be defined in mk.conf to select which options to
2107 enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
2108 disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
2109 which can be used to select or disable options specifically for package pkgbase
2110 . Options listed in these variables are selected, options preceded by "-" are
2111 disabled. A few examples:
2113 $ grep "PKG.*OPTION" mk.conf
2114 PKG_DEFAULT_OPTIONS= -arts -dvdread -esound
2115 PKG_OPTIONS.kdebase= debug -sasl
2116 PKG_OPTIONS.apache= suexec
2118 It is important to note that options that were specifically suggested by the
2119 package maintainer must be explicitly removed if you do not wish to include the
2120 option. If you are unsure you can view the current state with make show-options
2123 The following settings are consulted in the order given, and the last setting
2124 that selects or disables an option is used:
2126 1. the default options as suggested by the package maintainer
2128 2. the options implied by the settings of legacy variables (see below)
2130 3. PKG_DEFAULT_OPTIONS
2132 4. PKG_OPTIONS.pkgbase
2134 For groups of mutually exclusive options, the last option selected is used, all
2135 others are automatically disabled. If an option of the group is explicitly
2136 disabled, the previously selected option, if any, is used. It is an error if no
2137 option from a required group of options is selected, and building the package
2140 Before the options framework was introduced, build options were selected by
2141 setting a variable (often named USE_FOO) in mk.conf for each option. To ease
2142 transition to the options framework for the user, these legacy variables are
2143 converted to the appropriate options setting (PKG_OPTIONS.pkgbase)
2144 automatically. A warning is issued to prompt the user to update mk.conf to use
2145 the options framework directly. Support for the legacy variables will be
2148 Chapter 6. Creating binary packages
2152 6.1. Building a single binary package
2153 6.2. Settings for creation of binary packages
2155 6.1. Building a single binary package
2157 Once you have built and installed a package, you can create a binary package
2158 which can be installed on another system with pkg_add(1). This saves having to
2159 build the same package on a group of hosts and wasting CPU time. It also
2160 provides a simple means for others to install your package, should you
2163 To create a binary package, change into the appropriate directory in pkgsrc,
2164 and run make package:
2170 This will build and install your package (if not already done), and then build
2171 a binary package from what was installed. You can then use the pkg_* tools to
2172 manipulate it. Binary packages are created by default in /usr/pkgsrc/packages,
2173 in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a
2174 continuation of the above misc/figlet example.
2176 See Chapter 21, Submitting and Committing for information on how to submit such
2179 6.2. Settings for creation of binary packages
2181 See Section 17.17, "Other helpful targets".
2183 Chapter 7. Creating binary packages for everything in pkgsrc (bulk builds)
2187 7.1. Think first, build later
2188 7.2. Requirements of a bulk build
2189 7.3. Running an old-style bulk build
2191 7.3.1. Configuration
2192 7.3.2. Other environmental considerations
2195 7.3.5. Disk space requirements
2196 7.3.6. Setting up a sandbox for chrooted builds
2197 7.3.7. Building a partial set of packages
2198 7.3.8. Uploading results of a bulk build
2200 7.4. Running a pbulk-style bulk build
2203 7.4.2. Configuration
2205 7.5. Creating a multiple CD-ROM packages collection
2207 7.5.1. Example of cdpack
2209 When you have multiple machines that should run the same packages, it is wasted
2210 time if they all build their packages themselves from source. There are two
2211 ways of getting a set of binary packages: The old bulk build system, or the new
2212 (as of 2007) parallel bulk build (pbulk) system. This chapter describes how to
2213 set them up so that the packages are most likely to be usable later.
2215 7.1. Think first, build later
2217 Since a bulk build takes several days or even weeks to finish, you should think
2218 about the setup before you start everything. Pay attention to at least the
2221 * If you want to upload the binary packages to ftp.NetBSD.org, make sure the
2222 setup complies to the requirements for binary packages:
2224 o To end up on ftp.NetBSD.org, the packages must be built by a NetBSD
2225 developer on a trusted machine (that is, where you and only you have
2228 o Packages on ftp.NetBSD.org should only be created from the stable
2229 branches (like 2009Q1), so that users browsing the available
2230 collections can see at a glance how old the packages are.
2232 o The packages must be built as root, since some packages require set-uid
2233 binaries at runtime, and creating those packages as unprivileged user
2234 doesn't work well at the moment.
2236 * Make sure that the bulk build cannot break anything in your system. Most
2237 bulk builds run as root, so they should be run at least in a chroot
2238 environment or something even more restrictive, depending on what the
2239 operating system provides. There have been numerous cases where certain
2240 packages tried to install files outside the LOCALBASE or wanted to edit
2241 some files in /etc. Furthermore, the bulk builds install and deinstall
2242 packages in /usr/pkg (or whatever LOCALBASE is) during their operation, so
2243 be sure that you don't need any package during the build.
2245 7.2. Requirements of a bulk build
2247 A complete bulk build requires lots of disk space. Some of the disk space can
2248 be read-only, some other must be writable. Some can be on remote filesystems
2249 (such as NFS) and some should be local. Some can be temporary filesystems,
2250 others must survive a sudden reboot.
2252 * 10 GB for the distfiles (read-write, remote, temporary)
2254 * 10 GB for the binary packages (read-write, remote, permanent)
2256 * 400 MB for the pkgsrc tree (read-only, remote, permanent)
2258 * 5 GB for LOCALBASE (read-write, local, temporary for pbulk, permanent for
2261 * 5 GB for the log files (read-write, remote, permanent)
2263 * 5 GB for temporary files (read-write, local, temporary)
2265 7.3. Running an old-style bulk build
2269 There are two ways of doing a bulk build. The old-style one and the new-style
2270 "pbulk". The latter is the recommended way.
2272 7.3.1. Configuration
2276 The build.conf file is the main configuration file for bulk builds. You can
2277 configure how your copy of pkgsrc is kept up to date, how the distfiles are
2278 downloaded, how the packages are built and how the report is generated. You can
2279 find an annotated example file in pkgsrc/mk/bulk/build.conf-example. To use it,
2280 copy build.conf-example to build.conf and edit it, following the comments in
2285 You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf
2286 for details of the default settings. You will want to ensure that
2287 ACCEPTABLE_LICENSES meet your local policy. As used in this example,
2288 SKIP_LICENSE_CHECK=yes completely bypasses the license check.
2290 PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
2291 WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
2293 BSDXSRCDIR= /usr/xsrc # for x11/xservers
2294 OBJHOSTNAME?= yes # use work.`hostname`
2295 FAILOVER_FETCH= yes # insist on the correct checksum
2297 SKIP_LICENSE_CHECK= yes
2299 Some options that are especially useful for bulk builds can be found at the top
2300 lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are
2301 briefly described here.
2303 * If you are on a slow machine, you may want to set USE_BULK_BROKEN_CHECK to
2306 * If you are doing bulk builds from a read-only copy of pkgsrc, you have to
2307 set BULKFILESDIR to the directory where all log files are created.
2308 Otherwise the log files are created in the pkgsrc directory.
2310 * Another important variable is BULK_PREREQ, which is a list of packages that
2311 should be always available while building other packages.
2313 Some other options are scattered in the pkgsrc infrastructure:
2315 * ALLOW_VULNERABLE_PACKAGES should be set to yes. The purpose of the bulk
2316 builds is creating binary packages, no matter if they are vulnerable or
2317 not. When uploading the packages to a public server, the vulnerable
2318 packages will be put into a directory of their own. Leaving this variable
2319 unset would prevent the bulk build system from even trying to build them,
2320 so possible building errors would not show up.
2322 * CHECK_FILES (pkgsrc/mk/check/check-files.mk) can be set to "yes" to check
2323 that the installed set of files matches the PLIST.
2325 * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to
2326 "yes" to check that the installed "#!"-scripts will find their interpreter.
2328 * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before
2329 installing it. Note that some packages make heavy use of "good" random
2330 numbers, so you need to assure that the machine on which you are doing the
2331 bulk builds is not completely idle. Otherwise some test programs will seem
2332 to hang, while they are just waiting for new random data to be available.
2334 7.3.1.3. pre-build.local
2336 It is possible to configure the bulk build to perform certain site-specific
2337 tasks at the end of the pre-build stage. If the file pre-build.local exists in
2338 /usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the
2339 usual pre-build stage. An example use of pre-build.local is to have the line:
2341 echo "I do not have enough disk space to build this pig." \
2342 > misc/openoffice/$BROKENF
2344 to prevent the system from trying to build a particular package which requires
2345 nearly 3 GB of disk space.
2347 7.3.2. Other environmental considerations
2349 As /usr/pkg will be completely deleted at the start of bulk builds, make sure
2350 your login shell is placed somewhere else. Either drop it into /usr/local/bin
2351 (and adjust your login shell in the passwd file), or (re-)install it via
2352 pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that
2353 your current process won't die if the package is removed, you just can't start
2354 any new instances of the shell any more). Also, if you use NetBSD earlier than
2355 1.5, or you still want to use the pkgsrc version of ssh for some reason, be
2356 sure to install ssh before starting it from rc.local:
2358 (cd /usr/pkgsrc/security/ssh && make bulk-install)
2359 if [ -f /usr/pkg/etc/rc.d/sshd ]; then
2360 /usr/pkg/etc/rc.d/sshd
2363 Not doing so will result in you being not able to log in via ssh after the bulk
2364 build is finished or if the machine gets rebooted or crashes. You have been
2369 Make sure you don't need any of the packages still installed.
2373 During the bulk build, all packages, their configuration files and some more
2374 files from /var, /home and possibly other locations will be removed! So don't
2375 run a bulk build with privileges that might harm your system.
2377 Be sure to remove all other things that might interfere with builds, like some
2378 libs installed in /usr/local, etc. then become root and type:
2384 If for some reason your last build didn't complete (power failure, system
2385 panic, ...), you can continue it by running:
2387 # sh mk/bulk/build restart
2389 At the end of the bulk build, you will get a summary via mail, and find build
2390 logs in the directory specified by FTP in the build.conf file.
2394 The bulk builds consist of three steps:
2398 The script updates your pkgsrc tree via (anon)cvs, then cleans out any
2399 broken distfiles, and removes all packages installed.
2403 This is basically "make bulk-package" with an optimised order in which
2404 packages will be built. Packages that don't require other packages will be
2405 built first, and packages with many dependencies will be built later.
2409 Generates a report that's placed in the directory specified in the
2410 build.conf file named broken.html, a short version of that report will also
2411 be mailed to the build's admin.
2413 During the build, a list of broken packages will be compiled in /usr/pkgsrc
2414 /.broken (or .../.broken.${MACHINE} if OBJMACHINE is set), individual build
2415 logs of broken builds can be found in the package's directory. These files are
2416 used by the bulk-targets to mark broken builds to not waste time trying to
2417 rebuild them, and they can be used to debug these broken package builds later.
2419 7.3.5. Disk space requirements
2421 Currently, roughly the following requirements are valid for NetBSD 2.0/i386:
2423 * 10 GB - distfiles (NFS ok)
2425 * 8 GB - full set of all binaries (NFS ok)
2427 * 5 GB - temp space for compiling (local disk recommended)
2429 Note that all pkgs will be de-installed as soon as they are turned into a
2430 binary package, and that sources are removed, so there is no excessively huge
2431 demand to disk space. Afterwards, if the package is needed again, it will be
2432 installed via pkg_add(1) instead of building again, so there are no cycles
2433 wasted by recompiling.
2435 7.3.6. Setting up a sandbox for chrooted builds
2437 If you don't want all the packages nuked from a machine (rendering it useless
2438 for anything but pkg compiling), there is the possibility of doing the package
2439 bulk build inside a chroot environment.
2441 The first step is to set up a chroot sandbox, e.g. /usr/sandbox. This can be
2442 done by using null mounts, or manually.
2444 There is a shell script called pkgsrc/mk/bulk/mksandbox which will set up the
2445 sandbox environment using null mounts. It will also create a script called
2446 sandbox in the root of the sandbox environment, which will allow the null
2447 mounts to be activated using the sandbox mount command and deactivated using
2448 the sandbox umount command.
2450 To set up a sandbox environment by hand, after extracting all the sets from a
2451 NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in /usr/
2452 src/etc, be sure the following items are present and properly configured:
2456 # cp /netbsd /usr/sandbox
2460 # cd /usr/sandbox/dev ; sh MAKEDEV all
2462 3. /etc/resolv.conf (for security/smtpd and mail):
2464 # cp /etc/resolv.conf /usr/sandbox/etc
2466 4. Working(!) mail config (hostname, sendmail.cf):
2468 # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
2470 5. /etc/localtime (for security/smtpd):
2472 # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
2474 6. /usr/src (system sources, e. g. for sysutils/aperture):
2476 # ln -s ../disk1/cvs .
2477 # ln -s cvs/src-2.0 src
2479 7. Create /var/db/pkg (not part of default install):
2481 # mkdir /usr/sandbox/var/db/pkg
2483 8. Create /usr/pkg (not part of default install):
2485 # mkdir /usr/sandbox/usr/pkg
2487 9. Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:
2489 # cd /usr/sandbox/usr
2490 # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
2493 Do not mount/link this to the copy of your pkgsrc tree you do development
2494 in, as this will likely cause problems!
2496 10. Make /usr/sandbox/usr/pkgsrc/packages and .../distfiles point somewhere
2497 appropriate. NFS- and/or nullfs-mounts may come in handy!
2499 11. Edit mk.conf, see Section 7.3.1.2, "???".
2501 12. Adjust mk/bulk/build.conf to suit your needs.
2503 When the chroot sandbox is set up, you can start the build with the following
2506 # cd /usr/sandbox/usr/pkgsrc
2507 # sh mk/bulk/do-sandbox-build
2510 This will just jump inside the sandbox and start building. At the end of the
2511 build, mail will be sent with the results of the build. Created binary pkgs
2512 will be in /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/
2515 7.3.7. Building a partial set of packages
2517 In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk
2518 /bulk/build script may be used to build a subset of the packages contained in
2519 pkgsrc. By setting SPECIFIC_PKGS in mk.conf, the variables
2521 * SITE_SPECIFIC_PKGS
2523 * HOST_SPECIFIC_PKGS
2525 * GROUP_SPECIFIC_PKGS
2527 * USER_SPECIFIC_PKGS
2529 will define the set of packages which should be built. The bulk build code will
2530 also include any packages which are needed as dependencies for the explicitly
2533 One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
2534 periodically to have a complete set of the binary packages needed for your site
2535 available without the overhead of building extra packages that are not needed.
2537 7.3.8. Uploading results of a bulk build
2539 This section describes how pkgsrc developers can upload binary pkgs built by
2540 bulk builds to ftp.NetBSD.org.
2542 If you would like to automatically create checksum files for the binary
2543 packages you intend to upload, remember to set MKSUMS=yes in your mk/bulk/
2546 If you would like to PGP sign the checksum files (highly recommended!),
2547 remember to set SIGN_AS=username@NetBSD.org in your mk/bulk/build.conf. This
2548 will prompt you for your GPG password to sign the files before uploading
2551 Then, make sure that you have RSYNC_DST set properly in your mk/bulk/build.conf
2552 file, i.e. adjust it to something like one of the following:
2554 RSYNC_DST=ftp.NetBSD.org:/pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch/upload
2556 Please use appropriate values for "packages-200xQy", "NetBSD-a.b.c" and "arch"
2557 here. If your login on ftp.NetBSD.org is different from your local login, write
2558 your login directly into the variable, e.g. my local account is "feyrer", but
2559 for my login "hubertf", I use:
2561 RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch/upload
2563 A separate upload directory is used here to allow "closing" the directory
2564 during upload. To do so, run the following command on ftp.NetBSD.org next:
2566 nbftp% mkdir -p -m 750 /pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch/upload
2568 Please note that /pub/NetBSD/packages is only appropriate for packages for the
2569 NetBSD operating system. Binary packages for other operating systems should go
2572 Before uploading the binary pkgs, ssh authentication needs to be set up. This
2573 example shows how to set up temporary keys for the root account inside the
2574 sandbox (assuming that no keys should be present there usually):
2576 # chroot /usr/sandbox
2577 chroot-# rm $HOME/.ssh/id-dsa*
2578 chroot-# ssh-keygen -t dsa
2579 chroot-# cat $HOME/.ssh/id-dsa.pub
2582 Now take the output of id-dsa.pub and append it to your ~/.ssh/authorized_keys
2583 file on ftp.NetBSD.org. You can remove the key after the upload is done!
2585 Next, test if your ssh connection really works:
2587 chroot-# ssh ftp.NetBSD.org date
2589 Use "-l yourNetBSDlogin" here as appropriate!
2591 Now after all this works, you can exit the sandbox and start the upload:
2594 # cd /usr/sandbox/usr/pkgsrc
2595 # sh mk/bulk/do-sandbox-upload
2598 The upload process may take quite some time. Use ls(1) or du(1) on the FTP
2599 server to monitor progress of the upload. The upload script will take care of
2600 not uploading restricted packages and putting vulnerable packages into the
2601 vulnerable subdirectory.
2603 After the upload has ended, first thing is to revoke ssh access:
2605 nbftp% vi ~/.ssh/authorized_keys
2608 Use whatever is needed to remove the key you've entered before! Last, move the
2609 uploaded packages out of the upload directory to have them accessible to
2612 nbftp% cd /pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch
2613 nbftp% mv upload/* .
2618 7.4. Running a pbulk-style bulk build
2620 Running a pbulk-style bulk build works roughly as follows:
2622 * First, build the pbulk infrastructure in a fresh pkgsrc location.
2624 * Then, build each of the packages from a clean installation directory using
2629 First, you need to create a pkgsrc installation for the pbulk infrastructure.
2630 No matter on which platform you are (even on NetBSD), you should bootstrap into
2631 its own directory. Let's take the directory /usr/pbulk or $HOME/pbulk for it.
2632 This installation will be bootstrapped and all the tools that are required for
2633 the bulk build will be installed there.
2636 $ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap
2637 $ rm -rf /tmp/pbulk-bootstrap
2639 Now the basic environment for the pbulk infrastructure is installed. The
2640 specific tools are still missing. This is a good time to edit the pkgsrc
2641 configuration file /usr/pbulk/etc/mk.conf to fit your needs. Typical things you
2644 * PKG_DEVELOPER=yes, to enable many consistency checks,
2646 * WRKOBJDIR=/tmp/pbulk-outer, to keep /usr/pkgsrc free from any
2649 * DISTDIR=/distfiles, to have only one directory in which all distfiles (for
2650 the infrastructure and for the actual packages) are downloaded,
2652 * ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual
2653 Free/Open Source licenses that are acceptable to you,
2655 * SKIP_LICENSE_CHECK=yes, to bypass the license checks.
2657 Now you are ready to build the rest of the pbulk infrastructure.
2660 $ /usr/pbulk/bin/bmake install
2661 $ rm -rf /tmp/pbulk-outer
2663 Now the pbulk infrastructure is built and installed. It still needs to be
2664 configured, and after some more preparation, we will be able to start the real
2667 7.4.2. Configuration
2669 TODO; see pkgsrc/doc/HOWTO-pbulk for more information.
2671 TODO: continue writing
2673 7.5. Creating a multiple CD-ROM packages collection
2675 After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
2676 of the resulting binary packages to assist in installing packages on other
2677 machines. The pkgtools/cdpack package provides a simple tool for creating the
2678 ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
2679 keeps all the dependencies for a given package on the same CD as that package.
2681 7.5.1. Example of cdpack
2683 Complete documentation for cdpack is found in the cdpack(1) man page. The
2684 following short example assumes that the binary packages are left in /usr/
2685 pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
2689 # pkg_add /usr/pkgsrc/packages/All/cdpack
2690 # cdpack /usr/pkgsrc/packages/All /u2/images
2693 If you wish to include a common set of files (COPYRIGHT, README, etc.) on each
2694 CD in the collection, then you need to create a directory which contains these
2698 # echo "This is a README" > /tmp/common/README
2699 # echo "Another file" > /tmp/common/COPYING
2700 # mkdir /tmp/common/bin
2701 # echo "#!/bin/sh" > /tmp/common/bin/myscript
2702 # echo "echo Hello world" >> /tmp/common/bin/myscript
2703 # chmod 755 /tmp/common/bin/myscript
2706 Now create the images:
2708 # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
2710 Each image will contain README, COPYING, and bin/myscript in their root
2713 Chapter 8. Directory layout of the installed files
2717 8.1. File system layout in ${LOCALBASE}
2718 8.2. File system layout in ${VARBASE}
2720 The files that are installed by pkgsrc are organized in a way that is similar
2721 to what you find in the /usr directory of the base system. But some details are
2722 different. This is because pkgsrc initially came from FreeBSD and had adopted
2723 its file system hierarchy. Later it was largely influenced by NetBSD. But no
2724 matter which operating system you are using pkgsrc with, you can expect the
2725 same layout for pkgsrc.
2727 There are mainly four root directories for pkgsrc, which are all configurable
2728 in the bootstrap/bootstrap script. When pkgsrc has been installed as root, the
2729 default locations are:
2732 PKG_SYSCONFBASE= /usr/pkg/etc
2734 PKG_DBDIR= /var/db/pkg
2736 In unprivileged mode (when pkgsrc has been installed as any other user), the
2737 default locations are:
2739 LOCALBASE= ${HOME}/pkg
2740 PKG_SYSCONFBASE= ${HOME}/pkg/etc
2741 VARBASE= ${HOME}/pkg/var
2742 PKG_DBDIR= ${HOME}/pkg/var/db/pkg
2744 What these four directories are for, and what they look like is explained
2747 * LOCALBASE corresponds to the /usr directory in the base system. It is the
2748 "main" directory where the files are installed and contains the well-known
2749 subdirectories like bin, include, lib, share and sbin.
2751 * VARBASE corresponds to /var in the base system. Some programs (especially
2752 games, network daemons) need write access to it during normal operation.
2754 * PKG_SYSCONFDIR corresponds to /etc in the base system. It contains
2755 configuration files of the packages, as well as pkgsrc's mk.conf itself.
2757 8.1. File system layout in ${LOCALBASE}
2759 The following directories exist in a typical pkgsrc installation in $
2764 Contains executable programs that are intended to be directly used by the
2769 Contains files for the emulation layers of various other operating systems,
2770 especially for NetBSD.
2772 etc (the usual location of ${PKG_SYSCONFDIR})
2774 Contains the configuration files.
2778 Contains headers for the C and C++ programming languages.
2782 Contains GNU info files of various packages.
2786 Contains shared and static libraries.
2790 Contains data files that don't change after installation. Other data files
2791 belong into ${VARBASE}.
2795 Contains programs that are not intended to be used by end users, such as
2796 helper programs or network daemons.
2800 Contains programs that are intended to be executed as CGI scripts by a web
2803 man (the usual value of ${PKGMANDIR})
2805 Contains brief documentation in form of manual pages.
2809 Contains programs that are intended to be used only by the super-user.
2813 Contains platform-independent data files that don't change after
2818 Contains documentation files provided by the packages.
2822 Contains example files provided by the packages. Among others, the original
2823 configuration files are saved here and copied to ${PKG_SYSCONFDIR} during
2828 Contains the original files for rc.d scripts.
2830 var (the usual location of ${VARBASE})
2832 Contains files that may be modified after installation.
2834 8.2. File system layout in ${VARBASE}
2836 db/pkg (the usual location of ${PKG_DBDIR})
2838 Contains information about the currently installed packages.
2842 Contains highscore files.
2850 Contains informational files about daemons that are currently running.
2852 Chapter 9. Frequently Asked Questions
2856 9.1. Are there any mailing lists for pkg-related discussion?
2857 9.2. Where's the pkgviews documentation?
2858 9.3. Utilities for package management (pkgtools)
2859 9.4. How to use pkgsrc as non-root
2860 9.5. How to resume transfers when fetching distfiles?
2861 9.6. How can I install/use modular X.org from pkgsrc?
2862 9.7. How to fetch files from behind a firewall
2863 9.8. How do I tell make fetch to do passive FTP?
2864 9.9. How to fetch all distfiles at once
2865 9.10. What does Don't know how to make /usr/share/tmac/tmac.andoc mean?
2866 9.11. What does Could not find bsd.own.mk mean?
2867 9.12. Using 'sudo' with pkgsrc
2868 9.13. How do I change the location of configuration files?
2869 9.14. Automated security checks
2870 9.15. Why do some packages ignore my CFLAGS?
2871 9.16. A package does not build. What shall I do?
2872 9.17. What does Makefile appears to contain unresolved cvs/rcs/??? merge
2875 This section contains hints, tips & tricks on special things in pkgsrc that we
2876 didn't find a better place for in the previous chapters, and it contains items
2877 for both pkgsrc users and developers.
2879 9.1. Are there any mailing lists for pkg-related discussion?
2881 The following mailing lists may be of interest to pkgsrc users:
2883 * pkgsrc-users: This is a general purpose list for most issues regarding
2884 pkgsrc, regardless of platform, e.g. soliciting user help for pkgsrc
2885 configuration, unexpected build failures, using particular packages,
2886 upgrading pkgsrc installations, questions regarding the pkgsrc release
2887 branches, etc. General announcements or proposals for changes that impact
2888 the pkgsrc user community, e.g. major infrastructure changes, new features,
2889 package removals, etc., may also be posted.
2891 * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and
2894 * pkgsrc-changes: This list is for those who are interested in getting a
2895 commit message for every change committed to pkgsrc. It is also available
2896 in digest form, meaning one daily message containing all commit messages
2897 for changes to the package source tree in that 24 hour period.
2901 % echo subscribe listname | mail majordomo@NetBSD.org
2903 Archives for all these mailing lists are available from http://
2904 mail-index.NetBSD.org/.
2906 9.2. Where's the pkgviews documentation?
2908 Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's
2909 guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.
2911 9.3. Utilities for package management (pkgtools)
2913 The directory pkgsrc/pkgtools contains a number of useful utilities for both
2914 users and developers of pkgsrc. This section attempts only to make the reader
2915 aware of the utilities and when they might be useful, and not to duplicate the
2916 documentation that comes with each package.
2918 Utilities used by pkgsrc (automatically installed when needed):
2920 * pkgtools/x11-links: Symlinks for use by buildlink.
2922 OS tool augmentation (automatically installed when needed):
2924 * pkgtools/digest: Calculates various kinds of checksums (including SHA1).
2926 * pkgtools/libnbcompat: Compatibility library for pkgsrc tools.
2928 * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree.
2930 * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or
2931 for use on operating systems where pkg_install is not present.
2933 Utilities used by pkgsrc (not automatically installed):
2935 * pkgtools/pkg_tarup: Create a binary package from an already-installed
2936 package. Used by make replace to save the old package.
2938 * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch
2939 distfiles from multiple locations. It currently supports the following
2940 methods: multiple CD-ROMs and network FTP/HTTP connections.
2942 * pkgtools/xpkgwedge: Put X11 packages someplace else (enabled by default).
2944 * devel/cpuflags: Determine the best compiler flags to optimise code for your
2945 current CPU and compiler. Setting USE_CPUFLAGS to yes in mk.conf will cause
2946 pkgsrc to automatically use cpuflags.
2948 Utilities for keeping track of installed packages, being up to date, etc:
2950 * pkgtools/pkg_chk: Reports on packages whose installed versions do not match
2951 the latest pkgsrc entries.
2953 * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a
2954 strategy for updating.
2956 * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses
2959 * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors.
2961 * pkgtools/lintpkgsrc: The lintpkgsrc(1) program does various checks on the
2962 complete pkgsrc system.
2964 * pkgtools/pkgsurvey: Report what packages you have installed.
2966 Utilities for people maintaining or creating individual packages:
2968 * pkgtools/pkgdiff: Automate making and maintaining patches for a package
2969 (includes pkgdiff, pkgvi, mkpatches, etc.).
2971 * pkgtools/rpm2pkg, pkgtools/url2pkg: Aids in converting to pkgsrc.
2973 * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package.
2975 Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
2977 * pkgtools/pkg_comp: Build packages in a chrooted area.
2979 * pkgtools/libkver: Spoof kernel version for chrooted cross builds.
2981 9.4. How to use pkgsrc as non-root
2983 If you want to use pkgsrc as non-root user, you can set some variables to make
2984 pkgsrc work under these conditions. At the very least, you need to set
2985 UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple
2986 related variables to allow installation of packages as non-root.
2988 In case the defaults are not enough, you may want to tune some other variables
2989 used. For example, if the automatic user/group detection leads to incorrect
2990 values (or not the ones you would like to use), you can change them by setting
2991 UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively.
2993 As regards bootstrapping, please note that the bootstrap script will ease
2994 non-root configuration when given the "--ignore-user-check" flag, as it will
2995 choose and use multiple default directories under ~/pkg as the installation
2996 targets. These directories can be overridden by the "--prefix" flag provided by
2997 the script, as well as some others that allow finer tuning of the tree layout.
2999 9.5. How to resume transfers when fetching distfiles?
3001 By default, resuming transfers in pkgsrc is disabled, but you can enable this
3002 feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
3003 a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.
3005 You can also use a different program than the default ftp(1) by changing the
3006 FETCH_USING variable. You can specify the program by using of ftp, fetch, wget
3007 or curl. Alternatively, fetching can be disabled by using the value manual. A
3008 value of custom disables the system defaults and dependency tracking for the
3009 fetch program. In that case you have to provide FETCH_CMD, FETCH_BEFORE_ARGS,
3010 FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.
3012 For example, if you want to use wget to download, you'll have to use something
3017 9.6. How can I install/use modular X.org from pkgsrc?
3019 If you want to use modular X.org from pkgsrc instead of your system's own X11
3020 (/usr/X11R6, /usr/openwin, ...) you will have to add the following line into
3027 The DragonFly operating system defaults to using modular X.org from pkgsrc.
3029 9.7. How to fetch files from behind a firewall
3031 If you are sitting behind a firewall which does not allow direct connections to
3032 Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
3033 is done using an environment variable in the form of a URL, e.g. in Amdahl, the
3034 machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
3035 the proxy port number. So the proxy environment variables are:
3037 ftp_proxy=ftp://orpheus.amdahl.com:80/
3038 http_proxy=http://orpheus.amdahl.com:80/
3040 9.8. How do I tell make fetch to do passive FTP?
3042 This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
3043 FETCH_CMD is assigned the first available command from the following list:
3045 * ${LOCALBASE}/bin/ftp
3049 On a default NetBSD installation, this will be /usr/bin/ftp, which
3050 automatically tries passive connections first, and falls back to active
3051 connections if the server refuses to do passive. For the other tools, add the
3052 following to your mk.conf file: PASSIVE_FETCH=1.
3054 Having that option present will prevent /usr/bin/ftp from falling back to
3057 9.9. How to fetch all distfiles at once
3059 You would like to download all the distfiles in a single batch from work or
3060 university, where you can't run a make fetch. There is an archive of distfiles
3061 on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
3063 The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
3064 subdirectories, carry the resulting list to your machine at work/school and use
3065 it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work,
3066 don't forget to set FETCH_CMD to something that fetches a URL:
3071 % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
3072 % scp /tmp/fetch.sh work:/tmp
3078 then tar up /tmp/distfiles and take it home.
3080 If you have a machine running NetBSD, and you want to get all distfiles (even
3081 ones that aren't for your machine architecture), you can do so by using the
3082 above-mentioned make fetch-list approach, or fetch the distfiles directly by
3085 % make mirror-distfiles
3087 If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can get
3088 everything by running:
3090 % make fetch NO_SKIP=yes
3092 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
3094 When compiling the pkgtools/pkg_install package, you get the error from make
3095 that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
3096 that you don't have installed the "text" set (nroff, ...) from the NetBSD base
3097 distribution on your machine. It is recommended to do that to format man pages.
3099 In the case of the pkgtools/pkg_install package, you can get away with setting
3100 NOMAN=YES either in the environment or in mk.conf.
3102 9.11. What does "Could not find bsd.own.mk" mean?
3104 You didn't install the compiler set, comp.tgz, when you installed your NetBSD
3105 machine. Please get and install it, by extracting it in /:
3108 # tar --unlink -zxvpf .../comp.tgz
3110 comp.tgz is part of every NetBSD release. Get the one that corresponds to your
3111 release (determine via uname -r).
3113 9.12. Using 'sudo' with pkgsrc
3115 When installing packages as non-root user and using the just-in-time su(1)
3116 feature of pkgsrc, it can become annoying to type in the root password for each
3117 required package installed. To avoid this, the sudo package can be used, which
3118 does password caching over a limited time. To use it, install sudo (either as
3119 binary package or from security/sudo) and then put the following into your
3120 mk.conf, somewhere after the definition of the LOCALBASE variable:
3122 .if exists(${LOCALBASE}/bin/sudo)
3123 SU_CMD= ${LOCALBASE}/bin/sudo /bin/sh -c
3126 9.13. How do I change the location of configuration files?
3128 As the system administrator, you can choose where configuration files are
3129 installed. The default settings make all these files go into ${PREFIX}/etc or
3130 some of its subdirectories; this may be suboptimal depending on your
3131 expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine
3132 configuration of the provided packages).
3134 In order to change the defaults, you can modify the PKG_SYSCONFBASE variable
3135 (in mk.conf) to point to your preferred configuration directory; some common
3136 examples include /etc or /etc/pkg.
3138 Furthermore, you can change this value on a per-package basis by setting the
3139 PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
3140 matches the name of the package you would like to modify, that is, the contents
3143 Note that after changing these settings, you must rebuild and reinstall any
3146 9.14. Automated security checks
3148 Please be aware that there can often be bugs in third-party software, and some
3149 of these bugs can leave a machine vulnerable to exploitation by attackers. In
3150 an effort to lessen the exposure, the NetBSD packages team maintains a database
3151 of known-exploits to packages which have at one time been included in pkgsrc.
3152 The database can be downloaded automatically, and a security audit of all
3153 packages installed on a system can take place. To do this, refer to the
3154 following two tools (installed as part of the pkgtools/pkg_install package):
3156 1. pkg_admin fetch-pkg-vulnerabilities, an easy way to download a list of the
3157 security vulnerabilities information. This list is kept up to date by the
3158 NetBSD security officer and the NetBSD packages team, and is distributed
3159 from the NetBSD ftp server:
3161 ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities
3163 2. pkg_admin audit, an easy way to audit the current machine, checking each
3164 vulnerability which is known. If a vulnerable package is installed, it will
3165 be shown by output to stdout, including a description of the type of
3166 vulnerability, and a URL containing more information.
3168 Use of these tools is strongly recommended! After "pkg_install" is installed,
3169 please read the package's message, which you can get by running pkg_info -D
3172 If this package is installed, pkgsrc builds will use it to perform a security
3173 check before building any package. See Section 5.2, "Variables affecting the
3174 build process" for ways to control this check.
3176 9.15. Why do some packages ignore my CFLAGS?
3178 When you add your own preferences to the CFLAGS variable in your mk.conf, these
3179 flags are passed in environment variables to the ./configure scripts and to
3180 make(1). Some package authors ignore the CFLAGS from the environment variable
3181 by overriding them in the Makefiles of their package.
3183 Currently there is no solution to this problem. If you really need the package
3184 to use your CFLAGS you should run make patch in the package directory and then
3185 inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly.
3186 Usually you can remove these lines. But be aware that some "smart" programmers
3187 write so bad code that it only works for the specific combination of CFLAGS
3190 9.16. A package does not build. What shall I do?
3192 1. Make sure that your copy of pkgsrc is consistent. A case that occurs often
3193 is that people only update pkgsrc in parts, because of performance reasons.
3194 Since pkgsrc is one large system, not a collection of many small systems,
3195 there are sometimes changes that only work when the whole pkgsrc tree is
3198 2. Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or
3199 ">>>>>>" in all your pkgsrc files.
3201 3. Make sure that you don't have old copies of the packages extracted. Run
3202 make clean clean-depends to verify this.
3204 4. If the problem still exists, write a mail to the pkgsrc-users mailing list.
3206 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
3209 You have modified a file from pkgsrc, and someone else has modified that same
3210 file afterwards in the CVS repository. Both changes are in the same region of
3211 the file, so when you updated pkgsrc, the cvs command marked the conflicting
3212 changes in the file. Because of these markers, the file is no longer a valid
3215 Have a look at that file, and if you don't need your local changes anymore, you
3216 can remove that file and run cvs -q update -dP in that directory to download
3217 the current version.
3219 Part II. The pkgsrc developer's guide
3221 This part of the book deals with creating and modifying packages. It starts
3222 with a "HOWTO"-like guide on creating a new package. The remaining chapters are
3223 more like a reference manual for pkgsrc.
3227 10. Creating a new pkgsrc package from scratch
3229 10.1. Common types of packages
3231 10.1.1. Perl modules
3232 10.1.2. KDE applications
3233 10.1.3. Python modules and programs
3237 10.2.1. How the www/nvu package came into pkgsrc
3239 11. Package components - files, directories and contents
3245 11.3.1. Structure of a single patch file
3246 11.3.2. Creating patch files
3247 11.3.3. Sources where the patch files come from
3248 11.3.4. Patching guidelines
3249 11.3.5. Feedback to the author
3251 11.4. Other mandatory files
3252 11.5. Optional files
3254 11.5.1. Files affecting the binary package
3255 11.5.2. Files affecting the build process
3256 11.5.3. Files affecting nothing at all
3261 12. Programming in Makefiles
3264 12.2. Makefile variables
3266 12.2.1. Naming conventions
3270 12.3.1. Adding things to a list
3271 12.3.2. Converting an internal list into an external list
3272 12.3.3. Passing variables to a shell command
3273 12.3.4. Quoting guideline
3274 12.3.5. Workaround for a bug in BSD Make
3279 13.2. Semi-automatic PLIST generation
3280 13.3. Tweaking output of make print-PLIST
3281 13.4. Variable substitution in PLIST
3282 13.5. Man page compression
3283 13.6. Changing PLIST source with PLIST_SRC
3284 13.7. Platform-specific and differing PLISTs
3285 13.8. Sharing directories between packages
3287 14. Buildlink methodology
3289 14.1. Converting packages to use buildlink3
3290 14.2. Writing buildlink3.mk files
3292 14.2.1. Anatomy of a buildlink3.mk file
3293 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
3295 14.3. Writing builtin.mk files
3297 14.3.1. Anatomy of a builtin.mk file
3298 14.3.2. Global preferences for native or pkgsrc software
3300 15. The pkginstall framework
3302 15.1. Files and directories outside the installation prefix
3304 15.1.1. Directory manipulation
3305 15.1.2. File manipulation
3307 15.2. Configuration files
3309 15.2.1. How PKG_SYSCONFDIR is set
3310 15.2.2. Telling the software where configuration files are
3311 15.2.3. Patching installations
3312 15.2.4. Disabling handling of configuration files
3314 15.3. System startup scripts
3316 15.3.1. Disabling handling of system startup scripts
3318 15.4. System users and groups
3321 15.5.1. Disabling shell registration
3325 15.6.1. Disabling automatic update of the fonts databases
3327 16. Options handling
3329 16.1. Global default options
3330 16.2. Converting packages to use bsd.options.mk
3332 16.4. Determining the options of dependencies
3334 17. The build process
3337 17.2. Program location
3338 17.3. Directories used during the build process
3339 17.4. Running a phase
3340 17.5. The fetch phase
3342 17.5.1. What to fetch and where to get it from
3343 17.5.2. How are the files fetched?
3345 17.6. The checksum phase
3346 17.7. The extract phase
3347 17.8. The patch phase
3348 17.9. The tools phase
3349 17.10. The wrapper phase
3350 17.11. The configure phase
3351 17.12. The build phase
3352 17.13. The test phase
3353 17.14. The install phase
3354 17.15. The package phase
3356 17.17. Other helpful targets
3358 18. Tools needed for building or running
3360 18.1. Tools for pkgsrc builds
3361 18.2. Tools needed by packages
3362 18.3. Tools provided by platforms
3363 18.4. Questions regarding the tools
3365 19. Making your package work
3367 19.1. General operation
3369 19.1.1. Portability of packages
3370 19.1.2. How to pull in user-settable variables from ???
3371 19.1.3. User interaction
3372 19.1.4. Handling licenses
3373 19.1.5. Restricted packages
3374 19.1.6. Handling dependencies
3375 19.1.7. Handling conflicts with other packages
3376 19.1.8. Packages that cannot or should not be built
3377 19.1.9. Packages which should not be deleted, once installed
3378 19.1.10. Handling packages with security problems
3379 19.1.11. How to handle incrementing versions when fixing an existing
3381 19.1.12. Substituting variable text in the package files (the SUBST
3384 19.2. Fixing problems in the fetch phase
3386 19.2.1. Packages whose distfiles aren't available for plain downloading
3387 19.2.2. How to handle modified distfiles with the 'old' name
3389 19.3. Fixing problems in the configure phase
3391 19.3.1. Shared libraries - libtool
3392 19.3.2. Using libtool on GNU packages that already support libtool
3393 19.3.3. GNU Autoconf/Automake
3395 19.4. Programming languages
3397 19.4.1. C, C++, and Fortran
3399 19.4.3. Packages containing perl scripts
3400 19.4.4. Other programming languages
3402 19.5. Fixing problems in the build phase
3404 19.5.1. Compiling C and C++ code conditionally
3405 19.5.2. How to handle compiler bugs
3406 19.5.3. Undefined reference to ...
3407 19.5.4. Running out of memory
3409 19.6. Fixing problems in the install phase
3411 19.6.1. Creating needed directories
3412 19.6.2. Where to install documentation
3413 19.6.3. Installing highscore files
3414 19.6.4. Adding DESTDIR support to packages
3415 19.6.5. Packages with hardcoded paths to other interpreters
3416 19.6.6. Packages installing perl modules
3417 19.6.7. Packages installing info files
3418 19.6.8. Packages installing man pages
3419 19.6.9. Packages installing GConf data files
3420 19.6.10. Packages installing scrollkeeper/rarian data files
3421 19.6.11. Packages installing X11 fonts
3422 19.6.12. Packages installing GTK2 modules
3423 19.6.13. Packages installing SGML or XML data
3424 19.6.14. Packages installing extensions to the MIME database
3425 19.6.15. Packages using intltool
3426 19.6.16. Packages installing startup scripts
3427 19.6.17. Packages installing TeX modules
3428 19.6.18. Packages supporting running binaries in emulation
3429 19.6.19. Packages installing hicolor theme icons
3430 19.6.20. Packages installing desktop files
3432 19.7. Marking packages as having problems
3435 21. Submitting and Committing
3437 21.1. Submitting binary packages
3438 21.2. Submitting source packages (for non-NetBSD-developers)
3439 21.3. General notes when adding, updating, or removing packages
3440 21.4. Committing: Importing a package into CVS
3441 21.5. Updating a package to a newer version
3442 21.6. Renaming a package in pkgsrc
3443 21.7. Moving a package in pkgsrc
3445 22. Frequently Asked Questions
3446 23. GNOME packaging and porting
3449 23.2. Packaging a GNOME application
3450 23.3. Updating GNOME to a newer version
3451 23.4. Patching guidelines
3453 Chapter 10. Creating a new pkgsrc package from scratch
3457 10.1. Common types of packages
3459 10.1.1. Perl modules
3460 10.1.2. KDE applications
3461 10.1.3. Python modules and programs
3465 10.2.1. How the www/nvu package came into pkgsrc
3467 When you find a package that is not yet in pkgsrc, you most likely have a URL
3468 from where you can download the source code. Starting with this URL, creating a
3469 package involves only a few steps.
3471 1. First, install the packages pkgtools/url2pkg and pkgtools/pkglint.
3473 2. Then, choose one of the top-level directories as the category in which you
3474 want to place your package. You can also create a directory of your own
3475 (maybe called local). In that category directory, create another directory
3476 for your package and change into it.
3478 3. Run the program url2pkg, which will ask you for a URL. Enter the URL of the
3479 distribution file (in most cases a .tar.gz file) and watch how the basic
3480 ingredients of your package are created automatically. The distribution
3481 file is extracted automatically to fill in some details in the Makefile
3482 that would otherwise have to be done manually.
3484 4. Examine the extracted files to determine the dependencies of your package.
3485 Ideally, this is mentioned in some README file, but things may differ. For
3486 each of these dependencies, look where it exists in pkgsrc, and if there is
3487 a file called buildlink3.mk in that directory, add a line to your package
3488 Makefile which includes that file just before the last line. If the
3489 buildlink3.mk file does not exist, add a DEPENDS line to the Makefile,
3490 which specifies the version of the dependency and where it can be found in
3491 pkgsrc. This line should be placed in the third paragraph. If the
3492 dependency is only needed for building the package, but not when using it,
3493 use BUILD_DEPENDS instead of DEPENDS. Your package may then look like this:
3497 BUILD_DEPENDS+= lua>=5.0:../../lang/lua
3498 DEPENDS+= screen-[0-9]*:../../misc/screen
3499 DEPENDS+= screen>=4.0:../../misc/screen
3503 .include "../../category/package/buildlink3.mk"
3504 .include "../../devel/glib2/buildlink3.mk"
3505 .include "../../mk/bsd.pkg.mk"
3507 5. Run pkglint to see what things still need to be done to make your package a
3508 "good" one. If you don't know what pkglint's warnings want to tell you, try
3509 pkglint --explain or pkglint -e, which outputs additional explanations.
3511 6. In many cases the package is not yet ready to build. You can find
3512 instructions for the most common cases in the next section, Section 10.1,
3513 "Common types of packages". After you have followed the instructions over
3514 there, you can hopefully continue here.
3516 7. Run bmake clean to clean the working directory from the extracted files.
3517 Besides these files, a lot of cache files and other system information has
3518 been saved in the working directory, which may become wrong after you
3519 edited the Makefile.
3521 8. Now, run bmake to build the package. For the various things that can go
3522 wrong in this phase, consult Chapter 19, Making your package work.
3524 9. When the package builds fine, the next step is to install the package. Run
3525 bmake install and hope that everything works.
3527 10. Up to now, the file PLIST, which contains a list of the files that are
3528 installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to
3529 generate a probably correct list. Check the file using your preferred text
3530 editor to see if the list of files looks plausible.
3532 11. Run pkglint again to see if the generated PLIST contains garbage or not.
3534 12. When you ran bmake install, the package has been registered in the database
3535 of installed files, but with an empty list of files. To fix this, run bmake
3536 deinstall and bmake install again. Now the package is registered with the
3537 list of files from PLIST.
3539 13. Run bmake package to create a binary package from the set of installed
3542 10.1. Common types of packages
3544 10.1.1. Perl modules
3546 Simple Perl modules are handled automatically by url2pkg, including
3549 10.1.2. KDE applications
3551 KDE applications should always include meta-pkgs/kde3/kde3.mk, which contains
3552 numerous settings that are typical of KDE packages.
3554 10.1.3. Python modules and programs
3556 Python modules and programs packages are easily created using a set of
3557 predefined variables.
3559 Most Python packages use either "distutils" or easy-setup ("eggs"). If the
3560 software uses "distutils", set the PYDISTUTILSPKG variable to "yes" so pkgsrc
3561 will make use of this framework. "distutils" uses a script called setup.py, if
3562 the "distutils" driver is not called setup.py, set the PYSETUP variable to the
3565 If the default Python versions are not supported by the software, set the
3566 PYTHON_VERSIONS_ACCEPTED variable to the Python versions the software is known
3567 to work with, from the most recent to the older one, e.g.
3569 PYTHON_VERSIONS_ACCEPTED= 25 24
3571 If the packaged software is a Python module, include "../../lang/python/
3572 extension.mk". In this case, the package directory should be called
3573 "py-software" and PKGNAME should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.
3575 DISTNAME= foopymodule-1.2.10
3576 PKGNAME= ${PYPKGPREFIX}-${DISTNAME}
3578 If it is an application, also include "../../lang/python/application.mk" before
3581 If the packaged software, either it is an application or a module, is
3582 egg-aware, you only need to include "../../lang/python/egg.mk".
3584 In order to correctly set the path to the Python interpreter, use the
3585 REPLACE_PYTHON variable and set it to the list of files that must be corrected.
3588 REPLACE_PYTHON= ${WRKSRC}/*.py
3592 10.2.1. How the www/nvu package came into pkgsrc
3594 10.2.1.1. The initial package
3596 Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet
3597 been imported into pkgsrc. As the description says it has to do with the web,
3598 the obvious choice for the category is "www".
3603 The web site says that the sources are available as a tar file, so I fed that
3604 URL to the url2pkg program:
3606 $ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
3608 My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the
3609 package name should not have the word "sources" in it. I also filled in the
3610 MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like
3616 DISTNAME= nvu-1.0-sources
3619 MASTER_SITES= http://cvs.nvu.com/download/
3620 EXTRACT_SUFX= .tar.bz2
3622 MAINTAINER= rillig@NetBSD.org
3623 HOMEPAGE= http://cvs.nvu.com/
3624 COMMENT= Web Authoring System
3626 # url2pkg-marker (please do not remove this line.)
3627 .include "../../mk/bsd.pkg.mk"
3629 Then, I quit the editor and watched pkgsrc downloading a large source archive:
3631 url2pkg> Running "make makesum" ...
3632 => Required installed package digest>=20010302: digest-20060826 found
3633 => Fetching nvu-1.0-sources.tar.bz2
3634 Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
3635 100% |*************************************| 28992 KB 150.77 KB/s00:00 ETA
3636 29687976 bytes retrieved in 03:12 (150.77 KB/s)
3637 url2pkg> Running "make extract" ...
3638 => Required installed package digest>=20010302: digest-20060826 found
3639 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
3640 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
3641 work.bacc -> /tmp/roland/pkgsrc/www/nvu/work.bacc
3642 ===> Installing dependencies for nvu-1.0
3643 ===> Overriding tools for nvu-1.0
3644 ===> Extracting for nvu-1.0
3645 url2pkg> Adjusting the Makefile.
3647 Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done!
3649 Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)
3651 10.2.1.2. Fixing all kinds of problems to make the package work
3653 Now that the package has been extracted, let's see what's inside it. The
3654 package has a README.txt, but that only says something about mozilla, so it's
3655 probably useless for seeing what dependencies this package has. But since there
3656 is a GNU configure script in the package, let's hope that it will complain
3657 about everything it needs.
3660 => Required installed package digest>=20010302: digest-20060826 found
3661 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
3662 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
3663 ===> Patching for nvu-1.0
3664 ===> Creating toolchain wrappers for nvu-1.0
3665 ===> Configuring for nvu-1.0
3667 configure: error: Perl 5.004 or higher is required.
3669 WARNING: Please add USE_TOOLS+=perl to the package Makefile.
3672 That worked quite well. So I opened the package Makefile in my editor, and
3673 since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
3674 dependencies of the package have changed now, and since a perl wrapper is
3675 automatically installed in the "tools" phase, I need to build the package from
3679 ===> Cleaning for nvu-1.0
3682 *** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \
3683 GNU Make. You will not be able to build Mozilla without GNU Make.
3686 So I added "gmake" to the USE_TOOLS line and tried again (from scratch).
3689 checking for GTK - version >= 1.2.0... no
3690 *** Could not run GTK test program, checking why...
3693 Now to the other dependencies. The first question is: Where is the GTK package
3702 $ echo ../../*/gtk2/bui*
3703 ../../x11/gtk2/buildlink3.mk
3705 The first try was definitely too broad. The second one had exactly one result,
3706 which is very good. But there is one pitfall with GNOME packages. Before GNOME
3707 2 had been released, there were already many GNOME 1 packages in pkgsrc. To be
3708 able to continue to use these packages, the GNOME 2 packages were imported as
3709 separate packages, and their names usually have a "2" appended. So I checked
3710 whether this was the case here, and indeed it was.
3712 Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
3713 easy. I just inserted an .include line before the last line of the package
3714 Makefile, so that it now looks like this:
3717 .include "../../x11/gtk2/buildlink3.mk"
3718 .include "../../mk/bsd.pkg.mk
3720 After another bmake clean && bmake, the answer was:
3723 checking for gtk-config... /home/roland/pkg/bin/gtk-config
3724 checking for GTK - version >= 1.2.0... no
3725 *** Could not run GTK test program, checking why...
3726 *** The test program failed to compile or link. See the file config.log for the
3727 *** exact error that occured. This usually means GTK was incorrectly installed
3728 *** or that you have moved GTK since it was installed. In the latter case, you
3729 *** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config
3730 configure: error: Test for GTK failed.
3733 In this particular case, the assumption that "every package prefers GNOME 2"
3734 had been wrong. The first of the lines above told me that this package really
3735 wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
3736 it would have looked for pkg-config instead of gtk-config. So I changed the x11
3737 /gtk2 to x11/gtk in the package Makefile, and tried again.
3740 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
3741 In file included from xpidl.c:42:
3742 xpidl.h:53:24: libIDL/IDL.h: No such file or directory
3743 In file included from xpidl.c:42:
3744 xpidl.h:132: error: parse error before "IDL_ns"
3747 The package still does not find all of its dependencies. Now the question is:
3748 Which package provides the libIDL/IDL.h header file?
3750 $ echo ../../*/*idl*
3751 ../../devel/py-idle ../../wip/idled ../../x11/acidlaunch
3752 $ echo ../../*/*IDL*
3755 Let's take the one from the second try. So I included the ../../net/libIDL/
3756 buildlink3.mk file and tried again. But the error didn't change. After digging
3757 through some of the code, I concluded that the build process of the package was
3758 broken and couldn't have ever worked, but since the Mozilla source tree is
3759 quite large, I didn't want to fix it. So I added the following to the package
3760 Makefile and tried again:
3762 CPPFLAGS+= -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0
3763 BUILDLINK_TRANSFORM+= -l:IDL:IDL-2
3765 The latter line is needed because the package expects the library libIDL.so,
3766 but only libIDL-2.so is available. So I told the compiler wrapper to rewrite
3769 The next problem was related to a recent change of the FreeType interface. I
3770 looked up in www/seamonkey which patch files were relevant for this issue and
3771 copied them to the patches directory. Then I retried, fixed the patches so that
3772 they applied cleanly and retried again. This time, everything worked.
3774 10.2.1.3. Installing the package
3776 $ bmake CHECK_FILES=no install
3778 $ bmake print-PLIST >PLIST
3782 Chapter 11. Package components - files, directories and contents
3790 11.3.1. Structure of a single patch file
3791 11.3.2. Creating patch files
3792 11.3.3. Sources where the patch files come from
3793 11.3.4. Patching guidelines
3794 11.3.5. Feedback to the author
3796 11.4. Other mandatory files
3797 11.5. Optional files
3799 11.5.1. Files affecting the binary package
3800 11.5.2. Files affecting the build process
3801 11.5.3. Files affecting nothing at all
3806 Whenever you're preparing a package, there are a number of files involved which
3807 are described in the following sections.
3811 Building, installation and creation of a binary package are all controlled by
3812 the package's Makefile. The Makefile describes various things about a package,
3813 for example from where to get it, how to configure, build, and install it.
3815 A package Makefile contains several sections that describe the package.
3817 In the first section there are the following variables, which should appear
3818 exactly in the order given here. The order and grouping of the variables is
3819 mostly historical and has no further meaning.
3821 * DISTNAME is the basename of the distribution file to be downloaded from the
3824 * PKGNAME is the name of the package, as used by pkgsrc. You only need to
3825 provide it if DISTNAME (which is the default) is not a good name for the
3826 package in pkgsrc. Usually it is the pkgsrc directory name together with
3827 the version number. It must match the regular expression ^[A-Za-z0-9]
3828 [A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains
3829 only letters, digits, dashes, underscores, dots and plus signs.
3831 * SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't
3832 unique on a SVR4 system. The default is PKGNAME, which may be shortened
3833 when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not
3834 produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME
3835 is limited to 5 characters.
3837 * CATEGORIES is a list of categories which the package fits in. You can
3838 choose any of the top-level directories of pkgsrc for it.
3840 Currently the following values are available for CATEGORIES. If more than
3841 one is used, they need to be separated by spaces:
3843 archivers cross geography meta-pkgs security
3844 audio databases graphics misc shells
3845 benchmarks devel ham multimedia sysutils
3846 biology editors inputmethod net textproc
3847 cad emulators lang news time
3848 chat finance mail parallel wm
3849 comms fonts math pkgtools www
3850 converters games mbone print x11
3852 * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
3853 are discussed in detail in Section 17.5, "The fetch phase".
3855 The second section contains information about separately downloaded patches, if
3858 * PATCHFILES: Name(s) of additional files that contain distribution patches.
3859 There is no default. pkgsrc will look for them at PATCH_SITES. They will
3860 automatically be uncompressed before patching if the names end with .gz or
3863 * PATCH_SITES: Primary location(s) for distribution patch files (see
3864 PATCHFILES below) if not found locally.
3866 The third section contains the following variables.
3868 * MAINTAINER is the email address of the person who feels responsible for
3869 this package, and who is most likely to look at problems or questions
3870 regarding this package which have been reported with send-pr(1). Other
3871 developers may contact the MAINTAINER before making changes to the package,
3872 but are not required to do so. When packaging a new program, set MAINTAINER
3873 to yourself. If you really can't maintain the package for future updates,
3874 set it to <pkgsrc-users@NetBSD.org>.
3876 * OWNER should be used instead of MAINTAINER when you do not want other
3877 developers to update or change the package without contacting you first. A
3878 package Makefile should contain one of MAINTAINER or OWNER, but not both.
3880 * HOMEPAGE is a URL where users can find more information about the package.
3882 * COMMENT is a one-line description of the package (should not include the
3885 Other variables that affect the build:
3887 * WRKSRC: The directory where the interesting distribution files of the
3888 package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
3891 If a package doesn't create a subdirectory for itself (most GNU software
3892 does, for instance), but extracts itself in the current directory, you
3893 should set WRKSRC=${WRKDIR}.
3895 If a package doesn't create a subdirectory with the name of DISTNAME but
3896 some different name, set WRKSRC to point to the proper name in ${WRKDIR},
3897 for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
3900 The name of the working directory created by pkgsrc is taken from the
3901 WRKDIR_BASENAME variable. By default, its value is work. If you want to use
3902 the same pkgsrc tree for building different kinds of binary packages, you
3903 can change the variable according to your needs. Two other variables handle
3904 common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
3905 defined in mk.conf, the first component of the host's name is attached to
3906 the directory name. If OBJMACHINE is defined, the platform name is
3907 attached, which might look like work.i386 or work.sparc.
3909 Please pay attention to the following gotchas:
3911 * Add MANCOMPRESSED if man pages are installed in compressed form by the
3912 package. For packages using BSD-style makefiles which honor MANZ, there is
3913 MANCOMPRESSED_IF_MANZ.
3915 * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
3917 * If the package installs any info files, see Section 19.6.7, "Packages
3918 installing info files".
3922 The distinfo file contains the message digest, or checksum, of each distfile
3923 needed for the package. This ensures that the distfiles retrieved from the
3924 Internet have not been corrupted during transfer or altered by a malign force
3925 to introduce a security hole. Due to recent rumor about weaknesses of digest
3926 algorithms, all distfiles are protected using both SHA1 and RMD160 message
3927 digests, as well as the file size.
3929 The distinfo file also contains the checksums for all the patches found in the
3930 patches directory (see Section 11.3, "patches/*").
3932 To regenerate the distinfo file, use the make makedistinfo or make mdi command.
3934 Some packages have different sets of distfiles depending on the platform, for
3935 example www/navigator). These are kept in the same distinfo file and care
3936 should be taken when upgrading such a package to ensure distfile information is
3941 Many packages still don't work out-of-the box on the various platforms that are
3942 supported by pkgsrc. Therefore, a number of custom patch files are needed to
3943 make the package work. These patch files are found in the patches/ directory.
3945 In the patch phase, these patches are applied to the files in WRKSRC directory
3946 after extracting them, in alphabetic order, so patch-aa is applied before
3949 11.3.1. Structure of a single patch file
3951 The patch-* files should be in diff -bu format, and apply without a fuzz to
3952 avoid problems. (To force patches to apply with fuzz you can set
3953 PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
3954 a single file, and no file should be patched by more than one patch file. This
3955 helps to keep future modifications simple.
3957 Each patch file is structured as follows: In the first line, there is the RCS
3958 Id of the patch itself. The second line should be empty for aesthetic reasons.
3959 After that, there should be a comment for each change that the patch does.
3960 There are a number of standard cases:
3962 * Patches that replace the == operator for test(1) with = in shell scripts
3963 are so common that they don't need a comment at all.
3965 * Patches for commonly known vulnerabilities should mention the vulnerability
3968 * Patches that change source code should mention the platform and other
3969 environment (for example, the compiler) that the patch is needed for.
3971 In all other cases, the patch should be commented so that any developer who
3972 knows the code of the application can make some use of the patch. Special care
3973 should be taken for the upstream developers, since we generally want that they
3974 accept our patches, so we have less work in the future.
3976 11.3.2. Creating patch files
3978 One important thing to mention is to pay attention that no RCS IDs get stored
3979 in the patch files, as these will cause problems when later checked into the
3980 NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
3981 avoid these problems.
3983 For even more automation, we recommend using mkpatches from the same package to
3984 make a whole set of patches. You just have to backup files before you edit them
3985 to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using
3986 pkgvi again from the same package. If you upgrade a package this way, you can
3987 easily compare the new set of patches with the previously existing one with
3988 patchdiff. Copy the patches you want to use or update from the work/.newpatches
3989 directory to patches/.
3991 When you have finished a package, remember to generate the checksums for the
3992 patch files by using the make makepatchsum command, see Section 11.2,
3995 When adding a patch that corrects a problem in the distfile (rather than e.g.
3996 enforcing pkgsrc's view of where man pages should go), send the patch as a bug
3997 report to the maintainer. This benefits non-pkgsrc users of the package, and
3998 usually makes it possible to remove the patch in future version.
4000 The file names of the patch files are usually of the form patch-[a-z][a-z].
4002 11.3.3. Sources where the patch files come from
4004 If you want to share patches between multiple packages in pkgsrc, e.g. because
4005 they use the same distfiles, set PATCHDIR to the path where the patch files can
4008 PATCHDIR= ${.CURDIR}/../xemacs/patches
4010 Patch files that are distributed by the author or other maintainers can be
4011 listed in PATCHFILES.
4013 If it is desired to store any patches that should not be committed into pkgsrc,
4014 they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
4015 directory tree there is expected to have the same "category/package" structure
4016 as pkgsrc, and patches are expected to be stored inside these dirs (also known
4017 as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
4018 for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
4019 files in the named directory are expected to be patch files, and they are
4020 applied after pkgsrc patches are applied.
4022 11.3.4. Patching guidelines
4024 When fixing a portability issue in the code do not use preprocessor magic to
4025 check for the current operating system nor platform. Doing so hurts portability
4026 to other platforms because the OS-specific details are not abstracted
4029 The general rule to follow is: instead of checking for the operating system the
4030 application is being built on, check for the specific features you need. For
4031 example, instead of assuming that kqueue is available under NetBSD and using
4032 the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
4033 kqueue itself ? yes, this generally involves patching the configure script.
4034 There is absolutely nothing that prevents some OSes from adopting interfaces
4035 from other OSes (e.g. Linux implementing kqueue), something that the above
4036 checks cannot take into account.
4038 Of course, checking for features generally involves more work on the
4039 developer's side, but the resulting changes are cleaner and there are chances
4040 they will work on many other platforms. Not to mention that there are higher
4041 chances of being later integrated into the mainstream sources. Remember: It
4042 doesn't work unless it is right!
4044 Some typical examples:
4046 Table 11.1. Patching examples
4048 +-------------------------------------------------------------------------------------------+
4049 | Where | Incorrect | Correct |
4050 |---------+--------------------------+------------------------------------------------------|
4051 | |case ${target_os} in | |
4052 |configure|netbsd*) have_kvm=yes ;; |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)|
4053 |script |*) have_kvm=no ;; | |
4055 |---------+--------------------------+------------------------------------------------------|
4056 |C source |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) |
4057 |file |# include <sys/event.h> |# include <sys/event.h> |
4059 |---------+--------------------------+------------------------------------------------------|
4061 | |monitor_file(...) |monitor_file(...) |
4063 | |#if defined(__NetBSD__) |#if defined(HAVE_KQUEUE) |
4064 |C source | int fd = kqueue();| int fd = kqueue(); |
4070 +-------------------------------------------------------------------------------------------+
4073 For more information, please read the Making packager-friendly software article
4074 (part 1, part 2). It summarizes multiple details on how to make software easier
4075 to package; all the suggestions in it were collected from our experience in
4076 pkgsrc work, so they are possibly helpful when creating patches too.
4078 11.3.5. Feedback to the author
4080 Always, always, always feed back any portability fixes or improvements you do
4081 to a package to the mainstream developers. This is the only way to get their
4082 attention on portability issues and to ensure that future versions can be built
4083 out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will
4084 get the fixes straight from the packaged code.
4086 This generally involves cleaning up the patches (because sometimes the patches
4087 that are added to pkgsrc are quick hacks), filling bug reports in the
4088 appropriate trackers for the projects and working with the mainstream authors
4089 to accept your changes. It is extremely important that you do it so that the
4090 packages in pkgsrc are kept simple and thus further changes can be done without
4093 Support the idea of free software!
4095 11.4. Other mandatory files
4099 A multi-line description of the piece of software. This should include any
4100 credits where they are due. Please bear in mind that others do not share
4101 your sense of humour (or spelling idiosyncrasies), and that others will
4102 read everything that you write here.
4106 This file governs the files that are installed on your system: all the
4107 binaries, manual pages, etc. There are other directives which may be
4108 entered in this file, to control the creation and deletion of directories,
4109 and the location of inserted files. See Chapter 13, PLIST issues for more
4112 11.5. Optional files
4114 11.5.1. Files affecting the binary package
4118 This shell script is invoked twice by pkg_add(1). First time after package
4119 extraction and before files are moved in place, the second time after the
4120 files to install are moved in place. This can be used to do any custom
4121 procedures not possible with @exec commands in PLIST. See pkg_add(1) and
4122 pkg_create(1) for more information. See also Section 15.1, "Files and
4123 directories outside the installation prefix".
4127 This script is executed before and after any files are removed. It is this
4128 script's responsibility to clean up any additional messy details around the
4129 package's installation, since all pkg_delete knows is how to delete the
4130 files created in the original distribution. See pkg_delete(1) and
4131 pkg_create(1) for more information.
4135 This file is displayed after installation of the package. Useful for things
4136 like legal notices on almost-free software and hints for updating config
4137 files after installing modules for apache, PHP etc. Please note that you
4138 can modify variables in it easily by using MESSAGE_SUBST in the package's
4141 MESSAGE_SUBST+= SOMEVAR="somevalue"
4143 replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
4144 is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE,
4145 PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.
4147 You can display a different or additional files by setting the MESSAGE_SRC
4148 variable. Its default is MESSAGE, if the file exists.
4152 FIXME: There is no documentation on the alternatives framework.
4154 11.5.2. Files affecting the build process
4158 This file contains arbitrary things that could also go into a Makefile, but
4159 its purpose is to be used by more than one package. This file should only
4160 be used when the packages that will use the file are known in advance. For
4161 other purposes it is often better to write a *.mk file and give it a good
4162 name that describes what it does.
4166 This file contains the dependency information for the buildlink3 framework
4167 (see Chapter 14, Buildlink methodology).
4171 This file contains workarounds for compiler bugs and similar things. It is
4172 included automatically by the pkgsrc infrastructure, so you don't need an
4173 extra .include line for it.
4177 This file contains the code for the package-specific options (see
4178 Chapter 16, Options handling) that can be selected by the user. If a
4179 package has only one or two options, it is equally acceptable to put the
4180 code directly into the Makefile.
4182 11.5.3. Files affecting nothing at all
4186 These files do not take place in the creation of a package and thus are
4187 purely informative to the package developer.
4191 This file contains things that need to be done to make the package even
4196 When you type make, the distribution files are unpacked into the directory
4197 denoted by WRKDIR. It can be removed by running make clean. Besides the
4198 sources, this directory is also used to keep various timestamp files. The
4199 directory gets removed completely on clean. The default is ${.CURDIR}/work or $
4200 {.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
4204 If you have any files that you wish to be placed in the package prior to
4205 configuration or building, you could place these files here and use a ${CP}
4206 command in the "pre-configure" target to achieve this. Alternatively, you could
4207 simply diff the file against /dev/null and use the patch mechanism to manage
4208 the creation of this file.
4210 If you want to share files in this way with other packages, set the FILESDIR
4211 variable to point to the other package's files directory, e.g.:
4213 FILESDIR=${.CURDIR}/../xemacs/files
4215 Chapter 12. Programming in Makefiles
4220 12.2. Makefile variables
4222 12.2.1. Naming conventions
4226 12.3.1. Adding things to a list
4227 12.3.2. Converting an internal list into an external list
4228 12.3.3. Passing variables to a shell command
4229 12.3.4. Quoting guideline
4230 12.3.5. Workaround for a bug in BSD Make
4232 Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
4233 part of the pkgsrc system. Using the make(1) system as a programming language
4234 for a big system like pkgsrc requires some discipline to keep the code correct
4237 The basic ingredients for Makefile programming are variables (which are
4238 actually macros) and shell commands. Among these shell commands may even be
4239 more complex ones like awk(1) programs. To make sure that every shell command
4240 runs as intended it is necessary to quote all variables correctly when they are
4243 This chapter describes some patterns, that appear quite often in Makefiles,
4244 including the pitfalls that come along with them.
4248 * When you are creating a file as a target of a rule, always write the data
4249 to a temporary file first and finally rename that file. Otherwise there
4250 might occur an error in the middle of generating the file, and when the
4251 user runs make(1) for the second time, the file exists and will not be
4252 regenerated properly. Example:
4255 @echo "line 1" > ${.TARGET}
4256 @echo "line 2" >> ${.TARGET}
4260 @echo "line 1" > ${.TARGET}.tmp
4261 @echo "line 2" >> ${.TARGET}.tmp
4263 @mv ${.TARGET}.tmp ${.TARGET}
4265 When you run make wrong twice, the file wrong will exist, although there
4266 was an error message in the first run. On the other hand, running make
4267 correct gives an error message twice, as expected.
4269 You might remember that make(1) sometimes removes ${.TARGET} in case of
4270 error, but this only happens when it is interrupted, for example by
4271 pressing ^C. This does not happen when one of the commands fails (like
4274 12.2. Makefile variables
4276 Makefile variables contain strings that can be processed using the five
4277 operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
4280 When a variable's value is parsed from a Makefile, the hash character ``#'' and
4281 the backslash character ``\'' are handled specially. If a backslash is followed
4282 by a newline, any whitespace immediately in front of the backslash, the
4283 backslash, the newline, and any whitespace immediately behind the newline are
4284 replaced with a single space. A backslash character and an immediately
4285 following hash character are replaced with a single hash character. Otherwise,
4286 the backslash is passed as is. In a variable assignment, any hash character
4287 that is not preceded by a backslash starts a comment that continues upto the
4288 end of the logical line.
4290 Note: Because of this parsing algorithm the only way to create a variable
4291 consisting of a single backslash is using the ``!='' operator, for example:
4292 BACKSLASH!=echo "\\".
4294 So far for defining variables. The other thing you can do with variables is
4295 evaluating them. A variable is evaluated when it is part of the right side of
4296 the ``:='' or the ``!='' operator, or directly before executing a shell command
4297 which the variable is part of. In all other cases, make(1) performs lazy
4298 evaluation, that is, variables are not evaluated until there's no other way.
4299 The ``modifiers'' mentioned in the man page also evaluate the variable.
4301 Some of the modifiers split the string into words and then operate on the
4302 words, others operate on the string as a whole. When a string is split into
4303 words, it is split as you would expect it from sh(1).
4305 No rule without exception?the .for loop does not follow the shell quoting rules
4306 but splits at sequences of whitespace.
4308 There are several types of variables that should be handled differently.
4309 Strings and two types of lists.
4311 * Strings can contain arbitrary characters. Nevertheless, you should restrict
4312 yourself to only using printable characters. Examples are PREFIX and
4315 * Internal lists are lists that are never exported to any shell command.
4316 Their elements are separated by whitespace. Therefore, the elements
4317 themselves cannot have embedded whitespace. Any other characters are
4318 allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
4321 * External lists are lists that may be exported to a shell command. Their
4322 elements can contain any characters, including whitespace. That's why they
4323 cannot be used in .for loops. Examples are DISTFILES and MASTER_SITES.
4325 12.2.1. Naming conventions
4327 * All variable names starting with an underscore are reserved for use by the
4328 pkgsrc infrastructure. They shall not be used by package Makefiles.
4330 * In .for loops you should use lowercase variable names for the iteration
4333 * All list variables should have a ``plural'' name, e.g. PKG_OPTIONS or
4338 This section presents you with some code snippets you should use in your own
4339 code. If you don't find anything appropriate here, you should test your code
4342 12.3.1. Adding things to a list
4344 STRING= foo * bar `date`
4346 ANOTHER_INT_LIST= apache-[0-9]*:../../www/apache
4348 ANOTHER_EXT_LIST= a=b c=d
4350 INT_LIST+= ${STRING} # 1
4351 INT_LIST+= ${ANOTHER_INT_LIST} # 2
4352 EXT_LIST+= ${STRING:Q} # 3
4353 EXT_LIST+= ${ANOTHER_EXT_LIST} # 4
4355 When you add a string to an external list (example 3), it must be quoted. In
4356 all other cases, you must not add a quoting level. You must not merge internal
4357 and external lists, unless you are sure that all entries are correctly
4358 interpreted in both lists.
4360 12.3.2. Converting an internal list into an external list
4363 .for i in ${INT_LIST}
4367 This code converts the internal list INT_LIST into the external list EXT_LIST.
4368 As the elements of an internal list are unquoted they must be quoted here. The
4369 reason for appending "" is explained below.
4371 12.3.3. Passing variables to a shell command
4373 Sometimes you may want to print an arbitrary string. There are many ways to get
4374 it wrong and only few that can handle every nastiness.
4376 STRING= foo bar < > * `date` $$HOME ' "
4377 EXT_LIST= string=${STRING:Q} x=second\ item
4381 echo "${STRING}" # 2
4382 echo "${STRING:Q}" # 3
4383 echo ${STRING:Q} # 4
4384 echo x${STRING:Q} | sed 1s,.,, # 5
4385 printf "%s\\n" ${STRING:Q}"" # 6
4386 env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
4388 Example 1 leads to a syntax error in the shell, as the characters are just
4391 Example 2 leads to a syntax error too, and if you leave out the last "
4392 character from ${STRING}, date(1) will be executed. The $HOME shell variable
4393 would be evaluated, too.
4395 Example 3 outputs each space character preceded by a backslash (or not),
4396 depending on the implementation of the echo(1) command.
4398 Example 4 handles correctly every string that does not start with a dash. In
4399 that case, the result depends on the implementation of the echo(1) command. As
4400 long as you can guarantee that your input does not start with a dash, this form
4403 Example 5 handles even the case of a leading dash correctly.
4405 Example 6 also works with every string and is the light-weight solution, since
4406 it does not involve a pipe, which has its own problems.
4408 The EXT_LIST does not need to be quoted because the quoting has already been
4409 done when adding elements to the list.
4411 As internal lists shall not be passed to the shell, there is no example for it.
4413 12.3.4. Quoting guideline
4415 There are many possible sources of wrongly quoted variables. This section lists
4416 some of the commonly known ones.
4418 * Whenever you use the value of a list, think about what happens to leading
4419 or trailing whitespace. If the list is a well-formed shell expression, you
4420 can apply the :M* modifier to strip leading and trailing whitespace from
4421 each word. The :M operator first splits its argument according to the rules
4422 of the shell, and then creates a new list consisting of all words that
4423 match the shell glob expression *, that is: all. One class of situations
4424 where this is needed is when adding a variable like CPPFLAGS to
4425 CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
4426 strips the leading and trailing whitespace from the variable and then
4427 passes it to the other configure scripts. But these configure scripts
4428 expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
4429 That's why we better pass the CPPFLAGS value properly trimmed. And here is
4433 CPPFLAGS+= -Wundef -DPREFIX=\"${PREFIX:Q}\"
4434 CPPFLAGS+= ${MY_CPPFLAGS}
4436 CONFIGURE_ARGS+= CPPFLAGS=${CPPFLAGS:M*:Q}
4439 echo x${CPPFLAGS:Q}x # leading and trailing whitespace
4440 echo x${CONFIGURE_ARGS}x # properly trimmed
4442 * The example above contains one bug: The ${PREFIX} is a properly quoted
4443 shell expression, but there is the C compiler after it, which also expects
4444 a properly quoted string (this time in C syntax). The version above is
4445 therefore only correct if ${PREFIX} does not have embedded backslashes or
4446 double quotes. If you want to allow these, you have to add another layer of
4447 quoting to each variable that is used as a C string literal. You cannot use
4448 the :Q operator for it, as this operator only works for the shell.
4450 * Whenever a variable can be empty, the :Q operator can have surprising
4451 results. Here are two completely different cases which can be solved with
4456 for i in a ${EMPTY:Q} c; do \
4461 .for i in a:\ a:\test.txt
4466 The first example will only print two of the three lines we might have
4467 expected. This is because ${EMPTY:Q} expands to the empty string, which the
4468 shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
4469 be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
4472 The second example will only print three lines instead of four. The first
4473 line looks like a:\ echo foo. This is because the backslash of the value a:
4474 \ is interpreted as a line-continuation by make(1), which makes the second
4475 line the arguments of the echo(1) command from the first line. To avoid
4476 this, write ${i:Q}"".
4478 12.3.5. Workaround for a bug in BSD Make
4480 The pkgsrc bmake program does not handle the following assignment correctly. In
4481 case _othervar_ contains a ``-'' character, one of the closing braces is
4482 included in ${VAR} after this code executes.
4484 VAR:= ${VAR:N${_othervar_:C/-//}}
4486 For a more complex code snippet and a workaround, see the package regress/
4487 make-quoting, testcase bug1.
4489 Chapter 13. PLIST issues
4494 13.2. Semi-automatic PLIST generation
4495 13.3. Tweaking output of make print-PLIST
4496 13.4. Variable substitution in PLIST
4497 13.5. Man page compression
4498 13.6. Changing PLIST source with PLIST_SRC
4499 13.7. Platform-specific and differing PLISTs
4500 13.8. Sharing directories between packages
4502 The PLIST file contains a package's "packing list", i.e. a list of files that
4503 belong to the package (relative to the ${PREFIX} directory it's been installed
4504 in) plus some additional statements - see the pkg_create(1) man page for a full
4505 list. This chapter addresses some issues that need attention when dealing with
4506 the PLIST file (or files, see below!).
4510 Be sure to add a RCS ID line as the first thing in any PLIST file you write:
4515 13.2. Semi-automatic PLIST generation
4517 You can use the make print-PLIST command to output a PLIST that matches any new
4518 files since the package was extracted. See Section 17.17, "Other helpful
4519 targets" for more information on this target.
4521 13.3. Tweaking output of make print-PLIST
4523 If you have used any of the *-dirs packages, as explained in Section 13.8,
4524 "Sharing directories between packages", you may have noticed that make
4525 print-PLIST outputs a set of @comments instead of real @dirrm lines. You can
4526 also do this for specific directories and files, so that the results of that
4527 command are very close to reality. This helps a lot during the update of
4530 The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
4531 used to filter the output of print-PLIST. You can append any chunk of AWK
4532 scripting you like to it, but be careful with quoting.
4534 For example, to get all files inside the libdata/foo directory removed from the
4537 PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }
4540 And to get all the @dirrm lines referring to a specific (shared) directory
4541 converted to @comments:
4543 PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; }
4546 13.4. Variable substitution in PLIST
4548 A number of variables are substituted automatically in PLISTs when a package is
4549 installed on a system. This includes the following variables:
4551 ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
4553 Some packages like emacs and perl embed information about which
4554 architecture they were built on into the pathnames where they install their
4555 files. To handle this case, PLIST will be preprocessed before actually
4556 used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
4557 gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
4558 PLIST somewhere - use this on packages that have GNU autoconf-created
4563 There used to be a symbol "$ARCH" that was replaced by the output of uname
4564 -m, but that's no longer supported and has been removed.
4566 ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
4568 Some packages want to embed the OS name and version into some paths. To do
4569 this, use these variables in the PLIST:
4571 * ${OPSYS} - output of "uname -s"
4573 * ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
4575 * ${OS_VERSION} - "uname -r"
4577 For a complete list of values which are replaced by default, please look in
4578 bsd.pkg.mk (and search for PLIST_SUBST).
4580 If you want to change other variables not listed above, you can add variables
4581 and their expansions to this variable in the following way, similar to
4582 MESSAGE_SUBST (see Section 11.5, "Optional files"):
4584 PLIST_SUBST+= SOMEVAR="somevalue"
4587 This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".
4589 The PLIST_VARS variable can be used to simplify the common case of
4590 conditionally including some PLIST entries. It can be done by adding
4591 PLIST_VARS+=foo and setting the corresponding PLIST.foo variable to yes if the
4592 entry should be included. This will substitute "${PLIST.foo}" in the PLIST with
4593 either """" or ""@comment "". For example, in Makefile:
4607 ${PLIST.foo}man/man1/foo.1
4608 ${PLIST.foo}share/bar/foo.data
4609 ${PLIST.foo}@dirrm share/bar
4612 13.5. Man page compression
4614 Man pages should be installed in compressed form if MANZ is set (in
4615 bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
4616 suffix ".gz" is appended/removed automatically for man pages according to MANZ
4617 and MANCOMPRESSED being set or not, see above for details. This modification of
4618 the PLIST file is done on a copy of it, not PLIST itself.
4620 13.6. Changing PLIST source with PLIST_SRC
4622 To use one or more files as source for the PLIST used in generating the binary
4623 package, set the variable PLIST_SRC to the names of that file(s). The files are
4624 later concatenated using cat(1), and the order of things is important. The
4625 default for PLIST_SRC is ${PKGDIR}/PLIST.
4627 13.7. Platform-specific and differing PLISTs
4629 Some packages decide to install a different set of files based on the operating
4630 system being used. These differences can be automatically handled by using the
4637 * PLIST.${MACHINE_ARCH}
4639 * PLIST.${OPSYS}-${MACHINE_ARCH}
4643 13.8. Sharing directories between packages
4645 A "shared directory" is a directory where multiple (and unrelated) packages
4646 install files. These directories were problematic because you had to add
4647 special tricks in the PLIST to conditionally remove them, or have some
4648 centralized package handle them.
4650 In pkgsrc, it is now easy: Each package should create directories and install
4651 files as needed; pkg_delete will remove any directories left empty after
4652 uninstalling a package.
4654 If a package needs an empty directory to work, create the directory during
4655 installation as usual, and also add an entry to the PLIST:
4657 @pkgdir path/to/empty/directory
4660 Chapter 14. Buildlink methodology
4664 14.1. Converting packages to use buildlink3
4665 14.2. Writing buildlink3.mk files
4667 14.2.1. Anatomy of a buildlink3.mk file
4668 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
4670 14.3. Writing builtin.mk files
4672 14.3.1. Anatomy of a builtin.mk file
4673 14.3.2. Global preferences for native or pkgsrc software
4675 Buildlink is a framework in pkgsrc that controls what headers and libraries are
4676 seen by a package's configure and build processes. This is implemented in a two
4679 1. Symlink headers and libraries for dependencies into BUILDLINK_DIR, which by
4680 default is a subdirectory of WRKDIR.
4682 2. Create wrapper scripts that are used in place of the normal compiler tools
4683 that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib into
4684 references to BUILDLINK_DIR. The wrapper scripts also make native compiler
4685 on some operating systems look like GCC, so that packages that expect GCC
4686 won't require modifications to build with those native compilers.
4688 This normalizes the environment in which a package is built so that the package
4689 may be built consistently despite what other software may be installed. Please
4690 note that the normal system header and library paths, e.g. /usr/include, /usr/
4691 lib, etc., are always searched -- buildlink3 is designed to insulate the
4692 package build from non-system-supplied software.
4694 14.1. Converting packages to use buildlink3
4696 The process of converting packages to use the buildlink3 framework
4697 ("bl3ifying") is fairly straightforward. The things to keep in mind are:
4699 1. Ensure that the build always calls the wrapper scripts instead of the
4700 actual toolchain. Some packages are tricky, and the only way to know for
4701 sure is the check ${WRKDIR}/.work.log to see if the wrappers are being
4704 2. Don't override PREFIX from within the package Makefile, e.g. Java VMs,
4705 standalone shells, etc., because the code to symlink files into $
4706 {BUILDLINK_DIR} looks for files relative to "pkg_info -qp pkgname".
4708 3. Remember that only the buildlink3.mk files that you list in a package's
4709 Makefile are added as dependencies for that package.
4711 If a dependency on a particular package is required for its libraries and
4712 headers, then we replace:
4714 DEPENDS+= foo>=1.1.0:../../category/foo
4718 .include "../../category/foo/buildlink3.mk"
4720 The buildlink3.mk files usually define the required dependencies. If you need a
4721 newer version of the dependency when using buildlink3.mk files, then you can
4722 define it in your Makefile; for example:
4724 BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0
4725 .include "../../category/foo/buildlink3.mk"
4727 There are several buildlink3.mk files in pkgsrc/mk that handle special package
4730 * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
4731 implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.
4733 * curses.buildlink3.mk: If the system comes with neither Curses nor NCurses,
4734 this will take care to install the devel/ncurses package.
4736 * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding
4737 a dependency on Heimdal or MIT-krb5 for packages that require a Kerberos 5
4740 * motif.buildlink3.mk checks for a system-provided Motif installation or adds
4741 a dependency on x11/lesstif or x11/openmotif. The user can set MOTIF_TYPE
4742 to "dt", "lesstif", or "openmotif" to choose which Motif version will be
4745 * oss.buildlink3.mk defines several variables that may be used by packages
4746 that use the Open Sound System (OSS) API.
4748 * pgsql.buildlink3.mk will accept either Postgres 8.0, 8.1, or 8.2, whichever
4749 is found installed. See the file for more information.
4751 * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native
4752 pthreads or adds a dependency on devel/pth as needed.
4754 * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena
4757 The comments in those buildlink3.mk files provide a more complete description
4758 of how to use them properly.
4760 14.2. Writing buildlink3.mk files
4762 A package's buildlink3.mk file is included by Makefiles to indicate the need to
4763 compile and link against header files and libraries provided by the package. A
4764 buildlink3.mk file should always provide enough information to add the correct
4765 type of dependency relationship and include any other buildlink3.mk files that
4766 it needs to find headers and libraries that it needs in turn.
4768 To generate an initial buildlink3.mk file for further editing, Rene Hexel's
4769 pkgtools/createbuildlink package is highly recommended. For most packages, the
4770 following command will generate a good starting point for buildlink3.mk files:
4772 % cd pkgsrc/category/pkgdir
4773 % createbuildlink >buildlink3.mk
4776 14.2.1. Anatomy of a buildlink3.mk file
4778 The following real-life example buildlink3.mk is taken from pkgsrc/graphics/
4781 # $NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp $
4783 BUILDLINK_TREE+= tiff
4785 .if !defined(TIFF_BUILDLINK3_MK)
4786 TIFF_BUILDLINK3_MK:=
4788 BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1
4789 BUILDLINK_ABI_DEPENDS.tiff+= tiff>=3.7.2nb1
4790 BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff
4792 .include "../../devel/zlib/buildlink3.mk"
4793 .include "../../graphics/jpeg/buildlink3.mk"
4794 .endif # TIFF_BUILDLINK3_MK
4796 BUILDLINK_TREE+= -tiff
4798 The header and footer manipulate BUILDLINK_TREE, which is common across all
4799 buildlink3.mk files and is used to track the dependency tree.
4801 The main section is protected from multiple inclusion and controls how the
4802 dependency on pkg is added. Several important variables are set in the section:
4804 * BUILDLINK_API_DEPENDS.pkg is the actual dependency recorded in the
4805 installed package; this should always be set using += to ensure that we're
4806 appending to any pre-existing list of values. This variable should be set
4807 to the first version of the package that had an API change.
4809 * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory.
4811 * BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
4812 BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
4813 is selected by setting BUILDLINK_DEPMETHOD.pkg to "build". By default, the
4814 full dependency is used.
4816 * BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS.pkg (not shown above) are lists
4817 of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and
4818 library search paths. These default to "include" and "lib" respectively.
4820 * BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags
4821 to add to CPPFLAGS, which are passed on to the configure and build phases.
4822 The "-I" option should be avoided and instead be handled using
4823 BUILDLINK_INCDIRS.pkg as above.
4825 The following variables are all optionally defined within this second section
4826 (protected against multiple inclusion) and control which package files are
4827 symlinked into ${BUILDLINK_DIR} and how their names are transformed during the
4830 * BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to $
4831 {BUILDLINK_PREFIX.pkg} to be symlinked into ${BUILDLINK_DIR}, e.g. include/
4834 * BUILDLINK_FILES_CMD.pkg (not shown above) is a shell pipeline that outputs
4835 to stdout a list of files relative to ${BUILDLINK_PREFIX.pkg}. The
4836 resulting files are to be symlinked into ${BUILDLINK_DIR}. By default, this
4837 takes the +CONTENTS of a pkg and filters it through $
4838 {BUILDLINK_CONTENTS_FILTER.pkg}.
4840 * BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that
4841 filters +CONTENTS input into a list of files relative to $
4842 {BUILDLINK_PREFIX.pkg} on stdout. By default for overwrite packages,
4843 BUILDLINK_CONTENTS_FILTER.pkg outputs the contents of the include and lib
4844 directories in the package +CONTENTS, and for pkgviews packages, it outputs
4845 any libtool archives in lib directories.
4847 * BUILDLINK_FNAME_TRANSFORM.pkg (not shown above) is a list of sed arguments
4848 used to transform the name of the source filename into a destination
4849 filename, e.g. -e "s|/curses.h|/ncurses.h|g".
4851 This section can additionally include any buildlink3.mk needed for pkg's
4852 library dependencies. Including these buildlink3.mk files means that the
4853 headers and libraries for these dependencies are also symlinked into $
4854 {BUILDLINK_DIR} whenever the pkg buildlink3.mk file is included. Dependencies
4855 are only added for directly include buildlink3.mk files.
4857 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
4859 The situation that requires increasing the dependency listed in
4860 BUILDLINK_API_DEPENDS.pkg after a package update is when the API or interface
4861 to the header files change.
4863 In this case, BUILDLINK_API_DEPENDS.pkg should be adjusted to require at least
4864 the new package version. In some cases, the packages that depend on this new
4865 version may need their PKGREVISIONs increased and, if they have buildlink3.mk
4866 files, their BUILDLINK_API_DEPENDS.pkg adjusted, too. This is needed so pkgsrc
4867 will require the correct package dependency and not settle for an older one
4868 when building the source.
4870 BUILDLINK_ABI_DEPENDS.pkg should be increased when the binary interface or
4871 sonames (major number of the library version) of any installed shared libraries
4872 change. This is needed so that binary packages made using it will require the
4873 correct package dependency and not settle for an older one which will not
4874 contain the necessary shared libraries.
4876 See Section 19.1.6, "Handling dependencies" for more information about
4877 dependencies on other packages, including the BUILDLINK_ABI_DEPENDS and
4878 ABI_DEPENDS definitions.
4880 Please take careful consideration before adjusting BUILDLINK_API_DEPENDS.pkg or
4881 BUILDLINK_ABI_DEPENDS.pkg as we don't want to cause unneeded package deletions
4882 and rebuilds. In many cases, new versions of packages work just fine with older
4885 Also it is not needed to set BUILDLINK_ABI_DEPENDS.pkg when it is identical to
4886 BUILDLINK_API_DEPENDS.pkg.
4888 14.3. Writing builtin.mk files
4890 Some packages in pkgsrc install headers and libraries that coincide with
4891 headers and libraries present in the base system. Aside from a buildlink3.mk
4892 file, these packages should also include a builtin.mk file that includes the
4893 necessary checks to decide whether using the built-in software or the pkgsrc
4894 software is appropriate.
4896 The only requirements of a builtin.mk file for pkg are:
4898 1. It should set USE_BUILTIN.pkg to either "yes" or "no" after it is included.
4900 2. It should not override any USE_BUILTIN.pkg which is already set before the
4901 builtin.mk file is included.
4903 3. It should be written to allow multiple inclusion. This is very important
4904 and takes careful attention to Makefile coding.
4906 14.3.1. Anatomy of a builtin.mk file
4908 The following is the recommended template for builtin.mk files:
4910 .if !defined(IS_BUILTIN.foo)
4912 # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
4913 # genuinely exists in the system or not.
4917 # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
4918 # version can be determined.
4920 . if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
4921 BUILTIN_PKG.foo?= foo-1.0
4923 .endif # IS_BUILTIN.foo
4925 .if !defined(USE_BUILTIN.foo)
4926 USE_BUILTIN.foo?= ${IS_BUILTIN.foo}
4927 . if defined(BUILTIN_PKG.foo)
4928 . for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
4929 . if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
4931 ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo} \
4932 && ${ECHO} "yes" || ${ECHO} "no"
4936 .endif # USE_BUILTIN.foo
4938 CHECK_BUILTIN.foo?= no
4939 .if !empty(CHECK_BUILTIN.foo:M[nN][oO])
4941 # Here we place code that depends on whether USE_BUILTIN.foo is set to
4944 .endif # CHECK_BUILTIN.foo
4946 The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the
4947 base system. This should not be a base system software with similar
4948 functionality to pkg; it should only be "yes" if the actual package is included
4949 as part of the base system. This variable is only used internally within the
4952 The second section sets BUILTIN_PKG.pkg to the version of pkg in the base
4953 system if it exists (if IS_BUILTIN.pkg is "yes"). This variable is only used
4954 internally within the builtin.mk file.
4956 The third section sets USE_BUILTIN.pkg and is required in all builtin.mk files.
4957 The code in this section must make the determination whether the built-in
4958 software is adequate to satisfy the dependencies listed in
4959 BUILDLINK_API_DEPENDS.pkg. This is typically done by comparing BUILTIN_PKG.pkg
4960 against each of the dependencies in BUILDLINK_API_DEPENDS.pkg. USE_BUILTIN.pkg
4961 must be set to the correct value by the end of the builtin.mk file. Note that
4962 USE_BUILTIN.pkg may be "yes" even if IS_BUILTIN.pkg is "no" because we may make
4963 the determination that the built-in version of the software is similar enough
4964 to be used as a replacement.
4966 The last section is guarded by CHECK_BUILTIN.pkg, and includes code that uses
4967 the value of USE_BUILTIN.pkg set in the previous section. This typically
4968 includes, e.g., adding additional dependency restrictions and listing
4969 additional files to symlink into ${BUILDLINK_DIR} (via BUILDLINK_FILES.pkg).
4971 14.3.2. Global preferences for native or pkgsrc software
4973 When building packages, it's possible to choose whether to set a global
4974 preference for using either the built-in (native) version or the pkgsrc version
4975 of software to satisfy a dependency. This is controlled by setting
4976 PREFER_PKGSRC and PREFER_NATIVE. These variables take values of either "yes",
4977 "no", or a list of packages. PREFER_PKGSRC tells pkgsrc to use the pkgsrc
4978 versions of software, while PREFER_NATIVE tells pkgsrc to use the built-in
4979 versions. Preferences are determined by the most specific instance of the
4980 package in either PREFER_PKGSRC or PREFER_NATIVE. If a package is specified in
4981 neither or in both variables, then PREFER_PKGSRC has precedence over
4982 PREFER_NATIVE. For example, to require using pkgsrc versions of software for
4983 all but the most basic bits on a NetBSD system, you can set:
4986 PREFER_NATIVE= getopt skey tcp_wrappers
4988 A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise
4989 it is simply ignored in that list.
4991 Chapter 15. The pkginstall framework
4995 15.1. Files and directories outside the installation prefix
4997 15.1.1. Directory manipulation
4998 15.1.2. File manipulation
5000 15.2. Configuration files
5002 15.2.1. How PKG_SYSCONFDIR is set
5003 15.2.2. Telling the software where configuration files are
5004 15.2.3. Patching installations
5005 15.2.4. Disabling handling of configuration files
5007 15.3. System startup scripts
5009 15.3.1. Disabling handling of system startup scripts
5011 15.4. System users and groups
5014 15.5.1. Disabling shell registration
5018 15.6.1. Disabling automatic update of the fonts databases
5020 This chapter describes the framework known as pkginstall, whose key features
5023 * Generic installation and manipulation of directories and files outside the
5024 pkgsrc-handled tree, LOCALBASE.
5026 * Automatic handling of configuration files during installation, provided
5027 that packages are correctly designed.
5029 * Generation and installation of system startup scripts.
5031 * Registration of system users and groups.
5033 * Registration of system shells.
5035 * Automatic updating of fonts databases.
5037 The following sections inspect each of the above points in detail.
5039 You may be thinking that many of the things described here could be easily done
5040 with simple code in the package's post-installation target (post-install). This
5041 is incorrect, as the code in them is only executed when building from source.
5042 Machines using binary packages could not benefit from it at all (as the code
5043 itself could be unavailable). Therefore, the only way to achieve any of the
5044 items described above is by means of the installation scripts, which are
5045 automatically generated by pkginstall.
5047 15.1. Files and directories outside the installation prefix
5049 As you already know, the PLIST file holds a list of files and directories that
5050 belong to a package. The names used in it are relative to the installation
5051 prefix (${PREFIX}), which means that it cannot register files outside this
5052 directory (absolute path names are not allowed). Despite this restriction, some
5053 packages need to install files outside this location; e.g., under ${VARBASE} or
5054 ${PKG_SYSCONFDIR}. The only way to achieve this is to create such files during
5055 installation time by using installation scripts.
5057 The generic installation scripts are shell scripts that can contain arbitrary
5058 code. The list of scripts to execute is taken from the INSTALL_FILE variable,
5059 which defaults to INSTALL. A similar variable exists for package removal
5060 (DEINSTALL_FILE, whose default is DEINSTALL). These scripts can run arbitrary
5061 commands, so they have the potential to create and manage files anywhere in the
5064 Using these general installation files is not recommended, but may be needed in
5065 some special cases. One reason for avoiding them is that the user has to trust
5066 the packager that there is no unwanted or simply erroneous code included in the
5067 installation script. Also, previously there were many similar scripts for the
5068 same functionality, and fixing a common error involved finding and changing all
5071 The pkginstall framework offers another, standardized way. It provides generic
5072 scripts to abstract the manipulation of such files and directories based on
5073 variables set in the package's Makefile. The rest of this section describes
5076 15.1.1. Directory manipulation
5078 The following variables can be set to request the creation of directories
5079 anywhere in the file system:
5081 * MAKE_DIRS and OWN_DIRS contain a list of directories that should be created
5082 and should attempt to be destroyed by the installation scripts. The
5083 difference between the two is that the latter prompts the administrator to
5084 remove any directories that may be left after deinstallation (because they
5085 were not empty), while the former does not.
5087 * MAKE_DIRS_PERMS and OWN_DIRS_PERMS contain a list of tuples describing
5088 which directories should be created and should attempt to be destroyed by
5089 the installation scripts. Each tuple holds the following values, separated
5090 by spaces: the directory name, its owner, its group and its numerical mode.
5093 MAKE_DIRS_PERMS+= ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
5095 The difference between the two is exactly the same as their non-PERMS
5098 15.1.2. File manipulation
5100 Creating non-empty files outside the installation prefix is tricky because the
5101 PLIST forces all files to be inside it. To overcome this problem, the only
5102 solution is to extract the file in the known place (i.e., inside the
5103 installation prefix) and copy it to the appropriate location during
5104 installation (done by the installation scripts generated by pkginstall). We
5105 will call the former the master file in the following paragraphs, which
5106 describe the variables that can be used to automatically and consistently
5107 handle files outside the installation prefix:
5109 * CONF_FILES and SUPPORT_FILES are pairs of master and target files. During
5110 installation time, the master file is copied to the target one if and only
5111 if the latter does not exist. Upon deinstallation, the target file is
5112 removed provided that it was not modified by the installation.
5114 The difference between the two is that the latter prompts the administrator
5115 to remove any files that may be left after deinstallation (because they
5116 were not empty), while the former does not.
5118 * CONF_FILES_PERMS and SUPPORT_FILES_PERMS contain tuples describing master
5119 files as well as their target locations. For each of them, it also
5120 specifies their owner, their group and their numeric permissions, in this
5123 SUPPORT_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
5125 The difference between the two is exactly the same as their non-PERMS
5128 15.2. Configuration files
5130 Configuration files are special in the sense that they are installed in their
5131 own specific directory, PKG_SYSCONFDIR, and need special treatment during
5132 installation (most of which is automated by pkginstall). The main concept you
5133 must bear in mind is that files marked as configuration files are automatically
5134 copied to the right place (somewhere inside PKG_SYSCONFDIR) during installation
5135 if and only if they didn't exist before. Similarly, they will not be removed if
5136 they have local modifications. This ensures that administrators never lose any
5137 custom changes they may have made.
5139 15.2.1. How PKG_SYSCONFDIR is set
5141 As said before, the PKG_SYSCONFDIR variable specifies where configuration files
5142 shall be installed. Its contents are set based upon the following variables:
5144 * PKG_SYSCONFBASE: The configuration's root directory. Defaults to ${PREFIX}/
5145 etc although it may be overridden by the user to point to his preferred
5146 location (e.g., /etc, /etc/pkg, etc.). Packages must not use it directly.
5148 * PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the
5149 configuration files for the package being built shall be installed. The
5150 definition of this variable only makes sense in the package's Makefile
5151 (i.e., it is not user-customizable).
5153 As an example, consider the Apache package, www/apache2, which places its
5154 configuration files under the httpd/ subdirectory of PKG_SYSCONFBASE. This
5155 should be set in the package Makefile.
5157 * PKG_SYSCONFVAR: Specifies the name of the variable that holds this
5158 package's configuration directory (if different from PKG_SYSCONFBASE). It
5159 defaults to PKGBASE's value, and is always prefixed with PKG_SYSCONFDIR.
5161 * PKG_SYSCONFDIR.${PKG_SYSCONFVAR}: Holds the directory where the
5162 configuration files for the package identified by PKG_SYSCONFVAR's shall be
5165 Based on the above variables, pkginstall determines the value of
5166 PKG_SYSCONFDIR, which is the only variable that can be used within a package to
5167 refer to its configuration directory. The algorithm used to set its value is
5168 basically the following:
5170 1. If PKG_SYSCONFDIR.${PKG_SYSCONFVAR} is set, its value is used.
5172 2. If the previous variable is not defined but PKG_SYSCONFSUBDIR is set in the
5173 package's Makefile, the resulting value is ${PKG_SYSCONFBASE}/$
5174 {PKG_SYSCONFSUBDIR}.
5176 3. Otherwise, it is set to ${PKG_SYSCONFBASE}.
5178 It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
5179 OWN_DIRS. See Section 15.1.1, "Directory manipulation" what this means. This
5180 does not apply to subdirectories of ${PKG_SYSCONFDIR}, they still have to be
5181 created with OWN_DIRS or MAKE_DIRS.
5183 15.2.2. Telling the software where configuration files are
5185 Given that pkgsrc (and users!) expect configuration files to be in a known
5186 place, you need to teach each package where it shall install its files. In some
5187 cases you will have to patch the package Makefiles to achieve it. If you are
5188 lucky, though, it may be as easy as passing an extra flag to the configuration
5189 script; this is the case of GNU Autoconf- generated files:
5191 CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
5193 Note that this specifies where the package has to look for its configuration
5194 files, not where they will be originally installed (although the difference is
5195 never explicit, unfortunately).
5197 15.2.3. Patching installations
5199 As said before, pkginstall automatically handles configuration files. This
5200 means that the packages themselves must not touch the contents of $
5201 {PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts
5202 will, out of the box, mess with the contents of that directory. So what is the
5203 correct procedure to fix this issue?
5205 You must teach the package (usually by manually patching it) to install any
5206 configuration files under the examples hierarchy, share/examples/${PKGBASE}/.
5207 This way, the PLIST registers them and the administrator always has the
5208 original copies available.
5210 Once the required configuration files are in place (i.e., under the examples
5211 hierarchy), the pkginstall framework can use them as master copies during the
5212 package installation to update what is in ${PKG_SYSCONFDIR}. To achieve this,
5213 the variables CONF_FILES and CONF_FILES_PERMS are used. Check out
5214 Section 15.1.2, "File manipulation" for information about their syntax and
5215 their purpose. Here is an example, taken from the mail/mutt package:
5217 EGDIR= ${PREFIX}/share/doc/mutt/samples
5218 CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
5220 Note that the EGDIR variable is specific to that package and has no meaning
5223 15.2.4. Disabling handling of configuration files
5225 The automatic copying of config files can be toggled by setting the environment
5226 variable PKG_CONFIG prior to package installation.
5228 15.3. System startup scripts
5230 System startup scripts are special files because they must be installed in a
5231 place known by the underlying OS, usually outside the installation prefix.
5232 Therefore, the same rules described in Section 15.1, "Files and directories
5233 outside the installation prefix" apply, and the same solutions can be used.
5234 However, pkginstall provides a special mechanism to handle these files.
5236 In order to provide system startup scripts, the package has to:
5238 1. Store the script inside ${FILESDIR}, with the .sh suffix appended.
5239 Considering the print/cups package as an example, it has a cupsd.sh in its
5242 2. Tell pkginstall to handle it, appending the name of the script, without its
5243 extension, to the RCD_SCRIPTS variable. Continuing the previous example:
5247 Once this is done, pkginstall will do the following steps for each script in an
5250 1. Process the file found in the files directory applying all the
5251 substitutions described in the FILES_SUBST variable.
5253 2. Copy the script from the files directory to the examples hierarchy, $
5254 {PREFIX}/share/examples/rc.d/. Note that this master file must be
5255 explicitly registered in the PLIST.
5257 3. Add code to the installation scripts to copy the startup script from the
5258 examples hierarchy into the system-wide startup scripts directory.
5260 15.3.1. Disabling handling of system startup scripts
5262 The automatic copying of config files can be toggled by setting the environment
5263 variable PKG_RCD_SCRIPTS prior to package installation. Note that the scripts
5264 will be always copied inside the examples hierarchy, ${PREFIX}/share/examples/
5265 rc.d/, no matter what the value of this variable is.
5267 15.4. System users and groups
5269 If a package needs to create special users and/or groups during installation,
5270 it can do so by using the pkginstall framework.
5272 Users can be created by adding entries to the PKG_USERS variable. Each entry
5273 has the following syntax:
5277 Further specification of user details may be done by setting per-user
5278 variables. PKG_UID.user is the numeric UID for the user. PKG_GECOS.user is the
5279 user's description or comment. PKG_HOME.user is the user's home directory, and
5280 defaults to /nonexistent if not specified. PKG_SHELL.user is the user's shell,
5281 and defaults to /sbin/nologin if not specified.
5283 Similarly, groups can be created by adding entries to the PKG_GROUPS variable,
5288 The numeric GID of the group may be set by defining PKG_GID.group.
5290 If a package needs to create the users and groups at an earlier stage, then it
5291 can set USERGROUP_PHASE to either configure or build to indicate the phase
5292 before which the users and groups are created. In this case, the numeric UIDs
5293 and GIDs of the created users and groups are automatically hardcoded into the
5294 final installation scripts.
5298 Packages that install system shells should register them in the shell database,
5299 /etc/shells, to make things easier to the administrator. This must be done from
5300 the installation scripts to keep binary packages working on any system.
5301 pkginstall provides an easy way to accomplish this task.
5303 When a package provides a shell interpreter, it has to set the PKG_SHELL
5304 variable to its absolute file name. This will add some hooks to the
5305 installation scripts to handle it. Consider the following example, taken from
5308 PKG_SHELL= ${PREFIX}/bin/zsh
5310 15.5.1. Disabling shell registration
5312 The automatic registration of shell interpreters can be disabled by the
5313 administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.
5317 Packages that install X11 fonts should update the database files that index the
5318 fonts within each fonts directory. This can easily be accomplished within the
5319 pkginstall framework.
5321 When a package installs X11 fonts, it must list the directories in which fonts
5322 are installed in the FONTS_DIRS.type variables, where type can be one of "ttf",
5323 "type1" or "x11". This will add hooks to the installation scripts to run the
5324 appropriate commands to update the fonts database files within each of those
5325 directories. For convenience, if the directory path is relative, it is taken to
5326 be relative to the package's installation prefix. Consider the following
5327 example, taken from fonts/dbz-ttf:
5329 FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF
5331 15.6.1. Disabling automatic update of the fonts databases
5333 The automatic update of fonts databases can be disabled by the administrator by
5334 setting the PKG_UPDATE_FONTS_DB environment variable to NO.
5336 Chapter 16. Options handling
5340 16.1. Global default options
5341 16.2. Converting packages to use bsd.options.mk
5343 16.4. Determining the options of dependencies
5345 Many packages have the ability to be built to support different sets of
5346 features. bsd.options.mk is a framework in pkgsrc that provides generic
5347 handling of those options that determine different ways in which the packages
5348 can be built. It's possible for the user to specify exactly which sets of
5349 options will be built into a package or to allow a set of global default
5352 There are two broad classes of behaviors that one might want to control via
5353 options. One is whether some particular feature is enabled in a program that
5354 will be built anyway, often by including or not including a dependency on some
5355 other package. The other is whether or not an additional program will be built
5356 as part of the package. Generally, it is better to make a split package for
5357 such additional programs instead of using options, because it enables binary
5358 packages to be built which can then be added separately. For example, the foo
5359 package might have minimal dependencies (those packages without which foo
5360 doesn't make sense), and then the foo-gfoo package might include the GTK
5361 frontend program gfoo. This is better than including a gtk option to foo that
5362 adds gfoo, because either that option is default, in which case binary users
5363 can't get foo without gfoo, or not default, in which case they can't get gfoo.
5364 With split packages, they can install foo without having GTK, and later decide
5365 to install gfoo (pulling in GTK at that time). This is an advantage to source
5366 users too, avoiding the need for rebuilds.
5368 Plugins with widely varying dependencies should usually be split instead of
5371 It is often more work to maintain split packages, especially if the upstream
5372 package does not support this. The decision of split vs. option should be made
5373 based on the likelihood that users will want or object to the various pieces,
5374 the size of the dependencies that are included, and the amount of work.
5376 A further consideration is licensing. Non-free parts, or parts that depend on
5377 non-free dependencies (especially plugins) should almost always be split if
5380 16.1. Global default options
5382 Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of
5383 the options that should be built into every package if that option is
5384 supported. This variable should be set in mk.conf.
5386 16.2. Converting packages to use bsd.options.mk
5388 The following example shows how bsd.options.mk should be used by the
5389 hypothetical ``wibble'' package, either in the package Makefile, or in a file,
5390 e.g. options.mk, that is included by the main package Makefile.
5392 PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
5393 PKG_SUPPORTED_OPTIONS= wibble-foo ldap
5394 PKG_OPTIONS_OPTIONAL_GROUPS= database
5395 PKG_OPTIONS_GROUP.database= mysql pgsql
5396 PKG_SUGGESTED_OPTIONS= wibble-foo
5397 PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
5398 PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo
5400 .include "../../mk/bsd.prefs.mk"
5402 # this package was previously named wibble2
5403 .if defined(PKG_OPTIONS.wibble2)
5404 PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
5405 PKG_OPTIONS_DEPRECATED_WARNINGS+= \
5406 "Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR} instead."
5409 .include "../../mk/bsd.options.mk"
5411 # Package-specific option-handling
5416 .if !empty(PKG_OPTIONS:Mwibble-foo)
5417 CONFIGURE_ARGS+= --enable-foo
5423 .if !empty(PKG_OPTIONS:Mldap)
5424 . include "../../databases/openldap-client/buildlink3.mk"
5425 CONFIGURE_ARGS+= --enable-ldap=${BUILDLINK_PREFIX.openldap-client}
5429 ### database support
5431 .if !empty(PKG_OPTIONS:Mmysql)
5432 . include "../../mk/mysql.buildlink3.mk"
5434 .if !empty(PKG_OPTIONS:Mpgsql)
5435 . include "../../mk/pgsql.buildlink3.mk"
5438 The first section contains the information about which build options are
5439 supported by the package, and any default options settings if needed.
5441 1. PKG_OPTIONS_VAR is the name of the make(1) variable that the user can set
5442 to override the default options. It should be set to PKG_OPTIONS.pkgbase.
5443 Do not set it to PKG_OPTIONS.${PKGBASE}, since PKGBASE is not defined at
5444 the point where the options are processed.
5446 2. PKG_SUPPORTED_OPTIONS is a list of build options supported by the package.
5448 3. PKG_OPTIONS_OPTIONAL_GROUPS is a list of names of groups of mutually
5449 exclusive options. The options in each group are listed in
5450 PKG_OPTIONS_GROUP.groupname. The most specific setting of any option from
5451 the group takes precedence over all other options in the group. Options
5452 from the groups will be automatically added to PKG_SUPPORTED_OPTIONS.
5454 4. PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, but
5455 building the packages will fail if no option from the group is selected.
5457 5. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of options. At least
5458 one option from each set must be selected. The options in each set are
5459 listed in PKG_OPTIONS_SET.setname. Options from the sets will be
5460 automatically added to PKG_SUPPORTED_OPTIONS. Building the package will
5461 fail if no option from the set is selected.
5463 6. PKG_SUGGESTED_OPTIONS is a list of build options which are enabled by
5466 7. PKG_OPTIONS_LEGACY_VARS is a list of "USE_VARIABLE:option" pairs that map
5467 legacy mk.conf variables to their option counterparts. Pairs should be
5468 added with "+=" to keep the listing of global legacy variables. A warning
5469 will be issued if the user uses a legacy variable.
5471 8. PKG_OPTIONS_LEGACY_OPTS is a list of "old-option:new-option" pairs that map
5472 options that have been renamed to their new counterparts. Pairs should be
5473 added with "+=" to keep the listing of global legacy options. A warning
5474 will be issued if the user uses a legacy option.
5476 9. PKG_LEGACY_OPTIONS is a list of options implied by deprecated variables
5477 used. This can be used for cases that neither PKG_OPTIONS_LEGACY_VARS nor
5478 PKG_OPTIONS_LEGACY_OPTS can handle, e. g. when PKG_OPTIONS_VAR is renamed.
5480 10. PKG_OPTIONS_DEPRECATED_WARNINGS is a list of warnings about deprecated
5481 variables or options used, and what to use instead.
5483 A package should never modify PKG_DEFAULT_OPTIONS or the variable named in
5484 PKG_OPTIONS_VAR. These are strictly user-settable. To suggest a default set of
5485 options, use PKG_SUGGESTED_OPTIONS.
5487 PKG_OPTIONS_VAR must be defined before including bsd.options.mk. If none of
5488 PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, and
5489 PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform-specific
5490 options if none of them is supported on the current platform), PKG_OPTIONS is
5491 set to the empty list and the package is otherwise treated as not using the
5494 After the inclusion of bsd.options.mk, the variable PKG_OPTIONS contains the
5495 list of selected build options, properly filtered to remove unsupported and
5498 The remaining sections contain the logic that is specific to each option. The
5499 correct way to check for an option is to check whether it is listed in
5502 .if !empty(PKG_OPTIONS:Moption)
5506 Options that enable similar features in different packages (like optional
5507 support for a library) should use a common name in all packages that support it
5508 (like the name of the library). If another package already has an option with
5509 the same meaning, use the same name.
5511 Options that enable features specific to one package, where it's unlikely that
5512 another (unrelated) package has the same (or a similar) optional feature,
5513 should use a name prefixed with pkgname-.
5515 If a group of related packages share an optional feature specific to that
5516 group, prefix it with the name of the "main" package (e. g.
5517 djbware-errno-hack).
5519 For new options, add a line to mk/defaults/options.description. Lines have two
5520 fields, separated by tab. The first field is the option name, the second its
5521 description. The description should be a whole sentence (starting with an
5522 uppercase letter and ending with a period) that describes what enabling the
5523 option does. E. g. "Enable ispell support." The file is sorted by option names.
5525 16.4. Determining the options of dependencies
5527 When writing buildlink3.mk files, it is often necessary to list different
5528 dependencies based on the options with which the package was built. For
5529 querying these options, the file pkgsrc/mk/pkg-build-options.mk should be used.
5530 A typical example looks like this:
5532 pkgbase := libpurple
5533 .include "../../mk/pkg-build-options.mk"
5535 .if !empty(PKG_BUILD_OPTIONS.libpurple:Mdbus)
5539 Including pkg-build-options.mk here will set the variable
5540 PKG_BUILD_OPTIONS.libpurple to the build options of the libpurple package,
5541 which can then be queried like PKG_OPTIONS in the options.mk file. See the file
5542 pkg-build-options.mk for more details.
5544 Chapter 17. The build process
5549 17.2. Program location
5550 17.3. Directories used during the build process
5551 17.4. Running a phase
5552 17.5. The fetch phase
5554 17.5.1. What to fetch and where to get it from
5555 17.5.2. How are the files fetched?
5557 17.6. The checksum phase
5558 17.7. The extract phase
5559 17.8. The patch phase
5560 17.9. The tools phase
5561 17.10. The wrapper phase
5562 17.11. The configure phase
5563 17.12. The build phase
5564 17.13. The test phase
5565 17.14. The install phase
5566 17.15. The package phase
5568 17.17. Other helpful targets
5572 This chapter gives a detailed description on how a package is built. Building a
5573 package is separated into different phases (for example fetch, build, install),
5574 all of which are described in the following sections. Each phase is split into
5575 so-called stages, which take the name of the containing phase, prefixed by one
5576 of pre-, do- or post-. (Examples are pre-configure, post-build.) Most of the
5577 actual work is done in the do-* stages.
5579 Never override the regular targets (like fetch), if you have to, override the
5582 The basic steps for building a program are always the same. First the program's
5583 source (distfile) must be brought to the local system and then extracted. After
5584 any pkgsrc-specific patches to compile properly are applied, the software can
5585 be configured, then built (usually by compiling), and finally the generated
5586 binaries, etc. can be put into place on the system.
5588 To get more details about what is happening at each step, you can set the
5589 PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in
5590 more details about the patch step.
5592 17.2. Program location
5594 Before outlining the process performed by the NetBSD package system in the next
5595 section, here's a brief discussion on where programs are installed, and which
5596 variables influence this.
5598 The automatic variable PREFIX indicates where all files of the final program
5599 shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
5600 pkgs in the cross category. The value of PREFIX needs to be put into the
5601 various places in the program's source where paths to these files are encoded.
5602 See Section 11.3, "patches/*" and Section 19.3.1, "Shared libraries - libtool"
5605 When choosing which of these variables to use, follow the following rules:
5607 * PREFIX always points to the location where the current pkg will be
5608 installed. When referring to a pkg's own installation path, use "${PREFIX}
5611 * LOCALBASE is where all non-X11 pkgs are installed. If you need to construct
5612 a -I or -L argument to the compiler to find includes and libraries
5613 installed by another non-X11 pkg, use "${LOCALBASE}". The name LOCALBASE
5614 stems from FreeBSD, which installed all packages in /usr/local. As pkgsrc
5615 leaves /usr/local for the system administrator, this variable is a
5618 * X11BASE is where the actual X11 distribution (from xsrc, etc.) is
5619 installed. When looking for standard X11 includes (not those installed by a
5620 package), use "${X11BASE}".
5622 * X11-based packages are special in that they may be installed in either
5623 X11BASE or LOCALBASE.
5625 Usually, X11 packages should be installed under LOCALBASE whenever
5626 possible. Note that you will need to include ../../mk/x11.buildlink3.mk in
5627 them to request the presence of X11 and to get the right compilation flags.
5629 Even though, there are some packages that cannot be installed under
5630 LOCALBASE: those that come with app-defaults files. These packages are
5631 special and they must be placed under X11BASE. To accomplish this, set
5632 either USE_X11BASE or USE_IMAKE in your package.
5634 Some notes: If you need to find includes or libraries installed by a pkg
5635 that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in
5636 both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages
5637 in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default.
5639 * X11PREFIX should be used to refer to the installed location of an X11
5640 package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed,
5641 and to LOCALBASE if xpkgwedge is installed.
5643 * If xpkgwedge is installed, it is possible to have some packages installed
5644 in X11BASE and some in LOCALBASE. To determine the prefix of an installed
5645 package, the EVAL_PREFIX definition can be used. It takes pairs in the
5646 format "DIRNAME=<package>", and the make(1) variable DIRNAME will be set to
5647 the prefix of the installed package <package>, or "${X11PREFIX}" if the
5648 package is not installed.
5650 This is best illustrated by example.
5652 The following lines are taken from pkgsrc/wm/scwm/Makefile:
5654 EVAL_PREFIX+= GTKDIR=gtk+
5655 CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q}
5656 CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q}
5657 CONFIGURE_ARGS+= --enable-multibyte
5659 Specific defaults can be defined for the packages evaluated using
5660 EVAL_PREFIX, by using a definition of the form:
5662 GTKDIR_DEFAULT= ${LOCALBASE}
5664 where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair.
5666 * Within ${PREFIX}, packages should install files according to hier(7), with
5667 the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
5670 17.3. Directories used during the build process
5672 When building a package, various directories are used to store source files,
5673 temporary files, pkgsrc-internal files, and so on. These directories are
5676 Some of the directory variables contain relative pathnames. There are two
5677 common base directories for these relative directories: PKGSRCDIR/PKGPATH is
5678 used for directories that are pkgsrc-specific. WRKSRC is used for directories
5679 inside the package itself.
5683 This is an absolute pathname that points to the pkgsrc root directory.
5684 Generally, you don't need it.
5688 This is an absolute pathname that points to the current package.
5692 This is a pathname relative to PKGSRCDIR that points to the current
5697 This is an absolute pathname pointing to the directory where all work takes
5698 place. The distfiles are extracted to this directory. It also contains
5699 temporary directories and log files used by the various pkgsrc frameworks,
5700 like buildlink or the wrappers.
5704 This is an absolute pathname pointing to the directory where the distfiles
5705 are extracted. It is usually a direct subdirectory of WRKDIR, and often
5706 it's the only directory entry that isn't hidden. This variable may be
5707 changed by a package Makefile.
5709 The CREATE_WRKDIR_SYMLINK definition takes either the value yes or no and
5710 defaults to no. It indicates whether a symbolic link to the WRKDIR is to be
5711 created in the pkgsrc entry's directory. If users would like to have their
5712 pkgsrc trees behave in a read-only manner, then the value of
5713 CREATE_WRKDIR_SYMLINK should be set to no.
5715 17.4. Running a phase
5717 You can run a particular phase by typing make phase, where phase is the name of
5718 the phase. This will automatically run all phases that are required for this
5719 phase. The default phase is build, that is, when you run make without
5720 parameters in a package directory, the package will be built, but not
5723 17.5. The fetch phase
5725 The first step in building a package is to fetch the distribution files
5726 (distfiles) from the sites that are providing them. This is the task of the
5729 17.5.1. What to fetch and where to get it from
5731 In simple cases, MASTER_SITES defines all URLs from where the distfile, whose
5732 name is derived from the DISTNAME variable, is fetched. The more complicated
5733 cases are described below.
5735 The variable DISTFILES specifies the list of distfiles that have to be fetched.
5736 Its value defaults to ${DISTNAME}${EXTRACT_SUFX}, so that most packages don't
5737 need to define it at all. EXTRACT_SUFX is .tar.gz by default, but can be
5738 changed freely. Note that if your package requires additional distfiles to the
5739 default one, you cannot just append the additional filenames using the +=
5740 operator, but you have write for example:
5742 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
5744 Each distfile is fetched from a list of sites, usually MASTER_SITES. If the
5745 package has multiple DISTFILES or multiple PATCHFILES from different sites, you
5746 can set SITES.distfile to the list of URLs where the file distfile (including
5747 the suffix) can be found.
5749 DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
5750 DISTFILES+= foo-file.tar.gz
5751 SITES.foo-file.tar.gz= \
5752 http://www.somewhere.com/somehow/ \
5753 http://www.somewhereelse.com/mirror/somehow/
5755 When actually fetching the distfiles, each item from MASTER_SITES or SITES.*
5756 gets the name of each distfile appended to it, without an intermediate slash.
5757 Therefore, all site values have to end with a slash or other separator
5758 character. This allows for example to set MASTER_SITES to a URL of a CGI script
5759 that gets the name of the distfile as a parameter. In this case, the definition
5762 MASTER_SITES= http://www.example.com/download.cgi?file=
5764 The exception to this rule are URLs starting with a dash. In that case the URL
5765 is taken as is, fetched and the result stored under the name of the distfile.
5767 There are some predefined values for MASTER_SITES, which can be used in
5768 packages. The names of the variables should speak for themselves.
5770 ${MASTER_SITE_APACHE}
5771 ${MASTER_SITE_BACKUP}
5772 ${MASTER_SITE_CYGWIN}
5773 ${MASTER_SITE_DEBIAN}
5774 ${MASTER_SITE_FREEBSD}
5775 ${MASTER_SITE_FREEBSD_LOCAL}
5776 ${MASTER_SITE_GENTOO}
5777 ${MASTER_SITE_GNOME}
5779 ${MASTER_SITE_GNUSTEP}
5780 ${MASTER_SITE_IFARCHIVE}
5782 ${MASTER_SITE_MOZILLA}
5783 ${MASTER_SITE_MYSQL}
5784 ${MASTER_SITE_OPENOFFICE}
5785 ${MASTER_SITE_PERL_CPAN}
5786 ${MASTER_SITE_PGSQL}
5787 ${MASTER_SITE_R_CRAN}
5788 ${MASTER_SITE_SOURCEFORGE}
5789 ${MASTER_SITE_SOURCEFORGE_JP}
5790 ${MASTER_SITE_SUNSITE}
5792 ${MASTER_SITE_TEX_CTAN}
5793 ${MASTER_SITE_XCONTRIB}
5794 ${MASTER_SITE_XEMACS}
5796 Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP
5797 contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org/
5798 pub/NetBSD/packages/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local
5799 package source distributions that are maintained in ftp://ftp.NetBSD.org/pub/
5800 NetBSD/packages/distfiles/LOCAL_PORTS/.
5802 If you choose one of these predefined sites, you may want to specify a
5803 subdirectory of that site. Since these macros may expand to more than one
5804 actual site, you must use the following construct to specify a subdirectory:
5806 MASTER_SITES= ${MASTER_SITE_GNU:=subdirectory/name/}
5807 MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=project_name/}
5809 Note the trailing slash after the subdirectory name.
5811 17.5.2. How are the files fetched?
5813 The fetch phase makes sure that all the distfiles exist in a local directory
5814 (DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they
5815 are fetched using commands of the form
5817 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
5819 where ${site} varies through several possibilities in turn: first,
5820 MASTER_SITE_OVERRIDE is tried, then the sites specified in either SITES.file if
5821 defined, else MASTER_SITES or PATCH_SITES, as applies, then finally the value
5822 of MASTER_SITE_BACKUP. The order of all except the first and the last can be
5823 optionally sorted by the user, via setting either MASTER_SORT_RANDOM, and
5824 MASTER_SORT_AWK or MASTER_SORT_REGEX.
5826 The specific command and arguments used depend on the FETCH_USING parameter.
5827 The example above is for FETCH_USING=custom.
5829 The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles
5830 target to mirror the distfiles, if they are freely distributable. Packages
5831 setting NO_SRC_ON_FTP (usually to "${RESTRICTED}") will not have their
5834 17.6. The checksum phase
5836 After the distfile(s) are fetched, their checksum is generated and compared
5837 with the checksums stored in the distinfo file. If the checksums don't match,
5838 the build is aborted. This is to ensure the same distfile is used for building,
5839 and that the distfile wasn't changed, e.g. by some malign force, deliberately
5840 changed distfiles on the master distribution site or network lossage.
5842 17.7. The extract phase
5844 When the distfiles are present on the local system, they need to be extracted,
5845 as they usually come in the form of some compressed archive format.
5847 By default, all DISTFILES are extracted. If you only need some of them, you can
5848 set the EXTRACT_ONLY variable to the list of those files.
5850 Extracting the files is usually done by a little program, mk/extract/extract,
5851 which already knows how to extract various archive formats, so most likely you
5852 will not need to change anything here. But if you need, the following variables
5855 EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}
5857 Use these variables to override the default options for an extract command,
5858 which are defined in mk/extract/extract.
5862 This variable can be set to bsdtar, gtar, nbtar (which is the default
5863 value), pax, or an absolute pathname pointing to the command with which tar
5864 archives should be extracted. It is preferred to choose bsdtar over gtar if
5865 NetBSD's pax-as-tar is not good enough.
5867 If the extract program doesn't serve your needs, you can also override the
5868 EXTRACT_CMD variable, which holds the command used for extracting the files.
5869 This command is executed in the ${WRKSRC} directory. During execution of this
5870 command, the shell variable extract_file holds the absolute pathname of the
5871 file that is going to be extracted.
5873 And if that still does not suffice, you can override the do-extract target in
5874 the package Makefile.
5876 17.8. The patch phase
5878 After extraction, all the patches named by the PATCHFILES, those present in the
5879 patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
5880 /usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz
5881 are uncompressed before they are applied, files ending in .orig or .rej are
5882 ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See
5883 Section 11.3, "patches/*" for more details.
5885 By default patch(1) is given special args to make it fail if the patches apply
5886 with some lines of fuzz. Please fix (regen) the patches so that they apply
5887 cleanly. The rationale behind this is that patches that don't apply cleanly may
5888 end up being applied in the wrong place, and cause severe harm there.
5890 17.9. The tools phase
5892 This is covered in Chapter 18, Tools needed for building or running.
5894 17.10. The wrapper phase
5896 This phase creates wrapper programs for the compilers and linkers. The
5897 following variables can be used to tweak the wrappers.
5901 The command used to print progress messages. Does nothing by default. Set
5902 to ${ECHO} to see the progress messages.
5906 This variable can be set to yes (default) or no, depending on whether you
5907 want additional information in the wrapper log file.
5909 WRAPPER_UPDATE_CACHE
5911 This variable can be set to yes or no, depending on whether the wrapper
5912 should use its cache, which will improve the speed. The default value is
5913 yes, but is forced to no if the platform does not support it.
5915 WRAPPER_REORDER_CMDS
5917 A list of reordering commands. A reordering command has the form reorder:l:
5918 lib1:lib2. It ensures that that -llib1 occurs before -llib2.
5920 WRAPPER_TRANSFORM_CMDS
5922 A list of transformation commands. [TODO: investigate further]
5924 17.11. The configure phase
5926 Most pieces of software need information on the header files, system calls, and
5927 library routines which are available on the platform they run on. The process
5928 of determining this information is known as configuration, and is usually
5929 automated. In most cases, a script is supplied with the distfiles, and its
5930 invocation results in generation of header files, Makefiles, etc.
5932 If the package contains a configure script, this can be invoked by setting
5933 HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you
5934 should set GNU_CONFIGURE to "yes" instead. What happens in the configure phase
5937 .for d in ${CONFIGURE_DIRS}
5940 && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
5943 CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In
5944 each of these directories, the configure script is run with the environment
5945 CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV,
5946 CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed
5949 If the program uses an Imakefile for configuration, the appropriate steps can
5950 be invoked by setting USE_IMAKE to "yes". (If you only want the package
5951 installed in ${X11PREFIX} but xmkmf not being run, set USE_X11BASE instead.)
5952 You can add variables to xmkmf's environment by adding them to the SCRIPTS_ENV
5955 If the program uses cmake for configuration, the appropriate steps can be
5956 invoked by setting USE_CMAKE to "yes". You can add variables to cmake's
5957 environment by adding them to the CONFIGURE_ENV variable and arguments to cmake
5958 by adding them to the CMAKE_ARGS variable. The top directory argument is given
5959 by the CMAKE_ARG_PATH variable, that defaults to "." (relative to
5962 If there is no configure step at all, set NO_CONFIGURE to "yes".
5964 17.12. The build phase
5966 For building a package, a rough equivalent of the following code is executed.
5968 .for d in ${BUILD_DIRS}
5971 && env ${MAKE_ENV} \
5972 ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \
5977 BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of
5978 these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and
5979 arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE
5980 and BUILD_TARGET may all be changed by the package.
5982 The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake",
5983 "make" otherwise. The default value of MAKE_FILE is "Makefile", and
5984 BUILD_TARGET defaults to "all".
5986 If there is no build step at all, set NO_BUILD to "yes".
5988 17.13. The test phase
5992 17.14. The install phase
5994 Once the build stage has completed, the final step is to install the software
5995 in public directories, so users can access the programs and files.
5997 In the install phase, a rough equivalent of the following code is executed.
5998 Additionally, before and after this code, much magic is performed to do
5999 consistency checks, registering the package, and so on.
6001 .for d in ${INSTALL_DIRS}
6004 && env ${MAKE_ENV} \
6005 ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \
6010 The variable's meanings are analogous to the ones in the build phase.
6011 INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is "install" by default,
6012 plus "install.man" if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
6015 In the install phase, the following variables are useful. They are all
6016 variations of the install(1) command that have the owner, group and permissions
6017 preset. INSTALL is the plain install command. The specialized variants,
6018 together with their intended use, are:
6022 directories that contain binaries
6026 directories that contain scripts
6030 directories that contain shared and static libraries
6034 directories that contain data files
6038 directories that contain man pages
6042 binaries that can be stripped from debugging symbols
6046 binaries that cannot be stripped
6054 shared and static libraries
6062 data files for games
6068 Some other variables are:
6072 A list of directories relative to PREFIX that are created by pkgsrc at the
6073 beginning of the install phase. The package is supposed to create all
6074 needed directories itself before installing files to it and list all other
6077 In the rare cases that a package shouldn't install anything, set NO_INSTALL to
6078 "yes". This is mostly relevant for packages in the regress category.
6080 17.15. The package phase
6082 Once the install stage has completed, a binary package of the installed files
6083 can be built. These binary packages can be used for quick installation without
6084 previous compilation, e.g. by the make bin-install or by using pkg_add.
6086 By default, the binary packages are created in ${PACKAGES}/All and symlinks are
6087 created in ${PACKAGES}/category, one for each category in the CATEGORIES
6088 variable. PACKAGES defaults to pkgsrc/packages.
6092 Once you're finished with a package, you can clean the work directory by
6093 running make clean. If you want to clean the work directories of all
6094 dependencies too, use make clean-depends.
6096 17.17. Other helpful targets
6100 For any of the main targets described in the previous section, two
6101 auxiliary targets exist with "pre-" and "post-" used as a prefix for the
6102 main target's name. These targets are invoked before and after the main
6103 target is called, allowing extra configuration or installation steps be
6104 performed from a package's Makefile, for example, which a program's
6105 configure script or install target omitted.
6109 Should one of the main targets do the wrong thing, and should there be no
6110 variable to fix this, you can redefine it with the do-* target. (Note that
6111 redefining the target itself instead of the do-* target is a bad idea, as
6112 the pre-* and post-* targets won't be called anymore, etc.) You will not
6113 usually need to do this.
6117 If you did a make install and you noticed some file was not installed
6118 properly, you can repeat the installation with this target, which will
6119 ignore the "already installed" flag.
6121 This is the default value of DEPENDS_TARGET except in the case of make
6122 update and make package, where the defaults are "package" and "update",
6127 This target does a pkg_delete(1) in the current directory, effectively
6128 de-installing the package. The following variables can be used to tune the
6133 Add a "-v" to the pkg_delete(1) command.
6137 Remove all packages that require (depend on) the given package. This
6138 can be used to remove any packages that may have been pulled in by a
6139 given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
6140 pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding
6141 "-R" to the pkg_delete(1) command line.
6145 Install a binary package from local disk and via FTP from a list of sites
6146 (see the BINPKG_SITES variable), and do a make package if no binary package
6147 is available anywhere. The arguments given to pkg_add can be set via
6148 BIN_INSTALL_FLAGS e.g., to do verbose operation, etc.
6152 This target causes the current package to be updated to the latest version.
6153 The package and all depending packages first get de-installed, then current
6154 versions of the corresponding packages get compiled and installed. This is
6155 similar to manually noting which packages are currently installed, then
6156 performing a series of make deinstall and make install (or whatever
6157 UPDATE_TARGET is set to) for these packages.
6159 You can use the "update" target to resume package updating in case a
6160 previous make update was interrupted for some reason. However, in this
6161 case, make sure you don't call make clean or otherwise remove the list of
6162 dependent packages in WRKDIR. Otherwise, you lose the ability to
6163 automatically update the current package along with the dependent packages
6166 Resuming an interrupted make update will only work as long as the package
6167 tree remains unchanged. If the source code for one of the packages to be
6168 updated has been changed, resuming make update will most certainly fail!
6170 The following variables can be used either on the command line or in
6171 mk.conf to alter the behaviour of make update:
6175 Install target to recursively use for the updated package and the
6176 dependent packages. Defaults to DEPENDS_TARGET if set, "install"
6177 otherwise for make update. Other good targets are "package" or
6178 "bin-install". Do not set this to "update" or you will get stuck in an
6183 Don't clean up after updating. Useful if you want to leave the work
6184 sources of the updated packages around for inspection or other
6185 purposes. Be sure you eventually clean up the source tree (see the
6186 "clean-update" target below) or you may run into troubles with old
6187 source code still lying around on your next make or make update.
6191 Deinstall each package before installing (making DEPENDS_TARGET). This
6192 may be necessary if the "clean-update" target (see below) was called
6193 after interrupting a running make update.
6197 Allows you to disable recursion and hardcode the target for packages.
6198 The default is "update" for the update target, facilitating a recursive
6199 update of prerequisite packages. Only set DEPENDS_TARGET if you want to
6200 disable recursive updates. Use UPDATE_TARGET instead to just set a
6201 specific target for each package to be installed during make update
6206 Clean the source tree for all packages that would get updated if make
6207 update was called from the current directory. This target should not be
6208 used if the current package (or any of its depending packages) have already
6209 been de-installed (e.g., after calling make update) or you may lose some
6210 packages you intended to update. As a rule of thumb: only use this target
6211 before the first time you run make update and only if you have a dirty
6212 package tree (e.g., if you used NOCLEAN).
6214 If you are unsure about whether your tree is clean, you can either perform
6215 a make clean at the top of the tree, or use the following sequence of
6216 commands from the directory of the package you want to update (before
6217 running make update for the first time, otherwise you lose all the packages
6218 you wanted to update!):
6221 # make clean CLEANDEPENDS=YES
6225 The following variables can be used either on the command line or in
6226 mk.conf to alter the behaviour of make clean-update:
6230 After make clean, do not reconstruct the list of directories to update
6231 for this package. Only use this if make update successfully installed
6232 all packages you wanted to update. Normally, this is done automatically
6233 on make update, but may have been suppressed by the NOCLEAN variable
6238 Update the installation of the current package. This differs from update in
6239 that it does not replace dependent packages. You will need to install
6240 pkgtools/pkg_tarup for this target to work.
6242 Be careful when using this target! There are no guarantees that dependent
6243 packages will still work, in particular they will most certainly break if
6244 you make replace a library package whose shared library major version
6245 changed between your installed version and the new one. For this reason,
6246 this target is not officially supported and only recommended for advanced
6251 This target invokes pkg_info(1) for the current package. You can use this
6252 to check which version of a package is installed.
6256 This is a top-level command, i.e. it should be used in the pkgsrc
6257 directory. It creates a database of all packages in the local pkgsrc tree,
6258 including dependencies, comment, maintainer, and some other useful
6259 information. Individual entries are created by running make describe in the
6260 packages' directories. This index file is saved as pkgsrc/INDEX. It can be
6261 displayed in verbose format by running make print-index. You can search in
6262 it with make search key=something. You can extract a list of all packages
6263 that depend on a particular one by running make show-deps PKG=somepackage.
6265 Running this command takes a very long time, some hours even on fast
6270 This target generates a README.html file, which can be viewed using a
6271 browser such as www/firefox or www/links. The generated files contain
6272 references to any packages which are in the PACKAGES directory on the local
6273 host. The generated files can be made to refer to URLs based on
6274 FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate
6275 README.html files which pointed to binary packages on the local machine, in
6276 the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
6277 FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
6278 subdirectories will be searched for all the binary packages.
6280 The target can be run at the toplevel or in category directories, in which
6281 case it descends recursively.
6285 This is a top-level command, run it in pkgsrc. Use this target to create a
6286 file README-all.html which contains a list of all packages currently
6287 available in the NetBSD Packages Collection, together with the category
6288 they belong to and a short description. This file is compiled from the
6289 pkgsrc/*/README.html files, so be sure to run this after a make readme.
6293 This is very much the same as the "readme" target (see above), but is to be
6294 used when generating a pkgsrc tree to be written to a CD-ROM. This target
6295 also produces README.html files, and can be made to refer to URLs based on
6296 CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
6300 This target shows which distfiles and patchfiles are needed to build the
6301 package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not
6306 This target shows nothing if the package is not installed. If a version of
6307 this package is installed, but is not the version provided in this version
6308 of pkgsrc, then a warning message is displayed. This target can be used to
6309 show which of your installed packages are downlevel, and so the old
6310 versions can be deleted, and the current ones added.
6314 This target shows the directory in the pkgsrc hierarchy from which the
6315 package can be built and installed. This may not be the same directory as
6316 the one from which the package was installed. This target is intended to be
6317 used by people who may wish to upgrade many packages on a single host, and
6318 can be invoked from the top-level pkgsrc Makefile by using the
6319 "show-host-specific-pkgs" target.
6321 show-installed-depends
6323 This target shows which installed packages match the current package's
6324 DEPENDS. Useful if out of date dependencies are causing build problems.
6328 After a package is installed, check all its binaries and (on ELF platforms)
6329 shared libraries to see if they find the shared libs they need. Run by
6330 default if PKG_DEVELOPER is set in mk.conf.
6334 After a "make install" from a new or upgraded pkg, this prints out an
6335 attempt to generate a new PLIST from a find -newer work/.extract_done. An
6336 attempt is made to care for shared libs etc., but it is strongly
6337 recommended to review the result before putting it into PLIST. On upgrades,
6338 it's useful to diff the output of this command against an already existing
6341 If the package installs files via tar(1) or other methods that don't update
6342 file access times, be sure to add these files manually to your PLIST, as
6343 the "find -newer" command used by this target won't catch them!
6345 See Section 13.3, "Tweaking output of make print-PLIST" for more
6346 information on this target.
6350 Used to do bulk builds. If an appropriate binary package already exists, no
6351 action is taken. If not, this target will compile, install and package it
6352 (and its depends, if PKG_DEPENDS is set properly. See Section 7.3.1,
6353 "Configuration"). After creating the binary package, the sources, the
6354 just-installed package and its required packages are removed, preserving
6357 Beware that this target may deinstall all packages installed on a system!
6361 Used during bulk-installs to install required packages. If an up-to-date
6362 binary package is available, it will be installed via pkg_add(1). If not,
6363 make bulk-package will be executed, but the installed binary won't be
6366 A binary package is considered "up-to-date" to be installed via pkg_add(1)
6369 * None of the package's files (Makefile, ...) were modified since it was
6372 * None of the package's required (binary) packages were modified since it
6375 Beware that this target may deinstall all packages installed on a system!
6377 Chapter 18. Tools needed for building or running
6381 18.1. Tools for pkgsrc builds
6382 18.2. Tools needed by packages
6383 18.3. Tools provided by platforms
6384 18.4. Questions regarding the tools
6386 The USE_TOOLS definition is used both internally by pkgsrc and also for
6387 individual packages to define what commands are needed for building a package
6388 (like BUILD_DEPENDS) or for later run-time of an installed packaged (such as
6389 DEPENDS). If the native system provides an adequate tool, then in many cases, a
6390 pkgsrc package will not be used.
6392 When building a package, the replacement tools are made available in a
6393 directory (as symlinks or wrapper scripts) that is early in the executable
6394 search path. Just like the buildlink system, this helps with consistent builds.
6396 A tool may be needed to help build a specific package. For example, perl, GNU
6397 make (gmake) or yacc may be needed.
6399 Also a tool may be needed, for example, because the native system's supplied
6400 tool may be inefficient for building a package with pkgsrc. For example, a
6401 package may need GNU awk, bison (instead of yacc) or a better sed.
6403 The tools used by a package can be listed by running make show-tools.
6405 18.1. Tools for pkgsrc builds
6407 The default set of tools used by pkgsrc is defined in bsd.pkg.mk. This includes
6408 standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be
6409 seen by running: make show-var VARNAME=USE_TOOLS.
6411 If a package needs a specific program to build then the USE_TOOLS variable can
6412 be used to define the tools needed.
6414 18.2. Tools needed by packages
6416 In the following examples, the :pkgsrc means to use the pkgsrc version and not
6417 the native version for a build dependency. And the :run means that it is used
6418 for a run-time dependencies also (and becomes a DEPENDS). The default is a
6419 build dependency which can be set with :build. (So in this example, it is the
6420 same as gmake:build and pkg-config:build.)
6422 USE_TOOLS+= mktemp:pkgsrc
6423 USE_TOOLS+= gmake perl:run pkg-config
6425 When using the tools framework, a TOOLS_PATH.foo variable is defined which
6426 contains the full path to the appropriate tool. For example, TOOLS_PATH.bash
6427 could be "/bin/bash" on Linux systems.
6429 If you always need a pkgsrc version of the tool at run-time, then just use
6432 18.3. Tools provided by platforms
6434 When improving or porting pkgsrc to a new platform, have a look at (or create)
6435 the corresponding platform specific make file fragment under pkgsrc/mk/tools/
6436 tools.${OPSYS}.mk which defines the name of the common tools. For example:
6438 .if exists(/usr/bin/bzcat)
6439 TOOLS_PLATFORM.bzcat?= /usr/bin/bzcat
6440 .elif exists(/usr/bin/bzip2)
6441 TOOLS_PLATFORM.bzcat?= /usr/bin/bzip2 -cd
6444 TOOLS_PLATFORM.true?= true # shell builtin
6446 18.4. Questions regarding the tools
6448 18.4.1. How do I add a new tool?
6449 18.4.2. How do I get a list of all available tools?
6450 18.4.3. How can I get a list of all the tools that a package is using while
6451 being built? I want to know whether it uses sed or not.
6453 18.4.1. How do I add a new tool?
6457 18.4.2. How do I get a list of all available tools?
6461 18.4.3. How can I get a list of all the tools that a package is using while
6462 being built? I want to know whether it uses sed or not.
6464 Currently, you can't. (TODO: But I want to be able to do it.)
6466 Chapter 19. Making your package work
6470 19.1. General operation
6472 19.1.1. Portability of packages
6473 19.1.2. How to pull in user-settable variables from ???
6474 19.1.3. User interaction
6475 19.1.4. Handling licenses
6476 19.1.5. Restricted packages
6477 19.1.6. Handling dependencies
6478 19.1.7. Handling conflicts with other packages
6479 19.1.8. Packages that cannot or should not be built
6480 19.1.9. Packages which should not be deleted, once installed
6481 19.1.10. Handling packages with security problems
6482 19.1.11. How to handle incrementing versions when fixing an existing
6484 19.1.12. Substituting variable text in the package files (the SUBST
6487 19.2. Fixing problems in the fetch phase
6489 19.2.1. Packages whose distfiles aren't available for plain downloading
6490 19.2.2. How to handle modified distfiles with the 'old' name
6492 19.3. Fixing problems in the configure phase
6494 19.3.1. Shared libraries - libtool
6495 19.3.2. Using libtool on GNU packages that already support libtool
6496 19.3.3. GNU Autoconf/Automake
6498 19.4. Programming languages
6500 19.4.1. C, C++, and Fortran
6502 19.4.3. Packages containing perl scripts
6503 19.4.4. Other programming languages
6505 19.5. Fixing problems in the build phase
6507 19.5.1. Compiling C and C++ code conditionally
6508 19.5.2. How to handle compiler bugs
6509 19.5.3. Undefined reference to ...
6510 19.5.4. Running out of memory
6512 19.6. Fixing problems in the install phase
6514 19.6.1. Creating needed directories
6515 19.6.2. Where to install documentation
6516 19.6.3. Installing highscore files
6517 19.6.4. Adding DESTDIR support to packages
6518 19.6.5. Packages with hardcoded paths to other interpreters
6519 19.6.6. Packages installing perl modules
6520 19.6.7. Packages installing info files
6521 19.6.8. Packages installing man pages
6522 19.6.9. Packages installing GConf data files
6523 19.6.10. Packages installing scrollkeeper/rarian data files
6524 19.6.11. Packages installing X11 fonts
6525 19.6.12. Packages installing GTK2 modules
6526 19.6.13. Packages installing SGML or XML data
6527 19.6.14. Packages installing extensions to the MIME database
6528 19.6.15. Packages using intltool
6529 19.6.16. Packages installing startup scripts
6530 19.6.17. Packages installing TeX modules
6531 19.6.18. Packages supporting running binaries in emulation
6532 19.6.19. Packages installing hicolor theme icons
6533 19.6.20. Packages installing desktop files
6535 19.7. Marking packages as having problems
6537 19.1. General operation
6539 19.1.1. Portability of packages
6541 One appealing feature of pkgsrc is that it runs on many different platforms. As
6542 a result, it is important to ensure, where possible, that packages in pkgsrc
6543 are portable. This chapter mentions some particular details you should pay
6544 attention to while working on pkgsrc.
6546 19.1.2. How to pull in user-settable variables from mk.conf
6548 The pkgsrc user can configure pkgsrc by overriding several variables in the
6549 file pointed to by MAKECONF, which is mk.conf by default. When you want to use
6550 those variables in the preprocessor directives of make(1) (for example .if or
6551 .for), you need to include the file ../../mk/bsd.prefs.mk before, which in turn
6552 loads the user preferences.
6554 But note that some variables may not be completely defined after ../../mk/
6555 bsd.prefs.mk has been included, as they may contain references to variables
6556 that are not yet defined. In shell commands this is no problem, since variables
6557 are actually macros, which are only expanded when they are used. But in the
6558 preprocessor directives mentioned above and in dependency lines (of the form
6559 target: dependencies) the variables are expanded at load time.
6563 Currently there is no exhaustive list of all variables that tells you whether
6564 they can be used at load time or only at run time, but it is in preparation.
6566 19.1.3. User interaction
6568 Occasionally, packages require interaction from the user, and this can be in a
6571 * When fetching the distfiles, some packages require user interaction such as
6572 entering username/password or accepting a license on a web page.
6574 * When extracting the distfiles, some packages may ask for passwords.
6576 * help to configure the package before it is built
6578 * help during the build process
6580 * help during the installation of a package
6582 The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of
6583 an interactive stage which will be needed, and this should be set in the
6584 package's Makefile, e.g.:
6586 INTERACTIVE_STAGE= build
6589 Multiple interactive stages can be specified:
6591 INTERACTIVE_STAGE= configure install
6594 The user can then decide to skip this package by setting the BATCH variable.
6596 19.1.4. Handling licenses
6598 Authors of software can choose the licence under which software can be copied.
6599 This is due to copyright law, and reasons for license choices are outside the
6600 scope of pkgsrc. The pkgsrc system recognizes that there are a number of
6601 licenses which some users may find objectionable or difficult or impossible to
6602 comply with. The Free Software Foundation has declared some licenses "Free",
6603 and the Open Source Initiative has a definition of "Open Source". The pkgsrc
6604 system, as a policy choice, does not label packages which have licenses that
6605 are Free or Open Source. However, packages without a license meeting either of
6606 those tests are labeled with a license tag denoting the license. Note that a
6607 package with no license to copy trivially does not meet either the Free or Open
6610 For packages which are not Free or Open Source, pkgsrc will not build the
6611 package unless the user has indicated to pkgsrc that packages with that
6612 particular license may be built. Note that this documentation avoids the term
6613 "accepted the license". The pkgsrc system is merely providing a mechanism to
6614 avoid accidentally building a package with a non-free license; judgement and
6615 responsibility remain with the user. (Installation of binary packages are not
6616 currently subject to this mechanism; this is a bug.)
6618 One might want to only install packages with a BSD license, or the GPL, and not
6619 the other. The free licenses are added to the default ACCEPTABLE_LICENSES
6620 variable. The user can override the default by setting the ACCEPTABLE_LICENSES
6621 variable with "=" instead of "+=". The licenses accepted by default are:
6624 gnu-gpl-v2 gnu-lgpl-v2
6625 gnu-gpl-v3 gnu-lgpl-v3
6626 original-bsd modified-bsd
6633 The license tag mechanism is intended to address copyright-related issues
6634 surrounding building, installing and using a package, and not to address
6635 redistribution issues (see RESTRICTED and NO_SRC_ON_FTP, etc.). Packages with
6636 redistribution restrictions should set these tags.
6638 Denoting that a package may be copied according to a particular license is done
6639 by placing the license in pkgsrc/licenses and setting the LICENSE variable to a
6640 string identifying the license, e.g. in graphics/xv:
6645 When trying to build, the user will get a notice that the package is covered by
6646 a license which has not been placed in the ACCEPTABLE_LICENSES variable:
6649 ===> xv-3.10anb9 has an unacceptable license: xv-license.
6650 ===> To view the license, enter "/usr/bin/make show-license".
6651 ===> To indicate acceptance, add this line to your /etc/mk.conf:
6652 ===> ACCEPTABLE_LICENSES+=xv-license
6656 The license can be viewed with make show-license, and if the user so chooses,
6657 the line printed above can be added to mk.conf to convey to pkgsrc that it
6658 should not in the future fail because of that license:
6660 ACCEPTABLE_LICENSES+=xv-license
6663 When adding a package with a new license, the license text should be added to
6664 pkgsrc/licenses for displaying. A list of known licenses can be seen in this
6667 When the license changes (in a way other than formatting), please make sure
6668 that the new license has a different name (e.g., append the version number if
6669 it exists, or the date). Just because a user told pkgsrc to build programs
6670 under a previous version of a license does not mean that pkgsrc should build
6671 programs under the new licenses. The higher-level point is that pkgsrc does not
6672 evaluate licenses for reasonableness; the only test is a mechanistic test of
6673 whether a particular text has been approved by either of two bodies.
6675 The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar language
6676 is deprecated because it does not crisply refer to a particular license text.
6677 Another problem with such usage is that it does not enable a user to tell
6678 pkgsrc to proceed for a single package without also telling pkgsrc to proceed
6679 for all packages with that tag.
6681 19.1.5. Restricted packages
6683 Some licenses restrict how software may be re-distributed. Because a license
6684 tag is required unless the package is Free or Open Source, all packages with
6685 restrictions should have license tags. By declaring the restrictions, package
6686 tools can automatically refrain from e.g. placing binary packages on FTP sites.
6688 There are four restrictions that may be encoded, which are the cross product of
6689 sources (distfiles) and binaries not being placed on FTP sites and CD-ROMs.
6690 Because this is rarely the exact language in any license, and because non-Free
6691 licenses tend to be different from each other, pkgsrc adopts a definition of
6692 FTP and CD-ROM. Pkgsrc uses "FTP" to mean that the source or binary file should
6693 not be made available over the Internet at no charge. Pkgsrc uses "CD-ROM" to
6694 mean that the source or binary may not be made available on some kind of media,
6695 together with other source and binary packages, and which is sold for a
6696 distribution charge.
6698 In order to encode these restrictions, the package system defines five make
6699 variables that can be set to note these restrictions:
6703 This variable should be set whenever a restriction exists (regardless of
6704 its kind). Set this variable to a string containing the reason for the
6705 restriction. It should be understood that those wanting to understand the
6706 restriction will have to read the license, and perhaps seek advice of
6711 Binaries may not be placed on CD-ROM containing other binary packages, for
6712 which a distribution charge may be made. In this case, set this variable to
6717 Binaries may not made available on the Internet without charge. In this
6718 case, set this variable to ${RESTRICTED}. If this variable is set, binary
6719 packages will not be included on ftp.NetBSD.org.
6723 Distfiles may not be placed on CD-ROM, together with other distfiles, for
6724 which a fee may be charged. In this case, set this variable to $
6729 Distfiles may not made available via FTP at no charge. In this case, set
6730 this variable to ${RESTRICTED}. If this variable is set, the distfile(s)
6731 will not be mirrored on ftp.NetBSD.org.
6733 19.1.6. Handling dependencies
6735 Your package may depend on some other package being present - and there are
6736 various ways of expressing this dependency. pkgsrc supports the BUILD_DEPENDS
6737 and DEPENDS definitions, the USE_TOOLS definition, as well as dependencies via
6738 buildlink3.mk, which is the preferred way to handle dependencies, and which
6739 uses the variables named above. See Chapter 14, Buildlink methodology for more
6742 The basic difference between the two variables is as follows: The DEPENDS
6743 definition registers that pre-requisite in the binary package so it will be
6744 pulled in when the binary package is later installed, whilst the BUILD_DEPENDS
6745 definition does not, marking a dependency that is only needed for building the
6748 This means that if you only need a package present whilst you are building, it
6749 should be noted as a BUILD_DEPENDS.
6751 The format for a BUILD_DEPENDS and a DEPENDS definition is:
6753 <pre-req-package-name>:../../<category>/<pre-req-package>
6756 Please note that the "pre-req-package-name" may include any of the wildcard
6757 version numbers recognized by pkg_info(1).
6759 1. If your package needs another package's binaries or libraries to build or
6760 run, and if that package has a buildlink3.mk file available, use it:
6762 .include "../../graphics/jpeg/buildlink3.mk"
6765 2. If your package needs to use another package to build itself and there is
6766 no buildlink3.mk file available, use the BUILD_DEPENDS definition:
6768 BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
6771 3. If your package needs a library with which to link and again there is no
6772 buildlink3.mk file available, this is specified using the DEPENDS
6773 definition. For example:
6775 DEPENDS+= xpm-3.4j:../../graphics/xpm
6778 You can also use wildcards in package dependencies:
6780 DEPENDS+= xpm-[0-9]*:../../graphics/xpm
6783 Note that such wildcard dependencies are retained when creating binary
6784 packages. The dependency is checked when installing the binary package and
6785 any package which matches the pattern will be used. Wildcard dependencies
6786 should be used with care.
6788 The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
6789 matches such as "tk-postgresql" matching a "tk-*" DEPENDS.
6791 Wildcards can also be used to specify that a package will only build
6792 against a certain minimum version of a pre-requisite:
6794 DEPENDS+= tiff>=3.5.4:../../graphics/tiff
6797 This means that the package will build against version 3.5.4 of the tiff
6798 library or newer. Such a dependency may be warranted if, for example, the
6799 API of the library has changed with version 3.5.4 and a package would not
6800 compile against an earlier version of tiff.
6802 Please note that such dependencies should only be updated if a package
6803 requires a newer pre-requisite, but not to denote recommendations such as
6804 ABI changes that do not prevent a package from building correctly. Such
6805 recommendations can be expressed using ABI_DEPENDS:
6807 ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff
6810 In addition to the above DEPENDS line, this denotes that while a package
6811 will build against tiff>=3.5.4, at least version 3.6.1 is recommended.
6812 ABI_DEPENDS entries will be turned into dependencies unless explicitly
6813 ignored (in which case a warning will be printed).
6815 To ignore these ABI dependency recommendations and just use the required
6816 DEPENDS, set USE_ABI_DEPENDS=NO. This may make it easier and faster to
6817 update packages built using pkgsrc, since older compatible dependencies can
6818 continue to be used. This is useful for people who watch their rebuilds
6819 very carefully; it is not very good as a general-purpose hammer. If you use
6820 it, you need to be mindful of possible ABI changes, including those from
6823 Packages that are built with recommendations ignored may not be uploaded to
6824 ftp.NetBSD.org by developers and should not be used across different
6825 systems that may have different versions of binary packages installed.
6827 For security fixes, please update the package vulnerabilities file. See
6828 Section 19.1.10, "Handling packages with security problems" for more
6831 4. If your package needs some executable to be able to run correctly and if
6832 there's no buildlink3.mk file, this is specified using the DEPENDS
6833 variable. The print/lyx package needs to be able to execute the latex
6834 binary from the teTeX package when it runs, and that is specified:
6836 DEPENDS+= teTeX-[0-9]*:../../print/teTeX
6839 The comment about wildcard dependencies from previous paragraph applies
6842 If your package needs files from another package to build, add the relevant
6843 distribution files to DISTFILES, so they will be extracted automatically. See
6844 the print/ghostscript package for an example. (It relies on the jpeg sources
6845 being present in source form during the build.)
6847 19.1.7. Handling conflicts with other packages
6849 Your package may conflict with other packages a user might already have
6850 installed on his system, e.g. if your package installs the same set of files as
6851 another package in the pkgsrc tree.
6853 In this case you can set CONFLICTS to a space-separated list of packages
6854 (including version string) your package conflicts with.
6856 For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus
6857 you set in pkgsrc/x11/Xaw3d/Makefile:
6859 CONFLICTS= Xaw-Xpm-[0-9]*
6862 and in pkgsrc/x11/Xaw-Xpm/Makefile:
6864 CONFLICTS= Xaw3d-[0-9]*
6867 Packages will automatically conflict with other packages with the name prefix
6868 and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
6869 with the older version "Xaw3d-1.3".
6871 19.1.8. Packages that cannot or should not be built
6873 There are several reasons why a package might be instructed to not build under
6874 certain circumstances. If the package builds and runs on most platforms, the
6875 exceptions should be noted with NOT_FOR_PLATFORM. If the package builds and
6876 runs on a small handful of platforms, set ONLY_FOR_PLATFORM instead. Both
6877 ONLY_FOR_PLATFORM and NOT_FOR_PLATFORM are OS triples (OS-version-platform)
6878 that can use glob-style wildcards.
6880 Some packages are tightly bound to a specific version of an operating system,
6881 e.g. LKMs or sysutils/lsof. Such binary packages are not backwards compatible
6882 with other versions of the OS, and should be uploaded to a version specific
6883 directory on the FTP server. Mark these packages by setting OSVERSION_SPECIFIC
6884 to "yes". This variable is not currently used by any of the package system
6885 internals, but may be used in the future.
6887 If the package should be skipped (for example, because it provides
6888 functionality already provided by the system), set PKG_SKIP_REASON to a
6889 descriptive message. If the package should fail because some preconditions are
6890 not met, set PKG_FAIL_REASON to a descriptive message.
6892 19.1.9. Packages which should not be deleted, once installed
6894 To ensure that a package may not be deleted, once it has been installed, the
6895 PKG_PRESERVE definition should be set in the package Makefile. This will be
6896 carried into any binary package that is made from this pkgsrc entry. A
6897 "preserved" package will not be deleted using pkg_delete(1) unless the "-f"
6900 19.1.10. Handling packages with security problems
6902 When a vulnerability is found, this should be noted in localsrc/security/
6903 advisories/pkg-vulnerabilities, and after committing that file, use make upload
6904 in the same directory to update the file on ftp.NetBSD.org.
6906 After fixing the vulnerability by a patch, its PKGREVISION should be increased
6907 (this is of course not necessary if the problem is fixed by using a newer
6908 release of the software).
6910 Also, if the fix should be applied to the stable pkgsrc branch, be sure to
6911 submit a pullup request!
6913 Binary packages already on ftp.NetBSD.org will be handled semi-automatically by
6916 19.1.11. How to handle incrementing versions when fixing an existing package
6918 When making fixes to an existing package it can be useful to change the version
6919 number in PKGNAME. To avoid conflicting with future versions by the original
6920 author, a "nb1", "nb2", ... suffix can be used on package versions by setting
6921 PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools.
6928 will result in a PKGNAME of "foo-17.42nb9". If you want to use the original
6929 value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use
6932 When a new release of the package is released, the PKGREVISION should be
6933 removed, e.g. on a new minor release of the above package, things should be
6939 PKGREVISION should be incremented for any non-trivial change in the resulting
6940 binary package. Without a PKGREVISION bump, someone with the previous version
6941 installed has no way of knowing that their package is out of date. Thus,
6942 changes without increasing PKGREVISION are essentially labeled "this is so
6943 trivial that no reasonable person would want to upgrade", and this is the rough
6944 test for when increasing PKGREVISION is appropriate. Examples of changes that
6945 do not merit increasing PKGREVISION are:
6947 * Changing HOMEPAGE, MAINTAINER, OWNER, or comments in Makefile.
6949 * Changing build variables if the resulting binary package is the same.
6953 * Adding PKG_OPTIONS if the default options don't change.
6955 Examples of changes that do merit an increase to PKGREVISION include:
6959 * Changes or additions to a patch file
6961 * Changes to the PLIST
6963 * A dependency is changed or renamed.
6965 PKGREVISION must also be incremented when dependencies have ABI changes.
6967 19.1.12. Substituting variable text in the package files (the SUBST framework)
6969 When you want to replace the same text in multiple files or when the
6970 replacement text varies, patches alone cannot help. This is where the SUBST
6971 framework comes in. It provides an easy-to-use interface for replacing text in
6974 SUBST_CLASSES+= fix-paths
6975 SUBST_STAGE.fix-paths= pre-configure
6976 SUBST_MESSAGE.fix-paths= Fixing absolute paths.
6977 SUBST_FILES.fix-paths= src/*.c
6978 SUBST_FILES.fix-paths+= scripts/*.sh
6979 SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g'
6980 SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g'
6983 SUBST_CLASSES is a list of identifiers that are used to identify the different
6984 SUBST blocks that are defined. The SUBST framework is heavily used by pkgsrc,
6985 so it is important to always use the += operator with this variable. Otherwise
6986 some substitutions may be skipped.
6988 The remaining variables of each SUBST block are parameterized with the
6989 identifier from the first line (fix-paths in this case.) They can be seen as
6990 parameters to a function call.
6992 SUBST_STAGE.* specifies the stage at which the replacement will take place. All
6993 combinations of pre-, do- and post- together with a phase name are possible,
6994 though only few are actually used. Most commonly used are post-patch and
6995 pre-configure. Of these two, pre-configure should be preferred because then it
6996 is possible to run bmake patch and have the state after applying the patches
6997 but before making any other changes. This is especially useful when you are
6998 debugging a package in order to create new patches for it. Similarly,
6999 post-build is preferred over pre-install, because the install phase should
7000 generally be kept as simple as possible. When you use post-build, you have the
7001 same files in the working directory that will be installed later, so you can
7002 check if the substitution has succeeded.
7004 SUBST_MESSAGE.* is an optional text that is printed just before the
7005 substitution is done.
7007 SUBST_FILES.* is the list of shell globbing patterns that specifies the files
7008 in which the substitution will take place. The patterns are interpreted
7009 relatively to the WRKSRC directory.
7011 SUBST_SED.* is a list of arguments to sed(1) that specify the actual
7012 substitution. Every sed command should be prefixed with -e, so that all SUBST
7013 blocks look uniform.
7015 There are some more variables, but they are so seldomly used that they are only
7016 documented in the mk/subst.mk file.
7018 19.2. Fixing problems in the fetch phase
7020 19.2.1. Packages whose distfiles aren't available for plain downloading
7022 If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
7023 a make fetch will call files/getsite.sh with the name of each file to download
7024 as an argument, expecting it to output the URL of the directory from which to
7025 download it. graphics/ns-cult3d is an example of this usage.
7027 If the download can't be automated, because the user must submit personal
7028 information to apply for a password, or must pay for the source, or whatever,
7029 you can set FETCH_MESSAGE to a list of lines that are displayed to the user
7030 before aborting the build. Example:
7032 FETCH_MESSAGE= "Please download the files"
7033 FETCH_MESSAGE+= " "${DISTFILES:Q}
7034 FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
7037 19.2.2. How to handle modified distfiles with the 'old' name
7039 Sometimes authors of a software package make some modifications after the
7040 software was released, and they put up a new distfile without changing the
7041 package's version number. If a package is already in pkgsrc at that time, the
7042 checksum will no longer match. The contents of the new distfile should be
7043 compared against the old one before changing anything, to make sure the
7044 distfile was really updated on purpose, and that no trojan horse or so crept
7045 in. Please mention that the distfiles were compared and what was found in your
7046 commit message. Then, the correct way to work around this is to set DIST_SUBDIR
7047 to a unique directory name, usually based on PKGNAME_NOREV. All DISTFILES and
7048 PATCHFILES for this package will be put in that subdirectory of the local
7049 distfiles directory. (See Section 19.1.11, "How to handle incrementing versions
7050 when fixing an existing package" for more details.) In case this happens more
7051 often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can
7052 be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget regenerating the
7053 distinfo file after that, since it contains the DIST_SUBDIR path in the
7054 filenames. Also increase the PKGREVISION if the installed package is different.
7055 Furthermore, a mail to the package's authors seems appropriate telling them
7056 that changing distfiles after releases without changing the file names is not
7059 19.3. Fixing problems in the configure phase
7061 19.3.1. Shared libraries - libtool
7063 pkgsrc supports many different machines, with different object formats like
7064 a.out and ELF, and varying abilities to do shared library and dynamic loading
7065 at all. To accompany this, varying commands and options have to be passed to
7066 the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
7067 especially if you don't have all the machines at your hand to test things. The
7068 devel/libtool pkg can help here, as it just "knows" how to build both static
7069 and dynamic libraries from a set of source files, thus being
7070 platform-independent.
7072 Here's how to use libtool in a package in seven simple steps:
7074 1. Add USE_LIBTOOL=yes to the package Makefile.
7076 2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
7077 {CC}". You could even add it to the definition of CC, if only libraries are
7078 being built in a given Makefile. This one command will build both PIC and
7079 non-PIC library objects, so you need not have separate shared and
7080 non-shared library rules.
7082 3. For the linking of the library, remove any "ar", "ranlib", and "ld
7083 -Bshareable" commands, and instead use:
7085 ${LIBTOOL} --mode=link \
7086 ${CC} -o ${.TARGET:.a=.la} \
7088 -rpath ${PREFIX}/lib \
7089 -version-info major:minor
7092 Note that the library is changed to have a .la extension, and the objects
7093 are changed to have a .lo extension. Change OBJS as necessary. This
7094 automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
7095 necessary) in the build directory. Be sure to include "-version-info",
7096 especially when major and minor are zero, as libtool will otherwise strip
7097 off the shared library version.
7099 From the libtool manual:
7101 So, libtool library versions are described by three integers:
7104 The most recent interface number that this library implements.
7107 The implementation number of the CURRENT interface.
7110 The difference between the newest and oldest interfaces that
7111 this library implements. In other words, the library implements
7112 all the interface numbers in the range from number `CURRENT -
7115 If two libraries have identical CURRENT and AGE numbers, then the
7116 dynamic linker chooses the library with the greater REVISION number.
7119 The "-release" option will produce different results for a.out and ELF
7120 (excluding symlinks) in only one case. An ELF library of the form
7121 "libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
7122 platform. This is handled automatically.
7124 The "-rpath argument" is the install directory of the library being built.
7126 In the PLIST, include only the .la file, the other files will be added
7129 4. When linking shared object (.so) files, i.e. files that are loaded via
7130 dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
7131 them getting version tacked on.
7133 The PLIST file gets the foo.so entry.
7135 5. When linking programs that depend on these libraries before they are
7136 installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
7137 and it will find the correct libraries (static or shared), but please be
7138 aware that libtool will not allow you to specify a relative path in -L
7139 (such as "-L../somelib"), because it expects you to change that argument to
7140 be the .la file. e.g.
7142 ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
7145 should be changed to:
7147 ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
7150 and it will do the right thing with the libraries.
7152 6. When installing libraries, preface the install(1) or cp(1) command with "$
7153 {LIBTOOL} --mode=install", and change the library name to .la. e.g.
7155 ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
7158 This will install the static .a, shared library, any needed symlinks, and
7161 7. In your PLIST, include only the .la file (this is a change from previous
7164 19.3.2. Using libtool on GNU packages that already support libtool
7166 Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
7167 own libtool in most cases. For older libtool using packages, libtool is made by
7168 ltconfig script during the do-configure step; you can check the libtool script
7169 location by doing make configure; find work*/ -name libtool.
7171 LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
7172 override. By default, it is set to "libtool */libtool */*/libtool". If this
7173 does not match the location of the package's libtool script(s), set it as
7176 If you do not need *.a static libraries built and installed, then use
7177 SHLIBTOOL_OVERRIDE instead.
7179 If your package makes use of the platform-independent library for loading
7180 dynamic shared objects, that comes with libtool (libltdl), you should include
7181 devel/libltdl/buildlink3.mk.
7183 Some packages use libtool incorrectly so that the package may not work or build
7184 in some circumstances. Some of the more common errors are:
7186 * The inclusion of a shared object (-module) as a dependent library in an
7187 executable or library. This in itself isn't a problem if one of two things
7190 1. The shared object is named correctly, i.e. libfoo.la, not foo.la
7192 2. The -dlopen option is used when linking an executable.
7194 * The use of libltdl without the correct calls to initialisation routines.
7195 The function lt_dlinit() should be called and the macro
7196 LTDL_SET_PRELOADED_SYMBOLS included in executables.
7198 19.3.3. GNU Autoconf/Automake
7200 If a package needs GNU autoconf or automake to be executed to regenerate the
7201 configure script and Makefile.in makefile templates, then they should be
7202 executed in a pre-configure target.
7204 For packages that need only autoconf:
7206 AUTOCONF_REQD= 2.50 # if default version is not good enough
7207 USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13
7211 cd ${WRKSRC} && autoconf
7216 and for packages that need automake and autoconf:
7218 AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
7219 USE_TOOLS+= automake # use "automake14" for automake-1.4
7223 set -e; cd ${WRKSRC}; \
7224 aclocal; autoheader; automake -a --foreign -i; autoconf
7229 Packages which use GNU Automake will almost certainly require GNU Make.
7231 There are times when the configure process makes additional changes to the
7232 generated files, which then causes the build process to try to re-execute the
7233 automake sequence. This is prevented by touching various files in the configure
7234 stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
7235 NO in the package Makefile.
7237 19.4. Programming languages
7239 19.4.1. C, C++, and Fortran
7241 Compilers for the C, C++, and Fortran languages comes with the NetBSD base
7242 system. By default, pkgsrc assumes that a package is written in C and will hide
7243 all other compilers (via the wrapper framework, see Chapter 14, Buildlink
7246 To declare which language's compiler a package needs, set the USE_LANGUAGES
7247 variable. Allowed values currently are "c", "c++", and "fortran" (and any
7248 combination). The default is "c". Packages using GNU configure scripts, even if
7249 written in C++, usually need a C compiler for the configure phase.
7253 If a program is written in Java, use the Java framework in pkgsrc. The package
7254 must include ../../mk/java-vm.mk. This Makefile fragment provides the following
7257 * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is
7258 set to "run", then there is only a runtime dependency on the JDK. The
7259 default is "yes", which also adds a build dependency on the JDK.
7261 * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The
7262 supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2
7263 implementation, "1.4" insists on versions 1.4 or above, and "1.5" only
7264 accepts versions 1.5 or above. This variable is not set by default.
7266 19.4.3. Packages containing perl scripts
7268 If your package contains interpreted perl scripts, add "perl" to the USE_TOOLS
7269 variable and set REPLACE_PERL to ensure that the proper interpreter path is
7270 set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that
7271 you want adjusted. Every occurrence of */bin/perl will be replaced with the
7272 full path to the perl executable.
7274 If a particular version of perl is needed, set the PERL5_REQD variable to the
7275 version number. The default is "5.0".
7277 See Section 19.6.6, "Packages installing perl modules" for information about
7278 handling perl modules.
7280 19.4.4. Other programming languages
7282 Currently, there is no special handling for other languages in pkgsrc. If a
7283 compiler package provides a buildlink3.mk file, include that, otherwise just
7284 add a (build) dependency on the appropriate compiler package.
7286 19.5. Fixing problems in the build phase
7288 The most common failures when building a package are that some platforms do not
7289 provide certain header files, functions or libraries, or they provide the
7290 functions in a library that the original package author didn't know. To work
7291 around this, you can rewrite the source code in most cases so that it does not
7292 use the missing functions or provides a replacement function.
7294 19.5.1. Compiling C and C++ code conditionally
7296 If a package already comes with a GNU configure script, the preferred way to
7297 fix the build failure is to change the configure script, not the code. In the
7298 other cases, you can utilize the C preprocessor, which defines certain macros
7299 depending on the operating system and hardware architecture it compiles for.
7300 These macros can be queried using for example #if defined(__i386). Almost every
7301 operating system, hardware architecture and compiler has its own macro. For
7302 example, if the macros __GNUC__, __i386__ and __NetBSD__ are all defined, you
7303 know that you are using NetBSD on an i386 compatible CPU, and your compiler is
7306 The list of the following macros for hardware and operating system depends on
7307 the compiler that is used. For example, if you want to conditionally compile
7308 code on Solaris, don't use __sun__, as the SunPro compiler does not define it.
7311 19.5.1.1. C preprocessor macros to identify the operating system
7313 To distinguish between 4.4 BSD-derived systems and the rest of the world, you
7314 should use the following code.
7316 #include <sys/param.h>
7317 #if (defined(BSD) && BSD >= 199306)
7318 /* BSD-specific code goes here */
7320 /* non-BSD-specific code goes here */
7323 If this distinction is not fine enough, you can also test for the following
7327 DragonFly __DragonFly__
7329 IRIX __sgi (TODO: get a definite source for this)
7330 Linux linux, __linux, __linux__
7335 19.5.1.2. C preprocessor macros to identify the hardware architecture
7337 i386 i386, __i386, __i386__
7339 SPARC sparc, __sparc
7341 19.5.1.3. C preprocessor macros to identify the compiler
7343 GCC __GNUC__ (major version), __GNUC_MINOR__
7344 MIPSpro _COMPILER_VERSION (0x741 for MIPSpro 7.41)
7345 SunPro __SUNPRO_C (0x570 for Sun C 5.7)
7346 SunPro C++ __SUNPRO_CC (0x580 for Sun C++ 5.8)
7348 19.5.2. How to handle compiler bugs
7350 Some source files trigger bugs in the compiler, based on combinations of
7351 compiler version and architecture and almost always relation to optimisation
7352 being enabled. Common symptoms are gcc internal errors or never finishing
7355 Typically, a workaround involves testing the MACHINE_ARCH and compiler version,
7356 disabling optimisation for that combination of file, MACHINE_ARCH and compiler,
7357 and documenting it in pkgsrc/doc/HACKS. See that file for a number of examples.
7359 19.5.3. Undefined reference to "..."
7361 This error message often means that a package did not link to a shared library
7362 it needs. The following functions are known to cause this error message over
7365 +-----------------------------------------------------+
7366 | Function |Library |Affected platforms|
7367 |-------------------------+--------+------------------|
7368 |accept, bind, connect |-lsocket|Solaris |
7369 |-------------------------+--------+------------------|
7370 |crypt |-lcrypt |DragonFly, NetBSD |
7371 |-------------------------+--------+------------------|
7372 |dlopen, dlsym |-ldl |Linux |
7373 |-------------------------+--------+------------------|
7374 |gethost* |-lnsl |Solaris |
7375 |-------------------------+--------+------------------|
7376 |inet_aton |-lresolv|Solaris |
7377 |-------------------------+--------+------------------|
7378 |nanosleep, sem_*, timer_*|-lrt |Solaris |
7379 |-------------------------+--------+------------------|
7380 |openpty |-lutil |Linux |
7381 +-----------------------------------------------------+
7383 To fix these linker errors, it is often sufficient to say LIBS.OperatingSystem+
7384 = -lfoo to the package Makefile and then say bmake clean; bmake.
7386 19.5.3.1. Special issue: The SunPro compiler
7388 When you are using the SunPro compiler, there is another possibility. That
7389 compiler cannot handle the following code:
7391 extern int extern_func(int);
7396 return extern_func(x);
7404 It generates the code for inline_func even if that function is never used. This
7405 code then refers to extern_func, which can usually not be resolved. To solve
7406 this problem you can try to tell the package to disable inlining of functions.
7408 19.5.4. Running out of memory
7410 Sometimes packages fail to build because the compiler runs into an operating
7411 system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be
7412 told to unlimit the resources. Currently, the allowed values are "datasize" and
7413 "stacksize" (or both). Setting this variable is similar to running the shell
7414 builtin ulimit command to raise the maximum data segment size or maximum stack
7415 size of a process, respectively, to their hard limits.
7417 19.6. Fixing problems in the install phase
7419 19.6.1. Creating needed directories
7421 The BSD-compatible install supplied with some operating systems cannot create
7422 more than one directory at a time. As such, you should call ${INSTALL_*_DIR}
7425 ${INSTALL_DATA_DIR} ${PREFIX}/dir1
7426 ${INSTALL_DATA_DIR} ${PREFIX}/dir2
7429 You can also just append "dir1 dir2" to the INSTALLATION_DIRS variable, which
7430 will automatically do the right thing.
7432 19.6.2. Where to install documentation
7434 In general, documentation should be installed into ${PREFIX}/share/doc/$
7435 {PKGBASE} or ${PREFIX}/share/doc/${PKGNAME} (the latter includes the version
7436 number of the package).
7438 Many modern packages using GNU autoconf allow to set the directory where HTML
7439 documentation is installed with the "--with-html-dir" option. Sometimes using
7440 this flag is needed because otherwise the documentation ends up in ${PREFIX}/
7441 share/doc/html or other places.
7443 An exception to the above is that library API documentation generated with the
7444 textproc/gtk-doc tools, for use by special browsers (devhelp) should be left at
7445 their default location, which is ${PREFIX}/share/gtk-doc. Such documentation
7446 can be recognized from files ending in .devhelp or .devhelp2. (It is also
7447 acceptable to install such files in ${PREFIX}/share/doc/${PKGBASE} or ${PREFIX}
7448 /share/doc/${PKGNAME}; the .devhelp* file must be directly in that directory
7449 then, no additional subdirectory level is allowed in this case. This is usually
7450 achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/
7451 gtk-doc is preferred though.)
7453 19.6.3. Installing highscore files
7455 Certain packages, most of them in the games category, install a score file that
7456 allows all users on the system to record their highscores. In order for this to
7457 work, the binaries need to be installed setgid and the score files owned by the
7458 appropriate group and/or owner (traditionally the "games" user/group). The
7459 following variables, documented in more detail in mk/defaults/mk.conf, control
7460 this behaviour: SETGIDGAME, GAMEDATAMODE, GAMEGRP, GAMEMODE, GAMEOWN.
7462 Note that per default, setgid installation of games is disabled; setting
7463 SETGIDGAME=YES will set all the other variables accordingly.
7465 A package should therefore never hard code file ownership or access permissions
7466 but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly.
7468 19.6.4. Adding DESTDIR support to packages
7470 DESTDIR support means that a package installs into a staging directory, not the
7471 final location of the files. Then a binary package is created which can be used
7472 for installation as usual. There are two ways: Either the package must install
7473 as root ("destdir") or the package can install as non-root user
7476 * PKG_DESTDIR_SUPPORT has to be set to "destdir" or "user-destdir". If
7477 bsd.prefs.mk is included in the Makefile, PKG_DESTDIR_SUPPORT needs to be
7478 set before the inclusion.
7480 * All installation operations have to be prefixed with ${DESTDIR}.
7482 * automake gets this DESTDIR mostly right automatically. Many manual rules
7483 and pre/post-install often are incorrect; fix them.
7485 * If files are installed with special owner/group use SPECIAL_PERMS.
7487 * In general, packages should support UNPRIVILEGED to be able to use DESTDIR.
7489 19.6.5. Packages with hardcoded paths to other interpreters
7491 Your package may also contain scripts with hardcoded paths to other
7492 interpreters besides (or as well as) perl. To correct the full pathname to the
7493 script interpreter, you need to set the following definitions in your Makefile
7494 (we shall use tclsh in this example):
7496 REPLACE_INTERPRETER+= tcl
7497 REPLACE.tcl.old= .*/bin/tclsh
7498 REPLACE.tcl.new= ${PREFIX}/bin/tclsh
7499 REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed,
7500 # relative to ${WRKSRC}, just as in REPLACE_PERL
7505 Before March 2006, these variables were called _REPLACE.* and _REPLACE_FILES.*.
7507 19.6.6. Packages installing perl modules
7509 Makefiles of packages providing perl5 modules should include the Makefile
7510 fragment ../../lang/perl5/module.mk. It provides a do-configure target for the
7511 standard perl configuration for such modules as well as various hooks to tune
7512 this configuration. See comments in this file for details.
7514 Perl5 modules will install into different places depending on the version of
7515 perl used during the build process. To address this, pkgsrc will append lines
7516 to the PLIST corresponding to the files listed in the installed .packlist file
7517 generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to
7518 a space-separated list of paths to packlist files, e.g.:
7520 PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
7523 The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent the
7524 three locations in which perl5 modules may be installed, and may be used by
7525 perl5 packages that don't have a packlist. These three variables are also
7526 substituted for in the PLIST.
7528 19.6.7. Packages installing info files
7530 Some packages install info files or use the "makeinfo" or "install-info"
7531 commands. INFO_FILES should be defined in the package Makefile so that INSTALL
7532 and DEINSTALL scripts will be generated to handle registration of the info
7533 files in the Info directory file. The "install-info" command used for the info
7534 files registration is either provided by the system, or by a special purpose
7535 package automatically added as dependency if needed.
7537 PKGINFODIR is the directory under ${PREFIX} where info files are primarily
7538 located. PKGINFODIR defaults to "info" and can be overridden by the user.
7540 The info files for the package should be listed in the package PLIST; however
7541 any split info files need not be listed.
7543 A package which needs the "makeinfo" command at build time must add "makeinfo"
7544 to USE_TOOLS in its Makefile. If a minimum version of the "makeinfo" command is
7545 needed it should be noted with the TEXINFO_REQD variable in the package
7546 Makefile. By default, a minimum version of 3.12 is required. If the system does
7547 not provide a makeinfo command or if it does not match the required minimum, a
7548 build dependency on the devel/gtexinfo package will be added automatically.
7550 The build and installation process of the software provided by the package
7551 should not use the install-info command as the registration of info files is
7552 the task of the package INSTALL script, and it must use the appropriate
7555 To achieve this goal, the pkgsrc infrastructure creates overriding scripts for
7556 the install-info and makeinfo commands in a directory listed early in PATH.
7558 The script overriding install-info has no effect except the logging of a
7559 message. The script overriding makeinfo logs a message and according to the
7560 value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on
7563 19.6.8. Packages installing man pages
7565 All packages that install manual pages should install them into the same
7566 directory, so that there is one common place to look for them. In pkgsrc, this
7567 place is ${PREFIX}/${PKGMANDIR}, and this expression should be used in
7568 packages. The default for PKGMANDIR is "man". Another often-used value is
7573 The support for a custom PKGMANDIR is far from complete.
7575 The PLIST files can just use man/ as the top level directory for the man page
7576 file entries, and the pkgsrc framework will convert as needed. In all other
7577 places, the correct PKGMANDIR must be used.
7579 Packages that are configured with GNU_CONFIGURE set as "yes", by default will
7580 use the ./configure --mandir switch to set where the man pages should be
7581 installed. The path is GNU_CONFIGURE_MANDIR which defaults to ${PREFIX}/$
7584 Packages that use GNU_CONFIGURE but do not use --mandir, can set
7585 CONFIGURE_HAS_MANDIR to "no". Or if the ./configure script uses a non-standard
7586 use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed.
7588 See Section 13.5, "Man page compression" for information on installation of
7589 compressed manual pages.
7591 19.6.9. Packages installing GConf data files
7593 If a package installs .schemas or .entries files, used by GConf, you need to
7594 take some extra steps to make sure they get registered in the database:
7596 1. Include ../../devel/GConf/schemas.mk instead of its buildlink3.mk file.
7597 This takes care of rebuilding the GConf database at installation and
7598 deinstallation time, and tells the package where to install GConf data
7599 files using some standard configure arguments. It also disallows any access
7600 to the database directly from the package.
7602 2. Ensure that the package installs its .schemas files under ${PREFIX}/share/
7603 gconf/schemas. If they get installed under ${PREFIX}/etc, you will need to
7604 manually patch the package.
7606 3. Check the PLIST and remove any entries under the etc/gconf directory, as
7607 they will be handled automatically. See Section 9.13, "How do I change the
7608 location of configuration files?" for more information.
7610 4. Define the GCONF_SCHEMAS variable in your Makefile with a list of all
7611 .schemas files installed by the package, if any. Names must not contain any
7612 directories in them.
7614 5. Define the GCONF_ENTRIES variable in your Makefile with a list of all
7615 .entries files installed by the package, if any. Names must not contain any
7616 directories in them.
7618 19.6.10. Packages installing scrollkeeper/rarian data files
7620 If a package installs .omf files, used by scrollkeeper/rarian, you need to take
7621 some extra steps to make sure they get registered in the database:
7623 1. Include ../../mk/omf-scrollkeeper.mk instead of rarian's buildlink3.mk
7624 file. This takes care of rebuilding the scrollkeeper database at
7625 installation and deinstallation time, and disallows any access to it
7626 directly from the package.
7628 2. Check the PLIST and remove any entries under the libdata/scrollkeeper
7629 directory, as they will be handled automatically.
7631 3. Remove the share/omf directory from the PLIST. It will be handled by
7632 rarian. (make print-PLIST does this automatically.)
7634 19.6.11. Packages installing X11 fonts
7636 If a package installs font files, you will need to rebuild the fonts database
7637 in the directory where they get installed at installation and deinstallation
7638 time. This can be automatically done by using the pkginstall framework.
7640 You can list the directories where fonts are installed in the FONTS_DIRS.type
7641 variables, where type can be one of "ttf", "type1" or "x11". Also make sure
7642 that the database file fonts.dir is not listed in the PLIST.
7644 Note that you should not create new directories for fonts; instead use the
7645 standard ones to avoid that the user needs to manually configure his X server
7648 19.6.12. Packages installing GTK2 modules
7650 If a package installs GTK2 immodules or loaders, you need to take some extra
7651 steps to get them registered in the GTK2 database properly:
7653 1. Include ../../x11/gtk2/modules.mk instead of its buildlink3.mk file. This
7654 takes care of rebuilding the database at installation and deinstallation
7657 2. Set GTK2_IMMODULES=YES if your package installs GTK2 immodules.
7659 3. Set GTK2_LOADERS=YES if your package installs GTK2 loaders.
7661 4. Patch the package to not touch any of the GTK2 databases directly. These
7664 * libdata/gtk-2.0/gdk-pixbuf.loaders
7666 * libdata/gtk-2.0/gtk.immodules
7668 5. Check the PLIST and remove any entries under the libdata/gtk-2.0 directory,
7669 as they will be handled automatically.
7671 19.6.13. Packages installing SGML or XML data
7673 If a package installs SGML or XML data files that need to be registered in
7674 system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
7677 1. Include ../../textproc/xmlcatmgr/catalogs.mk in your Makefile, which takes
7678 care of registering those files in system-wide catalogs at installation and
7679 deinstallation time.
7681 2. Set SGML_CATALOGS to the full path of any SGML catalogs installed by the
7684 3. Set XML_CATALOGS to the full path of any XML catalogs installed by the
7687 4. Set SGML_ENTRIES to individual entries to be added to the SGML catalog.
7688 These come in groups of three strings; see xmlcatmgr(1) for more
7689 information (specifically, arguments recognized by the 'add' action). Note
7690 that you will normally not use this variable.
7692 5. Set XML_ENTRIES to individual entries to be added to the XML catalog. These
7693 come in groups of three strings; see xmlcatmgr(1) for more information
7694 (specifically, arguments recognized by the 'add' action). Note that you
7695 will normally not use this variable.
7697 19.6.14. Packages installing extensions to the MIME database
7699 If a package provides extensions to the MIME database by installing .xml files
7700 inside ${PREFIX}/share/mime/packages, you need to take some extra steps to
7701 ensure that the database is kept consistent with respect to these new files:
7703 1. Include ../../databases/shared-mime-info/mimedb.mk (avoid using the
7704 buildlink3.mk file from this same directory, which is reserved for
7705 inclusion from other buildlink3.mk files). It takes care of rebuilding the
7706 MIME database at installation and deinstallation time, and disallows any
7707 access to it directly from the package.
7709 2. Check the PLIST and remove any entries under the share/mime directory,
7710 except for files saved under share/mime/packages. The former are handled
7711 automatically by the update-mime-database program, but the latter are
7712 package-dependent and must be removed by the package that installed them in
7715 3. Remove any share/mime/* directories from the PLIST. They will be handled by
7716 the shared-mime-info package.
7718 19.6.15. Packages using intltool
7720 If a package uses intltool during its build, add intltool to the USE_TOOLS,
7721 which forces it to use the intltool package provided by pkgsrc, instead of the
7722 one bundled with the distribution file.
7724 This tracks intltool's build-time dependencies and uses the latest available
7725 version; this way, the package benefits of any bug fixes that may have appeared
7726 since it was released.
7728 19.6.16. Packages installing startup scripts
7730 If a package contains a rc.d script, it won't be copied into the startup
7731 directory by default, but you can enable it, by adding the option
7732 PKG_RCD_SCRIPTS=YES in mk.conf. This option will copy the scripts into /etc/
7733 rc.d when a package is installed, and it will automatically remove the scripts
7734 when the package is deinstalled.
7736 19.6.17. Packages installing TeX modules
7738 If a package installs TeX packages into the texmf tree, the ls-R database of
7739 the tree needs to be updated.
7743 Except the main TeX packages such as kpathsea, packages should install files
7744 into ${PREFIX}/share/texmf-dist, not ${PREFIX}/share/texmf.
7746 1. Include ../../print/kpathsea/texmf.mk. This takes care of rebuilding the
7747 ls-R database at installation and deinstallation time.
7749 2. If your package installs files into a texmf tree other than the one at $
7750 {PREFIX}/share/texmf-dist, set TEX_TEXMF_DIRS to the list of all texmf
7751 trees that need database update.
7753 If your package also installs font map files that need to be registered
7754 using updmap, include ../../print/texlive-tetex/map.mk and set
7755 TEX_MAP_FILES and/or TEX_MIXEDMAP_FILES to the list of all such font map
7756 files. Then updmap will be run automatically at installation/deinstallation
7757 to enable/disable font map files for TeX output drivers.
7759 3. Make sure that none of ls-R databases are included in PLIST, as they will
7760 be removed only by the teTeX-bin package.
7762 19.6.18. Packages supporting running binaries in emulation
7764 There are some packages that provide libraries and executables for running
7765 binaries from a one operating system on a different one (if the latter supports
7766 it). One example is running Linux binaries on NetBSD.
7768 The pkgtools/rpm2pkg helps in extracting and packaging Linux rpm packages.
7770 The CHECK_SHLIBS can be set to no to avoid the check-shlibs target, which tests
7771 if all libraries for each installed executable can be found by the dynamic
7772 linker. Since the standard dynamic linker is run, this fails for emulation
7773 packages, because the libraries used by the emulation are not in the standard
7776 19.6.19. Packages installing hicolor theme icons
7778 If a package installs images under the share/icons/hicolor and/or updates the
7779 share/icons/hicolor/icon-theme.cache database, you need to take some extra
7780 steps to make sure that the shared theme directory is handled appropriately and
7781 that the cache database is rebuilt:
7783 1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk.
7785 2. Check the PLIST and remove the entry that refers to the theme cache.
7787 3. Ensure that the PLIST does not remove the shared icon directories from the
7788 share/icons/hicolor hierarchy because they will be handled automatically.
7790 The best way to verify that the PLIST is correct with respect to the last two
7791 points is to regenerate it using make print-PLIST.
7793 19.6.20. Packages installing desktop files
7795 If a package installs .desktop files under share/applications and these include
7796 MIME information, you need to take extra steps to ensure that they are
7797 registered into the MIME database:
7799 1. Include ../../sysutils/desktop-file-utils/desktopdb.mk.
7801 2. Check the PLIST and remove the entry that refers to the share/applications/
7802 mimeinfo.cache file. It will be handled automatically.
7804 The best way to verify that the PLIST is correct with respect to the last point
7805 is to regenerate it using make print-PLIST.
7807 19.7. Marking packages as having problems
7809 In some cases one does not have the time to solve a problem immediately. In
7810 this case, one can plainly mark a package as broken. For this, one just sets
7811 the variable BROKEN to the reason why the package is broken (similar to the
7812 RESTRICTED variable). A user trying to build the package will immediately be
7813 shown this message, and the build will not be even tried.
7815 BROKEN packages are removed from pkgsrc in irregular intervals.
7817 Chapter 20. Debugging
7819 To check out all the gotchas when building a package, here are the steps that I
7820 do in order to get a package working. Please note this is basically the same as
7821 what was explained in the previous sections, only with some debugging aids.
7823 * Be sure to set PKG_DEVELOPER=yes in mk.conf.
7825 * Install pkgtools/url2pkg, create a directory for a new package, change into
7826 it, then run url2pkg:
7828 % mkdir /usr/pkgsrc/category/examplepkg
7829 % cd /usr/pkgsrc/category/examplepkg
7830 % url2pkg http://www.example.com/path/to/distfile.tar.gz
7832 * Edit the Makefile as requested.
7834 * Fill in the DESCR file
7836 * Run make configure
7838 * Add any dependencies glimpsed from documentation and the configure step to
7839 the package's Makefile.
7841 * Make the package compile, doing multiple rounds of
7844 % pkgvi ${WRKSRC}/some/file/that/does/not/compile
7847 % mv ${WRKDIR}/.newpatches/* patches
7851 Doing this step as non-root user will ensure that no files are modified
7852 that shouldn't be, especially during the build phase. mkpatches, patchdiff
7853 and pkgvi are from the pkgtools/pkgdiff package.
7855 * Look at the Makefile, fix if necessary; see Section 11.1, "Makefile".
7860 # make print-PLIST >PLIST
7865 You usually need to be root to do this. Look if there are any files left:
7869 If this reveals any files that are missing in PLIST, add them.
7871 * Now that the PLIST is OK, install the package again and make a binary
7877 * Delete the installed package:
7879 # pkg_delete examplepkg
7881 * Repeat the above make print-PLIST command, which shouldn't find anything
7886 * Reinstall the binary package:
7888 # pkg_add .../examplepkg.tgz
7890 * Play with it. Make sure everything works.
7892 * Run pkglint from pkgtools/pkglint, and fix the problems it reports:
7896 * Submit (or commit, if you have cvs access); see Chapter 21, Submitting and
7899 Chapter 21. Submitting and Committing
7903 21.1. Submitting binary packages
7904 21.2. Submitting source packages (for non-NetBSD-developers)
7905 21.3. General notes when adding, updating, or removing packages
7906 21.4. Committing: Importing a package into CVS
7907 21.5. Updating a package to a newer version
7908 21.6. Renaming a package in pkgsrc
7909 21.7. Moving a package in pkgsrc
7911 21.1. Submitting binary packages
7913 Our policy is that we accept binaries only from pkgsrc developers to guarantee
7914 that the packages don't contain any trojan horses etc. This is not to annoy
7915 anyone but rather to protect our users! You're still free to put up your
7916 home-made binary packages and tell the world where to get them. NetBSD
7917 developers doing bulk builds and wanting to upload them please see
7918 Section 7.3.8, "Uploading results of a bulk build".
7920 21.2. Submitting source packages (for non-NetBSD-developers)
7922 First, check that your package is complete, compiles and runs well; see
7923 Chapter 20, Debugging and the rest of this document. Next, generate an
7924 uuencoded gzipped tar(1) archive that contains all files that make up the
7925 package. Finally, send this package to the pkgsrc bug tracking system, either
7926 with the send-pr(1) command, or if you don't have that, go to the web page
7927 http://www.NetBSD.org/support/send-pr.html, which contains some instructions
7928 and a link to a form where you can submit packages. The sysutils/gtk-send-pr
7929 package is also available as a substitute for either of the above two tools.
7931 In the form of the problem report, the category should be "pkg", the synopsis
7932 should include the package name and version number, and the description field
7933 should contain a short description of your package (contents of the COMMENT
7934 variable or DESCR file are OK). The uuencoded package data should go into the
7937 If you want to submit several packages, please send a separate PR for each one,
7938 it's easier for us to track things that way.
7940 Alternatively, you can also import new packages into pkgsrc-wip ("pkgsrc
7941 work-in-progress"); see the homepage at http://pkgsrc-wip.sourceforge.net/ for
7944 21.3. General notes when adding, updating, or removing packages
7946 Please note all package additions, updates, moves, and removals in pkgsrc/doc/
7947 CHANGES-YYYY. It's very important to keep this file up to date and conforming
7948 to the existing format, because it will be used by scripts to automatically
7949 update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/
7950 doc/TODO file and remove the entry for the package you updated or removed, in
7951 case it was mentioned there.
7953 When the PKGREVISION of a package is bumped, the change should appear in pkgsrc
7954 /doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps
7955 that result from a dependency being updated should not be mentioned. In all
7956 other cases it's the developer's decision.
7958 There is a make target that helps in creating proper CHANGES-YYYY entries: make
7959 changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The
7960 general usage is to first make sure that your CHANGES-YYYY file is up-to-date
7961 (to avoid having to resolve conflicts later-on) and then to cd to the package
7962 directory. For package updates, make changes-entry is enough. For new packages,
7963 or package moves or removals, set the CTYPE variable on the command line to
7964 "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if
7965 your local login name is not the same as your NetBSD login name. The target
7966 also automatically removes possibly existing entries for the package in the
7967 TODO file. Don't forget to commit the changes, e.g. by using make
7968 changes-entry-commit! If you are not using a checkout directly from
7969 cvs.netbsd.org, but e.g. a local copy of the repository, you can set
7970 USE_NETBSD_REPO=yes. This makes the cvs commands use the main repository.
7972 21.4. Committing: Importing a package into CVS
7974 This section is only of interest for pkgsrc developers with write access to the
7975 pkgsrc repository. Please remember that cvs imports files relative to the
7976 current working directory, and that the pathname that you give the cvs import
7977 command is so that it knows where to place the files in the repository. Newly
7978 created packages should be imported with a vendor tag of "TNF" and a release
7979 tag of "pkgsrc-base", e.g:
7981 $ cd .../pkgsrc/category/pkgname
7982 $ cvs import pkgsrc/category/pkgname TNF pkgsrc-base
7984 Remember to move the directory from which you imported out of the way, or cvs
7985 will complain the next time you "cvs update" your source tree. Also don't
7986 forget to add the new package to the category's Makefile.
7988 The commit message of the initial import should include part of the DESCR file,
7989 so people reading the mailing lists know what the package is/does.
7991 For new packages, "cvs import" is preferred to "cvs add" because the former
7992 gets everything with a single command, and provides a consistent tag.
7994 21.5. Updating a package to a newer version
7996 Please always put a concise, appropriate and relevant summary of the changes
7997 between old and new versions into the commit log when updating a package. There
7998 are various reasons for this:
8000 * A URL is volatile, and can change over time. It may go away completely or
8001 its information may be overwritten by newer information.
8003 * Having the change information between old and new versions in our CVS
8004 repository is very useful for people who use either cvs or anoncvs.
8006 * Having the change information between old and new versions in our CVS
8007 repository is very useful for people who read the pkgsrc-changes mailing
8008 list, so that they can make tactical decisions about when to upgrade the
8011 Please also recognize that, just because a new version of a package has been
8012 released, it should not automatically be upgraded in the CVS repository. We
8013 prefer to be conservative in the packages that are included in pkgsrc -
8014 development or beta packages are not really the best thing for most places in
8015 which pkgsrc is used. Please use your judgement about what should go into
8016 pkgsrc, and bear in mind that stability is to be preferred above new and
8017 possibly untested features.
8019 21.6. Renaming a package in pkgsrc
8021 Renaming packages is not recommended.
8023 When renaming packages, be sure to fix any references to old name in other
8024 Makefiles, options, buildlink files, etc.
8026 Also When renaming a package, please define SUPERSEDES to the package name and
8027 dewey version pattern(s) of the previous package name. This may be repeated for
8028 multiple renames. The new package would be an exact replacement.
8030 Note that "successor" in the CHANGES-YYYY file doesn't necessarily mean that it
8031 supersedes, as that successor may not be an exact replacement but is a
8032 suggestion for the replaced functionality.
8034 21.7. Moving a package in pkgsrc
8036 It is preferred that packages are not renamed or moved, but if needed please
8039 1. Make a copy of the directory somewhere else.
8041 2. Remove all CVS dirs.
8043 Alternatively to the first two steps you can also do:
8045 % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
8047 and use that for further work.
8049 3. Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of
8050 "../../category/package".
8052 4. In the modified package's Makefile, consider setting PREV_PKGPATH to the
8053 previous category/package pathname. The PREV_PKGPATH can be used by tools
8054 for doing an update using pkgsrc building; for example, it can search the
8055 pkg_summary(5) database for PREV_PKGPATH (if no SUPERSEDES) and then use
8056 the corresponding new PKGPATH for that moved package. Note that it may have
8057 multiple matches, so the tool should also check on the PKGBASE too. The
8058 PREV_PKGPATH probably has no value unless SUPERSEDES is not set, i.e.
8059 PKGBASE stays the same.
8061 5. cvs import the modified package in the new place.
8063 6. Check if any package depends on it:
8066 % grep /package */*/Makefile* */*/buildlink*
8068 7. Fix paths in packages from step 5 to point to new location.
8070 8. cvs rm (-f) the package at the old location.
8072 9. Remove from oldcategory/Makefile.
8074 10. Add to newcategory/Makefile.
8076 11. Commit the changed and removed files:
8078 % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
8080 (and any packages from step 5, of course).
8082 Chapter 22. Frequently Asked Questions
8084 This section contains the answers to questions that may arise when you are
8085 writing a package. If you don't find your question answered here, first have a
8086 look in the other chapters, and if you still don't have the answer, ask on the
8087 pkgsrc-users mailing list.
8089 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
8090 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
8091 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
8092 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
8094 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
8095 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
8097 22.7. Which mailing lists are there for package developers?
8098 22.8. Where is the pkgsrc documentation?
8099 22.9. I have a little time to kill. What shall I do?
8101 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
8103 MAKEFLAGS are the flags passed to the pkgsrc-internal invocations of make
8104 (1), while MAKE_FLAGS are the flags that are passed to the MAKE_PROGRAM
8105 when building the package. [FIXME: What is .MAKEFLAGS for?]
8107 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
8109 MAKE is the path to the make(1) program that is used in the pkgsrc
8110 infrastructure. GMAKE is the path to GNU Make, but you need to say
8111 USE_TOOLS+=gmake to use that. MAKE_PROGRAM is the path to the Make
8112 program that is used for building the package.
8114 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
8116 CC is the path to the real C compiler, which can be configured by the
8117 pkgsrc user. PKG_CC is the path to the compiler wrapper. PKGSRC_COMPILER
8118 is not a path to a compiler, but the type of compiler that should be
8119 used. See mk/compiler.mk for more information about the latter variable.
8121 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
8126 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
8128 For optimization reasons, some variables are only available in the
8129 "wrapper" phase and later. To "simulate" the wrapper phase, append
8130 PKG_PHASE=wrapper to the above command.
8132 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
8135 The := is not really an assignment operator, like you might expect at
8136 first sight. Instead, it is a degenerate form of ${LIST:old_string=
8137 new_string}, which is documented in the make(1) man page and which you
8138 may have seen as in ${SRCS:.c=.o}. In the case of MASTER_SITE_*,
8139 old_string is the empty string and new_string is package/. That's where
8140 the : and the = fall together.
8142 22.7. Which mailing lists are there for package developers?
8146 This is a list for technical discussions related to pkgsrc
8147 development, e.g. soliciting feedback for changes to pkgsrc
8148 infrastructure, proposed new features, questions related to porting
8149 pkgsrc to a new platform, advice for maintaining a package, patches
8150 that affect many packages, help requests moved from pkgsrc-users when
8151 an infrastructure bug is found, etc.
8155 All bug reports in category "pkg" sent with send-pr(1) appear here.
8156 Please do not report your bugs here directly; use one of the other
8159 22.8. Where is the pkgsrc documentation?
8161 There are many places where you can find documentation about pkgsrc:
8163 * The pkgsrc guide (this document) is a collection of chapters that
8164 explain large parts of pkgsrc, but some chapters tend to be outdated.
8165 Which ones they are is hard to say.
8167 * On the mailing list archives (see http://mail-index.NetBSD.org/), you
8168 can find discussions about certain features, announcements of new
8169 parts of the pkgsrc infrastructure and sometimes even announcements
8170 that a certain feature has been marked as obsolete. The benefit here
8171 is that each message has a date appended to it.
8173 * Many of the files in the mk/ directory start with a comment that
8174 describes the purpose of the file and how it can be used by the
8175 pkgsrc user and package authors. An easy way to find this
8176 documentation is to run bmake help.
8178 * The CVS log messages are a rich source of information, but they tend
8179 to be highly abbreviated, especially for actions that occur often.
8180 Some contain a detailed description of what has changed, but they are
8181 geared towards the other pkgsrc developers, not towards an average
8182 pkgsrc user. They also only document changes, so if you don't know
8183 what has been before, these messages may not be worth too much to
8186 * Some parts of pkgsrc are only "implicitly documented", that is the
8187 documentation exists only in the mind of the developer who wrote the
8188 code. To get this information, use the cvs annotate command to see
8189 who has written it and ask on the tech-pkg mailing list, so that
8190 others can find your questions later (see above). To be sure that the
8191 developer in charge reads the mail, you may CC him or her.
8193 22.9. I have a little time to kill. What shall I do?
8195 This is not really an FAQ yet, but here's the answer anyway.
8197 * Run pkg_chk -N (from the pkgtools/pkg_chk package). It will tell you
8198 about newer versions of installed packages that are available, but
8199 not yet updated in pkgsrc.
8201 * Browse pkgsrc/doc/TODO ? it contains a list of suggested new packages
8202 and a list of cleanups and enhancements for pkgsrc that would be nice
8205 * Review packages for which review was requested on the pkgsrc-wip
8206 review mailing list.
8208 Chapter 23. GNOME packaging and porting
8213 23.2. Packaging a GNOME application
8214 23.3. Updating GNOME to a newer version
8215 23.4. Patching guidelines
8217 Quoting GNOME's web site:
8219 The GNOME project provides two things: The GNOME desktop environment, an
8220 intuitive and attractive desktop for users, and the GNOME development
8221 platform, an extensive framework for building applications that integrate
8222 into the rest of the desktop.
8224 pkgsrc provides a seamless way to automatically build and install a complete
8225 GNOME environment under many different platforms. We can say with confidence
8226 that pkgsrc is one of the most advanced build and packaging systems for GNOME
8227 due to its included technologies buildlink3, the wrappers and tools framework
8228 and automatic configuration file management. Lots of efforts are put into
8229 achieving a completely clean deinstallation of installed software components.
8231 Given that pkgsrc is NetBSD's official packaging system, the above also means
8232 that great efforts are put into making GNOME work under this operating system.
8233 Recently, DragonFly BSD also adopted pkgsrc as its preferred packaging system,
8234 contributing lots of portability fixes to make GNOME build and install under
8237 This chapter is aimed at pkgsrc developers and other people interested in
8238 helping our GNOME porting and packaging efforts. It provides instructions on
8239 how to manage the existing packages and some important information regarding
8244 Should you have some spare cycles to devote to NetBSD, pkgsrc and GNOME and are
8245 willing to learn new exciting stuff, please jump straight to the pending work
8246 list! There is still a long way to go to get a fully-functional GNOME desktop
8247 under NetBSD and we need your help to achieve it!
8251 pkgsrc includes three GNOME-related meta packages:
8253 * meta-pkgs/gnome-base: Provides the core GNOME desktop environment. It only
8254 includes the necessary bits to get it to boot correctly, although it may
8255 lack important functionality for daily operation. The idea behind this
8256 package is to let end users build their own configurations on top of this
8257 one, first installing this meta package to achieve a functional setup and
8258 then adding individual applications.
8260 * meta-pkgs/gnome: Provides a complete installation of the GNOME platform and
8261 desktop as defined by the GNOME project; this is based on the components
8262 distributed in the platform/x.y/x.y.z/sources and desktop/x.y/x.y.z/sources
8263 directories of the official FTP server. Developer-only tools found in those
8264 directories are not installed unless required by some other component to
8265 work properly. Similarly, packages from the bindings set (bindings/x.y/
8266 x.y.z/sources) are not pulled in unless required as a dependency for an
8267 end-user component. This package "extends" meta-pkgs/gnome-base.
8269 * meta-pkgs/gnome-devel: Installs all the tools required to build a GNOME
8270 component when fetched from the CVS repository. These are required to let
8271 the autogen.sh scripts work appropriately.
8273 In all these packages, the DEPENDS lines are sorted in a way that eases
8274 updates: a package may depend on other packages listed before it but not on any
8275 listed after it. It is very important to keep this order to ease updates so...
8276 do not change it to alphabetical sorting!
8278 23.2. Packaging a GNOME application
8280 Almost all GNOME applications are written in C and use a common set of tools as
8281 their build system. Things get different with the new bindings to other
8282 languages (such as Python), but the following will give you a general idea on
8283 the minimum required tools:
8285 * Almost all GNOME applications use the GNU Autotools as their build system.
8286 As a general rule you will need to tell this to your package:
8292 * If the package uses pkg-config to detect dependencies, add this tool to the
8293 list of required utilities:
8295 USE_TOOLS+=pkg-config
8297 Also use pkgtools/verifypc at the end of the build process to ensure that
8298 you did not miss to specify any dependency in your package and that the
8299 version requirements are all correct.
8301 * If the package uses intltool, be sure to add intltool to the USE_TOOLS to
8302 handle dependencies and to force the package to use the latest available
8305 * If the package uses gtk-doc (a documentation generation utility), do not
8306 add a dependency on it. The tool is rather big and the distfile should come
8307 with pregenerated documentation anyway; if it does not, it is a bug that
8308 you ought to report. For such packages you should disable gtk-doc (unless
8311 CONFIGURE_ARGS+=--disable-gtk-doc
8313 The default location of installed HTML files (share/gtk-doc/<package-name>)
8314 is correct and should not be changed unless the package insists on
8315 installing them somewhere else. Otherwise programs as devhelp will not be
8316 able to open them. You can do that with an entry similar to:
8318 CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
8320 GNOME uses multiple shared directories and files under the installation prefix
8321 to maintain databases. In this context, shared means that those exact same
8322 directories and files are used among several different packages, leading to
8323 conflicts in the PLIST. pkgsrc currently includes functionality to handle the
8324 most common cases, so you have to forget about using @unexec ${RMDIR} lines in
8325 your file lists and omitting shared files from them. If you find yourself doing
8326 those, your package is most likely incorrect.
8328 The following table lists the common situations that result in using shared
8329 directories or files. For each of them, the appropriate solution is given.
8330 After applying the solution be sure to regenerate the package's file list with
8331 make print-PLIST and ensure it is correct.
8333 Table 23.1. PLIST handling for GNOME packages
8335 +-----------------------------------------------------------------------------+
8336 | If the package... | Then... |
8337 |-------------------------------------------+---------------------------------|
8338 | |See Section 19.6.10, "Packages |
8339 |Installs OMF files under share/omf. |installing scrollkeeper/rarian |
8341 |-------------------------------------------+---------------------------------|
8342 |Installs icons under the share/icons/ |See Section 19.6.19, "Packages |
8343 |hicolor hierarchy or updates share/icons/ |installing hicolor theme icons". |
8344 |hicolor/icon-theme.cache. | |
8345 |-------------------------------------------+---------------------------------|
8346 | |See Section 19.6.14, "Packages |
8347 |Installs files under share/mime/packages. |installing extensions to the MIME|
8349 |-------------------------------------------+---------------------------------|
8350 |Installs .desktop files under share/ |See Section 19.6.20, "Packages |
8351 |applications and these include MIME |installing desktop files". |
8353 +-----------------------------------------------------------------------------+
8356 23.3. Updating GNOME to a newer version
8358 When seeing GNOME as a whole, there are two kinds of updates:
8362 Given that there is still a very long way for GNOME 3 (if it ever appears),
8363 we consider a major update one that goes from a 2.X version to a 2.Y one,
8364 where Y is even and greater than X. These are hard to achieve because they
8365 introduce lots of changes in the components' code and almost all GNOME
8366 distfiles are updated to newer versions. Some of them can even break API
8367 and ABI compatibility with the previous major version series. As a result,
8368 the update needs to be done all at once to minimize breakage.
8370 A major update typically consists of around 80 package updates and the
8371 addition of some new ones.
8375 We consider a minor update one that goes from a 2.A.X version to a 2.A.Y
8376 one where Y is greater than X. These are easy to achieve because they do
8377 not update all GNOME components, can be done in an incremental way and do
8378 not break API nor ABI compatibility.
8380 A minor update typically consists of around 50 package updates, although
8381 the numbers here may vary a lot.
8383 In order to update the GNOME components in pkgsrc to a new stable release
8384 (either major or minor), the following steps should be followed:
8386 1. Get a list of all the tarballs that form the new release by using the
8387 following commands. These will leave the full list of the components'
8388 distfiles into the list.txt file:
8390 % echo ls "*.tar.bz2" | \
8391 ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
8392 awk '{ print $9 }' >list.txt
8393 % echo ls "*.tar.bz2" | \
8394 ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
8395 awk '{ print $9 }' >>list.txt
8397 2. Open each meta package's Makefile and bump their version to the release you
8398 are updating them to. The three meta packages should be always consistent
8399 with versioning. Obviously remove any PKGREVISIONs that might be in them.
8401 3. For each meta package, update all its DEPENDS lines to match the latest
8402 versions as shown by the above commands. Do not list any newer version
8403 (even if found in the FTP) because the meta packages are supposed to list
8404 the exact versions that form a specific GNOME release. Exceptions are
8405 permitted here if a newer version solves a serious issue in the overall
8406 desktop experience; these typically come in the form of a revision bump in
8407 pkgsrc, not in newer versions from the developers.
8409 Packages not listed in the list.txt file should be updated to the latest
8410 version available (if found in pkgsrc). This is the case, for example, of
8411 the dependencies on the GNU Autotools in the meta-pkgs/gnome-devel meta
8414 4. Generate a patch from the modified meta packages and extract the list of
8415 "new" lines. This will provide you an outline on what packages need to be
8416 updated in pkgsrc and in what order:
8418 % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt
8420 5. For major desktop updates it is recommended to zap all your installed
8421 packages and start over from scratch at this point.
8423 6. Now comes the longest step by far: iterate over the contents of todo.txt
8424 and update the packages listed in it in order. For major desktop updates
8425 none of these should be committed until the entire set is completed because
8426 there are chances of breaking not-yet-updated packages.
8428 7. Once the packages are up to date and working, commit them to the tree one
8429 by one with appropriate log messages. At the end, commit the three meta
8430 package updates and all the corresponding changes to the doc/CHANGES-<YEAR>
8431 and pkgsrc/doc/TODO files.
8433 23.4. Patching guidelines
8435 GNOME is a very big component in pkgsrc which approaches 100 packages. Please,
8436 it is very important that you always, always, always feed back any portability
8437 fixes you do to a GNOME package to the mainstream developers (see
8438 Section 11.3.5, "Feedback to the author"). This is the only way to get their
8439 attention on portability issues and to ensure that future versions can be built
8440 out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further
8441 updates are. Those developers in charge of issuing major GNOME updates will be
8442 grateful if you do that.
8444 The most common places to report bugs are the GNOME's Bugzilla and the
8445 freedesktop.org's Bugzilla. Not all components use these to track bugs, but
8446 most of them do. Do not be short on your reports: always provide detailed
8447 explanations of the current failure, how it can be improved to achieve maximum
8448 portability and, if at all possible, provide a patch against CVS head. The more
8449 verbose you are, the higher chances of your patch being accepted.
8451 Also, please avoid using preprocessor magic to fix portability issues. While
8452 the FreeBSD GNOME people are doing a great job in porting GNOME to their
8453 operating system, the official GNOME sources are now plagued by conditionals
8454 that check for __FreeBSD__ and similar macros. This hurts portability. Please
8455 see our patching guidelines (Section 11.3.4, "Patching guidelines") for more
8458 Part III. The pkgsrc infrastructure internals
8460 This part of the guide deals with everything from the infrastructure that is
8461 behind the interfaces described in the developer's guide. A casual package
8462 maintainer should not need anything from this part.
8466 24. Design of the pkgsrc infrastructure
8468 24.1. The meaning of variable definitions
8469 24.2. Avoiding problems before they arise
8470 24.3. Variable evaluation
8472 24.3.1. At load time
8475 24.4. How can variables be specified?
8476 24.5. Designing interfaces for Makefile fragments
8478 24.5.1. Procedures with parameters
8479 24.5.2. Actions taken on behalf of parameters
8481 24.6. The order in which files are loaded
8483 24.6.1. The order in bsd.prefs.mk
8484 24.6.2. The order in bsd.pkg.mk
8486 25. Regression tests
8488 25.1. The regression tests framework
8489 25.2. Running the regression tests
8490 25.3. Adding a new regression test
8492 25.3.1. Overridable functions
8493 25.3.2. Helper functions
8497 26.1. Porting pkgsrc to a new operating system
8498 26.2. Adding support for a new compiler
8500 Chapter 24. Design of the pkgsrc infrastructure
8504 24.1. The meaning of variable definitions
8505 24.2. Avoiding problems before they arise
8506 24.3. Variable evaluation
8508 24.3.1. At load time
8511 24.4. How can variables be specified?
8512 24.5. Designing interfaces for Makefile fragments
8514 24.5.1. Procedures with parameters
8515 24.5.2. Actions taken on behalf of parameters
8517 24.6. The order in which files are loaded
8519 24.6.1. The order in bsd.prefs.mk
8520 24.6.2. The order in bsd.pkg.mk
8522 The pkgsrc infrastructure consists of many small Makefile fragments. Each such
8523 fragment needs a properly specified interface. This chapter explains how such
8524 an interface looks like.
8526 24.1. The meaning of variable definitions
8528 Whenever a variable is defined in the pkgsrc infrastructure, the location and
8529 the way of definition provide much information about the intended use of that
8530 variable. Additionally, more documentation may be found in a header comment or
8531 in this pkgsrc guide.
8533 A special file is mk/defaults/mk.conf, which lists all variables that are
8534 intended to be user-defined. They are either defined using the ?= operator or
8535 they are left undefined because defining them to anything would effectively
8536 mean "yes". All these variables may be overridden by the pkgsrc user in the
8539 Outside this file, the following conventions apply: Variables that are defined
8540 using the ?= operator may be overridden by a package.
8542 Variables that are defined using the = operator may be used read-only at
8545 Variables whose name starts with an underscore must not be accessed outside the
8546 pkgsrc infrastructure at all. They may change without further notice.
8550 These conventions are currently not applied consistently to the complete pkgsrc
8553 24.2. Avoiding problems before they arise
8555 All variables that contain lists of things should default to being empty. Two
8556 examples that do not follow this rule are USE_LANGUAGES and DISTFILES. These
8557 variables cannot simply be modified using the += operator in package Makefiles
8558 (or other files included by them), since there is no guarantee whether the
8559 variable is already set or not, and what its value is. In the case of
8560 DISTFILES, the packages "know" the default value and just define it as in the
8563 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
8565 Because of the selection of this default value, the same value appears in many
8566 package Makefiles. Similarly for USE_LANGUAGES, but in this case the default
8567 value ("c") is so short that it doesn't stand out. Nevertheless it is mentioned
8570 24.3. Variable evaluation
8572 24.3.1. At load time
8574 Variable evaluation takes place either at load time or at runtime, depending on
8575 the context in which they occur. The contexts where variables are evaluated at
8578 * The right hand side of the := and != operators,
8580 * Make directives like .if or .for,
8584 A special exception are references to the iteration variables of .for loops,
8585 which are expanded inline, no matter in which context they appear.
8587 As the values of variables may change during load time, care must be taken not
8588 to evaluate them by accident. Typical examples for variables that should not be
8589 evaluated at load time are DEPENDS and CONFIGURE_ARGS. To make the effect more
8590 clear, here is an example:
8592 CONFIGURE_ARGS= # none
8594 CONFIGURE_ARGS+= CFLAGS=${CFLAGS:Q}
8596 CONFIGURE_ARGS:= ${CONFIGURE_ARGS}
8601 This code shows how the use of the := operator can quickly lead to unexpected
8602 results. The first paragraph is fairly common code. The second paragraph
8603 evaluates the CONFIGURE_ARGS variable, which results in CFLAGS=-O. In the third
8604 paragraph, the -Wall is appended to the CFLAGS, but this addition will not
8605 appear in CONFIGURE_ARGS. In actual code, the three paragraphs from above
8606 typically occur in completely unrelated files.
8610 After all the files have been loaded, the values of the variables cannot be
8611 changed anymore. Variables that are used in the shell commands are expanded at
8614 24.4. How can variables be specified?
8616 There are many ways in which the definition and use of a variable can be
8617 restricted in order to detect bugs and violations of the (mostly unwritten)
8618 policies. See the pkglint developer's documentation for further details.
8620 24.5. Designing interfaces for Makefile fragments
8622 Most of the .mk files fall into one of the following classes. Cases where a
8623 file falls into more than one class should be avoided as it often leads to
8626 24.5.1. Procedures with parameters
8628 In a traditional imperative programming language some of the .mk files could be
8629 described as procedures. They take some input parameters and?after inclusion?
8630 provide a result in output parameters. Since all variables in Makefiles have
8631 global scope care must be taken not to use parameter names that have already
8632 another meaning. For example, PKGNAME is a bad choice for a parameter name.
8634 Procedures are completely evaluated at preprocessing time. That is, when
8635 calling a procedure all input parameters must be completely resolvable. For
8636 example, CONFIGURE_ARGS should never be an input parameter since it is very
8637 likely that further text will be added after calling the procedure, which would
8638 effectively apply the procedure to only a part of the variable. Also,
8639 references to other variables wit will be modified after calling the procedure.
8641 A procedure can declare its output parameters either as suitable for use in
8642 preprocessing directives or as only available at runtime. The latter
8643 alternative is for variables that contain references to other runtime
8646 Procedures shall be written such that it is possible to call the procedure more
8647 than once. That is, the file must not contain multiple-inclusion guards.
8649 Examples for procedures are mk/bsd.options.mk and mk/buildlink3/bsd.builtin.mk.
8650 To express that the parameters are evaluated at load time, they should be
8651 assigned using the := operator, which should be used only for this purpose.
8653 24.5.2. Actions taken on behalf of parameters
8655 Action files take some input parameters and may define runtime variables. They
8656 shall not define loadtime variables. There are action files that are included
8657 implicitly by the pkgsrc infrastructure, while other must be included
8660 An example for action files is mk/subst.mk.
8662 24.6. The order in which files are loaded
8664 Package Makefiles usually consist of a set of variable definitions, and include
8665 the file ../../mk/bsd.pkg.mk in the very last line. Before that, they may also
8666 include various other *.mk files if they need to query the availability of
8667 certain features like the type of compiler or the X11 implementation. Due to
8668 the heavy use of preprocessor directives like .if and .for, the order in which
8669 the files are loaded matters.
8671 This section describes at which point the various files are loaded and gives
8672 reasons for that order.
8674 24.6.1. The order in bsd.prefs.mk
8676 The very first action in bsd.prefs.mk is to define some essential variables
8677 like OPSYS, OS_VERSION and MACHINE_ARCH.
8679 Then, the user settings are loaded from the file specified in MAKECONF, which
8680 is usually mk.conf. After that, those variables that have not been overridden
8681 by the user are loaded from mk/defaults/mk.conf.
8683 After the user settings, the system settings and platform settings are loaded,
8684 which may override the user settings.
8686 Then, the tool definitions are loaded. The tool wrappers are not yet in effect.
8687 This only happens when building a package, so the proper variables must be used
8688 instead of the direct tool names.
8690 As the last steps, some essential variables from the wrapper and the package
8691 system flavor are loaded, as well as the variables that have been cached in
8692 earlier phases of a package build.
8694 24.6.2. The order in bsd.pkg.mk
8696 First, bsd.prefs.mk is loaded.
8698 Then, the various *-vars.mk files are loaded, which fill default values for
8699 those variables that have not been defined by the package. These variables may
8700 later be used even in unrelated files.
8702 Then, the file bsd.pkg.error.mk provides the target error-check that is added
8703 as a special dependency to all other targets that use DELAYED_ERROR_MSG or
8704 DELAYED_WARNING_MSG.
8706 Then, the package-specific hacks from hacks.mk are included.
8708 Then, various other files follow. Most of them don't have any dependencies on
8709 what they need to have included before or after them, though some do.
8711 The code to check PKG_FAIL_REASON and PKG_SKIP_REASON is then executed, which
8712 restricts the use of these variables to all the files that have been included
8713 before. Appearances in later files will be silently ignored.
8715 Then, the files for the main targets are included, in the order of later
8716 execution, though the actual order should not matter.
8718 At last, some more files are included that don't set any interesting variables
8719 but rather just define make targets to be executed.
8721 Chapter 25. Regression tests
8725 25.1. The regression tests framework
8726 25.2. Running the regression tests
8727 25.3. Adding a new regression test
8729 25.3.1. Overridable functions
8730 25.3.2. Helper functions
8732 The pkgsrc infrastructure consists of a large codebase, and there are many
8733 corners where every little bit of a file is well thought out, making pkgsrc
8734 likely to fail as soon as anything is changed near those parts. To prevent most
8735 changes from breaking anything, a suite of regression tests should go along
8736 with every important part of the pkgsrc infrastructure. This chapter describes
8737 how regression tests work in pkgsrc and how you can add new tests.
8739 25.1. The regression tests framework
8741 25.2. Running the regression tests
8743 You first need to install the pkgtools/pkg_regress package, which provides the
8744 pkg_regress command. Then you can simply run that command, which will run all
8745 tests in the regress category.
8747 25.3. Adding a new regression test
8749 Every directory in the regress category that contains a file called spec is
8750 considered a regression test. This file is a shell program that is included by
8751 the pkg_regress command. The following functions can be overridden to suit your
8754 25.3.1. Overridable functions
8756 These functions do not take any parameters. They are all called in "set -e"
8757 mode, so you should be careful to check the exitcodes of any commands you run
8762 This function prepares the environment for the test. By default it does
8767 This function runs the actual test. By default, it calls TEST_MAKE with the
8768 arguments MAKEARGS_TEST and writes its output including error messages into
8769 the file TEST_OUTFILE.
8773 This function is run after the test and is typically used to compare the
8774 actual output from the one that is expected. It can make use of the various
8775 helper functions from the next section.
8779 This function cleans everything up after the test has been run. By default
8782 25.3.2. Helper functions
8784 exit_status(expected)
8786 This function compares the exitcode of the do_test() function with its
8787 first parameter. If they differ, the test will fail.
8789 output_require(regex...)
8791 This function checks for each of its parameters if the output from do_test
8792 () matches the extended regular expression. If it does not, the test will
8795 output_prohibit(regex...)
8797 This function checks for each of its parameters if the output from do_test
8798 () does not match the extended regular expression. If any of the regular
8799 expressions matches, the test will fail.
8801 Chapter 26. Porting pkgsrc
8805 26.1. Porting pkgsrc to a new operating system
8806 26.2. Adding support for a new compiler
8808 The pkgsrc system has already been ported to many operating systems, hardware
8809 architectures and compilers. This chapter explains the necessary steps to make
8810 pkgsrc even more portable.
8812 26.1. Porting pkgsrc to a new operating system
8814 To port pkgsrc to a new operating system (called MyOS in this example), you
8815 need to touch the following files:
8817 pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk
8819 This file contains some basic definitions, for example the name of the C
8824 Insert code that defines the variables OPSYS, OS_VERSION, LOWER_OS_VERSION,
8825 LOWER_VENDOR, MACHINE_ARCH, OBJECT_FMT, APPEND_ELF, and the other variables
8826 that appear in this file.
8830 This file contains the platform-specific definitions that are used by
8831 pkgsrc. Start by copying one of the other files and edit it to your needs.
8833 mk/platform/MyOS.pkg.dist
8835 This file contains a list of directories, together with their permission
8836 bits and ownership. These directories will be created automatically with
8837 every package that explicitly sets USE_MTREE. This feature will be removed.
8839 mk/platform/MyOS.x11.dist
8841 Just copy one of the pre-existing x11.dist files to your MyOS.x11.dist.
8843 mk/tools/bootstrap.mk
8845 On some operating systems, the tools that are provided with the base system
8846 are not good enough for pkgsrc. For example, there are many versions of sed
8847 (1) that have a narrow limit on the line length they can process. Therefore
8848 pkgsrc brings its own tools, which can be enabled here.
8850 mk/tools/tools.MyOS.mk
8852 This file defines the paths to all the tools that are needed by one or the
8853 other package in pkgsrc, as well as by pkgsrc itself. Find out where these
8854 tools are on your platform and add them.
8856 Now, you should be able to build some basic packages, like lang/perl5, shells/
8859 26.2. Adding support for a new compiler
8863 Appendix A. A simple example package: bison
8872 A.1.4. Checking a package with pkglint
8874 A.2. Steps for building, installing, packaging
8876 We checked to find a piece of software that wasn't in the packages collection,
8877 and picked GNU bison. Quite why someone would want to have bison when Berkeley
8878 yacc is already present in the tree is beyond us, but it's useful for the
8879 purposes of this exercise.
8888 DISTNAME= bison-1.25
8890 MASTER_SITES= ${MASTER_SITE_GNU}
8892 MAINTAINER= thorpej@NetBSD.org
8893 HOMEPAGE= http://www.gnu.org/software/bison/bison.html
8894 COMMENT= GNU yacc clone
8897 INFO_FILES= bison.info
8899 .include "../../mk/bsd.pkg.mk"
8903 GNU version of yacc. Can make re-entrant parsers, and numerous other
8904 improvements. Why you would want this when Berkeley yacc(1) is part
8905 of the NetBSD source tree is beyond me.
8915 A.1.4. Checking a package with pkglint
8917 The NetBSD package system comes with pkgtools/pkglint which helps to check the
8918 contents of these files. After installation it is quite easy to use, just
8919 change to the directory of the package you wish to examine and execute pkglint:
8924 Depending on the supplied command line arguments (see pkglint(1)), more checks
8925 will be performed. Use e.g. pkglint -Call -Wall for a very thorough check.
8927 A.2. Steps for building, installing, packaging
8929 Create the directory where the package lives, plus any auxiliary directories:
8931 # cd /usr/pkgsrc/lang
8936 Create Makefile, DESCR and PLIST (see Chapter 11, Package components - files,
8937 directories and contents) then continue with fetching the distfile:
8940 >> bison-1.25.tar.gz doesn't seem to exist on this system.
8941 >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
8942 Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
8943 ftp: Error retrieving file: 500 Internal error
8945 >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
8946 Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
8947 ftp: Error retrieving file: 500 Internal error
8949 >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
8950 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
8951 Successfully retrieved file.
8953 Generate the checksum of the distfile into distinfo:
8960 >> Checksum OK for bison-1.25.tar.gz.
8961 ===> Extracting for bison-1.25
8962 ===> Patching for bison-1.25
8963 ===> Ignoring empty patch directory
8964 ===> Configuring for bison-1.25
8965 creating cache ./config.cache
8966 checking for gcc... cc
8967 checking whether we are using GNU C... yes
8968 checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
8969 checking how to run the C preprocessor... cc -E
8970 checking for minix/config.h... no
8971 checking for POSIXized ISC... no
8972 checking whether cross-compiling... no
8973 checking for ANSI C header files... yes
8974 checking for string.h... yes
8975 checking for stdlib.h... yes
8976 checking for memory.h... yes
8977 checking for working const... yes
8978 checking for working alloca.h... no
8979 checking for alloca... yes
8980 checking for strerror... yes
8981 updating cache ./config.cache
8982 creating ./config.status
8984 ===> Building for bison-1.25
8985 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
8986 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
8987 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
8988 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
8989 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
8990 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
8991 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
8992 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
8993 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
8994 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
8995 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
8996 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
8997 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
8998 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
8999 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
9000 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
9001 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
9002 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
9003 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
9004 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
9005 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
9006 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
9007 ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
9009 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
9011 Everything seems OK, so install the files:
9014 >> Checksum OK for bison-1.25.tar.gz.
9015 ===> Installing for bison-1.25
9016 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
9017 rm -f /usr/pkg/bin/bison
9018 cd /usr/pkg/share; rm -f bison.simple bison.hairy
9019 rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
9020 install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison
9021 /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
9022 /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
9023 cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
9024 /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
9025 ===> Registering installation for bison-1.25
9027 You can now use bison, and also - if you decide so - remove it with pkg_delete
9028 bison. Should you decide that you want a binary package, do this now:
9031 >> Checksum OK for bison-1.25.tar.gz.
9032 ===> Building package for bison-1.25
9033 Creating package bison-1.25.tgz
9034 Registering depends:.
9035 Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
9037 Now that you don't need the source and object files any more, clean up:
9040 ===> Cleaning for bison-1.25
9042 Appendix B. Build logs
9046 B.1. Building figlet
9047 B.2. Packaging figlet
9049 B.1. Building figlet
9052 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9053 => figlet221.tar.gz doesn't seem to exist on this system.
9054 => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
9056 Connected to ftp.plig.net.
9057 220 ftp.plig.org NcFTPd Server (licensed copy) ready.
9058 331 Guest login ok, send your complete e-mail address as password.
9059 230-You are user #5 of 500 simultaneous users allowed.
9062 230- | _| |_ ___ ___| |_|___ ___ ___ ___
9063 230- | _| _| . |_| . | | | . |_| . | _| . |
9064 230- |_| |_| | _|_| _|_|_|_ |_|___|_| |_ |
9065 230- |_| |_| |___| |___|
9067 230-** Welcome to ftp.plig.org **
9069 230-Please note that all transfers from this FTP site are logged. If you
9070 230-do not like this, please disconnect now.
9072 230-This archive is available via
9074 230-HTTP: http://ftp.plig.org/
9075 230-FTP: ftp://ftp.plig.org/ (max 500 connections)
9076 230-RSYNC: rsync://ftp.plig.org/ (max 30 connections)
9078 230-Please email comments, bug reports and requests for packages to be
9079 230-mirrored to ftp-admin@plig.org.
9082 230 Logged in anonymously.
9083 Remote system type is UNIX.
9084 Using binary mode to transfer files.
9086 250 "/pub" is new cwd.
9087 250-"/pub/figlet" is new cwd.
9089 250-Welcome to the figlet archive at ftp.figlet.org
9091 250- ftp://ftp.figlet.org/pub/figlet/
9093 250-The official FIGlet web page is:
9094 250- http://www.figlet.org/
9096 250-If you have questions, please mailto:info@figlet.org. If you want to
9097 250-contribute a font or something else, you can email us.
9099 250 "/pub/figlet/program" is new cwd.
9100 250 "/pub/figlet/program/unix" is new cwd.
9101 local: figlet221.tar.gz remote: figlet221.tar.gz
9102 502 Unimplemented command.
9103 227 Entering Passive Mode (195,40,6,41,246,104)
9104 150 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
9105 38% |************** | 65800 64.16 KB/s 00:01 ETA
9106 226 Transfer completed.
9107 172219 bytes received in 00:02 (75.99 KB/s)
9109 => Checksum OK for figlet221.tar.gz.
9110 ===> Extracting for figlet-2.2.1nb2
9111 ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found
9112 ===> Patching for figlet-2.2.1nb2
9113 ===> Applying pkgsrc patches for figlet-2.2.1nb2
9114 ===> Overriding tools for figlet-2.2.1nb2
9115 ===> Creating toolchain wrappers for figlet-2.2.1nb2
9116 ===> Configuring for figlet-2.2.1nb2
9117 ===> Building for figlet-2.2.1nb2
9118 gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\" -DDEFAULTFONTFILE=\"standard.flf\" figlet.c zipio.c crc.c inflate.c -o figlet
9120 gcc -O2 -o chkfont chkfont.c
9121 => Unwrapping files-to-be-installed.
9124 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9125 ===> Installing for figlet-2.2.1nb2
9126 install -d -o root -g wheel -m 755 /usr/pkg/bin
9127 install -d -o root -g wheel -m 755 /usr/pkg/man/man6
9128 mkdir -p /usr/pkg/share/figlet
9129 cp figlet /usr/pkg/bin
9130 cp chkfont /usr/pkg/bin
9131 chmod 555 figlist showfigfonts
9132 cp figlist /usr/pkg/bin
9133 cp showfigfonts /usr/pkg/bin
9134 cp fonts/*.flf /usr/pkg/share/figlet
9135 cp fonts/*.flc /usr/pkg/share/figlet
9136 cp figlet.6 /usr/pkg/man/man6
9137 ===> Registering installation for figlet-2.2.1nb2
9140 B.2. Packaging figlet
9143 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9144 ===> Packaging figlet-2.2.1nb2
9145 ===> Building binary package for figlet-2.2.1nb2
9146 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
9147 Using SrcDir value of /usr/pkg
9148 Registering depends:.
9151 Appendix C. Directory layout of the pkgsrc FTP server
9155 C.1. bootstrap-pkgsrc: Bootstrap kits
9156 C.2. distfiles: The distributed source files
9157 C.3. iso: Currently empty
9158 C.4. misc: Miscellaneous things
9159 C.5. packages: Binary packages
9160 C.6. reports: Bulk build reports
9161 C.7. current, pkgsrc-200xQy: source packages
9163 As in other big projects, the directory layout of pkgsrc is quite complex for
9164 newbies. This chapter explains where you find things on the FTP server. The
9165 base directory on ftp.NetBSD.org is /pub/pkgsrc/. On other servers it may be
9166 different, but inside this directory, everything should look the same, no
9167 matter on which server you are. This directory contains some subdirectories,
9168 which are explained below.
9170 C.1. bootstrap-pkgsrc: Bootstrap kits
9172 This directory used to contain binary packages of the package management tools
9173 for various platforms. For those package collections that need them, they are
9174 now stored near the binary packages, so you should look in the packages
9177 C.2. distfiles: The distributed source files
9179 The directory distfiles contains lots of archive files from all pkgsrc
9180 packages, which are mirrored here. The subdirectories are called after their
9181 package names and are used when the distributed files have names that don't
9182 explicitly contain a version number or are otherwise too generic (for example
9185 C.3. iso: Currently empty
9187 This directory is currently not in use.
9189 C.4. misc: Miscellaneous things
9191 This directory contains things that individual pkgsrc developers find worth
9194 C.5. packages: Binary packages
9196 This directory contains binary packages for the various platforms that are
9197 supported by pkgsrc. Each subdirectory is of the form OPSYS/ARCH/OSVERSION_TAG.
9198 The meaning of these variables is:
9200 * OPSYS is the name of the operating system for which the packages have been
9201 built. The name is taken from the output of the uname command, so it may
9202 differ from the one you are used to hear.
9204 * ARCH is the hardware architecture of the platform for which the packages
9205 have been built. It also includes the ABI (Application Binary Interface)
9206 for platforms that have several of them.
9208 * OSVERSION is the version of the operating system. For version numbers that
9209 change often (for example NetBSD-current), the often-changing part should
9210 be replaced with an x, for example 4.99.x.
9212 * TAG is either 200xQy for a stable branch, or head for packages built from
9213 the HEAD branch. The latter should only be used when the packages are
9214 updated on a regular basis. Otherwise the date from checking out pkgsrc
9215 should be appended, for example head_20071015.
9217 The rationale for exactly this scheme is that the pkgsrc users looking for
9218 binary packages can quickly click through the directories on the server and
9219 find the best binary packages for their machines. Since they usually know the
9220 operating system and the hardware architecture, OPSYS and ARCH are placed
9221 first. After these choices, they can select the best combination of OSVERSION
9222 and TAG together, since it is usually the case that packages stay compatible
9223 between different version of the operating system.
9225 In each of these directories, there is a whole binary packages collection for a
9226 specific platform. It has a directory called All which contains all binary
9227 packages. Besides that, there are various category directories that contain
9228 symbolic links to the real binary packages.
9230 C.6. reports: Bulk build reports
9232 Here are the reports from bulk builds, for those who want to fix packages that
9233 didn't build on some of the platforms. The structure of subdirectories should
9234 look like the one in Section C.5, "packages: Binary packages".
9236 C.7. current, pkgsrc-200xQy: source packages
9238 These directories contain the "real" pkgsrc, that is the files that define how
9239 to create binary packages from source archives.
9241 The directory pkgsrc contains a snapshot of the CVS repository, which is
9242 updated regularly. The file pkgsrc.tar.gz contains the same as the directory,
9243 ready to be downloaded as a whole.
9245 In the directories for the quarterly branches, there is an additional file
9246 called pkgsrc-200xQy.tar.gz, which contains the state of pkgsrc when it was
9249 Appendix D. Editing guidelines for the pkgsrc guide
9256 This section contains information on editing the pkgsrc guide itself.
9260 The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several
9261 files are created from it:
9263 * pkgsrc/doc/pkgsrc.txt
9265 * pkgsrc/doc/pkgsrc.html
9267 * http://www.NetBSD.org/docs/pkgsrc/
9269 * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.pdf: The PDF version of the pkgsrc
9272 * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps: PostScript version of the
9277 The procedure to edit the pkgsrc guide is:
9279 1. Make sure you have the packages needed to regenerate the pkgsrc guide (and
9280 other XML-based NetBSD documentation) installed. These are meta-pkgs/
9281 netbsd-doc for creating the ASCII and HTML versions, and meta-pkgs/
9282 netbsd-doc-print for the PostScript and PDF versions. You will need both
9283 packages installed, to make sure documentation is consistent across all
9286 2. Run cd doc/guide to get to the right directory. All further steps will take
9289 3. Edit the XML file(s) in files/.
9291 4. Run bmake to check the pkgsrc guide for valid XML and to build the final
9292 output files. If you get any errors at this stage, you can just edit the
9293 files, as there are only symbolic links in the working directory, pointing
9294 to the files in files/.
9296 5. (cd files && cvs commit)
9298 6. Run bmake clean && bmake to regenerate the output files with the proper RCS
9301 7. Run bmake regen to install and commit the files in both pkgsrc/doc and
9306 If you have added, removed or renamed some chapters, you need to
9307 synchronize them using cvs add or cvs delete in the htdocs directory.