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
51 2.1.2. Via anonymous CVS
53 2.2. Keeping pkgsrc up-to-date
58 3. Using pkgsrc on systems other than NetBSD
60 3.1. Binary distribution
61 3.2. Bootstrapping pkgsrc
62 3.3. Platform-specific notes
64 3.3.1. Darwin (Mac OS X)
74 4.1. Using binary packages
76 4.1.1. Finding binary packages
77 4.1.2. Installing binary packages
78 4.1.3. Deinstalling packages
79 4.1.4. Getting information about installed packages
80 4.1.5. Checking for security vulnerabilities in installed packages
81 4.1.6. Finding if newer versions of your installed packages are in
83 4.1.7. Other administrative functions
84 4.1.8. A word of warning
86 4.2. Building packages from source
89 4.2.2. Fetching distfiles
90 4.2.3. How to build and install
94 5.1. General configuration
95 5.2. Variables affecting the build process
96 5.3. Variables affecting the installation process
97 5.4. Selecting and configuring the compiler
99 5.4.1. Selecting the compiler
100 5.4.2. Additional flags to the compiler (CFLAGS)
101 5.4.3. Additional flags to the linker (LDFLAGS)
103 5.5. Developer/advanced settings
104 5.6. Selecting Build Options
106 6. Creating binary packages
108 6.1. Building a single binary package
109 6.2. Settings for creation of binary packages
111 7. Creating binary packages for everything in pkgsrc (bulk builds)
113 7.1. Think first, build later
114 7.2. Requirements of a bulk build
115 7.3. Running an old-style bulk build
118 7.3.2. Other environmental considerations
121 7.3.5. Disk space requirements
122 7.3.6. Setting up a sandbox for chrooted builds
123 7.3.7. Building a partial set of packages
124 7.3.8. Uploading results of a bulk build
126 7.4. Running a pbulk-style bulk build
131 7.5. Creating a multiple CD-ROM packages collection
133 7.5.1. Example of cdpack
135 8. Directory layout of the installed files
137 8.1. File system layout in ${LOCALBASE}
138 8.2. File system layout in ${VARBASE}
140 9. Frequently Asked Questions
142 9.1. Are there any mailing lists for pkg-related discussion?
143 9.2. Where's the pkgviews documentation?
144 9.3. Utilities for package management (pkgtools)
145 9.4. How to use pkgsrc as non-root
146 9.5. How to resume transfers when fetching distfiles?
147 9.6. How can I install/use modular X.org from pkgsrc?
148 9.7. How to fetch files from behind a firewall
149 9.8. How do I tell make fetch to do passive FTP?
150 9.9. How to fetch all distfiles at once
151 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc"
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 mk.conf
308 19.1.3. User interaction
309 19.1.4. Handling licenses
310 19.1.5. Restricted packages
311 19.1.6. Handling dependencies
312 19.1.7. Handling conflicts with other packages
313 19.1.8. Packages that cannot or should not be built
314 19.1.9. Packages which should not be deleted, once installed
315 19.1.10. Handling packages with security problems
316 19.1.11. How to handle incrementing versions when fixing an
318 19.1.12. Substituting variable text in the package files (the SUBST
321 19.2. Fixing problems in the fetch phase
323 19.2.1. Packages whose distfiles aren't available for plain
325 19.2.2. How to handle modified distfiles with the 'old' name
327 19.3. Fixing problems in the configure phase
329 19.3.1. Shared libraries - libtool
330 19.3.2. Using libtool on GNU packages that already support libtool
331 19.3.3. GNU Autoconf/Automake
333 19.4. Programming languages
335 19.4.1. C, C++, and Fortran
337 19.4.3. Packages containing perl scripts
338 19.4.4. Other programming languages
340 19.5. Fixing problems in the build phase
342 19.5.1. Compiling C and C++ code conditionally
343 19.5.2. How to handle compiler bugs
344 19.5.3. Undefined reference to "..."
345 19.5.4. Running out of memory
347 19.6. Fixing problems in the install phase
349 19.6.1. Creating needed directories
350 19.6.2. Where to install documentation
351 19.6.3. Installing highscore files
352 19.6.4. Adding DESTDIR support to packages
353 19.6.5. Packages with hardcoded paths to other interpreters
354 19.6.6. Packages installing perl modules
355 19.6.7. Packages installing info files
356 19.6.8. Packages installing man pages
357 19.6.9. Packages installing GConf data files
358 19.6.10. Packages installing scrollkeeper/rarian data files
359 19.6.11. Packages installing X11 fonts
360 19.6.12. Packages installing GTK2 modules
361 19.6.13. Packages installing SGML or XML data
362 19.6.14. Packages installing extensions to the MIME database
363 19.6.15. Packages using intltool
364 19.6.16. Packages installing startup scripts
365 19.6.17. Packages installing TeX modules
366 19.6.18. Packages supporting running binaries in emulation
367 19.6.19. Packages installing hicolor theme icons
368 19.6.20. Packages installing desktop files
370 19.7. Marking packages as having problems
373 21. Submitting and Committing
375 21.1. Submitting binary packages
376 21.2. Submitting source packages (for non-NetBSD-developers)
377 21.3. General notes when adding, updating, or removing packages
378 21.4. Committing: Importing a package into CVS
379 21.5. Updating a package to a newer version
380 21.6. Renaming a package in pkgsrc
381 21.7. Moving a package in pkgsrc
383 22. Frequently Asked Questions
384 23. GNOME packaging and porting
387 23.2. Packaging a GNOME application
388 23.3. Updating GNOME to a newer version
389 23.4. Patching guidelines
391 III. The pkgsrc infrastructure internals
393 24. Design of the pkgsrc infrastructure
395 24.1. The meaning of variable definitions
396 24.2. Avoiding problems before they arise
397 24.3. Variable evaluation
402 24.4. How can variables be specified?
403 24.5. Designing interfaces for Makefile fragments
405 24.5.1. Procedures with parameters
406 24.5.2. Actions taken on behalf of parameters
408 24.6. The order in which files are loaded
410 24.6.1. The order in bsd.prefs.mk
411 24.6.2. The order in bsd.pkg.mk
415 25.1. The regression tests framework
416 25.2. Running the regression tests
417 25.3. Adding a new regression test
419 25.3.1. Overridable functions
420 25.3.2. Helper functions
424 26.1. Porting pkgsrc to a new operating system
425 26.2. Adding support for a new compiler
427 A. A simple example package: bison
434 A.1.4. Checking a package with pkglint
436 A.2. Steps for building, installing, packaging
441 B.2. Packaging figlet
443 C. Directory layout of the pkgsrc FTP server
445 C.1. distfiles: The distributed source files
446 C.2. misc: Miscellaneous things
447 C.3. packages: Binary packages
448 C.4. reports: Bulk build reports
449 C.5. current, pkgsrc-20xxQy: source packages
451 D. Editing guidelines for the pkgsrc guide
458 1.1. Platforms supported by pkgsrc
459 11.1. Patching examples
460 23.1. PLIST handling for GNOME packages
462 Chapter 1. What is pkgsrc?
469 1.1.2. Supported platforms
474 1.3.1. Roles involved in pkgsrc
480 There is a lot of software freely available for Unix-based systems, which is
481 usually available in form of the source code. Before such software can be used,
482 it needs to be configured to the local system, compiled and installed, and this
483 is exactly what The NetBSD Packages Collection (pkgsrc) does. pkgsrc also has
484 some basic commands to handle binary packages, so that not every user has to
485 build the packages for himself, which is a time-costly task.
487 pkgsrc currently contains several thousand packages, including:
489 * www/apache - The Apache web server
491 * www/firefox - The Firefox web browser
493 * meta-pkgs/gnome - The GNOME Desktop Environment
495 * meta-pkgs/kde3 - The K Desktop Environment
497 ...just to name a few.
499 pkgsrc has built-in support for handling varying dependencies, such as pthreads
500 and X11, and extended features such as IPv6 support on a range of platforms.
504 pkgsrc provides the following key features:
506 * Easy building of software from source as well as the creation and
507 installation of binary packages. The source and latest patches are
508 retrieved from a master or mirror download site, checksum verified, then
509 built on your system. Support for binary-only distributions is available
510 for both native platforms and NetBSD emulated platforms.
512 * All packages are installed in a consistent directory tree, including
513 binaries, libraries, man pages and other documentation.
515 * Package dependencies, including when performing package updates, are
516 handled automatically. The configuration files of various packages are
517 handled automatically during updates, so local changes are preserved.
519 * Like NetBSD, pkgsrc is designed with portability in mind and consists of
520 highly portable code. This allows the greatest speed of development when
521 porting to new a platform. This portability also ensures that pkgsrc is
522 consistent across all platforms.
524 * The installation prefix, acceptable software licenses, international
525 encryption requirements and build-time options for a large number of
526 packages are all set in a simple, central configuration file.
528 * The entire source (not including the distribution files) is freely
529 available under a BSD license, so you may extend and adapt pkgsrc to your
530 needs. Support for local packages and patches is available right out of the
531 box, so you can configure it specifically for your environment.
533 The following principles are basic to pkgsrc:
535 * "It should only work if it's right." ? That means, if a package contains
536 bugs, it's better to find them and to complain about them rather than to
537 just install the package and hope that it works. There are numerous checks
538 in pkgsrc that try to find such bugs: Static analysis tools (pkgtools/
539 pkglint), build-time checks (portability of shell scripts), and
540 post-installation checks (installed files, references to shared libraries,
541 script interpreters).
543 * "If it works, it should work everywhere" ? Like NetBSD has been ported to
544 many hardware architectures, pkgsrc has been ported to many operating
545 systems. Care is taken that packages behave the same on all platforms.
547 1.1.2. Supported platforms
549 pkgsrc consists of both a source distribution and a binary distribution for
550 these operating systems. After retrieving the required source or binaries, you
551 can be up and running with pkgsrc in just minutes!
553 pkgsrc was derived from FreeBSD's ports system, and initially developed for
554 NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
557 Table 1.1. Platforms supported by pkgsrc
559 +----------------------------------------------------------------+
560 | Platform |Date Support Added|
561 |---------------------------------------------+------------------|
563 |---------------------------------------------+------------------|
564 |Solaris | Mar 1999 |
565 |---------------------------------------------+------------------|
567 |---------------------------------------------+------------------|
568 |Darwin (Mac OS X) | Oct 2001 |
569 |---------------------------------------------+------------------|
570 |FreeBSD | Nov 2002 |
571 |---------------------------------------------+------------------|
572 |OpenBSD | Nov 2002 |
573 |---------------------------------------------+------------------|
575 |---------------------------------------------+------------------|
577 |---------------------------------------------+------------------|
579 |---------------------------------------------+------------------|
580 |Interix (Microsoft Windows Services for Unix)| Mar 2004 |
581 |---------------------------------------------+------------------|
582 |DragonFlyBSD | Oct 2004 |
583 |---------------------------------------------+------------------|
585 |---------------------------------------------+------------------|
587 |---------------------------------------------+------------------|
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
694 2.1.2. Via anonymous CVS
696 2.2. Keeping pkgsrc up-to-date
701 3. Using pkgsrc on systems other than NetBSD
703 3.1. Binary distribution
704 3.2. Bootstrapping pkgsrc
705 3.3. Platform-specific notes
707 3.3.1. Darwin (Mac OS X)
717 4.1. Using binary packages
719 4.1.1. Finding binary packages
720 4.1.2. Installing binary packages
721 4.1.3. Deinstalling packages
722 4.1.4. Getting information about installed packages
723 4.1.5. Checking for security vulnerabilities in installed packages
724 4.1.6. Finding if newer versions of your installed packages are in
726 4.1.7. Other administrative functions
727 4.1.8. A word of warning
729 4.2. Building packages from source
732 4.2.2. Fetching distfiles
733 4.2.3. How to build and install
735 5. Configuring pkgsrc
737 5.1. General configuration
738 5.2. Variables affecting the build process
739 5.3. Variables affecting the installation process
740 5.4. Selecting and configuring the compiler
742 5.4.1. Selecting the compiler
743 5.4.2. Additional flags to the compiler (CFLAGS)
744 5.4.3. Additional flags to the linker (LDFLAGS)
746 5.5. Developer/advanced settings
747 5.6. Selecting Build Options
749 6. Creating binary packages
751 6.1. Building a single binary package
752 6.2. Settings for creation of binary packages
754 7. Creating binary packages for everything in pkgsrc (bulk builds)
756 7.1. Think first, build later
757 7.2. Requirements of a bulk build
758 7.3. Running an old-style bulk build
761 7.3.2. Other environmental considerations
764 7.3.5. Disk space requirements
765 7.3.6. Setting up a sandbox for chrooted builds
766 7.3.7. Building a partial set of packages
767 7.3.8. Uploading results of a bulk build
769 7.4. Running a pbulk-style bulk build
774 7.5. Creating a multiple CD-ROM packages collection
776 7.5.1. Example of cdpack
778 8. Directory layout of the installed files
780 8.1. File system layout in ${LOCALBASE}
781 8.2. File system layout in ${VARBASE}
783 9. Frequently Asked Questions
785 9.1. Are there any mailing lists for pkg-related discussion?
786 9.2. Where's the pkgviews documentation?
787 9.3. Utilities for package management (pkgtools)
788 9.4. How to use pkgsrc as non-root
789 9.5. How to resume transfers when fetching distfiles?
790 9.6. How can I install/use modular X.org from pkgsrc?
791 9.7. How to fetch files from behind a firewall
792 9.8. How do I tell make fetch to do passive FTP?
793 9.9. How to fetch all distfiles at once
794 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
795 9.11. What does "Could not find bsd.own.mk" mean?
796 9.12. Using 'sudo' with pkgsrc
797 9.13. How do I change the location of configuration files?
798 9.14. Automated security checks
799 9.15. Why do some packages ignore my CFLAGS?
800 9.16. A package does not build. What shall I do?
801 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
804 Chapter 2. Where to get pkgsrc and how to keep it up-to-date
808 2.1. Getting pkgsrc for the first time
811 2.1.2. Via anonymous CVS
813 2.2. Keeping pkgsrc up-to-date
818 Before you download and extract the files, you need to decide where you want to
819 extract them. When using pkgsrc as root user, pkgsrc is usually installed in /
820 usr/pkgsrc. You are though free to install the sources and binary packages
821 wherever you want in your filesystem, provided that the pathname does not
822 contain white-space or other characters that are interpreted specially by the
823 shell and some other programs. A safe bet is to use only letters, digits,
824 underscores and dashes.
826 2.1. Getting pkgsrc for the first time
828 Before you download any pkgsrc files, you should decide whether you want the
829 current branch or the stable branch. The latter is forked on a quarterly basis
830 from the current branch and only gets modified for security updates. The names
831 of the stable branches are built from the year and the quarter, for example
834 The second step is to decide how you want to download pkgsrc. You can get it as
835 a tar file or via CVS. Both ways are described here.
839 The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/
840 pkgsrc/. There are a number of subdirectories for different purposes, which are
841 described in detail in Appendix C, Directory layout of the pkgsrc FTP server.
843 The tar file for the current branch is in the directory current and is called
844 pkgsrc.tar.gz. It is autogenerated daily.
846 The tar file for the stable branch 2009Q1 is in the directory pkgsrc-2009Q1 and
847 is also called pkgsrc-2009Q1.tar.gz.
849 To download a pkgsrc stable tarball, run:
851 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-20xxQy/pkgsrc-20xxQy.tar.gz
853 Where pkgsrc-20xxQy is the stable branch to be downloaded, for example, "
856 Then, extract it with:
858 $ tar -xzf pkgsrc-20xxQy.tar.gz -C /usr
860 This will create the directory pkgsrc/ in /usr/ and all the package source will
861 be stored under /usr/pkgsrc/.
863 To download pkgsrc-current, run:
865 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
867 2.1.2. Via anonymous CVS
869 To fetch a specific pkgsrc stable branch, run:
871 $ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-20xxQy -P pkgsrc
873 Where pkgsrc-20xxQy is the stable branch to be checked out, for example, "
876 This will create the directory pkgsrc/ in your /usr/ directory and all the
877 package source will be stored under /usr/pkgsrc/.
879 To fetch the pkgsrc current branch, run:
881 $ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
883 Refer to list of available CVS mirrors to choose faster one.
885 If you get error messages from rsh, you need to set CVS_RSH variable. E.g.:
887 $ cd /usr && env CVS_RSH=ssh cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
889 Refer to documentation on your command shell how to set CVS_RSH=ssh
890 permanently. For Bourne shells, you can set it in your .profile or better
891 globally in /etc/profile:
893 # set CVS remote shell command
897 By default, CVS doesn't do things like most people would expect it to do. But
898 there is a way to convince CVS, by creating a file called .cvsrc in your home
899 directory and saving the following lines to it. This file will save you lots of
900 headache and some bug reports, so we strongly recommend it. You can find an
901 explanation of this file in the CVS documentation.
903 # recommended CVS configuration file from the pkgsrc guide
911 2.2. Keeping pkgsrc up-to-date
913 The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you
914 have first installed it via a tar file). It saves bandwidth and hard disk
915 activity, compared to downloading the tar file again.
921 When updating from a tar file, you first need to completely remove the old
922 pkgsrc directory. Otherwise those files that have been removed from pkgsrc in
923 the mean time will not be removed on your local disk, resulting in
924 inconsistencies. When removing the old files, any changes that you have done to
925 the pkgsrc files will be lost after updating. Therefore updating via CVS is
926 strongly recommended.
928 Note that by default the distfiles and the binary packages are saved in the
929 pkgsrc tree, so don't forget to rescue them before updating. You can also
930 configure pkgsrc to use other than the default directories by setting the
931 DISTDIR and PACKAGES variables. See Chapter 5, Configuring pkgsrc for the
934 To update pkgsrc from a tar file, download the tar file as explained above.
935 Then, make sure that you have not made any changes to the files in the pkgsrc
936 directory. Remove the pkgsrc directory and extract the new tar file. Done.
940 To update pkgsrc via CVS, make sure the environment variable CVS_RSH is set as
941 above. Then, change to the pkgsrc directory and run cvs:
946 2.2.2.1. Switching between different pkgsrc branches
948 When updating pkgsrc, the CVS program keeps track of the branch you selected.
949 But if you, for whatever reason, want to switch from the stable branch to the
950 current one, you can do it by adding the option "-A" after the "update"
951 keyword. To switch from the current branch back to the stable branch, add the "
952 -rpkgsrc-2009Q3" option.
954 2.2.2.2. What happens to my changes when updating?
956 When you update pkgsrc, the CVS program will only touch those files that are
957 registered in the CVS repository. That means that any packages that you created
958 on your own will stay unmodified. If you change files that are managed by CVS,
959 later updates will try to merge your changes with those that have been done by
960 others. See the CVS manual, chapter "update" for details.
962 Chapter 3. Using pkgsrc on systems other than NetBSD
966 3.1. Binary distribution
967 3.2. Bootstrapping pkgsrc
968 3.3. Platform-specific notes
970 3.3.1. Darwin (Mac OS X)
978 3.1. Binary distribution
980 See Section 4.1, "Using binary packages".
982 3.2. Bootstrapping pkgsrc
984 Installing the bootstrap kit from source should be as simple as:
986 # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
987 # cd pkgsrc/bootstrap
991 See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways
992 to get pkgsrc before bootstrapping. The given bootstrap command will use the
993 defaults of /usr/pkg for the prefix where programs will be installed in, and /
994 var/db/pkg for the package database directory where pkgsrc will do its internal
995 bookkeeping. However, these can also be set using command-line arguments.
999 The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
1000 For examples in this guide, use bmake instead of "make".
1002 3.3. Platform-specific notes
1004 Here are some platform-specific notes you should be aware of.
1006 3.3.1. Darwin (Mac OS X)
1008 Darwin 5.x and up are supported. Before you start, you will need to download
1009 and install the Mac OS X Developer Tools from Apple's Developer Connection. See
1010 http://developer.apple.com/macosx/ for details. Also, make sure you install X11
1011 (an optional package included with the Developer Tools) if you intend to build
1012 packages that use the X11 Window System.
1016 FreeBSD 4.7 and 5.0 have been tested and are supported, other versions may
1019 Care should be taken so that the tools that this kit installs do not conflict
1020 with the FreeBSD userland tools. There are several steps:
1022 1. FreeBSD stores its ports pkg database in /var/db/pkg. It is therefore
1023 recommended that you choose a different location (e.g. /usr/pkgdb) by using
1024 the --pkgdbdir option to the bootstrap script.
1026 2. If you do not intend to use the FreeBSD ports tools, it's probably a good
1027 idea to move them out of the way to avoid confusion, e.g.
1030 # mv pkg_add pkg_add.orig
1031 # mv pkg_create pkg_create.orig
1032 # mv pkg_delete pkg_delete.orig
1033 # mv pkg_info pkg_info.orig
1036 3. An example mk.conf file will be placed in /etc/mk.conf.example file when
1037 you use the bootstrap script.
1041 Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a
1042 Unix-like environment with a tighter kernel integration than available with
1043 Cygwin. It is part of the Windows Services for Unix package, available for free
1044 for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU
1045 can be downloaded from http://www.microsoft.com/windows/sfu/.
1047 Services for Unix 3.5 has been tested. 3.0 or 3.1 may work, but are not
1048 officially supported. (The main difference in 3.0/3.1 is lack of pthreads, but
1049 other parts of libc may also be lacking.)
1051 Services for Unix Applications (aka SUA) is an integrated component of Windows
1052 Server 2003 R2 (5.2), Windows Vista and Windows Server 2008 (6.0), Windows 7
1053 and Windows Server 2008 R2 (6.1). As of this writing, the SUA's Interix 6.0
1054 (32bit) and 6.1 (64bit) subsystems have been tested. Other versions may work as
1055 well. The Interix 5.x subsystem has not yet been tested with pkgsrc.
1057 3.3.3.1. When installing Interix/SFU
1059 At an absolute minimum, the following packages must be installed from the
1060 Windows Services for Unix 3.5 distribution in order to use pkgsrc:
1062 * Utilities -> Base Utilities
1064 * Interix GNU Components -> (all)
1066 * Remote Connectivity
1070 When using pkgsrc on Interix, DO NOT install the Utilities subcomponent "UNIX
1071 Perl". That is Perl 5.6 without shared module support, installed to /usr/local,
1072 and will only cause confusion. Instead, install Perl 5.8 from pkgsrc (or from a
1075 The Remote Connectivity subcomponent "Windows Remote Shell Service" does not
1076 need to be installed, but Remote Connectivity itself should be installed in
1077 order to have a working inetd.
1079 During installation you may be asked whether to enable setuid behavior for
1080 Interix programs, and whether to make pathnames default to case-sensitive.
1081 Setuid should be enabled, and case-sensitivity MUST be enabled. (Without
1082 case-sensitivity, a large number of packages including perl will not build.)
1084 NOTE: Newer Windows service packs change the way binary execution works (via
1085 the Data Execution Prevention feature). In order to use pkgsrc and other
1086 gcc-compiled binaries reliably, a hotfix containing POSIX.EXE, PSXDLL.DLL,
1087 PSXRUN.EXE, and PSXSS.EXE (899522 or newer) must be installed. Hotfixes are
1088 available from Microsoft through a support contract; however, Debian Interix
1089 Port has made most Interix hotfixes available for personal use from http://
1090 www.debian-interix.net/hotfixes/.
1092 In addition to the hotfix noted above, it may be necessary to disable Data
1093 Execution Prevention entirely to make Interix functional. This may happen only
1094 with certain types of CPUs; the cause is not fully understood at this time. If
1095 gcc or other applications still segfault repeatedly after installing one of the
1096 hotfixes note above, the following option can be added to the appropriate
1097 "boot.ini" line on the Windows boot drive: /NoExecute=AlwaysOff (WARNING, this
1098 will disable DEP completely, which may be a security risk if applications are
1099 often run as a user in the Administrators group!)
1101 3.3.3.2. What to do if Interix/SFU is already installed
1103 If SFU is already installed and you wish to alter these settings to work with
1104 pkgsrc, note the following things.
1106 * To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft Windows
1107 Services for UNIX, then click Change. In the installer, choose Add or
1108 Remove, then uncheck Utilities->UNIX Perl.
1110 * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change
1111 the following registry key:
1113 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
1115 Set the DWORD value "obcaseinsensitive" to 0; then reboot.
1117 * To enable setuid binaries (optional), run REGEDIT.EXE, and change the
1118 following registry key:
1120 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX
1122 Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.
1124 3.3.3.3. Important notes for using pkgsrc
1126 The package manager (either the pkgsrc "su" user, or the user running
1127 "pkg_add") must be a member of the local Administrators group. Such a user must
1128 also be used to run the bootstrap. This is slightly relaxed from the normal
1129 pkgsrc requirement of "root".
1131 The package manager should use a umask of 002. "make install" will
1132 automatically complain if this is not the case. This ensures that directories
1133 written in /var/db/pkg are Administrators-group writeable.
1135 The popular Interix binary packages from http://www.interopsystems.com/ use an
1136 older version of pkgsrc's pkg_* tools. Ideally, these should NOT be used in
1137 conjunction with pkgsrc. If you choose to use them at the same time as the
1138 pkgsrc packages, ensure that you use the proper pkg_* tools for each type of
1141 The TERM setting used for DOS-type console windows (including those invoked by
1142 the csh and ksh startup shortcuts) is "interix". Most systems don't have a
1143 termcap/terminfo entry for it, but the following .termcap entry provides
1144 adequate emulation in most cases:
1146 interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
1149 3.3.3.4. Limitations of the Interix platform
1151 Though Interix suffices as a familiar and flexible substitute for a full
1152 Unix-like platform, it has some drawbacks that should be noted for those
1153 desiring to make the most of Interix.
1157 Interix comes with the standard set of X11R6 client libraries, and can run
1158 X11 based applications, but it does not come with an X server. Some options
1159 are StarNet X-Win32, Hummingbird Exceed (available in a trimmed version for
1160 Interix from Interop Systems as the Interop X Server), and the free X11
1161 server included with Cygwin.
1165 Because Interix runs in a completely different NT subsystem from Win32
1166 applications, it does not currently support various X11 protocol extensions
1167 for acceleration (such as MIT-SHM or DGA). Most interactive applications to
1168 a local X server will run reasonably fast, but full motion video and other
1169 graphics intensive applications may require a faster-than-expected CPU.
1173 Interix has no native support for audio output. For audio support, pkgsrc
1174 uses the esound client/server audio system on Interix. Unlike on most
1175 platforms, the audio/esound package does not contain the esd server
1176 component. To output audio via an Interix host, the emulators/cygwin_esound
1177 package must also be installed.
1179 * CD/DVDs, USB, and SCSI:
1181 Direct device access is not currently supported in Interix, so it is not
1182 currently possible to access CD/DVD drives, USB devices, or SCSI devices
1183 through non-filesystem means. Among other things, this makes it impossible
1184 to use Interix directly for CD/DVD burning.
1188 Due to the same limitations as for CD-ROMs and SCSI devices, tape drives
1189 are also not directly accessible in Interix. However, support is in work to
1190 make tape drive access possible by using Cygwin as a bridge (similarly to
1191 audio bridged via Cygwin's esound server).
1193 3.3.3.5. Known issues for pkgsrc on Interix
1195 It is not necessary, in general, to have a "root" user on the Windows system;
1196 any member of the local Administrators group will suffice. However, some
1197 packages currently assume that the user named "root" is the privileged user. To
1198 accommodate these, you may create such a user; make sure it is in the local
1199 group Administrators (or your language equivalent).
1201 pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time
1202 being, install packages as the local Administrator (or your language
1203 equivalent), or run the following command after installing a package to work
1206 # chmod -R g+w $PKG_DBDIR
1211 You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro
1212 compiler (cc/c89). Please set the CC environment variable according to your
1213 preference. If you do not have a license for the MIPSpro compiler suite, you
1214 can download a gcc tardist file from http://freeware.sgi.com/.
1216 Please note that you will need IRIX 6.5.17 or higher, as this is the earliest
1217 version of IRIX providing support for if_indextoname(3), if_nametoindex(3),
1220 At this point in time, pkgsrc only supports one ABI at a time. That is, you
1221 cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit
1222 ABI. If you start out using "abi=n32", that's what all your packages will be
1225 Therefore, please make sure that you have no conflicting CFLAGS in your
1226 environment or the mk.conf. Particularly, make sure that you do not try to link
1227 n32 object files with lib64 or vice versa. Check your /etc/compiler.defaults!
1229 If you have the actual pkgsrc tree mounted via NFS from a different host,
1230 please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX
1231 linker occasionally runs into issues when trying to link over a network-mounted
1234 The bootstrapping process should set all the right options for programs such as
1235 imake(1), but you may want to set some options depending on your local setup.
1236 Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages
1239 If you are using SGI's MIPSPro compiler, please set
1241 PKGSRC_COMPILER= mipspro
1244 in mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up
1245 passing invalid flags to the compiler. Note that bootstrap should create an
1246 appropriate mk.conf.example by default.
1248 If you have both the MIPSPro compiler chain installed as well as gcc, but want
1249 to make sure that MIPSPro is used, please set your PATH to not include the
1250 location of gcc (often /usr/freeware/bin), and (important) pass the
1251 '--preserve-path' flag.
1255 Some versions of Linux (for example Debian GNU/Linux) need either libtermcap or
1256 libcurses (libncurses). Installing the distributions libncurses-dev package (or
1257 equivalent) should fix the problem.
1259 pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++
1260 Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested.
1262 To bootstrap using icc, assuming the default icc installation directory:
1264 env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \
1265 ac_cv___attribute__=yes ./bootstrap
1270 icc 8.1 needs the `-i-static' argument instead of -static-libcxa.
1272 icc supports __attribute__, but the GNU configure test uses a nested function,
1273 which icc does not support. #undef'ing __attribute__ has the unfortunate
1274 side-effect of breaking many of the Linux header files, which cannot be
1275 compiled properly without __attribute__. The test must be overridden so that
1276 __attribute__ is assumed supported by the compiler.
1278 After bootstrapping, you should set PKGSRC_COMPILER in mk.conf:
1280 PKGSRC_COMPILER= icc
1283 The default installation directory for icc is /opt/intel_cc_80, which is also
1284 the pkgsrc default. If you have installed it into a different directory, set
1290 pkgsrc uses the static linking method of the runtime libraries provided by icc,
1291 so binaries can be run on other systems which do not have the shared libraries
1294 Libtool, however, extracts a list of libraries from the ld(1) command run when
1295 linking a C++ shared library and records it, throwing away the -Bstatic and
1296 -Bdynamic options interspersed between the libraries. This means that
1297 libtool-linked C++ shared libraries will have a runtime dependency on the icc
1298 libraries until this is fixed in libtool.
1302 OpenBSD 3.0 and 3.2 are tested and supported.
1304 Care should be taken so that the tools that this kit installs do not conflict
1305 with the OpenBSD userland tools. There are several steps:
1307 1. OpenBSD stores its ports pkg database in /var/db/pkg. It is therefore
1308 recommended that you choose a different location (e.g. /usr/pkgdb) by using
1309 the --pkgdbdir option to the bootstrap script.
1311 2. If you do not intend to use the OpenBSD ports tools, it's probably a good
1312 idea to move them out of the way to avoid confusion, e.g.
1315 # mv pkg_add pkg_add.orig
1316 # mv pkg_create pkg_create.orig
1317 # mv pkg_delete pkg_delete.orig
1318 # mv pkg_info pkg_info.orig
1321 3. An example mk.conf file will be placed in /etc/mk.conf.example file when
1322 you use the bootstrap script. OpenBSD's make program uses mk.conf as well.
1323 You can work around this by enclosing all the pkgsrc-specific parts of the
1327 # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
1335 Solaris 2.6 through 9 are supported on both x86 and sparc. You will need a
1336 working C compiler. Both gcc 2.95.3 and Sun WorkShop 5 have been tested.
1338 The following packages are required on Solaris 8 for the bootstrap process and
1351 Please note that the use of GNU binutils on Solaris is not supported, as of
1354 Whichever compiler you use, please ensure the compiler tools and your $prefix
1355 are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/
1358 3.3.7.1. If you are using gcc
1360 It makes life much simpler if you only use the same gcc consistently for
1361 building all packages.
1363 It is recommended that an external gcc be used only for bootstrapping, then
1364 either build gcc from lang/gcc or install a binary gcc package, then remove gcc
1365 used during bootstrapping.
1367 Binary packages of gcc can be found through http://www.sunfreeware.com/.
1369 3.3.7.2. If you are using Sun WorkShop
1371 You will need at least the following packages installed (from WorkShop 5.0)
1373 * SPROcc - Sun WorkShop Compiler C 5.0
1375 * SPROcpl - Sun WorkShop Compiler C++ 5.0
1377 * SPROild - Sun WorkShop Incremental Linker
1379 * SPROlang - Sun WorkShop Compilers common components
1381 You should set the following variables in your mk.conf file:
1390 The CPP setting might break some packages that use the C preprocessor for
1391 processing things other than C source code.
1393 3.3.7.3. Building 64-bit binaries with SunPro
1395 To build 64-bit packages, you just need to have the following lines in your
1398 PKGSRC_COMPILER= sunpro
1403 This setting has been tested for the SPARC architecture. Intel and AMD machines
1404 need some more work.
1406 3.3.7.4. Common problems
1408 Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The
1409 workaround is to use another shell for the configure scripts, for example by
1410 installing shells/bash and adding the following lines to your mk.conf:
1412 CONFIG_SHELL= ${LOCALBASE}/bin/bash
1413 WRAPPER_SHELL= ${LOCALBASE}/bin/bash
1416 Then, rebuild the devel/libtool-base package.
1418 Chapter 4. Using pkgsrc
1422 4.1. Using binary packages
1424 4.1.1. Finding binary packages
1425 4.1.2. Installing binary packages
1426 4.1.3. Deinstalling packages
1427 4.1.4. Getting information about installed packages
1428 4.1.5. Checking for security vulnerabilities in installed packages
1429 4.1.6. Finding if newer versions of your installed packages are in pkgsrc
1430 4.1.7. Other administrative functions
1431 4.1.8. A word of warning
1433 4.2. Building packages from source
1436 4.2.2. Fetching distfiles
1437 4.2.3. How to build and install
1439 Basically, there are two ways of using pkgsrc. The first is to only install the
1440 package tools and to use binary packages that someone else has prepared. This
1441 is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
1442 Then you are able to build your own packages, and you can still use binary
1443 packages from someone else.
1445 4.1. Using binary packages
1447 On the ftp.NetBSD.org server and its mirrors, there are collections of binary
1448 packages, ready to be installed. These binary packages have been built using
1449 the default settings for the directories, that is:
1451 * /usr/pkg for LOCALBASE, where most of the files are installed,
1453 * /usr/pkg/etc for configuration files,
1455 * /var for VARBASE, where those files are installed that may change after
1458 If you cannot use these directories for whatever reasons (maybe because you're
1459 not root), you cannot use these binary packages, but have to build the packages
1460 yourself, which is explained in Section 3.2, "Bootstrapping pkgsrc".
1462 4.1.1. Finding binary packages
1464 To install binary packages, you first need to know from where to get them. The
1465 first place where you should look is on the main pkgsrc FTP server in the
1466 directory /pub/pkgsrc/packages.
1468 This directory contains binary packages for multiple platforms. First, select
1469 your operating system. (Ignore the directories with version numbers attached to
1470 it, they just exist for legacy reasons.) Then, select your hardware
1471 architecture, and in the third step, the OS version and the "version" of
1474 In this directory, you often find a file called bootstrap.tar.gz which contains
1475 the package management tools. If the file is missing, it is likely that your
1476 operating system already provides those tools. Download the file and extract it
1477 in the / directory. It will create the directories /usr/pkg (containing the
1478 tools for managing binary packages) and /var/db/pkg (the database of installed
1481 4.1.2. Installing binary packages
1483 In the directory from the last section, there is a subdirectory called All,
1484 which contains all the binary packages that are available for the platform,
1485 excluding those that may not be distributed via FTP or CDROM (depending on
1486 which medium you are using).
1488 To install packages directly from an FTP or HTTP server, run the following
1489 commands in a Bourne-compatible shell (be sure to su to root first):
1491 # PATH="/usr/pkg/sbin:$PATH"
1492 # PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All"
1493 # export PATH PKG_PATH
1495 Instead of URLs, you can also use local paths, for example if you are
1496 installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want
1497 to install packages from multiple sources, you can separate them by a semicolon
1500 After these preparations, installing a package is very easy:
1502 # pkg_add openoffice2
1504 # pkg_add ap2-php5-*
1506 Note that any prerequisite packages needed to run the package in question will
1507 be installed, too, assuming they are present where you install from.
1509 Adding packages might install vulnerable packages. Thus you should run
1510 pkg_admin audit regularly, especially after installing new packages, and verify
1511 that the vulnerabilities are acceptable for your configuration.
1513 After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
1514 in your PATH so you can actually start the just installed program.
1516 4.1.3. Deinstalling packages
1518 To deinstall a package, it does not matter whether it was installed from source
1519 code or from a binary package. The pkg_delete command does not know it anyway.
1520 To delete a package, you can just run pkg_delete package-name. The package name
1521 can be given with or without version number. Wildcards can also be used to
1522 deinstall a set of packages, for example *emacs*. Be sure to include them in
1523 quotes, so that the shell does not expand them before pkg_delete sees them.
1525 The -r option is very powerful: it removes all the packages that require the
1526 package in question and then removes the package itself. For example:
1528 # pkg_delete -r jpeg
1531 will remove jpeg and all the packages that used it; this allows upgrading the
1534 4.1.4. Getting information about installed packages
1536 The pkg_info shows information about installed packages or binary package
1539 4.1.5. Checking for security vulnerabilities in installed packages
1541 The NetBSD Security-Officer and Packages Groups maintain a list of known
1542 security vulnerabilities to packages which are (or have been) included in
1543 pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/
1544 pub/pkgsrc/distfiles/vulnerabilities.
1546 Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded
1547 automatically, and a security audit of all packages installed on a system can
1550 There are two components to auditing. The first step, pkg_admin
1551 fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
1552 the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of
1553 your installed packages are vulnerable. If a package is vulnerable, you will
1554 see output similar to the following:
1556 Package samba-2.0.9 has a local-root-shell vulnerability, see
1557 http://www.samba.org/samba/whatsnew/macroexploit.html
1559 You may wish to have the vulnerabilities file downloaded daily so that it
1560 remains current. This may be done by adding an appropriate entry to the root
1561 users crontab(5) entry. For example the entry
1563 # download vulnerabilities file
1564 0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
1567 will update the vulnerability list every day at 3AM. You may wish to do this
1568 more often than once a day. In addition, you may wish to run the package audit
1569 from the daily security script. This may be accomplished by adding the
1570 following line to /etc/security.local:
1572 /usr/sbin/pkg_admin audit
1575 4.1.6. Finding if newer versions of your installed packages are in pkgsrc
1577 Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
1578 if your packages are up-to-date, e.g.
1582 Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
1585 You can then use make update to update the package on your system and rebuild
1588 4.1.7. Other administrative functions
1590 The pkg_admin executes various administrative functions on the package system.
1592 4.1.8. A word of warning
1594 Please pay very careful attention to the warnings expressed in the pkg_add(1)
1595 manual page about the inherent dangers of installing binary packages which you
1596 did not create yourself, and the security holes that can be introduced onto
1597 your system by indiscriminate adding of such files.
1599 The same warning of course applies to every package you install from source
1600 when you haven't completely read and understood the source code of the package,
1601 the compiler that is used to build the package and all the other tools that are
1604 4.2. Building packages from source
1606 After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
1607 organized into categories. You can browse the online index of packages, or run
1608 make readme from the pkgsrc directory to build local README.html files for all
1609 packages, viewable with any web browser such as www/lynx or www/firefox.
1611 The default prefix for installed packages is /usr/pkg. If you wish to change
1612 this, you should do so by setting LOCALBASE in mk.conf. You should not try to
1613 use multiple different LOCALBASE definitions on the same system (inside a
1614 chroot is an exception).
1616 The rest of this chapter assumes that the package is already in pkgsrc. If it
1617 is not, see Part II, "The pkgsrc developer's guide" for instructions how to
1618 create your own packages.
1622 To build packages from source, you need a working C compiler. On NetBSD, you
1623 need to install the "comp" and the "text" distribution sets. If you want to
1624 build X11-related packages, the "xbase" and "xcomp" distribution sets are
1627 4.2.2. Fetching distfiles
1629 The first step for building a package is downloading the distfiles (i.e. the
1630 unmodified source). If they have not yet been downloaded, pkgsrc will fetch
1633 If you have all files that you need in the distfiles directory, you don't need
1634 to connect. If the distfiles are on CD-ROM, you can mount the CD-ROM on /cdrom
1637 DISTDIR=/cdrom/pkgsrc/distfiles
1641 By default a list of distribution sites will be randomly intermixed to prevent
1642 huge load on servers which holding popular packages (for example,
1643 SourceForge.net mirrors). Thus, every time when you need to fetch yet another
1644 distfile all the mirrors will be tried in new (random) order. You can turn this
1645 feature off by setting MASTER_SORT_RANDOM=NO (for PKG_DEVELOPERs it's already
1648 You can overwrite some of the major distribution sites to fit to sites that are
1649 close to your own. By setting one or two variables you can modify the order in
1650 which the master sites are accessed. MASTER_SORT contains a whitespace
1651 delimited list of domain suffixes. MASTER_SORT_REGEX is even more flexible, it
1652 contains a whitespace delimited list of regular expressions. It has higher
1653 priority than MASTER_SORT. Have a look at pkgsrc/mk/defaults/mk.conf to find
1654 some examples. This may save some of your bandwidth and time.
1656 You can change these settings either in your shell's environment, or, if you
1657 want to keep the settings, by editing the mk.conf file, and adding the
1660 If a package depends on many other packages (such as meta-pkgs/kde3), the build
1661 process may alternate between periods of downloading source, and compiling. To
1662 ensure you have all the source downloaded initially you can run the command:
1664 % make fetch-list | sh
1666 which will output and run a set of shell commands to fetch the necessary files
1667 into the distfiles directory. You can also choose to download the files
1670 4.2.3. How to build and install
1672 Once the software has downloaded, any patches will be applied, then it will be
1673 compiled for you. This may take some time depending on your computer, and how
1674 many other packages the software depends on and their compile time.
1678 If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
1679 command instead of "make" in the examples in this guide.
1687 at the shell prompt to build the various components of the package.
1689 The next stage is to actually install the newly compiled program onto your
1690 system. Do this by entering:
1695 while you are still in the directory for whatever package you are installing.
1697 Installing the package on your system may require you to be root. However,
1698 pkgsrc has a just-in-time-su feature, which allows you to only become root for
1699 the actual installation step.
1701 That's it, the software should now be installed and setup for use. You can now
1707 to remove the compiled files in the work directory, as you shouldn't need them
1708 any more. If other packages were also added to your system (dependencies) to
1709 allow your program to compile, you can tidy these up also with the command:
1711 % make clean-depends
1714 Taking the figlet utility as an example, we can install it on our system by
1715 building as shown in Appendix B, Build logs.
1717 The program is installed under the default root of the packages tree - /usr/
1718 pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
1719 environment, and it will use that value as the root of your packages tree. So,
1720 to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
1721 that you should use a directory which is dedicated to packages and not shared
1722 with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
1723 not try to add any of your own files or directories (such as src/, obj/, or
1724 pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
1725 between programs and other files installed by the package system and whatever
1726 else may have been installed there.
1728 Some packages look in mk.conf to alter some configuration options at build
1729 time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will
1730 be set there by default. Environment variables such as LOCALBASE can be set in
1731 mk.conf to save having to remember to set them each time you want to use
1734 Occasionally, people want to "look under the covers" to see what is going on
1735 when a package is building or being installed. This may be for debugging
1736 purposes, or out of simple curiosity. A number of utility values have been
1737 added to help with this.
1739 1. If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a huge
1740 amount of information will be displayed. For example,
1742 make patch PKG_DEBUG_LEVEL=2
1744 will show all the commands that are invoked, up to and including the "patch
1747 2. If you want to know the value of a certain make(1) definition, then the
1748 VARNAME definition should be used, in conjunction with the show-var target.
1749 e.g. to show the expansion of the make(1) variable LOCALBASE:
1751 % make show-var VARNAME=LOCALBASE
1756 If you want to install a binary package that you've either created yourself
1757 (see next section), that you put into pkgsrc/packages manually or that is
1758 located on a remote FTP server, you can use the "bin-install" target. This
1759 target will install a binary package - if available - via pkg_add(1), else do a
1760 make package. The list of remote FTP sites searched is kept in the variable
1761 BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
1762 to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
1765 A final word of warning: If you set up a system that has a non-standard setting
1766 for LOCALBASE, be sure to set that before any packages are installed, as you
1767 cannot use several directories for the same purpose. Doing so will result in
1768 pkgsrc not being able to properly detect your installed packages, and fail
1769 miserably. Note also that precompiled binary packages are usually built with
1770 the default LOCALBASE of /usr/pkg, and that you should not install any if you
1771 use a non-standard LOCALBASE.
1773 Chapter 5. Configuring pkgsrc
1777 5.1. General configuration
1778 5.2. Variables affecting the build process
1779 5.3. Variables affecting the installation process
1780 5.4. Selecting and configuring the compiler
1782 5.4.1. Selecting the compiler
1783 5.4.2. Additional flags to the compiler (CFLAGS)
1784 5.4.3. Additional flags to the linker (LDFLAGS)
1786 5.5. Developer/advanced settings
1787 5.6. Selecting Build Options
1789 The whole pkgsrc system is configured in a single file, usually called mk.conf.
1790 In which directory pkgsrc looks for that file depends on the installation. On
1791 NetBSD, when you use make(1) from the base system, it is in the directory /etc
1792 /. In all other cases the default location is ${PREFIX}/etc/, depending on
1793 where you told the bootstrap program to install the binary packages.
1795 During the bootstrap, an example configuration file is created. To use that,
1796 you have to create the directory ${PREFIX}/etc and copy the example file there.
1798 The format of the configuration file is that of the usual BSD-style Makefiles.
1799 The whole pkgsrc configuration is done by setting variables in this file. Note
1800 that you can define all kinds of variables, and no special error checking (for
1801 example for spelling mistakes) takes place, so you have to try it out to see if
1804 5.1. General configuration
1806 In this section, you can find some variables that apply to all pkgsrc packages.
1807 A complete list of the variables that can be configured by the user is
1808 available in mk/defaults/mk.conf, together with some comments that describe
1809 each variable's intent.
1811 * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
1812 not mix binary packages with different LOCALBASEs!
1814 * CROSSBASE: Where "cross" category packages will be installed. The default
1815 is ${LOCALBASE}/cross.
1817 * X11BASE: Where X11 is installed on the system. The default is /usr/X11R6.
1819 * DISTDIR: Where to store the downloaded copies of the original source
1820 distributions used for building pkgsrc packages. The default is $
1821 {PKGSRCDIR}/distfiles.
1823 * PKG_DBDIR: Where the database about installed packages is stored. The
1824 default is /var/db/pkg.
1826 * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
1829 * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
1830 files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
1831 respectively. The defaults are ftp://ftp.NetBSD.org/pub/NetBSD/packages/
1832 distfiles/${DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$
1835 * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
1836 with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
1838 * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
1839 case-sensitive. Whenever you try to build a package whose license is not in
1840 this list, you will get an error message. If the license condition is
1841 simple enough, the error message will include specific instructions on how
1842 to change this variable.
1844 5.2. Variables affecting the build process
1848 * PACKAGES: The top level directory for the binary packages. The default is $
1849 {PKGSRCDIR}/packages.
1851 * WRKOBJDIR: The top level directory where, if defined, the separate working
1852 directories will get created, and symbolically linked to from ${WRKDIR}
1853 (see below). This is useful for building packages on several architectures,
1854 then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
1855 architecture. (It should be noted that PKGSRCDIR should not be set by the
1856 user ? it is an internal definition which refers to the root of the pkgsrc
1857 tree. It is possible to have many pkgsrc tree instances.)
1859 * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
1860 Section 11.3, "patches/*" for more information.
1862 * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
1863 Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
1864 up settings used by builds in /usr/src.
1866 * DEPENDS_TARGET: By default, dependencies are only installed, and no binary
1867 package is created for them. You can set this variable to package to
1868 automatically create binary packages after installing dependencies.
1870 5.3. Variables affecting the installation process
1872 Most packages support installation into a subdirectory of WRKDIR. This allows a
1873 package to be built, before the actual filesystem is touched. DESTDIR support
1874 exists in two variations:
1876 * Basic DESTDIR support means that the package installation and packaging is
1879 * Full DESTDIR support can run the complete build, installation and packaging
1880 as normal user. Root privileges are only needed to add packages.
1882 DESTDIR support is now the default. To switch back to non-DESTDIR, you can set
1883 USE_DESTDIR=no; this setting will be deprecated though, so it's preferable to
1884 convert a package to DESTDIR instead.
1886 DESTDIR support changes the behaviour of various targets slightly. To install a
1887 package after building it, use package-install. package and install don't do
1888 that any longer. package-install can be used as DEPENDS_TARGET. bin-install
1889 will ask for the root password to install the package and fail, package-install
1892 With basic DESTDIR support, make clean needs to be run as root.
1894 Considering the foo/bar package, DESTDIR full support can be tested using the
1898 uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
1899 $ mkdir $HOME/packages
1900 $ cd $PKGSRCDIR/foo/bar
1902 Verify DESTDIR full support, no root privileges should be needed
1904 $ make USE_DESTDIR=yes install
1906 Create a package without root privileges
1908 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package
1910 For the following command, you must be able to gain root privileges using su(1)
1912 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install
1914 Then, as a simple user
1918 5.4. Selecting and configuring the compiler
1920 5.4.1. Selecting the compiler
1922 By default, pkgsrc will use GCC to build packages. This may be overridden by
1923 setting the following variables in /etc/mk.conf:
1927 This is a list of values specifying the chain of compilers to invoke when
1928 building packages. Valid values are:
1930 * distcc: distributed C/C++ (chainable)
1932 * ccache: compiler cache (chainable)
1934 * gcc: GNU C/C++ Compiler
1936 * mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)
1938 * mipspro: Silicon Graphics, Inc. MIPSpro (o32)
1940 * sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio
1942 The default is "gcc". You can use ccache and/or distcc with an appropriate
1943 PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
1944 terminated with a value for a real compiler. Note that only one real
1945 compiler should be listed (e.g. "sunpro gcc" is not allowed).
1949 This specifies the minimum version of GCC to use when building packages. If
1950 the system GCC doesn't satisfy this requirement, then pkgsrc will build and
1951 install one of the GCC packages to use instead.
1953 5.4.2. Additional flags to the compiler (CFLAGS)
1955 If you wish to set the CFLAGS variable, please make sure to use the += operator
1956 instead of the = operator:
1958 CFLAGS+= -your -flags
1960 Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
1961 need to add their own flags. You may want to take a look at the devel/cpuflags
1962 package if you're interested in optimization specifically for the current CPU.
1964 5.4.3. Additional flags to the linker (LDFLAGS)
1966 If you want to pass flags to the linker, both in the configure step and the
1967 build step, you can do this in two ways. Either set LDFLAGS or LIBS. The
1968 difference between the two is that LIBS will be appended to the command line,
1969 while LDFLAGS come earlier. LDFLAGS is pre-loaded with rpath settings for ELF
1970 machines depending on the setting of USE_IMAKE or the inclusion of mk/
1971 x11.buildlink3.mk. As with CFLAGS, if you do not wish to override these
1972 settings, use the += operator:
1974 LDFLAGS+= -your -linkerflags
1976 5.5. Developer/advanced settings
1980 * PKG_DEVELOPER: Run some sanity checks that package developers want:
1982 o make sure patches apply with zero fuzz
1984 o run check-shlibs to see that all binaries will find their shared libs.
1986 * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst
1987 making and installing the package. The default value for this is 0, which
1988 will not display the commands as they are executed (normal, default, quiet
1989 operation); the value 1 will display all shell commands before their
1990 invocation, and the value 2 will display both the shell commands before
1991 their invocation, and their actual execution progress with set -x will be
1994 5.6. Selecting Build Options
1996 Some packages have build time options, usually to select between different
1997 dependencies, enable optional support for big dependencies or enable
1998 experimental features.
2000 To see which options, if any, a package supports, and which options are
2001 mutually exclusive, run make show-options, for example:
2003 The following options are supported by this package:
2004 ssl Enable SSL support.
2005 Exactly one of the following gecko options is required:
2006 firefox Use firefox as gecko rendering engine.
2007 mozilla Use mozilla as gecko rendering engine.
2008 At most one of the following database options may be selected:
2009 mysql Enable support for MySQL database.
2010 pgsql Enable support for PostgreSQL database.
2012 These options are enabled by default: firefox
2013 These options are currently enabled: mozilla ssl
2015 The following variables can be defined in mk.conf to select which options to
2016 enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
2017 disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
2018 which can be used to select or disable options specifically for package pkgbase
2019 . Options listed in these variables are selected, options preceded by "-" are
2020 disabled. A few examples:
2022 $ grep "PKG.*OPTION" mk.conf
2023 PKG_DEFAULT_OPTIONS= -arts -dvdread -esound
2024 PKG_OPTIONS.kdebase= debug -sasl
2025 PKG_OPTIONS.apache= suexec
2027 It is important to note that options that were specifically suggested by the
2028 package maintainer must be explicitly removed if you do not wish to include the
2029 option. If you are unsure you can view the current state with make show-options
2032 The following settings are consulted in the order given, and the last setting
2033 that selects or disables an option is used:
2035 1. the default options as suggested by the package maintainer
2037 2. the options implied by the settings of legacy variables (see below)
2039 3. PKG_DEFAULT_OPTIONS
2041 4. PKG_OPTIONS.pkgbase
2043 For groups of mutually exclusive options, the last option selected is used, all
2044 others are automatically disabled. If an option of the group is explicitly
2045 disabled, the previously selected option, if any, is used. It is an error if no
2046 option from a required group of options is selected, and building the package
2049 Before the options framework was introduced, build options were selected by
2050 setting a variable (often named USE_FOO) in mk.conf for each option. To ease
2051 transition to the options framework for the user, these legacy variables are
2052 converted to the appropriate options setting (PKG_OPTIONS.pkgbase)
2053 automatically. A warning is issued to prompt the user to update mk.conf to use
2054 the options framework directly. Support for the legacy variables will be
2057 Chapter 6. Creating binary packages
2061 6.1. Building a single binary package
2062 6.2. Settings for creation of binary packages
2064 6.1. Building a single binary package
2066 Once you have built and installed a package, you can create a binary package
2067 which can be installed on another system with pkg_add(1). This saves having to
2068 build the same package on a group of hosts and wasting CPU time. It also
2069 provides a simple means for others to install your package, should you
2072 To create a binary package, change into the appropriate directory in pkgsrc,
2073 and run make package:
2079 This will build and install your package (if not already done), and then build
2080 a binary package from what was installed. You can then use the pkg_* tools to
2081 manipulate it. Binary packages are created by default in /usr/pkgsrc/packages,
2082 in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a
2083 continuation of the above misc/figlet example.
2085 See Chapter 21, Submitting and Committing for information on how to submit such
2088 6.2. Settings for creation of binary packages
2090 See Section 17.17, "Other helpful targets".
2092 Chapter 7. Creating binary packages for everything in pkgsrc (bulk builds)
2096 7.1. Think first, build later
2097 7.2. Requirements of a bulk build
2098 7.3. Running an old-style bulk build
2100 7.3.1. Configuration
2101 7.3.2. Other environmental considerations
2104 7.3.5. Disk space requirements
2105 7.3.6. Setting up a sandbox for chrooted builds
2106 7.3.7. Building a partial set of packages
2107 7.3.8. Uploading results of a bulk build
2109 7.4. Running a pbulk-style bulk build
2112 7.4.2. Configuration
2114 7.5. Creating a multiple CD-ROM packages collection
2116 7.5.1. Example of cdpack
2118 When you have multiple machines that should run the same packages, it is wasted
2119 time if they all build their packages themselves from source. There are two
2120 ways of getting a set of binary packages: The old bulk build system, or the new
2121 (as of 2007) parallel bulk build (pbulk) system. This chapter describes how to
2122 set them up so that the packages are most likely to be usable later.
2124 7.1. Think first, build later
2126 Since a bulk build takes several days or even weeks to finish, you should think
2127 about the setup before you start everything. Pay attention to at least the
2130 * If you want to upload the binary packages to ftp.NetBSD.org, make sure the
2131 setup complies to the requirements for binary packages:
2133 o To end up on ftp.NetBSD.org, the packages must be built by a NetBSD
2134 developer on a trusted machine (that is, where you and only you have
2137 o Packages on ftp.NetBSD.org should only be created from the stable
2138 branches (like 2009Q1), so that users browsing the available
2139 collections can see at a glance how old the packages are.
2141 o The packages must be built as root, since some packages require set-uid
2142 binaries at runtime, and creating those packages as unprivileged user
2143 doesn't work well at the moment.
2145 * Make sure that the bulk build cannot break anything in your system. Most
2146 bulk builds run as root, so they should be run at least in a chroot
2147 environment or something even more restrictive, depending on what the
2148 operating system provides. There have been numerous cases where certain
2149 packages tried to install files outside the LOCALBASE or wanted to edit
2150 some files in /etc. Furthermore, the bulk builds install and deinstall
2151 packages in /usr/pkg (or whatever LOCALBASE is) during their operation, so
2152 be sure that you don't need any package during the build.
2154 7.2. Requirements of a bulk build
2156 A complete bulk build requires lots of disk space. Some of the disk space can
2157 be read-only, some other must be writable. Some can be on remote filesystems
2158 (such as NFS) and some should be local. Some can be temporary filesystems,
2159 others must survive a sudden reboot.
2161 * 10 GB for the distfiles (read-write, remote, temporary)
2163 * 10 GB for the binary packages (read-write, remote, permanent)
2165 * 400 MB for the pkgsrc tree (read-only, remote, permanent)
2167 * 5 GB for LOCALBASE (read-write, local, temporary for pbulk, permanent for
2170 * 5 GB for the log files (read-write, remote, permanent)
2172 * 5 GB for temporary files (read-write, local, temporary)
2174 7.3. Running an old-style bulk build
2178 There are two ways of doing a bulk build. The old-style one and the new-style "
2179 pbulk". The latter is the recommended way.
2181 7.3.1. Configuration
2185 The build.conf file is the main configuration file for bulk builds. You can
2186 configure how your copy of pkgsrc is kept up to date, how the distfiles are
2187 downloaded, how the packages are built and how the report is generated. You can
2188 find an annotated example file in pkgsrc/mk/bulk/build.conf-example. To use it,
2189 copy build.conf-example to build.conf and edit it, following the comments in
2194 You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf
2195 for details of the default settings. You will want to ensure that
2196 ACCEPTABLE_LICENSES meet your local policy. As used in this example,
2197 SKIP_LICENSE_CHECK=yes completely bypasses the license check.
2199 PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
2200 WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
2202 BSDXSRCDIR= /usr/xsrc # for x11/xservers
2203 OBJHOSTNAME?= yes # use work.`hostname`
2204 FAILOVER_FETCH= yes # insist on the correct checksum
2206 SKIP_LICENSE_CHECK= yes
2208 Some options that are especially useful for bulk builds can be found at the top
2209 lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are
2210 briefly described here.
2212 * If you are on a slow machine, you may want to set USE_BULK_BROKEN_CHECK to
2215 * If you are doing bulk builds from a read-only copy of pkgsrc, you have to
2216 set BULKFILESDIR to the directory where all log files are created.
2217 Otherwise the log files are created in the pkgsrc directory.
2219 * Another important variable is BULK_PREREQ, which is a list of packages that
2220 should be always available while building other packages.
2222 Some other options are scattered in the pkgsrc infrastructure:
2224 * ALLOW_VULNERABLE_PACKAGES should be set to yes. The purpose of the bulk
2225 builds is creating binary packages, no matter if they are vulnerable or
2226 not. Leaving this variable unset would prevent the bulk build system from
2227 even trying to build them, so possible building errors would not show up.
2229 * CHECK_FILES (pkgsrc/mk/check/check-files.mk) can be set to "yes" to check
2230 that the installed set of files matches the PLIST.
2232 * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to "yes
2233 " to check that the installed "#!"-scripts will find their interpreter.
2235 * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before
2236 installing it. Note that some packages make heavy use of "good" random
2237 numbers, so you need to assure that the machine on which you are doing the
2238 bulk builds is not completely idle. Otherwise some test programs will seem
2239 to hang, while they are just waiting for new random data to be available.
2241 7.3.1.3. pre-build.local
2243 It is possible to configure the bulk build to perform certain site-specific
2244 tasks at the end of the pre-build stage. If the file pre-build.local exists in
2245 /usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the
2246 usual pre-build stage. An example use of pre-build.local is to have the line:
2248 echo "I do not have enough disk space to build this pig." \
2249 > misc/openoffice/$BROKENF
2251 to prevent the system from trying to build a particular package which requires
2252 nearly 3 GB of disk space.
2254 7.3.2. Other environmental considerations
2256 As /usr/pkg will be completely deleted at the start of bulk builds, make sure
2257 your login shell is placed somewhere else. Either drop it into /usr/local/bin
2258 (and adjust your login shell in the passwd file), or (re-)install it via
2259 pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that
2260 your current process won't die if the package is removed, you just can't start
2261 any new instances of the shell any more). Also, if you use NetBSD earlier than
2262 1.5, or you still want to use the pkgsrc version of ssh for some reason, be
2263 sure to install ssh before starting it from rc.local:
2265 (cd /usr/pkgsrc/security/ssh && make bulk-install)
2266 if [ -f /usr/pkg/etc/rc.d/sshd ]; then
2267 /usr/pkg/etc/rc.d/sshd
2270 Not doing so will result in you being not able to log in via ssh after the bulk
2271 build is finished or if the machine gets rebooted or crashes. You have been
2276 Make sure you don't need any of the packages still installed.
2280 During the bulk build, all packages, their configuration files and some more
2281 files from /var, /home and possibly other locations will be removed! So don't
2282 run a bulk build with privileges that might harm your system.
2284 Be sure to remove all other things that might interfere with builds, like some
2285 libs installed in /usr/local, etc. then become root and type:
2291 If for some reason your last build didn't complete (power failure, system
2292 panic, ...), you can continue it by running:
2294 # sh mk/bulk/build restart
2296 At the end of the bulk build, you will get a summary via mail, and find build
2297 logs in the directory specified by FTP in the build.conf file.
2301 The bulk builds consist of three steps:
2305 The script updates your pkgsrc tree via (anon)cvs, then cleans out any
2306 broken distfiles, and removes all packages installed.
2310 This is basically "make bulk-package" with an optimised order in which
2311 packages will be built. Packages that don't require other packages will be
2312 built first, and packages with many dependencies will be built later.
2316 Generates a report that's placed in the directory specified in the
2317 build.conf file named broken.html, a short version of that report will also
2318 be mailed to the build's admin.
2320 During the build, a list of broken packages will be compiled in /usr/pkgsrc
2321 /.broken (or .../.broken.${MACHINE} if OBJMACHINE is set), individual build
2322 logs of broken builds can be found in the package's directory. These files are
2323 used by the bulk-targets to mark broken builds to not waste time trying to
2324 rebuild them, and they can be used to debug these broken package builds later.
2326 7.3.5. Disk space requirements
2328 Currently, roughly the following requirements are valid for NetBSD 2.0/i386:
2330 * 10 GB - distfiles (NFS ok)
2332 * 8 GB - full set of all binaries (NFS ok)
2334 * 5 GB - temp space for compiling (local disk recommended)
2336 Note that all pkgs will be de-installed as soon as they are turned into a
2337 binary package, and that sources are removed, so there is no excessively huge
2338 demand to disk space. Afterwards, if the package is needed again, it will be
2339 installed via pkg_add(1) instead of building again, so there are no cycles
2340 wasted by recompiling.
2342 7.3.6. Setting up a sandbox for chrooted builds
2344 If you don't want all the packages nuked from a machine (rendering it useless
2345 for anything but pkg compiling), there is the possibility of doing the package
2346 bulk build inside a chroot environment.
2348 The first step is to set up a chroot sandbox, e.g. /usr/sandbox. This can be
2349 done by using null mounts, or manually.
2351 There is a shell script called pkgsrc/mk/bulk/mksandbox which will set up the
2352 sandbox environment using null mounts. It will also create a script called
2353 sandbox in the root of the sandbox environment, which will allow the null
2354 mounts to be activated using the sandbox mount command and deactivated using
2355 the sandbox umount command.
2357 To set up a sandbox environment by hand, after extracting all the sets from a
2358 NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in /usr/
2359 src/etc, be sure the following items are present and properly configured:
2363 # cp /netbsd /usr/sandbox
2367 # cd /usr/sandbox/dev ; sh MAKEDEV all
2369 3. /etc/resolv.conf (for security/smtpd and mail):
2371 # cp /etc/resolv.conf /usr/sandbox/etc
2373 4. Working(!) mail config (hostname, sendmail.cf):
2375 # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
2377 5. /etc/localtime (for security/smtpd):
2379 # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
2381 6. /usr/src (system sources, e. g. for sysutils/aperture):
2383 # ln -s ../disk1/cvs .
2384 # ln -s cvs/src-2.0 src
2386 7. Create /var/db/pkg (not part of default install):
2388 # mkdir /usr/sandbox/var/db/pkg
2390 8. Create /usr/pkg (not part of default install):
2392 # mkdir /usr/sandbox/usr/pkg
2394 9. Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:
2396 # cd /usr/sandbox/usr
2397 # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
2400 Do not mount/link this to the copy of your pkgsrc tree you do development
2401 in, as this will likely cause problems!
2403 10. Make /usr/sandbox/usr/pkgsrc/packages and .../distfiles point somewhere
2404 appropriate. NFS- and/or nullfs-mounts may come in handy!
2406 11. Edit mk.conf, see Section 7.3.1.2, "mk.conf".
2408 12. Adjust mk/bulk/build.conf to suit your needs.
2410 When the chroot sandbox is set up, you can start the build with the following
2413 # cd /usr/sandbox/usr/pkgsrc
2414 # sh mk/bulk/do-sandbox-build
2417 This will just jump inside the sandbox and start building. At the end of the
2418 build, mail will be sent with the results of the build. Created binary pkgs
2419 will be in /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/
2422 7.3.7. Building a partial set of packages
2424 In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk
2425 /bulk/build script may be used to build a subset of the packages contained in
2426 pkgsrc. By setting SPECIFIC_PKGS in mk.conf, the variables
2428 * SITE_SPECIFIC_PKGS
2430 * HOST_SPECIFIC_PKGS
2432 * GROUP_SPECIFIC_PKGS
2434 * USER_SPECIFIC_PKGS
2436 will define the set of packages which should be built. The bulk build code will
2437 also include any packages which are needed as dependencies for the explicitly
2440 One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
2441 periodically to have a complete set of the binary packages needed for your site
2442 available without the overhead of building extra packages that are not needed.
2444 7.3.8. Uploading results of a bulk build
2446 This section describes how pkgsrc developers can upload binary pkgs built by
2447 bulk builds to ftp.NetBSD.org.
2449 If you would like to automatically create checksum files for the binary
2450 packages you intend to upload, remember to set MKSUMS=yes in your mk/bulk/
2453 If you would like to PGP sign the checksum files (highly recommended!),
2454 remember to set SIGN_AS=username@NetBSD.org in your mk/bulk/build.conf. This
2455 will prompt you for your GPG password to sign the files before uploading
2458 Then, make sure that you have RSYNC_DST set properly in your mk/bulk/build.conf
2459 file, i.e. adjust it to something like one of the following:
2461 RSYNC_DST=ftp.NetBSD.org:/pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch/upload
2463 Please use appropriate values for "packages-20xxQy", "NetBSD-a.b.c" and "arch"
2464 here. If your login on ftp.NetBSD.org is different from your local login, write
2465 your login directly into the variable, e.g. my local account is "feyrer", but
2466 for my login "hubertf", I use:
2468 RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch/upload
2470 A separate upload directory is used here to allow "closing" the directory
2471 during upload. To do so, run the following command on ftp.NetBSD.org next:
2473 nbftp% mkdir -p -m 750 /pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch/upload
2475 Please note that /pub/NetBSD/packages is only appropriate for packages for the
2476 NetBSD operating system. Binary packages for other operating systems should go
2479 Before uploading the binary pkgs, ssh authentication needs to be set up. This
2480 example shows how to set up temporary keys for the root account inside the
2481 sandbox (assuming that no keys should be present there usually):
2483 # chroot /usr/sandbox
2484 chroot-# rm $HOME/.ssh/id-dsa*
2485 chroot-# ssh-keygen -t dsa
2486 chroot-# cat $HOME/.ssh/id-dsa.pub
2489 Now take the output of id-dsa.pub and append it to your ~/.ssh/authorized_keys
2490 file on ftp.NetBSD.org. You can remove the key after the upload is done!
2492 Next, test if your ssh connection really works:
2494 chroot-# ssh ftp.NetBSD.org date
2496 Use "-l yourNetBSDlogin" here as appropriate!
2498 Now after all this works, you can exit the sandbox and start the upload:
2501 # cd /usr/sandbox/usr/pkgsrc
2502 # sh mk/bulk/do-sandbox-upload
2505 The upload process may take quite some time. Use ls(1) or du(1) on the FTP
2506 server to monitor progress of the upload. The upload script will take care of
2507 not uploading restricted packages.
2509 After the upload has ended, first thing is to revoke ssh access:
2511 nbftp% vi ~/.ssh/authorized_keys
2514 Use whatever is needed to remove the key you've entered before! Last, move the
2515 uploaded packages out of the upload directory to have them accessible to
2518 nbftp% cd /pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch
2519 nbftp% mv upload/* .
2524 7.4. Running a pbulk-style bulk build
2526 Running a pbulk-style bulk build works roughly as follows:
2528 * First, build the pbulk infrastructure in a fresh pkgsrc location.
2530 * Then, build each of the packages from a clean installation directory using
2535 First, you need to create a pkgsrc installation for the pbulk infrastructure.
2536 No matter on which platform you are (even on NetBSD), you should bootstrap into
2537 its own directory. Let's take the directory /usr/pbulk or $HOME/pbulk for it.
2538 This installation will be bootstrapped and all the tools that are required for
2539 the bulk build will be installed there.
2542 $ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap
2543 $ rm -rf /tmp/pbulk-bootstrap
2545 Now the basic environment for the pbulk infrastructure is installed. The
2546 specific tools are still missing. This is a good time to edit the pkgsrc
2547 configuration file /usr/pbulk/etc/mk.conf to fit your needs. Typical things you
2550 * PKG_DEVELOPER=yes, to enable many consistency checks,
2552 * WRKOBJDIR=/tmp/pbulk-outer, to keep /usr/pkgsrc free from any
2555 * DISTDIR=/distfiles, to have only one directory in which all distfiles (for
2556 the infrastructure and for the actual packages) are downloaded,
2558 * ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual
2559 Free/Open Source licenses that are acceptable to you,
2561 * SKIP_LICENSE_CHECK=yes, to bypass the license checks.
2563 Now you are ready to build the rest of the pbulk infrastructure.
2566 $ /usr/pbulk/bin/bmake install
2567 $ rm -rf /tmp/pbulk-outer
2569 Now the pbulk infrastructure is built and installed. It still needs to be
2570 configured, and after some more preparation, we will be able to start the real
2573 7.4.2. Configuration
2575 TODO; see pkgsrc/doc/HOWTO-pbulk for more information.
2577 TODO: continue writing
2579 7.5. Creating a multiple CD-ROM packages collection
2581 After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
2582 of the resulting binary packages to assist in installing packages on other
2583 machines. The pkgtools/cdpack package provides a simple tool for creating the
2584 ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
2585 keeps all the dependencies for a given package on the same CD as that package.
2587 7.5.1. Example of cdpack
2589 Complete documentation for cdpack is found in the cdpack(1) man page. The
2590 following short example assumes that the binary packages are left in /usr/
2591 pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
2595 # pkg_add /usr/pkgsrc/packages/All/cdpack
2596 # cdpack /usr/pkgsrc/packages/All /u2/images
2599 If you wish to include a common set of files (COPYRIGHT, README, etc.) on each
2600 CD in the collection, then you need to create a directory which contains these
2604 # echo "This is a README" > /tmp/common/README
2605 # echo "Another file" > /tmp/common/COPYING
2606 # mkdir /tmp/common/bin
2607 # echo "#!/bin/sh" > /tmp/common/bin/myscript
2608 # echo "echo Hello world" >> /tmp/common/bin/myscript
2609 # chmod 755 /tmp/common/bin/myscript
2612 Now create the images:
2614 # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
2616 Each image will contain README, COPYING, and bin/myscript in their root
2619 Chapter 8. Directory layout of the installed files
2623 8.1. File system layout in ${LOCALBASE}
2624 8.2. File system layout in ${VARBASE}
2626 The files that are installed by pkgsrc are organized in a way that is similar
2627 to what you find in the /usr directory of the base system. But some details are
2628 different. This is because pkgsrc initially came from FreeBSD and had adopted
2629 its file system hierarchy. Later it was largely influenced by NetBSD. But no
2630 matter which operating system you are using pkgsrc with, you can expect the
2631 same layout for pkgsrc.
2633 There are mainly four root directories for pkgsrc, which are all configurable
2634 in the bootstrap/bootstrap script. When pkgsrc has been installed as root, the
2635 default locations are:
2638 PKG_SYSCONFBASE= /usr/pkg/etc
2640 PKG_DBDIR= /var/db/pkg
2642 In unprivileged mode (when pkgsrc has been installed as any other user), the
2643 default locations are:
2645 LOCALBASE= ${HOME}/pkg
2646 PKG_SYSCONFBASE= ${HOME}/pkg/etc
2647 VARBASE= ${HOME}/pkg/var
2648 PKG_DBDIR= ${HOME}/pkg/var/db/pkg
2650 What these four directories are for, and what they look like is explained
2653 * LOCALBASE corresponds to the /usr directory in the base system. It is the "
2654 main" directory where the files are installed and contains the well-known
2655 subdirectories like bin, include, lib, share and sbin.
2657 * VARBASE corresponds to /var in the base system. Some programs (especially
2658 games, network daemons) need write access to it during normal operation.
2660 * PKG_SYSCONFDIR corresponds to /etc in the base system. It contains
2661 configuration files of the packages, as well as pkgsrc's mk.conf itself.
2663 8.1. File system layout in ${LOCALBASE}
2665 The following directories exist in a typical pkgsrc installation in $
2670 Contains executable programs that are intended to be directly used by the
2675 Contains files for the emulation layers of various other operating systems,
2676 especially for NetBSD.
2678 etc (the usual location of ${PKG_SYSCONFDIR})
2680 Contains the configuration files.
2684 Contains headers for the C and C++ programming languages.
2688 Contains GNU info files of various packages.
2692 Contains shared and static libraries.
2696 Contains data files that don't change after installation. Other data files
2697 belong into ${VARBASE}.
2701 Contains programs that are not intended to be used by end users, such as
2702 helper programs or network daemons.
2706 Contains programs that are intended to be executed as CGI scripts by a web
2709 man (the usual value of ${PKGMANDIR})
2711 Contains brief documentation in form of manual pages.
2715 Contains programs that are intended to be used only by the super-user.
2719 Contains platform-independent data files that don't change after
2724 Contains documentation files provided by the packages.
2728 Contains example files provided by the packages. Among others, the original
2729 configuration files are saved here and copied to ${PKG_SYSCONFDIR} during
2734 Contains the original files for rc.d scripts.
2736 var (the usual location of ${VARBASE})
2738 Contains files that may be modified after installation.
2740 8.2. File system layout in ${VARBASE}
2742 db/pkg (the usual location of ${PKG_DBDIR})
2744 Contains information about the currently installed packages.
2748 Contains highscore files.
2756 Contains informational files about daemons that are currently running.
2758 Chapter 9. Frequently Asked Questions
2762 9.1. Are there any mailing lists for pkg-related discussion?
2763 9.2. Where's the pkgviews documentation?
2764 9.3. Utilities for package management (pkgtools)
2765 9.4. How to use pkgsrc as non-root
2766 9.5. How to resume transfers when fetching distfiles?
2767 9.6. How can I install/use modular X.org from pkgsrc?
2768 9.7. How to fetch files from behind a firewall
2769 9.8. How do I tell make fetch to do passive FTP?
2770 9.9. How to fetch all distfiles at once
2771 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
2772 9.11. What does "Could not find bsd.own.mk" mean?
2773 9.12. Using 'sudo' with pkgsrc
2774 9.13. How do I change the location of configuration files?
2775 9.14. Automated security checks
2776 9.15. Why do some packages ignore my CFLAGS?
2777 9.16. A package does not build. What shall I do?
2778 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
2781 This section contains hints, tips & tricks on special things in pkgsrc that we
2782 didn't find a better place for in the previous chapters, and it contains items
2783 for both pkgsrc users and developers.
2785 9.1. Are there any mailing lists for pkg-related discussion?
2787 The following mailing lists may be of interest to pkgsrc users:
2789 * pkgsrc-users: This is a general purpose list for most issues regarding
2790 pkgsrc, regardless of platform, e.g. soliciting user help for pkgsrc
2791 configuration, unexpected build failures, using particular packages,
2792 upgrading pkgsrc installations, questions regarding the pkgsrc release
2793 branches, etc. General announcements or proposals for changes that impact
2794 the pkgsrc user community, e.g. major infrastructure changes, new features,
2795 package removals, etc., may also be posted.
2797 * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and
2800 * pkgsrc-changes: This list is for those who are interested in getting a
2801 commit message for every change committed to pkgsrc. It is also available
2802 in digest form, meaning one daily message containing all commit messages
2803 for changes to the package source tree in that 24 hour period.
2807 % echo subscribe listname | mail majordomo@NetBSD.org
2809 Archives for all these mailing lists are available from http://
2810 mail-index.NetBSD.org/.
2812 9.2. Where's the pkgviews documentation?
2814 Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's
2815 guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.
2817 9.3. Utilities for package management (pkgtools)
2819 The directory pkgsrc/pkgtools contains a number of useful utilities for both
2820 users and developers of pkgsrc. This section attempts only to make the reader
2821 aware of the utilities and when they might be useful, and not to duplicate the
2822 documentation that comes with each package.
2824 Utilities used by pkgsrc (automatically installed when needed):
2826 * pkgtools/x11-links: Symlinks for use by buildlink.
2828 OS tool augmentation (automatically installed when needed):
2830 * pkgtools/digest: Calculates various kinds of checksums (including SHA1).
2832 * pkgtools/libnbcompat: Compatibility library for pkgsrc tools.
2834 * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree.
2836 * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or
2837 for use on operating systems where pkg_install is not present.
2839 Utilities used by pkgsrc (not automatically installed):
2841 * pkgtools/pkg_tarup: Create a binary package from an already-installed
2842 package. Used by make replace to save the old package.
2844 * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch
2845 distfiles from multiple locations. It currently supports the following
2846 methods: multiple CD-ROMs and network FTP/HTTP connections.
2848 * pkgtools/xpkgwedge: Put X11 packages someplace else (enabled by default).
2850 * devel/cpuflags: Determine the best compiler flags to optimise code for your
2851 current CPU and compiler.
2853 Utilities for keeping track of installed packages, being up to date, etc:
2855 * pkgtools/pkg_chk: Reports on packages whose installed versions do not match
2856 the latest pkgsrc entries.
2858 * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a
2859 strategy for updating.
2861 * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses
2864 * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors.
2866 * pkgtools/lintpkgsrc: The lintpkgsrc(1) program does various checks on the
2867 complete pkgsrc system.
2869 * pkgtools/pkgsurvey: Report what packages you have installed.
2871 Utilities for people maintaining or creating individual packages:
2873 * pkgtools/pkgdiff: Automate making and maintaining patches for a package
2874 (includes pkgdiff, pkgvi, mkpatches, etc.).
2876 * pkgtools/rpm2pkg, pkgtools/url2pkg: Aids in converting to pkgsrc.
2878 * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package.
2880 Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
2882 * pkgtools/pkg_comp: Build packages in a chrooted area.
2884 * pkgtools/libkver: Spoof kernel version for chrooted cross builds.
2886 9.4. How to use pkgsrc as non-root
2888 If you want to use pkgsrc as non-root user, you can set some variables to make
2889 pkgsrc work under these conditions. At the very least, you need to set
2890 UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple
2891 related variables to allow installation of packages as non-root.
2893 In case the defaults are not enough, you may want to tune some other variables
2894 used. For example, if the automatic user/group detection leads to incorrect
2895 values (or not the ones you would like to use), you can change them by setting
2896 UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively.
2898 As regards bootstrapping, please note that the bootstrap script will ease
2899 non-root configuration when given the "--ignore-user-check" flag, as it will
2900 choose and use multiple default directories under ~/pkg as the installation
2901 targets. These directories can be overridden by the "--prefix" flag provided by
2902 the script, as well as some others that allow finer tuning of the tree layout.
2904 9.5. How to resume transfers when fetching distfiles?
2906 By default, resuming transfers in pkgsrc is disabled, but you can enable this
2907 feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
2908 a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.
2910 You can also use a different program than the default ftp(1) by changing the
2911 FETCH_USING variable. You can specify the program by using of ftp, fetch, wget
2912 or curl. Alternatively, fetching can be disabled by using the value manual. A
2913 value of custom disables the system defaults and dependency tracking for the
2914 fetch program. In that case you have to provide FETCH_CMD, FETCH_BEFORE_ARGS,
2915 FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.
2917 For example, if you want to use wget to download, you'll have to use something
2922 9.6. How can I install/use modular X.org from pkgsrc?
2924 If you want to use modular X.org from pkgsrc instead of your system's own X11
2925 (/usr/X11R6, /usr/openwin, ...) you will have to add the following line into
2932 The DragonFly operating system defaults to using modular X.org from pkgsrc.
2934 9.7. How to fetch files from behind a firewall
2936 If you are sitting behind a firewall which does not allow direct connections to
2937 Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
2938 is done using an environment variable in the form of a URL, e.g. in Amdahl, the
2939 machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
2940 the proxy port number. So the proxy environment variables are:
2942 ftp_proxy=ftp://orpheus.amdahl.com:80/
2943 http_proxy=http://orpheus.amdahl.com:80/
2945 9.8. How do I tell make fetch to do passive FTP?
2947 This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
2948 FETCH_CMD is assigned the first available command from the following list:
2950 * ${LOCALBASE}/bin/ftp
2954 On a default NetBSD installation, this will be /usr/bin/ftp, which
2955 automatically tries passive connections first, and falls back to active
2956 connections if the server refuses to do passive. For the other tools, add the
2957 following to your mk.conf file: PASSIVE_FETCH=1.
2959 Having that option present will prevent /usr/bin/ftp from falling back to
2962 9.9. How to fetch all distfiles at once
2964 You would like to download all the distfiles in a single batch from work or
2965 university, where you can't run a make fetch. There is an archive of distfiles
2966 on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
2968 The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
2969 subdirectories, carry the resulting list to your machine at work/school and use
2970 it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work,
2971 don't forget to set FETCH_CMD to something that fetches a URL:
2976 % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
2977 % scp /tmp/fetch.sh work:/tmp
2983 then tar up /tmp/distfiles and take it home.
2985 If you have a machine running NetBSD, and you want to get all distfiles (even
2986 ones that aren't for your machine architecture), you can do so by using the
2987 above-mentioned make fetch-list approach, or fetch the distfiles directly by
2990 % make mirror-distfiles
2992 If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can get
2993 everything by running:
2995 % make fetch NO_SKIP=yes
2997 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
2999 When compiling the pkgtools/pkg_install package, you get the error from make
3000 that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
3001 that you don't have installed the "text" set (nroff, ...) from the NetBSD base
3002 distribution on your machine. It is recommended to do that to format man pages.
3004 In the case of the pkgtools/pkg_install package, you can get away with setting
3005 NOMAN=YES either in the environment or in mk.conf.
3007 9.11. What does "Could not find bsd.own.mk" mean?
3009 You didn't install the compiler set, comp.tgz, when you installed your NetBSD
3010 machine. Please get and install it, by extracting it in /:
3013 # tar --unlink -zxvpf .../comp.tgz
3015 comp.tgz is part of every NetBSD release. Get the one that corresponds to your
3016 release (determine via uname -r).
3018 9.12. Using 'sudo' with pkgsrc
3020 When installing packages as non-root user and using the just-in-time su(1)
3021 feature of pkgsrc, it can become annoying to type in the root password for each
3022 required package installed. To avoid this, the sudo package can be used, which
3023 does password caching over a limited time. To use it, install sudo (either as
3024 binary package or from security/sudo) and then put the following into your
3025 mk.conf, somewhere after the definition of the LOCALBASE variable:
3027 .if exists(${LOCALBASE}/bin/sudo)
3028 SU_CMD= ${LOCALBASE}/bin/sudo /bin/sh -c
3031 9.13. How do I change the location of configuration files?
3033 As the system administrator, you can choose where configuration files are
3034 installed. The default settings make all these files go into ${PREFIX}/etc or
3035 some of its subdirectories; this may be suboptimal depending on your
3036 expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine
3037 configuration of the provided packages).
3039 In order to change the defaults, you can modify the PKG_SYSCONFBASE variable
3040 (in mk.conf) to point to your preferred configuration directory; some common
3041 examples include /etc or /etc/pkg.
3043 Furthermore, you can change this value on a per-package basis by setting the
3044 PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
3045 matches the name of the package you would like to modify, that is, the contents
3048 Note that after changing these settings, you must rebuild and reinstall any
3051 9.14. Automated security checks
3053 Please be aware that there can often be bugs in third-party software, and some
3054 of these bugs can leave a machine vulnerable to exploitation by attackers. In
3055 an effort to lessen the exposure, the NetBSD packages team maintains a database
3056 of known-exploits to packages which have at one time been included in pkgsrc.
3057 The database can be downloaded automatically, and a security audit of all
3058 packages installed on a system can take place. To do this, refer to the
3059 following two tools (installed as part of the pkgtools/pkg_install package):
3061 1. pkg_admin fetch-pkg-vulnerabilities, an easy way to download a list of the
3062 security vulnerabilities information. This list is kept up to date by the
3063 NetBSD security officer and the NetBSD packages team, and is distributed
3064 from the NetBSD ftp server:
3066 ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities
3068 2. pkg_admin audit, an easy way to audit the current machine, checking each
3069 known vulnerability. If a vulnerable package is installed, it will be shown
3070 by output to stdout, including a description of the type of vulnerability,
3071 and a URL containing more information.
3073 Use of these tools is strongly recommended! After "pkg_install" is installed,
3074 please read the package's message, which you can get by running pkg_info -D
3077 If this package is installed, pkgsrc builds will use it to perform a security
3078 check before building any package. See Section 5.2, "Variables affecting the
3079 build process" for ways to control this check.
3081 9.15. Why do some packages ignore my CFLAGS?
3083 When you add your own preferences to the CFLAGS variable in your mk.conf, these
3084 flags are passed in environment variables to the ./configure scripts and to
3085 make(1). Some package authors ignore the CFLAGS from the environment variable
3086 by overriding them in the Makefiles of their package.
3088 Currently there is no solution to this problem. If you really need the package
3089 to use your CFLAGS you should run make patch in the package directory and then
3090 inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly.
3091 Usually you can remove these lines. But be aware that some "smart" programmers
3092 write so bad code that it only works for the specific combination of CFLAGS
3095 9.16. A package does not build. What shall I do?
3097 1. Make sure that your copy of pkgsrc is consistent. A case that occurs often
3098 is that people only update pkgsrc in parts, because of performance reasons.
3099 Since pkgsrc is one large system, not a collection of many small systems,
3100 there are sometimes changes that only work when the whole pkgsrc tree is
3103 2. Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or "
3104 >>>>>>" in all your pkgsrc files.
3106 3. Make sure that you don't have old copies of the packages extracted. Run
3107 make clean clean-depends to verify this.
3109 4. If the problem still exists, write a mail to the pkgsrc-users mailing list.
3111 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
3114 You have modified a file from pkgsrc, and someone else has modified that same
3115 file afterwards in the CVS repository. Both changes are in the same region of
3116 the file, so when you updated pkgsrc, the cvs command marked the conflicting
3117 changes in the file. Because of these markers, the file is no longer a valid
3120 Have a look at that file, and if you don't need your local changes anymore, you
3121 can remove that file and run cvs -q update -dP in that directory to download
3122 the current version.
3124 Part II. The pkgsrc developer's guide
3126 This part of the book deals with creating and modifying packages. It starts
3127 with a "HOWTO"-like guide on creating a new package. The remaining chapters are
3128 more like a reference manual for pkgsrc.
3132 10. Creating a new pkgsrc package from scratch
3134 10.1. Common types of packages
3136 10.1.1. Perl modules
3137 10.1.2. KDE applications
3138 10.1.3. Python modules and programs
3142 10.2.1. How the www/nvu package came into pkgsrc
3144 11. Package components - files, directories and contents
3150 11.3.1. Structure of a single patch file
3151 11.3.2. Creating patch files
3152 11.3.3. Sources where the patch files come from
3153 11.3.4. Patching guidelines
3154 11.3.5. Feedback to the author
3156 11.4. Other mandatory files
3157 11.5. Optional files
3159 11.5.1. Files affecting the binary package
3160 11.5.2. Files affecting the build process
3161 11.5.3. Files affecting nothing at all
3166 12. Programming in Makefiles
3169 12.2. Makefile variables
3171 12.2.1. Naming conventions
3175 12.3.1. Adding things to a list
3176 12.3.2. Converting an internal list into an external list
3177 12.3.3. Passing variables to a shell command
3178 12.3.4. Quoting guideline
3179 12.3.5. Workaround for a bug in BSD Make
3184 13.2. Semi-automatic PLIST generation
3185 13.3. Tweaking output of make print-PLIST
3186 13.4. Variable substitution in PLIST
3187 13.5. Man page compression
3188 13.6. Changing PLIST source with PLIST_SRC
3189 13.7. Platform-specific and differing PLISTs
3190 13.8. Sharing directories between packages
3192 14. Buildlink methodology
3194 14.1. Converting packages to use buildlink3
3195 14.2. Writing buildlink3.mk files
3197 14.2.1. Anatomy of a buildlink3.mk file
3198 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
3200 14.3. Writing builtin.mk files
3202 14.3.1. Anatomy of a builtin.mk file
3203 14.3.2. Global preferences for native or pkgsrc software
3205 15. The pkginstall framework
3207 15.1. Files and directories outside the installation prefix
3209 15.1.1. Directory manipulation
3210 15.1.2. File manipulation
3212 15.2. Configuration files
3214 15.2.1. How PKG_SYSCONFDIR is set
3215 15.2.2. Telling the software where configuration files are
3216 15.2.3. Patching installations
3217 15.2.4. Disabling handling of configuration files
3219 15.3. System startup scripts
3221 15.3.1. Disabling handling of system startup scripts
3223 15.4. System users and groups
3226 15.5.1. Disabling shell registration
3230 15.6.1. Disabling automatic update of the fonts databases
3232 16. Options handling
3234 16.1. Global default options
3235 16.2. Converting packages to use bsd.options.mk
3237 16.4. Determining the options of dependencies
3239 17. The build process
3242 17.2. Program location
3243 17.3. Directories used during the build process
3244 17.4. Running a phase
3245 17.5. The fetch phase
3247 17.5.1. What to fetch and where to get it from
3248 17.5.2. How are the files fetched?
3250 17.6. The checksum phase
3251 17.7. The extract phase
3252 17.8. The patch phase
3253 17.9. The tools phase
3254 17.10. The wrapper phase
3255 17.11. The configure phase
3256 17.12. The build phase
3257 17.13. The test phase
3258 17.14. The install phase
3259 17.15. The package phase
3261 17.17. Other helpful targets
3263 18. Tools needed for building or running
3265 18.1. Tools for pkgsrc builds
3266 18.2. Tools needed by packages
3267 18.3. Tools provided by platforms
3268 18.4. Questions regarding the tools
3270 19. Making your package work
3272 19.1. General operation
3274 19.1.1. Portability of packages
3275 19.1.2. How to pull in user-settable variables from mk.conf
3276 19.1.3. User interaction
3277 19.1.4. Handling licenses
3278 19.1.5. Restricted packages
3279 19.1.6. Handling dependencies
3280 19.1.7. Handling conflicts with other packages
3281 19.1.8. Packages that cannot or should not be built
3282 19.1.9. Packages which should not be deleted, once installed
3283 19.1.10. Handling packages with security problems
3284 19.1.11. How to handle incrementing versions when fixing an existing
3286 19.1.12. Substituting variable text in the package files (the SUBST
3289 19.2. Fixing problems in the fetch phase
3291 19.2.1. Packages whose distfiles aren't available for plain downloading
3292 19.2.2. How to handle modified distfiles with the 'old' name
3294 19.3. Fixing problems in the configure phase
3296 19.3.1. Shared libraries - libtool
3297 19.3.2. Using libtool on GNU packages that already support libtool
3298 19.3.3. GNU Autoconf/Automake
3300 19.4. Programming languages
3302 19.4.1. C, C++, and Fortran
3304 19.4.3. Packages containing perl scripts
3305 19.4.4. Other programming languages
3307 19.5. Fixing problems in the build phase
3309 19.5.1. Compiling C and C++ code conditionally
3310 19.5.2. How to handle compiler bugs
3311 19.5.3. Undefined reference to "..."
3312 19.5.4. Running out of memory
3314 19.6. Fixing problems in the install phase
3316 19.6.1. Creating needed directories
3317 19.6.2. Where to install documentation
3318 19.6.3. Installing highscore files
3319 19.6.4. Adding DESTDIR support to packages
3320 19.6.5. Packages with hardcoded paths to other interpreters
3321 19.6.6. Packages installing perl modules
3322 19.6.7. Packages installing info files
3323 19.6.8. Packages installing man pages
3324 19.6.9. Packages installing GConf data files
3325 19.6.10. Packages installing scrollkeeper/rarian data files
3326 19.6.11. Packages installing X11 fonts
3327 19.6.12. Packages installing GTK2 modules
3328 19.6.13. Packages installing SGML or XML data
3329 19.6.14. Packages installing extensions to the MIME database
3330 19.6.15. Packages using intltool
3331 19.6.16. Packages installing startup scripts
3332 19.6.17. Packages installing TeX modules
3333 19.6.18. Packages supporting running binaries in emulation
3334 19.6.19. Packages installing hicolor theme icons
3335 19.6.20. Packages installing desktop files
3337 19.7. Marking packages as having problems
3340 21. Submitting and Committing
3342 21.1. Submitting binary packages
3343 21.2. Submitting source packages (for non-NetBSD-developers)
3344 21.3. General notes when adding, updating, or removing packages
3345 21.4. Committing: Importing a package into CVS
3346 21.5. Updating a package to a newer version
3347 21.6. Renaming a package in pkgsrc
3348 21.7. Moving a package in pkgsrc
3350 22. Frequently Asked Questions
3351 23. GNOME packaging and porting
3354 23.2. Packaging a GNOME application
3355 23.3. Updating GNOME to a newer version
3356 23.4. Patching guidelines
3358 Chapter 10. Creating a new pkgsrc package from scratch
3362 10.1. Common types of packages
3364 10.1.1. Perl modules
3365 10.1.2. KDE applications
3366 10.1.3. Python modules and programs
3370 10.2.1. How the www/nvu package came into pkgsrc
3372 When you find a package that is not yet in pkgsrc, you most likely have a URL
3373 from where you can download the source code. Starting with this URL, creating a
3374 package involves only a few steps.
3376 1. First, install the packages pkgtools/url2pkg and pkgtools/pkglint.
3378 2. Then, choose one of the top-level directories as the category in which you
3379 want to place your package. You can also create a directory of your own
3380 (maybe called local). In that category directory, create another directory
3381 for your package and change into it.
3383 3. Run the program url2pkg, which will ask you for a URL. Enter the URL of the
3384 distribution file (in most cases a .tar.gz file) and watch how the basic
3385 ingredients of your package are created automatically. The distribution
3386 file is extracted automatically to fill in some details in the Makefile
3387 that would otherwise have to be done manually.
3389 4. Examine the extracted files to determine the dependencies of your package.
3390 Ideally, this is mentioned in some README file, but things may differ. For
3391 each of these dependencies, look where it exists in pkgsrc, and if there is
3392 a file called buildlink3.mk in that directory, add a line to your package
3393 Makefile which includes that file just before the last line. If the
3394 buildlink3.mk file does not exist, add a DEPENDS line to the Makefile,
3395 which specifies the version of the dependency and where it can be found in
3396 pkgsrc. This line should be placed in the third paragraph. If the
3397 dependency is only needed for building the package, but not when using it,
3398 use BUILD_DEPENDS instead of DEPENDS. Your package may then look like this:
3402 BUILD_DEPENDS+= lua>=5.0:../../lang/lua
3403 DEPENDS+= screen-[0-9]*:../../misc/screen
3404 DEPENDS+= screen>=4.0:../../misc/screen
3408 .include "../../category/package/buildlink3.mk"
3409 .include "../../devel/glib2/buildlink3.mk"
3410 .include "../../mk/bsd.pkg.mk"
3412 5. Run pkglint to see what things still need to be done to make your package a
3413 "good" one. If you don't know what pkglint's warnings want to tell you, try
3414 pkglint --explain or pkglint -e, which outputs additional explanations.
3416 6. In many cases the package is not yet ready to build. You can find
3417 instructions for the most common cases in the next section, Section 10.1,
3418 "Common types of packages". After you have followed the instructions over
3419 there, you can hopefully continue here.
3421 7. Run bmake clean to clean the working directory from the extracted files.
3422 Besides these files, a lot of cache files and other system information has
3423 been saved in the working directory, which may become wrong after you
3424 edited the Makefile.
3426 8. Now, run bmake to build the package. For the various things that can go
3427 wrong in this phase, consult Chapter 19, Making your package work.
3429 9. When the package builds fine, the next step is to install the package. Run
3430 bmake install and hope that everything works.
3432 10. Up to now, the file PLIST, which contains a list of the files that are
3433 installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to
3434 generate a probably correct list. Check the file using your preferred text
3435 editor to see if the list of files looks plausible.
3437 11. Run pkglint again to see if the generated PLIST contains garbage or not.
3439 12. When you ran bmake install, the package has been registered in the database
3440 of installed files, but with an empty list of files. To fix this, run bmake
3441 deinstall and bmake install again. Now the package is registered with the
3442 list of files from PLIST.
3444 13. Run bmake package to create a binary package from the set of installed
3447 10.1. Common types of packages
3449 10.1.1. Perl modules
3451 Simple Perl modules are handled automatically by url2pkg, including
3454 10.1.2. KDE applications
3456 KDE applications should always include meta-pkgs/kde3/kde3.mk, which contains
3457 numerous settings that are typical of KDE packages.
3459 10.1.3. Python modules and programs
3461 Python modules and programs packages are easily created using a set of
3462 predefined variables.
3464 Most Python packages use either "distutils" or easy-setup ("eggs"). If the
3465 software uses "distutils", set the PYDISTUTILSPKG variable to "yes" so pkgsrc
3466 will make use of this framework. "distutils" uses a script called setup.py, if
3467 the "distutils" driver is not called setup.py, set the PYSETUP variable to the
3470 If the default Python versions are not supported by the software, set the
3471 PYTHON_VERSIONS_ACCEPTED variable to the Python versions the software is known
3472 to work with, from the most recent to the older one, e.g.
3474 PYTHON_VERSIONS_ACCEPTED= 25 24
3476 If the packaged software is a Python module, include "../../lang/python/
3477 extension.mk". In this case, the package directory should be called "
3478 py-software" and PKGNAME should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.
3480 DISTNAME= foopymodule-1.2.10
3481 PKGNAME= ${PYPKGPREFIX}-${DISTNAME}
3483 If it is an application, also include "../../lang/python/application.mk" before
3486 If the packaged software, either it is an application or a module, is
3487 egg-aware, you only need to include "../../lang/python/egg.mk".
3489 In order to correctly set the path to the Python interpreter, use the
3490 REPLACE_PYTHON variable and set it to the list of files that must be corrected.
3493 REPLACE_PYTHON= ${WRKSRC}/*.py
3497 10.2.1. How the www/nvu package came into pkgsrc
3499 10.2.1.1. The initial package
3501 Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet
3502 been imported into pkgsrc. As the description says it has to do with the web,
3503 the obvious choice for the category is "www".
3508 The web site says that the sources are available as a tar file, so I fed that
3509 URL to the url2pkg program:
3511 $ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
3513 My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the
3514 package name should not have the word "sources" in it. I also filled in the
3515 MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like
3521 DISTNAME= nvu-1.0-sources
3524 MASTER_SITES= http://cvs.nvu.com/download/
3525 EXTRACT_SUFX= .tar.bz2
3527 MAINTAINER= rillig@NetBSD.org
3528 HOMEPAGE= http://cvs.nvu.com/
3529 COMMENT= Web Authoring System
3531 # url2pkg-marker (please do not remove this line.)
3532 .include "../../mk/bsd.pkg.mk"
3534 Then, I quit the editor and watched pkgsrc downloading a large source archive:
3536 url2pkg> Running "make makesum" ...
3537 => Required installed package digest>=20010302: digest-20060826 found
3538 => Fetching nvu-1.0-sources.tar.bz2
3539 Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
3540 100% |*************************************| 28992 KB 150.77 KB/s00:00 ETA
3541 29687976 bytes retrieved in 03:12 (150.77 KB/s)
3542 url2pkg> Running "make extract" ...
3543 => Required installed package digest>=20010302: digest-20060826 found
3544 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
3545 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
3546 work.bacc -> /tmp/roland/pkgsrc/www/nvu/work.bacc
3547 ===> Installing dependencies for nvu-1.0
3548 ===> Overriding tools for nvu-1.0
3549 ===> Extracting for nvu-1.0
3550 url2pkg> Adjusting the Makefile.
3552 Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done!
3554 Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)
3556 10.2.1.2. Fixing all kinds of problems to make the package work
3558 Now that the package has been extracted, let's see what's inside it. The
3559 package has a README.txt, but that only says something about mozilla, so it's
3560 probably useless for seeing what dependencies this package has. But since there
3561 is a GNU configure script in the package, let's hope that it will complain
3562 about everything it needs.
3565 => Required installed package digest>=20010302: digest-20060826 found
3566 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
3567 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
3568 ===> Patching for nvu-1.0
3569 ===> Creating toolchain wrappers for nvu-1.0
3570 ===> Configuring for nvu-1.0
3572 configure: error: Perl 5.004 or higher is required.
3574 WARNING: Please add USE_TOOLS+=perl to the package Makefile.
3577 That worked quite well. So I opened the package Makefile in my editor, and
3578 since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
3579 dependencies of the package have changed now, and since a perl wrapper is
3580 automatically installed in the "tools" phase, I need to build the package from
3584 ===> Cleaning for nvu-1.0
3587 *** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \
3588 GNU Make. You will not be able to build Mozilla without GNU Make.
3591 So I added "gmake" to the USE_TOOLS line and tried again (from scratch).
3594 checking for GTK - version >= 1.2.0... no
3595 *** Could not run GTK test program, checking why...
3598 Now to the other dependencies. The first question is: Where is the GTK package
3607 $ echo ../../*/gtk2/bui*
3608 ../../x11/gtk2/buildlink3.mk
3610 The first try was definitely too broad. The second one had exactly one result,
3611 which is very good. But there is one pitfall with GNOME packages. Before GNOME
3612 2 had been released, there were already many GNOME 1 packages in pkgsrc. To be
3613 able to continue to use these packages, the GNOME 2 packages were imported as
3614 separate packages, and their names usually have a "2" appended. So I checked
3615 whether this was the case here, and indeed it was.
3617 Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
3618 easy. I just inserted an .include line before the last line of the package
3619 Makefile, so that it now looks like this:
3622 .include "../../x11/gtk2/buildlink3.mk"
3623 .include "../../mk/bsd.pkg.mk
3625 After another bmake clean && bmake, the answer was:
3628 checking for gtk-config... /home/roland/pkg/bin/gtk-config
3629 checking for GTK - version >= 1.2.0... no
3630 *** Could not run GTK test program, checking why...
3631 *** The test program failed to compile or link. See the file config.log for the
3632 *** exact error that occured. This usually means GTK was incorrectly installed
3633 *** or that you have moved GTK since it was installed. In the latter case, you
3634 *** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config
3635 configure: error: Test for GTK failed.
3638 In this particular case, the assumption that "every package prefers GNOME 2"
3639 had been wrong. The first of the lines above told me that this package really
3640 wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
3641 it would have looked for pkg-config instead of gtk-config. So I changed the x11
3642 /gtk2 to x11/gtk in the package Makefile, and tried again.
3645 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
3646 In file included from xpidl.c:42:
3647 xpidl.h:53:24: libIDL/IDL.h: No such file or directory
3648 In file included from xpidl.c:42:
3649 xpidl.h:132: error: parse error before "IDL_ns"
3652 The package still does not find all of its dependencies. Now the question is:
3653 Which package provides the libIDL/IDL.h header file?
3655 $ echo ../../*/*idl*
3656 ../../devel/py-idle ../../wip/idled ../../x11/acidlaunch
3657 $ echo ../../*/*IDL*
3660 Let's take the one from the second try. So I included the ../../net/libIDL/
3661 buildlink3.mk file and tried again. But the error didn't change. After digging
3662 through some of the code, I concluded that the build process of the package was
3663 broken and couldn't have ever worked, but since the Mozilla source tree is
3664 quite large, I didn't want to fix it. So I added the following to the package
3665 Makefile and tried again:
3667 CPPFLAGS+= -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0
3668 BUILDLINK_TRANSFORM+= -l:IDL:IDL-2
3670 The latter line is needed because the package expects the library libIDL.so,
3671 but only libIDL-2.so is available. So I told the compiler wrapper to rewrite
3674 The next problem was related to a recent change of the FreeType interface. I
3675 looked up in www/seamonkey which patch files were relevant for this issue and
3676 copied them to the patches directory. Then I retried, fixed the patches so that
3677 they applied cleanly and retried again. This time, everything worked.
3679 10.2.1.3. Installing the package
3681 $ bmake CHECK_FILES=no install
3683 $ bmake print-PLIST >PLIST
3687 Chapter 11. Package components - files, directories and contents
3695 11.3.1. Structure of a single patch file
3696 11.3.2. Creating patch files
3697 11.3.3. Sources where the patch files come from
3698 11.3.4. Patching guidelines
3699 11.3.5. Feedback to the author
3701 11.4. Other mandatory files
3702 11.5. Optional files
3704 11.5.1. Files affecting the binary package
3705 11.5.2. Files affecting the build process
3706 11.5.3. Files affecting nothing at all
3711 Whenever you're preparing a package, there are a number of files involved which
3712 are described in the following sections.
3716 Building, installation and creation of a binary package are all controlled by
3717 the package's Makefile. The Makefile describes various things about a package,
3718 for example from where to get it, how to configure, build, and install it.
3720 A package Makefile contains several sections that describe the package.
3722 In the first section there are the following variables, which should appear
3723 exactly in the order given here. The order and grouping of the variables is
3724 mostly historical and has no further meaning.
3726 * DISTNAME is the basename of the distribution file to be downloaded from the
3729 * PKGNAME is the name of the package, as used by pkgsrc. You only need to
3730 provide it if DISTNAME (which is the default) is not a good name for the
3731 package in pkgsrc. Usually it is the pkgsrc directory name together with
3732 the version number. It must match the regular expression ^[A-Za-z0-9]
3733 [A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains
3734 only letters, digits, dashes, underscores, dots and plus signs.
3736 * SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't
3737 unique on a SVR4 system. The default is PKGNAME, which may be shortened
3738 when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not
3739 produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME
3740 is limited to 5 characters.
3742 * CATEGORIES is a list of categories which the package fits in. You can
3743 choose any of the top-level directories of pkgsrc for it.
3745 Currently the following values are available for CATEGORIES. If more than
3746 one is used, they need to be separated by spaces:
3748 archivers cross geography meta-pkgs security
3749 audio databases graphics misc shells
3750 benchmarks devel ham multimedia sysutils
3751 biology editors inputmethod net textproc
3752 cad emulators lang news time
3753 chat finance mail parallel wm
3754 comms fonts math pkgtools www
3755 converters games mbone print x11
3757 * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
3758 are discussed in detail in Section 17.5, "The fetch phase".
3760 The second section contains information about separately downloaded patches, if
3763 * PATCHFILES: Name(s) of additional files that contain distribution patches.
3764 There is no default. pkgsrc will look for them at PATCH_SITES. They will
3765 automatically be uncompressed before patching if the names end with .gz or
3768 * PATCH_SITES: Primary location(s) for distribution patch files (see
3769 PATCHFILES below) if not found locally.
3771 The third section contains the following variables.
3773 * MAINTAINER is the email address of the person who feels responsible for
3774 this package, and who is most likely to look at problems or questions
3775 regarding this package which have been reported with send-pr(1). Other
3776 developers may contact the MAINTAINER before making changes to the package,
3777 but are not required to do so. When packaging a new program, set MAINTAINER
3778 to yourself. If you really can't maintain the package for future updates,
3779 set it to <pkgsrc-users@NetBSD.org>.
3781 * OWNER should be used instead of MAINTAINER when you do not want other
3782 developers to update or change the package without contacting you first. A
3783 package Makefile should contain one of MAINTAINER or OWNER, but not both.
3785 * HOMEPAGE is a URL where users can find more information about the package.
3787 * COMMENT is a one-line description of the package (should not include the
3790 Other variables that affect the build:
3792 * WRKSRC: The directory where the interesting distribution files of the
3793 package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
3796 If a package doesn't create a subdirectory for itself (most GNU software
3797 does, for instance), but extracts itself in the current directory, you
3798 should set WRKSRC=${WRKDIR}.
3800 If a package doesn't create a subdirectory with the name of DISTNAME but
3801 some different name, set WRKSRC to point to the proper name in ${WRKDIR},
3802 for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
3805 The name of the working directory created by pkgsrc is taken from the
3806 WRKDIR_BASENAME variable. By default, its value is work. If you want to use
3807 the same pkgsrc tree for building different kinds of binary packages, you
3808 can change the variable according to your needs. Two other variables handle
3809 common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
3810 defined in mk.conf, the first component of the host's name is attached to
3811 the directory name. If OBJMACHINE is defined, the platform name is
3812 attached, which might look like work.i386 or work.sparc.
3814 Please pay attention to the following gotchas:
3816 * Add MANCOMPRESSED if man pages are installed in compressed form by the
3817 package. For packages using BSD-style makefiles which honor MANZ, there is
3818 MANCOMPRESSED_IF_MANZ.
3820 * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
3822 * If the package installs any info files, see Section 19.6.7, "Packages
3823 installing info files".
3827 The distinfo file contains the message digest, or checksum, of each distfile
3828 needed for the package. This ensures that the distfiles retrieved from the
3829 Internet have not been corrupted during transfer or altered by a malign force
3830 to introduce a security hole. Due to recent rumor about weaknesses of digest
3831 algorithms, all distfiles are protected using both SHA1 and RMD160 message
3832 digests, as well as the file size.
3834 The distinfo file also contains the checksums for all the patches found in the
3835 patches directory (see Section 11.3, "patches/*").
3837 To regenerate the distinfo file, use the make makedistinfo or make mdi command.
3839 Some packages have different sets of distfiles depending on the platform, for
3840 example lang/openjdk7. These are kept in the same distinfo file and care should
3841 be taken when upgrading such a package to ensure distfile information is not
3846 Many packages still don't work out-of-the box on the various platforms that are
3847 supported by pkgsrc. Therefore, a number of custom patch files are needed to
3848 make the package work. These patch files are found in the patches/ directory.
3850 In the patch phase, these patches are applied to the files in WRKSRC directory
3851 after extracting them, in alphabetic order.
3853 11.3.1. Structure of a single patch file
3855 The patch-* files should be in diff -bu format, and apply without a fuzz to
3856 avoid problems. (To force patches to apply with fuzz you can set
3857 PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
3858 a single file, and no file should be patched by more than one patch file. This
3859 helps to keep future modifications simple.
3861 Each patch file is structured as follows: In the first line, there is the RCS
3862 Id of the patch itself. The second line should be empty for aesthetic reasons.
3863 After that, there should be a comment for each change that the patch does.
3864 There are a number of standard cases:
3866 * Patches for commonly known vulnerabilities should mention the vulnerability
3869 * Patches that change source code should mention the platform and other
3870 environment (for example, the compiler) that the patch is needed for.
3872 In all, the patch should be commented so that any developer who knows the code
3873 of the application can make some use of the patch. Special care should be taken
3874 for the upstream developers, since we generally want that they accept our
3875 patches, so we have less work in the future.
3877 11.3.2. Creating patch files
3879 One important thing to mention is to pay attention that no RCS IDs get stored
3880 in the patch files, as these will cause problems when later checked into the
3881 NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
3882 avoid these problems.
3884 For even more automation, we recommend using mkpatches from the same package to
3885 make a whole set of patches. You just have to backup files before you edit them
3886 to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using
3887 pkgvi again from the same package. If you upgrade a package this way, you can
3888 easily compare the new set of patches with the previously existing one with
3889 patchdiff. The files in patches are replaced by new files, so carefully check
3890 if you want to take all the changes.
3892 When you have finished a package, remember to generate the checksums for the
3893 patch files by using the make makepatchsum command, see Section 11.2,
3896 When adding a patch that corrects a problem in the distfile (rather than e.g.
3897 enforcing pkgsrc's view of where man pages should go), send the patch as a bug
3898 report to the maintainer. This benefits non-pkgsrc users of the package, and
3899 usually makes it possible to remove the patch in future version.
3901 The file names of the patch files are usually of the form patch-
3902 path_to_file__with__underscores.c. Many packages still use the previous
3903 convention patch-[a-z][a-z], but new patches should be of the form containing
3904 the filename. mkpatches included in pkgtools/pkgdiff takes care of the name
3907 11.3.3. Sources where the patch files come from
3909 If you want to share patches between multiple packages in pkgsrc, e.g. because
3910 they use the same distfiles, set PATCHDIR to the path where the patch files can
3913 PATCHDIR= ${.CURDIR}/../xemacs/patches
3915 Patch files that are distributed by the author or other maintainers can be
3916 listed in PATCHFILES.
3918 If it is desired to store any patches that should not be committed into pkgsrc,
3919 they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
3920 directory tree there is expected to have the same "category/package" structure
3921 as pkgsrc, and patches are expected to be stored inside these dirs (also known
3922 as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
3923 for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
3924 files in the named directory are expected to be patch files, and they are
3925 applied after pkgsrc patches are applied.
3927 11.3.4. Patching guidelines
3929 When fixing a portability issue in the code do not use preprocessor magic to
3930 check for the current operating system nor platform. Doing so hurts portability
3931 to other platforms because the OS-specific details are not abstracted
3934 The general rule to follow is: instead of checking for the operating system the
3935 application is being built on, check for the specific features you need. For
3936 example, instead of assuming that kqueue is available under NetBSD and using
3937 the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
3938 kqueue itself ? yes, this generally involves patching the configure script.
3939 There is absolutely nothing that prevents some OSes from adopting interfaces
3940 from other OSes (e.g. Linux implementing kqueue), something that the above
3941 checks cannot take into account.
3943 Of course, checking for features generally involves more work on the
3944 developer's side, but the resulting changes are cleaner and there are chances
3945 they will work on many other platforms. Not to mention that there are higher
3946 chances of being later integrated into the mainstream sources. Remember: It
3947 doesn't work unless it is right!
3949 Some typical examples:
3951 Table 11.1. Patching examples
3953 +-------------------------------------------------------------------------------------------+
3954 | Where | Incorrect | Correct |
3955 |---------+--------------------------+------------------------------------------------------|
3956 | |case ${target_os} in | |
3957 |configure|netbsd*) have_kvm=yes ;; |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)|
3958 |script |*) have_kvm=no ;; | |
3960 |---------+--------------------------+------------------------------------------------------|
3961 |C source |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) |
3962 |file |# include <sys/event.h> |# include <sys/event.h> |
3964 |---------+--------------------------+------------------------------------------------------|
3966 | |monitor_file(...) |monitor_file(...) |
3968 | |#if defined(__NetBSD__) |#if defined(HAVE_KQUEUE) |
3969 |C source | int fd = kqueue();| int fd = kqueue(); |
3975 +-------------------------------------------------------------------------------------------+
3978 For more information, please read the Making packager-friendly software article
3979 (part 1, part 2). It summarizes multiple details on how to make software easier
3980 to package; all the suggestions in it were collected from our experience in
3981 pkgsrc work, so they are possibly helpful when creating patches too.
3983 11.3.5. Feedback to the author
3985 Always, always, always feed back any portability fixes or improvements you do
3986 to a package to the mainstream developers. This is the only way to get their
3987 attention on portability issues and to ensure that future versions can be built
3988 out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will
3989 get the fixes straight from the packaged code.
3991 This generally involves cleaning up the patches (because sometimes the patches
3992 that are added to pkgsrc are quick hacks), filling bug reports in the
3993 appropriate trackers for the projects and working with the mainstream authors
3994 to accept your changes. It is extremely important that you do it so that the
3995 packages in pkgsrc are kept simple and thus further changes can be done without
3998 When you have done this, please add a URL to the upstream bug report to the
4001 Support the idea of free software!
4003 11.4. Other mandatory files
4007 A multi-line description of the piece of software. This should include any
4008 credits where they are due. Please bear in mind that others do not share
4009 your sense of humour (or spelling idiosyncrasies), and that others will
4010 read everything that you write here.
4014 This file governs the files that are installed on your system: all the
4015 binaries, manual pages, etc. There are other directives which may be
4016 entered in this file, to control the creation and deletion of directories,
4017 and the location of inserted files. See Chapter 13, PLIST issues for more
4020 11.5. Optional files
4022 11.5.1. Files affecting the binary package
4026 This shell script is invoked twice by pkg_add(1). First time after package
4027 extraction and before files are moved in place, the second time after the
4028 files to install are moved in place. This can be used to do any custom
4029 procedures not possible with @exec commands in PLIST. See pkg_add(1) and
4030 pkg_create(1) for more information. See also Section 15.1, "Files and
4031 directories outside the installation prefix".
4035 This script is executed before and after any files are removed. It is this
4036 script's responsibility to clean up any additional messy details around the
4037 package's installation, since all pkg_delete knows is how to delete the
4038 files created in the original distribution. See pkg_delete(1) and
4039 pkg_create(1) for more information.
4043 This file is displayed after installation of the package. Useful for things
4044 like legal notices on almost-free software and hints for updating config
4045 files after installing modules for apache, PHP etc. Please note that you
4046 can modify variables in it easily by using MESSAGE_SUBST in the package's
4049 MESSAGE_SUBST+= SOMEVAR="somevalue"
4051 replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
4052 is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE,
4053 PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.
4055 You can display a different or additional files by setting the MESSAGE_SRC
4056 variable. Its default is MESSAGE, if the file exists.
4060 FIXME: There is no documentation on the alternatives framework.
4062 11.5.2. Files affecting the build process
4066 This file contains arbitrary things that could also go into a Makefile, but
4067 its purpose is to be used by more than one package. This file should only
4068 be used when the packages that will use the file are known in advance. For
4069 other purposes it is often better to write a *.mk file and give it a good
4070 name that describes what it does.
4074 This file contains the dependency information for the buildlink3 framework
4075 (see Chapter 14, Buildlink methodology).
4079 This file contains workarounds for compiler bugs and similar things. It is
4080 included automatically by the pkgsrc infrastructure, so you don't need an
4081 extra .include line for it.
4085 This file contains the code for the package-specific options (see
4086 Chapter 16, Options handling) that can be selected by the user. If a
4087 package has only one or two options, it is equally acceptable to put the
4088 code directly into the Makefile.
4090 11.5.3. Files affecting nothing at all
4094 These files do not take place in the creation of a package and thus are
4095 purely informative to the package developer.
4099 This file contains things that need to be done to make the package even
4104 When you type make, the distribution files are unpacked into the directory
4105 denoted by WRKDIR. It can be removed by running make clean. Besides the
4106 sources, this directory is also used to keep various timestamp files. The
4107 directory gets removed completely on clean. The default is ${.CURDIR}/work or $
4108 {.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
4112 If you have any files that you wish to be placed in the package prior to
4113 configuration or building, you could place these files here and use a ${CP}
4114 command in the "pre-configure" target to achieve this. Alternatively, you could
4115 simply diff the file against /dev/null and use the patch mechanism to manage
4116 the creation of this file.
4118 If you want to share files in this way with other packages, set the FILESDIR
4119 variable to point to the other package's files directory, e.g.:
4121 FILESDIR=${.CURDIR}/../xemacs/files
4123 Chapter 12. Programming in Makefiles
4128 12.2. Makefile variables
4130 12.2.1. Naming conventions
4134 12.3.1. Adding things to a list
4135 12.3.2. Converting an internal list into an external list
4136 12.3.3. Passing variables to a shell command
4137 12.3.4. Quoting guideline
4138 12.3.5. Workaround for a bug in BSD Make
4140 Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
4141 part of the pkgsrc system. Using the make(1) system as a programming language
4142 for a big system like pkgsrc requires some discipline to keep the code correct
4145 The basic ingredients for Makefile programming are variables (which are
4146 actually macros) and shell commands. Among these shell commands may even be
4147 more complex ones like awk(1) programs. To make sure that every shell command
4148 runs as intended it is necessary to quote all variables correctly when they are
4151 This chapter describes some patterns, that appear quite often in Makefiles,
4152 including the pitfalls that come along with them.
4156 * When you are creating a file as a target of a rule, always write the data
4157 to a temporary file first and finally rename that file. Otherwise there
4158 might occur an error in the middle of generating the file, and when the
4159 user runs make(1) for the second time, the file exists and will not be
4160 regenerated properly. Example:
4163 @echo "line 1" > ${.TARGET}
4164 @echo "line 2" >> ${.TARGET}
4168 @echo "line 1" > ${.TARGET}.tmp
4169 @echo "line 2" >> ${.TARGET}.tmp
4171 @mv ${.TARGET}.tmp ${.TARGET}
4173 When you run make wrong twice, the file wrong will exist, although there
4174 was an error message in the first run. On the other hand, running make
4175 correct gives an error message twice, as expected.
4177 You might remember that make(1) sometimes removes ${.TARGET} in case of
4178 error, but this only happens when it is interrupted, for example by
4179 pressing ^C. This does not happen when one of the commands fails (like
4182 12.2. Makefile variables
4184 Makefile variables contain strings that can be processed using the five
4185 operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
4188 When a variable's value is parsed from a Makefile, the hash character ``#'' and
4189 the backslash character ``\'' are handled specially. If a backslash is followed
4190 by a newline, any whitespace immediately in front of the backslash, the
4191 backslash, the newline, and any whitespace immediately behind the newline are
4192 replaced with a single space. A backslash character and an immediately
4193 following hash character are replaced with a single hash character. Otherwise,
4194 the backslash is passed as is. In a variable assignment, any hash character
4195 that is not preceded by a backslash starts a comment that continues upto the
4196 end of the logical line.
4198 Note: Because of this parsing algorithm the only way to create a variable
4199 consisting of a single backslash is using the ``!='' operator, for example:
4200 BACKSLASH!=echo "\\".
4202 So far for defining variables. The other thing you can do with variables is
4203 evaluating them. A variable is evaluated when it is part of the right side of
4204 the ``:='' or the ``!='' operator, or directly before executing a shell command
4205 which the variable is part of. In all other cases, make(1) performs lazy
4206 evaluation, that is, variables are not evaluated until there's no other way.
4207 The ``modifiers'' mentioned in the man page also evaluate the variable.
4209 Some of the modifiers split the string into words and then operate on the
4210 words, others operate on the string as a whole. When a string is split into
4211 words, it is split as you would expect it from sh(1).
4213 No rule without exception?the .for loop does not follow the shell quoting rules
4214 but splits at sequences of whitespace.
4216 There are several types of variables that should be handled differently.
4217 Strings and two types of lists.
4219 * Strings can contain arbitrary characters. Nevertheless, you should restrict
4220 yourself to only using printable characters. Examples are PREFIX and
4223 * Internal lists are lists that are never exported to any shell command.
4224 Their elements are separated by whitespace. Therefore, the elements
4225 themselves cannot have embedded whitespace. Any other characters are
4226 allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
4229 * External lists are lists that may be exported to a shell command. Their
4230 elements can contain any characters, including whitespace. That's why they
4231 cannot be used in .for loops. Examples are DISTFILES and MASTER_SITES.
4233 12.2.1. Naming conventions
4235 * All variable names starting with an underscore are reserved for use by the
4236 pkgsrc infrastructure. They shall not be used by package Makefiles.
4238 * In .for loops you should use lowercase variable names for the iteration
4241 * All list variables should have a ``plural'' name, e.g. PKG_OPTIONS or
4246 This section presents you with some code snippets you should use in your own
4247 code. If you don't find anything appropriate here, you should test your code
4250 12.3.1. Adding things to a list
4252 STRING= foo * bar `date`
4254 ANOTHER_INT_LIST= apache-[0-9]*:../../www/apache
4256 ANOTHER_EXT_LIST= a=b c=d
4258 INT_LIST+= ${STRING} # 1
4259 INT_LIST+= ${ANOTHER_INT_LIST} # 2
4260 EXT_LIST+= ${STRING:Q} # 3
4261 EXT_LIST+= ${ANOTHER_EXT_LIST} # 4
4263 When you add a string to an external list (example 3), it must be quoted. In
4264 all other cases, you must not add a quoting level. You must not merge internal
4265 and external lists, unless you are sure that all entries are correctly
4266 interpreted in both lists.
4268 12.3.2. Converting an internal list into an external list
4271 .for i in ${INT_LIST}
4275 This code converts the internal list INT_LIST into the external list EXT_LIST.
4276 As the elements of an internal list are unquoted they must be quoted here. The
4277 reason for appending "" is explained below.
4279 12.3.3. Passing variables to a shell command
4281 Sometimes you may want to print an arbitrary string. There are many ways to get
4282 it wrong and only few that can handle every nastiness.
4284 STRING= foo bar < > * `date` $$HOME ' "
4285 EXT_LIST= string=${STRING:Q} x=second\ item
4289 echo "${STRING}" # 2
4290 echo "${STRING:Q}" # 3
4291 echo ${STRING:Q} # 4
4292 echo x${STRING:Q} | sed 1s,.,, # 5
4293 printf "%s\\n" ${STRING:Q}"" # 6
4294 env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
4296 Example 1 leads to a syntax error in the shell, as the characters are just
4299 Example 2 leads to a syntax error too, and if you leave out the last "
4300 character from ${STRING}, date(1) will be executed. The $HOME shell variable
4301 would be evaluated, too.
4303 Example 3 outputs each space character preceded by a backslash (or not),
4304 depending on the implementation of the echo(1) command.
4306 Example 4 handles correctly every string that does not start with a dash. In
4307 that case, the result depends on the implementation of the echo(1) command. As
4308 long as you can guarantee that your input does not start with a dash, this form
4311 Example 5 handles even the case of a leading dash correctly.
4313 Example 6 also works with every string and is the light-weight solution, since
4314 it does not involve a pipe, which has its own problems.
4316 The EXT_LIST does not need to be quoted because the quoting has already been
4317 done when adding elements to the list.
4319 As internal lists shall not be passed to the shell, there is no example for it.
4321 12.3.4. Quoting guideline
4323 There are many possible sources of wrongly quoted variables. This section lists
4324 some of the commonly known ones.
4326 * Whenever you use the value of a list, think about what happens to leading
4327 or trailing whitespace. If the list is a well-formed shell expression, you
4328 can apply the :M* modifier to strip leading and trailing whitespace from
4329 each word. The :M operator first splits its argument according to the rules
4330 of the shell, and then creates a new list consisting of all words that
4331 match the shell glob expression *, that is: all. One class of situations
4332 where this is needed is when adding a variable like CPPFLAGS to
4333 CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
4334 strips the leading and trailing whitespace from the variable and then
4335 passes it to the other configure scripts. But these configure scripts
4336 expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
4337 That's why we better pass the CPPFLAGS value properly trimmed. And here is
4341 CPPFLAGS+= -Wundef -DPREFIX=\"${PREFIX:Q}\"
4342 CPPFLAGS+= ${MY_CPPFLAGS}
4344 CONFIGURE_ARGS+= CPPFLAGS=${CPPFLAGS:M*:Q}
4347 echo x${CPPFLAGS:Q}x # leading and trailing whitespace
4348 echo x${CONFIGURE_ARGS}x # properly trimmed
4350 * The example above contains one bug: The ${PREFIX} is a properly quoted
4351 shell expression, but there is the C compiler after it, which also expects
4352 a properly quoted string (this time in C syntax). The version above is
4353 therefore only correct if ${PREFIX} does not have embedded backslashes or
4354 double quotes. If you want to allow these, you have to add another layer of
4355 quoting to each variable that is used as a C string literal. You cannot use
4356 the :Q operator for it, as this operator only works for the shell.
4358 * Whenever a variable can be empty, the :Q operator can have surprising
4359 results. Here are two completely different cases which can be solved with
4364 for i in a ${EMPTY:Q} c; do \
4369 .for i in a:\ a:\test.txt
4374 The first example will only print two of the three lines we might have
4375 expected. This is because ${EMPTY:Q} expands to the empty string, which the
4376 shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
4377 be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
4380 The second example will only print three lines instead of four. The first
4381 line looks like a:\ echo foo. This is because the backslash of the value a:
4382 \ is interpreted as a line-continuation by make(1), which makes the second
4383 line the arguments of the echo(1) command from the first line. To avoid
4384 this, write ${i:Q}"".
4386 12.3.5. Workaround for a bug in BSD Make
4388 The pkgsrc bmake program does not handle the following assignment correctly. In
4389 case _othervar_ contains a ``-'' character, one of the closing braces is
4390 included in ${VAR} after this code executes.
4392 VAR:= ${VAR:N${_othervar_:C/-//}}
4394 For a more complex code snippet and a workaround, see the package regress/
4395 make-quoting, testcase bug1.
4397 Chapter 13. PLIST issues
4402 13.2. Semi-automatic PLIST generation
4403 13.3. Tweaking output of make print-PLIST
4404 13.4. Variable substitution in PLIST
4405 13.5. Man page compression
4406 13.6. Changing PLIST source with PLIST_SRC
4407 13.7. Platform-specific and differing PLISTs
4408 13.8. Sharing directories between packages
4410 The PLIST file contains a package's "packing list", i.e. a list of files that
4411 belong to the package (relative to the ${PREFIX} directory it's been installed
4412 in) plus some additional statements - see the pkg_create(1) man page for a full
4413 list. This chapter addresses some issues that need attention when dealing with
4414 the PLIST file (or files, see below!).
4418 Be sure to add a RCS ID line as the first thing in any PLIST file you write:
4423 13.2. Semi-automatic PLIST generation
4425 You can use the make print-PLIST command to output a PLIST that matches any new
4426 files since the package was extracted. See Section 17.17, "Other helpful
4427 targets" for more information on this target.
4429 13.3. Tweaking output of make print-PLIST
4431 If you have used any of the *-dirs packages, as explained in Section 13.8,
4432 "Sharing directories between packages", you may have noticed that make
4433 print-PLIST outputs a set of @comments instead of real @dirrm lines. You can
4434 also do this for specific directories and files, so that the results of that
4435 command are very close to reality. This helps a lot during the update of
4438 The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
4439 used to filter the output of print-PLIST. You can append any chunk of AWK
4440 scripting you like to it, but be careful with quoting.
4442 For example, to get all files inside the libdata/foo directory removed from the
4445 PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }
4448 And to get all the @dirrm lines referring to a specific (shared) directory
4449 converted to @comments:
4451 PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; }
4454 13.4. Variable substitution in PLIST
4456 A number of variables are substituted automatically in PLISTs when a package is
4457 installed on a system. This includes the following variables:
4459 ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
4461 Some packages like emacs and perl embed information about which
4462 architecture they were built on into the pathnames where they install their
4463 files. To handle this case, PLIST will be preprocessed before actually
4464 used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
4465 gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
4466 PLIST somewhere - use this on packages that have GNU autoconf-created
4471 There used to be a symbol "$ARCH" that was replaced by the output of uname
4472 -m, but that's no longer supported and has been removed.
4474 ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
4476 Some packages want to embed the OS name and version into some paths. To do
4477 this, use these variables in the PLIST:
4479 * ${OPSYS} - output of "uname -s"
4481 * ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
4483 * ${OS_VERSION} - "uname -r"
4485 For a complete list of values which are replaced by default, please look in
4486 bsd.pkg.mk (and search for PLIST_SUBST).
4488 If you want to change other variables not listed above, you can add variables
4489 and their expansions to this variable in the following way, similar to
4490 MESSAGE_SUBST (see Section 11.5, "Optional files"):
4492 PLIST_SUBST+= SOMEVAR="somevalue"
4495 This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".
4497 The PLIST_VARS variable can be used to simplify the common case of
4498 conditionally including some PLIST entries. It can be done by adding
4499 PLIST_VARS+=foo and setting the corresponding PLIST.foo variable to yes if the
4500 entry should be included. This will substitute "${PLIST.foo}" in the PLIST with
4501 either """" or ""@comment "". For example, in Makefile:
4515 ${PLIST.foo}man/man1/foo.1
4516 ${PLIST.foo}share/bar/foo.data
4517 ${PLIST.foo}@dirrm share/bar
4520 13.5. Man page compression
4522 Man pages should be installed in compressed form if MANZ is set (in
4523 bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
4524 suffix ".gz" is appended/removed automatically for man pages according to MANZ
4525 and MANCOMPRESSED being set or not, see above for details. This modification of
4526 the PLIST file is done on a copy of it, not PLIST itself.
4528 13.6. Changing PLIST source with PLIST_SRC
4530 To use one or more files as source for the PLIST used in generating the binary
4531 package, set the variable PLIST_SRC to the names of that file(s). The files are
4532 later concatenated using cat(1), and the order of things is important. The
4533 default for PLIST_SRC is ${PKGDIR}/PLIST.
4535 13.7. Platform-specific and differing PLISTs
4537 Some packages decide to install a different set of files based on the operating
4538 system being used. These differences can be automatically handled by using the
4545 * PLIST.${MACHINE_ARCH}
4547 * PLIST.${OPSYS}-${MACHINE_ARCH}
4551 13.8. Sharing directories between packages
4553 A "shared directory" is a directory where multiple (and unrelated) packages
4554 install files. These directories were problematic because you had to add
4555 special tricks in the PLIST to conditionally remove them, or have some
4556 centralized package handle them.
4558 In pkgsrc, it is now easy: Each package should create directories and install
4559 files as needed; pkg_delete will remove any directories left empty after
4560 uninstalling a package.
4562 If a package needs an empty directory to work, create the directory during
4563 installation as usual, and also add an entry to the PLIST:
4565 @pkgdir path/to/empty/directory
4568 Chapter 14. Buildlink methodology
4572 14.1. Converting packages to use buildlink3
4573 14.2. Writing buildlink3.mk files
4575 14.2.1. Anatomy of a buildlink3.mk file
4576 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
4578 14.3. Writing builtin.mk files
4580 14.3.1. Anatomy of a builtin.mk file
4581 14.3.2. Global preferences for native or pkgsrc software
4583 Buildlink is a framework in pkgsrc that controls what headers and libraries are
4584 seen by a package's configure and build processes. This is implemented in a two
4587 1. Symlink headers and libraries for dependencies into BUILDLINK_DIR, which by
4588 default is a subdirectory of WRKDIR.
4590 2. Create wrapper scripts that are used in place of the normal compiler tools
4591 that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib into
4592 references to BUILDLINK_DIR. The wrapper scripts also make native compiler
4593 on some operating systems look like GCC, so that packages that expect GCC
4594 won't require modifications to build with those native compilers.
4596 This normalizes the environment in which a package is built so that the package
4597 may be built consistently despite what other software may be installed. Please
4598 note that the normal system header and library paths, e.g. /usr/include, /usr/
4599 lib, etc., are always searched -- buildlink3 is designed to insulate the
4600 package build from non-system-supplied software.
4602 14.1. Converting packages to use buildlink3
4604 The process of converting packages to use the buildlink3 framework ("bl3ifying"
4605 ) is fairly straightforward. The things to keep in mind are:
4607 1. Ensure that the build always calls the wrapper scripts instead of the
4608 actual toolchain. Some packages are tricky, and the only way to know for
4609 sure is the check ${WRKDIR}/.work.log to see if the wrappers are being
4612 2. Don't override PREFIX from within the package Makefile, e.g. Java VMs,
4613 standalone shells, etc., because the code to symlink files into $
4614 {BUILDLINK_DIR} looks for files relative to "pkg_info -qp pkgname".
4616 3. Remember that only the buildlink3.mk files that you list in a package's
4617 Makefile are added as dependencies for that package.
4619 If a dependency on a particular package is required for its libraries and
4620 headers, then we replace:
4622 DEPENDS+= foo>=1.1.0:../../category/foo
4626 .include "../../category/foo/buildlink3.mk"
4628 The buildlink3.mk files usually define the required dependencies. If you need a
4629 newer version of the dependency when using buildlink3.mk files, then you can
4630 define it in your Makefile; for example:
4632 BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0
4633 .include "../../category/foo/buildlink3.mk"
4635 There are several buildlink3.mk files in pkgsrc/mk that handle special package
4638 * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
4639 implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.
4641 * curses.buildlink3.mk: If the system comes with neither Curses nor NCurses,
4642 this will take care to install the devel/ncurses package.
4644 * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding
4645 a dependency on Heimdal or MIT-krb5 for packages that require a Kerberos 5
4648 * motif.buildlink3.mk checks for a system-provided Motif installation or adds
4649 a dependency on x11/lesstif or x11/openmotif. The user can set MOTIF_TYPE
4650 to "dt", "lesstif", or "openmotif" to choose which Motif version will be
4653 * oss.buildlink3.mk defines several variables that may be used by packages
4654 that use the Open Sound System (OSS) API.
4656 * pgsql.buildlink3.mk will accept either Postgres 8.0, 8.1, or 8.2, whichever
4657 is found installed. See the file for more information.
4659 * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native
4660 pthreads or adds a dependency on devel/pth as needed.
4662 * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena
4665 The comments in those buildlink3.mk files provide a more complete description
4666 of how to use them properly.
4668 14.2. Writing buildlink3.mk files
4670 A package's buildlink3.mk file is included by Makefiles to indicate the need to
4671 compile and link against header files and libraries provided by the package. A
4672 buildlink3.mk file should always provide enough information to add the correct
4673 type of dependency relationship and include any other buildlink3.mk files that
4674 it needs to find headers and libraries that it needs in turn.
4676 To generate an initial buildlink3.mk file for further editing, Rene Hexel's
4677 pkgtools/createbuildlink package is highly recommended. For most packages, the
4678 following command will generate a good starting point for buildlink3.mk files:
4680 % cd pkgsrc/category/pkgdir
4681 % createbuildlink >buildlink3.mk
4684 14.2.1. Anatomy of a buildlink3.mk file
4686 The following real-life example buildlink3.mk is taken from pkgsrc/graphics/
4689 # $NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp $
4691 BUILDLINK_TREE+= tiff
4693 .if !defined(TIFF_BUILDLINK3_MK)
4694 TIFF_BUILDLINK3_MK:=
4696 BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1
4697 BUILDLINK_ABI_DEPENDS.tiff+= tiff>=3.7.2nb1
4698 BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff
4700 .include "../../devel/zlib/buildlink3.mk"
4701 .include "../../graphics/jpeg/buildlink3.mk"
4702 .endif # TIFF_BUILDLINK3_MK
4704 BUILDLINK_TREE+= -tiff
4706 The header and footer manipulate BUILDLINK_TREE, which is common across all
4707 buildlink3.mk files and is used to track the dependency tree.
4709 The main section is protected from multiple inclusion and controls how the
4710 dependency on pkg is added. Several important variables are set in the section:
4712 * BUILDLINK_API_DEPENDS.pkg is the actual dependency recorded in the
4713 installed package; this should always be set using += to ensure that we're
4714 appending to any pre-existing list of values. This variable should be set
4715 to the first version of the package that had an API change.
4717 * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory.
4719 * BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
4720 BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
4721 is selected by setting BUILDLINK_DEPMETHOD.pkg to "build". By default, the
4722 full dependency is used.
4724 * BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS.pkg (not shown above) are lists
4725 of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and
4726 library search paths. These default to "include" and "lib" respectively.
4728 * BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags
4729 to add to CPPFLAGS, which are passed on to the configure and build phases.
4730 The "-I" option should be avoided and instead be handled using
4731 BUILDLINK_INCDIRS.pkg as above.
4733 The following variables are all optionally defined within this second section
4734 (protected against multiple inclusion) and control which package files are
4735 symlinked into ${BUILDLINK_DIR} and how their names are transformed during the
4738 * BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to $
4739 {BUILDLINK_PREFIX.pkg} to be symlinked into ${BUILDLINK_DIR}, e.g. include/
4742 * BUILDLINK_FILES_CMD.pkg (not shown above) is a shell pipeline that outputs
4743 to stdout a list of files relative to ${BUILDLINK_PREFIX.pkg}. The
4744 resulting files are to be symlinked into ${BUILDLINK_DIR}. By default, this
4745 takes the +CONTENTS of a pkg and filters it through $
4746 {BUILDLINK_CONTENTS_FILTER.pkg}.
4748 * BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that
4749 filters +CONTENTS input into a list of files relative to $
4750 {BUILDLINK_PREFIX.pkg} on stdout. By default for overwrite packages,
4751 BUILDLINK_CONTENTS_FILTER.pkg outputs the contents of the include and lib
4752 directories in the package +CONTENTS, and for pkgviews packages, it outputs
4753 any libtool archives in lib directories.
4755 * BUILDLINK_FNAME_TRANSFORM.pkg (not shown above) is a list of sed arguments
4756 used to transform the name of the source filename into a destination
4757 filename, e.g. -e "s|/curses.h|/ncurses.h|g".
4759 This section can additionally include any buildlink3.mk needed for pkg's
4760 library dependencies. Including these buildlink3.mk files means that the
4761 headers and libraries for these dependencies are also symlinked into $
4762 {BUILDLINK_DIR} whenever the pkg buildlink3.mk file is included. Dependencies
4763 are only added for directly include buildlink3.mk files.
4765 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
4767 The situation that requires increasing the dependency listed in
4768 BUILDLINK_API_DEPENDS.pkg after a package update is when the API or interface
4769 to the header files change.
4771 In this case, BUILDLINK_API_DEPENDS.pkg should be adjusted to require at least
4772 the new package version. In some cases, the packages that depend on this new
4773 version may need their PKGREVISIONs increased and, if they have buildlink3.mk
4774 files, their BUILDLINK_API_DEPENDS.pkg adjusted, too. This is needed so pkgsrc
4775 will require the correct package dependency and not settle for an older one
4776 when building the source.
4778 BUILDLINK_ABI_DEPENDS.pkg should be increased when the binary interface or
4779 sonames (major number of the library version) of any installed shared libraries
4780 change. This is needed so that binary packages made using it will require the
4781 correct package dependency and not settle for an older one which will not
4782 contain the necessary shared libraries.
4784 See Section 19.1.6, "Handling dependencies" for more information about
4785 dependencies on other packages, including the BUILDLINK_ABI_DEPENDS and
4786 ABI_DEPENDS definitions.
4788 Please take careful consideration before adjusting BUILDLINK_API_DEPENDS.pkg or
4789 BUILDLINK_ABI_DEPENDS.pkg as we don't want to cause unneeded package deletions
4790 and rebuilds. In many cases, new versions of packages work just fine with older
4793 Also it is not needed to set BUILDLINK_ABI_DEPENDS.pkg when it is identical to
4794 BUILDLINK_API_DEPENDS.pkg.
4796 14.3. Writing builtin.mk files
4798 Some packages in pkgsrc install headers and libraries that coincide with
4799 headers and libraries present in the base system. Aside from a buildlink3.mk
4800 file, these packages should also include a builtin.mk file that includes the
4801 necessary checks to decide whether using the built-in software or the pkgsrc
4802 software is appropriate.
4804 The only requirements of a builtin.mk file for pkg are:
4806 1. It should set USE_BUILTIN.pkg to either "yes" or "no" after it is included.
4808 2. It should not override any USE_BUILTIN.pkg which is already set before the
4809 builtin.mk file is included.
4811 3. It should be written to allow multiple inclusion. This is very important
4812 and takes careful attention to Makefile coding.
4814 14.3.1. Anatomy of a builtin.mk file
4816 The following is the recommended template for builtin.mk files:
4818 .if !defined(IS_BUILTIN.foo)
4820 # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
4821 # genuinely exists in the system or not.
4825 # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
4826 # version can be determined.
4828 . if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
4829 BUILTIN_PKG.foo?= foo-1.0
4831 .endif # IS_BUILTIN.foo
4833 .if !defined(USE_BUILTIN.foo)
4834 USE_BUILTIN.foo?= ${IS_BUILTIN.foo}
4835 . if defined(BUILTIN_PKG.foo)
4836 . for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
4837 . if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
4839 ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo} \
4840 && ${ECHO} "yes" || ${ECHO} "no"
4844 .endif # USE_BUILTIN.foo
4846 CHECK_BUILTIN.foo?= no
4847 .if !empty(CHECK_BUILTIN.foo:M[nN][oO])
4849 # Here we place code that depends on whether USE_BUILTIN.foo is set to
4852 .endif # CHECK_BUILTIN.foo
4854 The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the
4855 base system. This should not be a base system software with similar
4856 functionality to pkg; it should only be "yes" if the actual package is included
4857 as part of the base system. This variable is only used internally within the
4860 The second section sets BUILTIN_PKG.pkg to the version of pkg in the base
4861 system if it exists (if IS_BUILTIN.pkg is "yes"). This variable is only used
4862 internally within the builtin.mk file.
4864 The third section sets USE_BUILTIN.pkg and is required in all builtin.mk files.
4865 The code in this section must make the determination whether the built-in
4866 software is adequate to satisfy the dependencies listed in
4867 BUILDLINK_API_DEPENDS.pkg. This is typically done by comparing BUILTIN_PKG.pkg
4868 against each of the dependencies in BUILDLINK_API_DEPENDS.pkg. USE_BUILTIN.pkg
4869 must be set to the correct value by the end of the builtin.mk file. Note that
4870 USE_BUILTIN.pkg may be "yes" even if IS_BUILTIN.pkg is "no" because we may make
4871 the determination that the built-in version of the software is similar enough
4872 to be used as a replacement.
4874 The last section is guarded by CHECK_BUILTIN.pkg, and includes code that uses
4875 the value of USE_BUILTIN.pkg set in the previous section. This typically
4876 includes, e.g., adding additional dependency restrictions and listing
4877 additional files to symlink into ${BUILDLINK_DIR} (via BUILDLINK_FILES.pkg).
4879 14.3.2. Global preferences for native or pkgsrc software
4881 When building packages, it's possible to choose whether to set a global
4882 preference for using either the built-in (native) version or the pkgsrc version
4883 of software to satisfy a dependency. This is controlled by setting
4884 PREFER_PKGSRC and PREFER_NATIVE. These variables take values of either "yes", "
4885 no", or a list of packages. PREFER_PKGSRC tells pkgsrc to use the pkgsrc
4886 versions of software, while PREFER_NATIVE tells pkgsrc to use the built-in
4887 versions. Preferences are determined by the most specific instance of the
4888 package in either PREFER_PKGSRC or PREFER_NATIVE. If a package is specified in
4889 neither or in both variables, then PREFER_PKGSRC has precedence over
4890 PREFER_NATIVE. For example, to require using pkgsrc versions of software for
4891 all but the most basic bits on a NetBSD system, you can set:
4894 PREFER_NATIVE= getopt skey tcp_wrappers
4896 A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise
4897 it is simply ignored in that list.
4899 Chapter 15. The pkginstall framework
4903 15.1. Files and directories outside the installation prefix
4905 15.1.1. Directory manipulation
4906 15.1.2. File manipulation
4908 15.2. Configuration files
4910 15.2.1. How PKG_SYSCONFDIR is set
4911 15.2.2. Telling the software where configuration files are
4912 15.2.3. Patching installations
4913 15.2.4. Disabling handling of configuration files
4915 15.3. System startup scripts
4917 15.3.1. Disabling handling of system startup scripts
4919 15.4. System users and groups
4922 15.5.1. Disabling shell registration
4926 15.6.1. Disabling automatic update of the fonts databases
4928 This chapter describes the framework known as pkginstall, whose key features
4931 * Generic installation and manipulation of directories and files outside the
4932 pkgsrc-handled tree, LOCALBASE.
4934 * Automatic handling of configuration files during installation, provided
4935 that packages are correctly designed.
4937 * Generation and installation of system startup scripts.
4939 * Registration of system users and groups.
4941 * Registration of system shells.
4943 * Automatic updating of fonts databases.
4945 The following sections inspect each of the above points in detail.
4947 You may be thinking that many of the things described here could be easily done
4948 with simple code in the package's post-installation target (post-install). This
4949 is incorrect, as the code in them is only executed when building from source.
4950 Machines using binary packages could not benefit from it at all (as the code
4951 itself could be unavailable). Therefore, the only way to achieve any of the
4952 items described above is by means of the installation scripts, which are
4953 automatically generated by pkginstall.
4955 15.1. Files and directories outside the installation prefix
4957 As you already know, the PLIST file holds a list of files and directories that
4958 belong to a package. The names used in it are relative to the installation
4959 prefix (${PREFIX}), which means that it cannot register files outside this
4960 directory (absolute path names are not allowed). Despite this restriction, some
4961 packages need to install files outside this location; e.g., under ${VARBASE} or
4962 ${PKG_SYSCONFDIR}. The only way to achieve this is to create such files during
4963 installation time by using installation scripts.
4965 The generic installation scripts are shell scripts that can contain arbitrary
4966 code. The list of scripts to execute is taken from the INSTALL_FILE variable,
4967 which defaults to INSTALL. A similar variable exists for package removal
4968 (DEINSTALL_FILE, whose default is DEINSTALL). These scripts can run arbitrary
4969 commands, so they have the potential to create and manage files anywhere in the
4972 Using these general installation files is not recommended, but may be needed in
4973 some special cases. One reason for avoiding them is that the user has to trust
4974 the packager that there is no unwanted or simply erroneous code included in the
4975 installation script. Also, previously there were many similar scripts for the
4976 same functionality, and fixing a common error involved finding and changing all
4979 The pkginstall framework offers another, standardized way. It provides generic
4980 scripts to abstract the manipulation of such files and directories based on
4981 variables set in the package's Makefile. The rest of this section describes
4984 15.1.1. Directory manipulation
4986 The following variables can be set to request the creation of directories
4987 anywhere in the file system:
4989 * MAKE_DIRS and OWN_DIRS contain a list of directories that should be created
4990 and should attempt to be destroyed by the installation scripts. The
4991 difference between the two is that the latter prompts the administrator to
4992 remove any directories that may be left after deinstallation (because they
4993 were not empty), while the former does not.
4995 * MAKE_DIRS_PERMS and OWN_DIRS_PERMS contain a list of tuples describing
4996 which directories should be created and should attempt to be destroyed by
4997 the installation scripts. Each tuple holds the following values, separated
4998 by spaces: the directory name, its owner, its group and its numerical mode.
5001 MAKE_DIRS_PERMS+= ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
5003 The difference between the two is exactly the same as their non-PERMS
5006 15.1.2. File manipulation
5008 Creating non-empty files outside the installation prefix is tricky because the
5009 PLIST forces all files to be inside it. To overcome this problem, the only
5010 solution is to extract the file in the known place (i.e., inside the
5011 installation prefix) and copy it to the appropriate location during
5012 installation (done by the installation scripts generated by pkginstall). We
5013 will call the former the master file in the following paragraphs, which
5014 describe the variables that can be used to automatically and consistently
5015 handle files outside the installation prefix:
5017 * CONF_FILES and SUPPORT_FILES are pairs of master and target files. During
5018 installation time, the master file is copied to the target one if and only
5019 if the latter does not exist. Upon deinstallation, the target file is
5020 removed provided that it was not modified by the installation.
5022 The difference between the two is that the latter prompts the administrator
5023 to remove any files that may be left after deinstallation (because they
5024 were not empty), while the former does not.
5026 * CONF_FILES_PERMS and SUPPORT_FILES_PERMS contain tuples describing master
5027 files as well as their target locations. For each of them, it also
5028 specifies their owner, their group and their numeric permissions, in this
5031 SUPPORT_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
5033 The difference between the two is exactly the same as their non-PERMS
5036 15.2. Configuration files
5038 Configuration files are special in the sense that they are installed in their
5039 own specific directory, PKG_SYSCONFDIR, and need special treatment during
5040 installation (most of which is automated by pkginstall). The main concept you
5041 must bear in mind is that files marked as configuration files are automatically
5042 copied to the right place (somewhere inside PKG_SYSCONFDIR) during installation
5043 if and only if they didn't exist before. Similarly, they will not be removed if
5044 they have local modifications. This ensures that administrators never lose any
5045 custom changes they may have made.
5047 15.2.1. How PKG_SYSCONFDIR is set
5049 As said before, the PKG_SYSCONFDIR variable specifies where configuration files
5050 shall be installed. Its contents are set based upon the following variables:
5052 * PKG_SYSCONFBASE: The configuration's root directory. Defaults to ${PREFIX}/
5053 etc although it may be overridden by the user to point to his preferred
5054 location (e.g., /etc, /etc/pkg, etc.). Packages must not use it directly.
5056 * PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the
5057 configuration files for the package being built shall be installed. The
5058 definition of this variable only makes sense in the package's Makefile
5059 (i.e., it is not user-customizable).
5061 As an example, consider the Apache package, www/apache2, which places its
5062 configuration files under the httpd/ subdirectory of PKG_SYSCONFBASE. This
5063 should be set in the package Makefile.
5065 * PKG_SYSCONFVAR: Specifies the name of the variable that holds this
5066 package's configuration directory (if different from PKG_SYSCONFBASE). It
5067 defaults to PKGBASE's value, and is always prefixed with PKG_SYSCONFDIR.
5069 * PKG_SYSCONFDIR.${PKG_SYSCONFVAR}: Holds the directory where the
5070 configuration files for the package identified by PKG_SYSCONFVAR's shall be
5073 Based on the above variables, pkginstall determines the value of
5074 PKG_SYSCONFDIR, which is the only variable that can be used within a package to
5075 refer to its configuration directory. The algorithm used to set its value is
5076 basically the following:
5078 1. If PKG_SYSCONFDIR.${PKG_SYSCONFVAR} is set, its value is used.
5080 2. If the previous variable is not defined but PKG_SYSCONFSUBDIR is set in the
5081 package's Makefile, the resulting value is ${PKG_SYSCONFBASE}/$
5082 {PKG_SYSCONFSUBDIR}.
5084 3. Otherwise, it is set to ${PKG_SYSCONFBASE}.
5086 It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
5087 OWN_DIRS. See Section 15.1.1, "Directory manipulation" what this means. This
5088 does not apply to subdirectories of ${PKG_SYSCONFDIR}, they still have to be
5089 created with OWN_DIRS or MAKE_DIRS.
5091 15.2.2. Telling the software where configuration files are
5093 Given that pkgsrc (and users!) expect configuration files to be in a known
5094 place, you need to teach each package where it shall install its files. In some
5095 cases you will have to patch the package Makefiles to achieve it. If you are
5096 lucky, though, it may be as easy as passing an extra flag to the configuration
5097 script; this is the case of GNU Autoconf- generated files:
5099 CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
5101 Note that this specifies where the package has to look for its configuration
5102 files, not where they will be originally installed (although the difference is
5103 never explicit, unfortunately).
5105 15.2.3. Patching installations
5107 As said before, pkginstall automatically handles configuration files. This
5108 means that the packages themselves must not touch the contents of $
5109 {PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts
5110 will, out of the box, mess with the contents of that directory. So what is the
5111 correct procedure to fix this issue?
5113 You must teach the package (usually by manually patching it) to install any
5114 configuration files under the examples hierarchy, share/examples/${PKGBASE}/.
5115 This way, the PLIST registers them and the administrator always has the
5116 original copies available.
5118 Once the required configuration files are in place (i.e., under the examples
5119 hierarchy), the pkginstall framework can use them as master copies during the
5120 package installation to update what is in ${PKG_SYSCONFDIR}. To achieve this,
5121 the variables CONF_FILES and CONF_FILES_PERMS are used. Check out
5122 Section 15.1.2, "File manipulation" for information about their syntax and
5123 their purpose. Here is an example, taken from the mail/mutt package:
5125 EGDIR= ${PREFIX}/share/doc/mutt/samples
5126 CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
5128 Note that the EGDIR variable is specific to that package and has no meaning
5131 15.2.4. Disabling handling of configuration files
5133 The automatic copying of config files can be toggled by setting the environment
5134 variable PKG_CONFIG prior to package installation.
5136 15.3. System startup scripts
5138 System startup scripts are special files because they must be installed in a
5139 place known by the underlying OS, usually outside the installation prefix.
5140 Therefore, the same rules described in Section 15.1, "Files and directories
5141 outside the installation prefix" apply, and the same solutions can be used.
5142 However, pkginstall provides a special mechanism to handle these files.
5144 In order to provide system startup scripts, the package has to:
5146 1. Store the script inside ${FILESDIR}, with the .sh suffix appended.
5147 Considering the print/cups package as an example, it has a cupsd.sh in its
5150 2. Tell pkginstall to handle it, appending the name of the script, without its
5151 extension, to the RCD_SCRIPTS variable. Continuing the previous example:
5155 Once this is done, pkginstall will do the following steps for each script in an
5158 1. Process the file found in the files directory applying all the
5159 substitutions described in the FILES_SUBST variable.
5161 2. Copy the script from the files directory to the examples hierarchy, $
5162 {PREFIX}/share/examples/rc.d/. Note that this master file must be
5163 explicitly registered in the PLIST.
5165 3. Add code to the installation scripts to copy the startup script from the
5166 examples hierarchy into the system-wide startup scripts directory.
5168 15.3.1. Disabling handling of system startup scripts
5170 The automatic copying of config files can be toggled by setting the environment
5171 variable PKG_RCD_SCRIPTS prior to package installation. Note that the scripts
5172 will be always copied inside the examples hierarchy, ${PREFIX}/share/examples/
5173 rc.d/, no matter what the value of this variable is.
5175 15.4. System users and groups
5177 If a package needs to create special users and/or groups during installation,
5178 it can do so by using the pkginstall framework.
5180 Users can be created by adding entries to the PKG_USERS variable. Each entry
5181 has the following syntax:
5185 Further specification of user details may be done by setting per-user
5186 variables. PKG_UID.user is the numeric UID for the user. PKG_GECOS.user is the
5187 user's description or comment. PKG_HOME.user is the user's home directory, and
5188 defaults to /nonexistent if not specified. PKG_SHELL.user is the user's shell,
5189 and defaults to /sbin/nologin if not specified.
5191 Similarly, groups can be created by adding entries to the PKG_GROUPS variable,
5196 The numeric GID of the group may be set by defining PKG_GID.group.
5198 If a package needs to create the users and groups at an earlier stage, then it
5199 can set USERGROUP_PHASE to either configure or build to indicate the phase
5200 before which the users and groups are created. In this case, the numeric UIDs
5201 and GIDs of the created users and groups are automatically hardcoded into the
5202 final installation scripts.
5206 Packages that install system shells should register them in the shell database,
5207 /etc/shells, to make things easier to the administrator. This must be done from
5208 the installation scripts to keep binary packages working on any system.
5209 pkginstall provides an easy way to accomplish this task.
5211 When a package provides a shell interpreter, it has to set the PKG_SHELL
5212 variable to its absolute file name. This will add some hooks to the
5213 installation scripts to handle it. Consider the following example, taken from
5216 PKG_SHELL= ${PREFIX}/bin/zsh
5218 15.5.1. Disabling shell registration
5220 The automatic registration of shell interpreters can be disabled by the
5221 administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.
5225 Packages that install X11 fonts should update the database files that index the
5226 fonts within each fonts directory. This can easily be accomplished within the
5227 pkginstall framework.
5229 When a package installs X11 fonts, it must list the directories in which fonts
5230 are installed in the FONTS_DIRS.type variables, where type can be one of "ttf",
5231 "type1" or "x11". This will add hooks to the installation scripts to run the
5232 appropriate commands to update the fonts database files within each of those
5233 directories. For convenience, if the directory path is relative, it is taken to
5234 be relative to the package's installation prefix. Consider the following
5235 example, taken from fonts/dbz-ttf:
5237 FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF
5239 15.6.1. Disabling automatic update of the fonts databases
5241 The automatic update of fonts databases can be disabled by the administrator by
5242 setting the PKG_UPDATE_FONTS_DB environment variable to NO.
5244 Chapter 16. Options handling
5248 16.1. Global default options
5249 16.2. Converting packages to use bsd.options.mk
5251 16.4. Determining the options of dependencies
5253 Many packages have the ability to be built to support different sets of
5254 features. bsd.options.mk is a framework in pkgsrc that provides generic
5255 handling of those options that determine different ways in which the packages
5256 can be built. It's possible for the user to specify exactly which sets of
5257 options will be built into a package or to allow a set of global default
5260 There are two broad classes of behaviors that one might want to control via
5261 options. One is whether some particular feature is enabled in a program that
5262 will be built anyway, often by including or not including a dependency on some
5263 other package. The other is whether or not an additional program will be built
5264 as part of the package. Generally, it is better to make a split package for
5265 such additional programs instead of using options, because it enables binary
5266 packages to be built which can then be added separately. For example, the foo
5267 package might have minimal dependencies (those packages without which foo
5268 doesn't make sense), and then the foo-gfoo package might include the GTK
5269 frontend program gfoo. This is better than including a gtk option to foo that
5270 adds gfoo, because either that option is default, in which case binary users
5271 can't get foo without gfoo, or not default, in which case they can't get gfoo.
5272 With split packages, they can install foo without having GTK, and later decide
5273 to install gfoo (pulling in GTK at that time). This is an advantage to source
5274 users too, avoiding the need for rebuilds.
5276 Plugins with widely varying dependencies should usually be split instead of
5279 It is often more work to maintain split packages, especially if the upstream
5280 package does not support this. The decision of split vs. option should be made
5281 based on the likelihood that users will want or object to the various pieces,
5282 the size of the dependencies that are included, and the amount of work.
5284 A further consideration is licensing. Non-free parts, or parts that depend on
5285 non-free dependencies (especially plugins) should almost always be split if
5288 16.1. Global default options
5290 Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of
5291 the options that should be built into every package if that option is
5292 supported. This variable should be set in mk.conf.
5294 16.2. Converting packages to use bsd.options.mk
5296 The following example shows how bsd.options.mk should be used by the
5297 hypothetical ``wibble'' package, either in the package Makefile, or in a file,
5298 e.g. options.mk, that is included by the main package Makefile.
5300 PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
5301 PKG_SUPPORTED_OPTIONS= wibble-foo ldap
5302 PKG_OPTIONS_OPTIONAL_GROUPS= database
5303 PKG_OPTIONS_GROUP.database= mysql pgsql
5304 PKG_SUGGESTED_OPTIONS= wibble-foo
5305 PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
5306 PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo
5308 .include "../../mk/bsd.prefs.mk"
5310 # this package was previously named wibble2
5311 .if defined(PKG_OPTIONS.wibble2)
5312 PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
5313 PKG_OPTIONS_DEPRECATED_WARNINGS+= \
5314 "Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR} instead."
5317 .include "../../mk/bsd.options.mk"
5319 # Package-specific option-handling
5324 .if !empty(PKG_OPTIONS:Mwibble-foo)
5325 CONFIGURE_ARGS+= --enable-foo
5331 .if !empty(PKG_OPTIONS:Mldap)
5332 . include "../../databases/openldap-client/buildlink3.mk"
5333 CONFIGURE_ARGS+= --enable-ldap=${BUILDLINK_PREFIX.openldap-client}
5337 ### database support
5339 .if !empty(PKG_OPTIONS:Mmysql)
5340 . include "../../mk/mysql.buildlink3.mk"
5342 .if !empty(PKG_OPTIONS:Mpgsql)
5343 . include "../../mk/pgsql.buildlink3.mk"
5346 The first section contains the information about which build options are
5347 supported by the package, and any default options settings if needed.
5349 1. PKG_OPTIONS_VAR is the name of the make(1) variable that the user can set
5350 to override the default options. It should be set to PKG_OPTIONS.pkgbase.
5351 Do not set it to PKG_OPTIONS.${PKGBASE}, since PKGBASE is not defined at
5352 the point where the options are processed.
5354 2. PKG_SUPPORTED_OPTIONS is a list of build options supported by the package.
5356 3. PKG_OPTIONS_OPTIONAL_GROUPS is a list of names of groups of mutually
5357 exclusive options. The options in each group are listed in
5358 PKG_OPTIONS_GROUP.groupname. The most specific setting of any option from
5359 the group takes precedence over all other options in the group. Options
5360 from the groups will be automatically added to PKG_SUPPORTED_OPTIONS.
5362 4. PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, but
5363 building the packages will fail if no option from the group is selected.
5365 5. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of options. At least
5366 one option from each set must be selected. The options in each set are
5367 listed in PKG_OPTIONS_SET.setname. Options from the sets will be
5368 automatically added to PKG_SUPPORTED_OPTIONS. Building the package will
5369 fail if no option from the set is selected.
5371 6. PKG_SUGGESTED_OPTIONS is a list of build options which are enabled by
5374 7. PKG_OPTIONS_LEGACY_VARS is a list of "USE_VARIABLE:option" pairs that map
5375 legacy mk.conf variables to their option counterparts. Pairs should be
5376 added with "+=" to keep the listing of global legacy variables. A warning
5377 will be issued if the user uses a legacy variable.
5379 8. PKG_OPTIONS_LEGACY_OPTS is a list of "old-option:new-option" pairs that map
5380 options that have been renamed to their new counterparts. Pairs should be
5381 added with "+=" to keep the listing of global legacy options. A warning
5382 will be issued if the user uses a legacy option.
5384 9. PKG_LEGACY_OPTIONS is a list of options implied by deprecated variables
5385 used. This can be used for cases that neither PKG_OPTIONS_LEGACY_VARS nor
5386 PKG_OPTIONS_LEGACY_OPTS can handle, e. g. when PKG_OPTIONS_VAR is renamed.
5388 10. PKG_OPTIONS_DEPRECATED_WARNINGS is a list of warnings about deprecated
5389 variables or options used, and what to use instead.
5391 A package should never modify PKG_DEFAULT_OPTIONS or the variable named in
5392 PKG_OPTIONS_VAR. These are strictly user-settable. To suggest a default set of
5393 options, use PKG_SUGGESTED_OPTIONS.
5395 PKG_OPTIONS_VAR must be defined before including bsd.options.mk. If none of
5396 PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, and
5397 PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform-specific
5398 options if none of them is supported on the current platform), PKG_OPTIONS is
5399 set to the empty list and the package is otherwise treated as not using the
5402 After the inclusion of bsd.options.mk, the variable PKG_OPTIONS contains the
5403 list of selected build options, properly filtered to remove unsupported and
5406 The remaining sections contain the logic that is specific to each option. The
5407 correct way to check for an option is to check whether it is listed in
5410 .if !empty(PKG_OPTIONS:Moption)
5414 Options that enable similar features in different packages (like optional
5415 support for a library) should use a common name in all packages that support it
5416 (like the name of the library). If another package already has an option with
5417 the same meaning, use the same name.
5419 Options that enable features specific to one package, where it's unlikely that
5420 another (unrelated) package has the same (or a similar) optional feature,
5421 should use a name prefixed with pkgname-.
5423 If a group of related packages share an optional feature specific to that
5424 group, prefix it with the name of the "main" package (e. g.
5425 djbware-errno-hack).
5427 For new options, add a line to mk/defaults/options.description. Lines have two
5428 fields, separated by tab. The first field is the option name, the second its
5429 description. The description should be a whole sentence (starting with an
5430 uppercase letter and ending with a period) that describes what enabling the
5431 option does. E. g. "Enable ispell support." The file is sorted by option names.
5433 16.4. Determining the options of dependencies
5435 When writing buildlink3.mk files, it is often necessary to list different
5436 dependencies based on the options with which the package was built. For
5437 querying these options, the file pkgsrc/mk/pkg-build-options.mk should be used.
5438 A typical example looks like this:
5440 pkgbase := libpurple
5441 .include "../../mk/pkg-build-options.mk"
5443 .if !empty(PKG_BUILD_OPTIONS.libpurple:Mdbus)
5447 Including pkg-build-options.mk here will set the variable
5448 PKG_BUILD_OPTIONS.libpurple to the build options of the libpurple package,
5449 which can then be queried like PKG_OPTIONS in the options.mk file. See the file
5450 pkg-build-options.mk for more details.
5452 Chapter 17. The build process
5457 17.2. Program location
5458 17.3. Directories used during the build process
5459 17.4. Running a phase
5460 17.5. The fetch phase
5462 17.5.1. What to fetch and where to get it from
5463 17.5.2. How are the files fetched?
5465 17.6. The checksum phase
5466 17.7. The extract phase
5467 17.8. The patch phase
5468 17.9. The tools phase
5469 17.10. The wrapper phase
5470 17.11. The configure phase
5471 17.12. The build phase
5472 17.13. The test phase
5473 17.14. The install phase
5474 17.15. The package phase
5476 17.17. Other helpful targets
5480 This chapter gives a detailed description on how a package is built. Building a
5481 package is separated into different phases (for example fetch, build, install),
5482 all of which are described in the following sections. Each phase is split into
5483 so-called stages, which take the name of the containing phase, prefixed by one
5484 of pre-, do- or post-. (Examples are pre-configure, post-build.) Most of the
5485 actual work is done in the do-* stages.
5487 Never override the regular targets (like fetch), if you have to, override the
5490 The basic steps for building a program are always the same. First the program's
5491 source (distfile) must be brought to the local system and then extracted. After
5492 any pkgsrc-specific patches to compile properly are applied, the software can
5493 be configured, then built (usually by compiling), and finally the generated
5494 binaries, etc. can be put into place on the system.
5496 To get more details about what is happening at each step, you can set the
5497 PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in
5498 more details about the patch step.
5500 17.2. Program location
5502 Before outlining the process performed by the NetBSD package system in the next
5503 section, here's a brief discussion on where programs are installed, and which
5504 variables influence this.
5506 The automatic variable PREFIX indicates where all files of the final program
5507 shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
5508 pkgs in the cross category. The value of PREFIX needs to be put into the
5509 various places in the program's source where paths to these files are encoded.
5510 See Section 11.3, "patches/*" and Section 19.3.1, "Shared libraries - libtool"
5513 When choosing which of these variables to use, follow the following rules:
5515 * PREFIX always points to the location where the current pkg will be
5516 installed. When referring to a pkg's own installation path, use "${PREFIX}"
5519 * LOCALBASE is where all non-X11 pkgs are installed. If you need to construct
5520 a -I or -L argument to the compiler to find includes and libraries
5521 installed by another non-X11 pkg, use "${LOCALBASE}". The name LOCALBASE
5522 stems from FreeBSD, which installed all packages in /usr/local. As pkgsrc
5523 leaves /usr/local for the system administrator, this variable is a
5526 * X11BASE is where the actual X11 distribution (from xsrc, etc.) is
5527 installed. When looking for standard X11 includes (not those installed by a
5528 package), use "${X11BASE}".
5530 * X11-based packages are special in that they may be installed in either
5531 X11BASE or LOCALBASE.
5533 Usually, X11 packages should be installed under LOCALBASE whenever
5534 possible. Note that you will need to include ../../mk/x11.buildlink3.mk in
5535 them to request the presence of X11 and to get the right compilation flags.
5537 Even though, there are some packages that cannot be installed under
5538 LOCALBASE: those that come with app-defaults files. These packages are
5539 special and they must be placed under X11BASE. To accomplish this, set
5540 either USE_X11BASE or USE_IMAKE in your package.
5542 Some notes: If you need to find includes or libraries installed by a pkg
5543 that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in
5544 both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages
5545 in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default.
5547 * X11PREFIX should be used to refer to the installed location of an X11
5548 package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed,
5549 and to LOCALBASE if xpkgwedge is installed.
5551 * If xpkgwedge is installed, it is possible to have some packages installed
5552 in X11BASE and some in LOCALBASE. To determine the prefix of an installed
5553 package, the EVAL_PREFIX definition can be used. It takes pairs in the
5554 format "DIRNAME=<package>", and the make(1) variable DIRNAME will be set to
5555 the prefix of the installed package <package>, or "${X11PREFIX}" if the
5556 package is not installed.
5558 This is best illustrated by example.
5560 The following lines are taken from pkgsrc/wm/scwm/Makefile:
5562 EVAL_PREFIX+= GTKDIR=gtk+
5563 CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q}
5564 CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q}
5565 CONFIGURE_ARGS+= --enable-multibyte
5567 Specific defaults can be defined for the packages evaluated using
5568 EVAL_PREFIX, by using a definition of the form:
5570 GTKDIR_DEFAULT= ${LOCALBASE}
5572 where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair.
5574 * Within ${PREFIX}, packages should install files according to hier(7), with
5575 the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
5578 17.3. Directories used during the build process
5580 When building a package, various directories are used to store source files,
5581 temporary files, pkgsrc-internal files, and so on. These directories are
5584 Some of the directory variables contain relative pathnames. There are two
5585 common base directories for these relative directories: PKGSRCDIR/PKGPATH is
5586 used for directories that are pkgsrc-specific. WRKSRC is used for directories
5587 inside the package itself.
5591 This is an absolute pathname that points to the pkgsrc root directory.
5592 Generally, you don't need it.
5596 This is an absolute pathname that points to the current package.
5600 This is a pathname relative to PKGSRCDIR that points to the current
5605 This is an absolute pathname pointing to the directory where all work takes
5606 place. The distfiles are extracted to this directory. It also contains
5607 temporary directories and log files used by the various pkgsrc frameworks,
5608 like buildlink or the wrappers.
5612 This is an absolute pathname pointing to the directory where the distfiles
5613 are extracted. It is usually a direct subdirectory of WRKDIR, and often
5614 it's the only directory entry that isn't hidden. This variable may be
5615 changed by a package Makefile.
5617 The CREATE_WRKDIR_SYMLINK definition takes either the value yes or no and
5618 defaults to no. It indicates whether a symbolic link to the WRKDIR is to be
5619 created in the pkgsrc entry's directory. If users would like to have their
5620 pkgsrc trees behave in a read-only manner, then the value of
5621 CREATE_WRKDIR_SYMLINK should be set to no.
5623 17.4. Running a phase
5625 You can run a particular phase by typing make phase, where phase is the name of
5626 the phase. This will automatically run all phases that are required for this
5627 phase. The default phase is build, that is, when you run make without
5628 parameters in a package directory, the package will be built, but not
5631 17.5. The fetch phase
5633 The first step in building a package is to fetch the distribution files
5634 (distfiles) from the sites that are providing them. This is the task of the
5637 17.5.1. What to fetch and where to get it from
5639 In simple cases, MASTER_SITES defines all URLs from where the distfile, whose
5640 name is derived from the DISTNAME variable, is fetched. The more complicated
5641 cases are described below.
5643 The variable DISTFILES specifies the list of distfiles that have to be fetched.
5644 Its value defaults to ${DISTNAME}${EXTRACT_SUFX}, so that most packages don't
5645 need to define it at all. EXTRACT_SUFX is .tar.gz by default, but can be
5646 changed freely. Note that if your package requires additional distfiles to the
5647 default one, you cannot just append the additional filenames using the +=
5648 operator, but you have write for example:
5650 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
5652 Each distfile is fetched from a list of sites, usually MASTER_SITES. If the
5653 package has multiple DISTFILES or multiple PATCHFILES from different sites, you
5654 can set SITES.distfile to the list of URLs where the file distfile (including
5655 the suffix) can be found.
5657 DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
5658 DISTFILES+= foo-file.tar.gz
5659 SITES.foo-file.tar.gz= \
5660 http://www.somewhere.com/somehow/ \
5661 http://www.somewhereelse.com/mirror/somehow/
5663 When actually fetching the distfiles, each item from MASTER_SITES or SITES.*
5664 gets the name of each distfile appended to it, without an intermediate slash.
5665 Therefore, all site values have to end with a slash or other separator
5666 character. This allows for example to set MASTER_SITES to a URL of a CGI script
5667 that gets the name of the distfile as a parameter. In this case, the definition
5670 MASTER_SITES= http://www.example.com/download.cgi?file=
5672 The exception to this rule are URLs starting with a dash. In that case the URL
5673 is taken as is, fetched and the result stored under the name of the distfile.
5675 There are some predefined values for MASTER_SITES, which can be used in
5676 packages. The names of the variables should speak for themselves.
5678 ${MASTER_SITE_APACHE}
5679 ${MASTER_SITE_BACKUP}
5680 ${MASTER_SITE_CYGWIN}
5681 ${MASTER_SITE_DEBIAN}
5682 ${MASTER_SITE_FREEBSD}
5683 ${MASTER_SITE_FREEBSD_LOCAL}
5684 ${MASTER_SITE_GENTOO}
5685 ${MASTER_SITE_GNOME}
5687 ${MASTER_SITE_GNUSTEP}
5688 ${MASTER_SITE_IFARCHIVE}
5690 ${MASTER_SITE_MOZILLA}
5691 ${MASTER_SITE_MYSQL}
5692 ${MASTER_SITE_OPENOFFICE}
5693 ${MASTER_SITE_PERL_CPAN}
5694 ${MASTER_SITE_PGSQL}
5695 ${MASTER_SITE_R_CRAN}
5696 ${MASTER_SITE_SOURCEFORGE}
5697 ${MASTER_SITE_SOURCEFORGE_JP}
5698 ${MASTER_SITE_SUNSITE}
5700 ${MASTER_SITE_TEX_CTAN}
5701 ${MASTER_SITE_XCONTRIB}
5702 ${MASTER_SITE_XEMACS}
5704 Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP
5705 contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org/
5706 pub/NetBSD/packages/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local
5707 package source distributions that are maintained in ftp://ftp.NetBSD.org/pub/
5708 NetBSD/packages/distfiles/LOCAL_PORTS/.
5710 If you choose one of these predefined sites, you may want to specify a
5711 subdirectory of that site. Since these macros may expand to more than one
5712 actual site, you must use the following construct to specify a subdirectory:
5714 MASTER_SITES= ${MASTER_SITE_GNU:=subdirectory/name/}
5715 MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=project_name/}
5717 Note the trailing slash after the subdirectory name.
5719 17.5.2. How are the files fetched?
5721 The fetch phase makes sure that all the distfiles exist in a local directory
5722 (DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they
5723 are fetched using commands of the form
5725 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
5727 where ${site} varies through several possibilities in turn: first,
5728 MASTER_SITE_OVERRIDE is tried, then the sites specified in either SITES.file if
5729 defined, else MASTER_SITES or PATCH_SITES, as applies, then finally the value
5730 of MASTER_SITE_BACKUP. The order of all except the first and the last can be
5731 optionally sorted by the user, via setting either MASTER_SORT_RANDOM, and
5732 MASTER_SORT_AWK or MASTER_SORT_REGEX.
5734 The specific command and arguments used depend on the FETCH_USING parameter.
5735 The example above is for FETCH_USING=custom.
5737 The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles
5738 target to mirror the distfiles, if they are freely distributable. Packages
5739 setting NO_SRC_ON_FTP (usually to "${RESTRICTED}") will not have their
5742 17.6. The checksum phase
5744 After the distfile(s) are fetched, their checksum is generated and compared
5745 with the checksums stored in the distinfo file. If the checksums don't match,
5746 the build is aborted. This is to ensure the same distfile is used for building,
5747 and that the distfile wasn't changed, e.g. by some malign force, deliberately
5748 changed distfiles on the master distribution site or network lossage.
5750 17.7. The extract phase
5752 When the distfiles are present on the local system, they need to be extracted,
5753 as they usually come in the form of some compressed archive format.
5755 By default, all DISTFILES are extracted. If you only need some of them, you can
5756 set the EXTRACT_ONLY variable to the list of those files.
5758 Extracting the files is usually done by a little program, mk/extract/extract,
5759 which already knows how to extract various archive formats, so most likely you
5760 will not need to change anything here. But if you need, the following variables
5763 EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}
5765 Use these variables to override the default options for an extract command,
5766 which are defined in mk/extract/extract.
5770 This variable can be set to bsdtar, gtar, nbtar (which is the default
5771 value), pax, or an absolute pathname pointing to the command with which tar
5772 archives should be extracted. It is preferred to choose bsdtar over gtar if
5773 NetBSD's pax-as-tar is not good enough.
5775 If the extract program doesn't serve your needs, you can also override the
5776 EXTRACT_CMD variable, which holds the command used for extracting the files.
5777 This command is executed in the ${WRKSRC} directory. During execution of this
5778 command, the shell variable extract_file holds the absolute pathname of the
5779 file that is going to be extracted.
5781 And if that still does not suffice, you can override the do-extract target in
5782 the package Makefile.
5784 17.8. The patch phase
5786 After extraction, all the patches named by the PATCHFILES, those present in the
5787 patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
5788 /usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz
5789 are uncompressed before they are applied, files ending in .orig or .rej are
5790 ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See
5791 Section 11.3, "patches/*" for more details.
5793 By default patch(1) is given special args to make it fail if the patches apply
5794 with some lines of fuzz. Please fix (regen) the patches so that they apply
5795 cleanly. The rationale behind this is that patches that don't apply cleanly may
5796 end up being applied in the wrong place, and cause severe harm there.
5798 17.9. The tools phase
5800 This is covered in Chapter 18, Tools needed for building or running.
5802 17.10. The wrapper phase
5804 This phase creates wrapper programs for the compilers and linkers. The
5805 following variables can be used to tweak the wrappers.
5809 The command used to print progress messages. Does nothing by default. Set
5810 to ${ECHO} to see the progress messages.
5814 This variable can be set to yes (default) or no, depending on whether you
5815 want additional information in the wrapper log file.
5817 WRAPPER_UPDATE_CACHE
5819 This variable can be set to yes or no, depending on whether the wrapper
5820 should use its cache, which will improve the speed. The default value is
5821 yes, but is forced to no if the platform does not support it.
5823 WRAPPER_REORDER_CMDS
5825 A list of reordering commands. A reordering command has the form reorder:l:
5826 lib1:lib2. It ensures that that -llib1 occurs before -llib2.
5828 WRAPPER_TRANSFORM_CMDS
5830 A list of transformation commands. [TODO: investigate further]
5832 17.11. The configure phase
5834 Most pieces of software need information on the header files, system calls, and
5835 library routines which are available on the platform they run on. The process
5836 of determining this information is known as configuration, and is usually
5837 automated. In most cases, a script is supplied with the distfiles, and its
5838 invocation results in generation of header files, Makefiles, etc.
5840 If the package contains a configure script, this can be invoked by setting
5841 HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you
5842 should set GNU_CONFIGURE to "yes" instead. What happens in the configure phase
5845 .for d in ${CONFIGURE_DIRS}
5848 && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
5851 CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In
5852 each of these directories, the configure script is run with the environment
5853 CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV,
5854 CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed
5857 If the program uses an Imakefile for configuration, the appropriate steps can
5858 be invoked by setting USE_IMAKE to "yes". (If you only want the package
5859 installed in ${X11PREFIX} but xmkmf not being run, set USE_X11BASE instead.)
5860 You can add variables to xmkmf's environment by adding them to the SCRIPTS_ENV
5863 If the program uses cmake for configuration, the appropriate steps can be
5864 invoked by setting USE_CMAKE to "yes". You can add variables to cmake's
5865 environment by adding them to the CONFIGURE_ENV variable and arguments to cmake
5866 by adding them to the CMAKE_ARGS variable. The top directory argument is given
5867 by the CMAKE_ARG_PATH variable, that defaults to "." (relative to
5870 If there is no configure step at all, set NO_CONFIGURE to "yes".
5872 17.12. The build phase
5874 For building a package, a rough equivalent of the following code is executed.
5876 .for d in ${BUILD_DIRS}
5879 && env ${MAKE_ENV} \
5880 ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \
5885 BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of
5886 these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and
5887 arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE
5888 and BUILD_TARGET may all be changed by the package.
5890 The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", "
5891 make" otherwise. The default value of MAKE_FILE is "Makefile", and BUILD_TARGET
5894 If there is no build step at all, set NO_BUILD to "yes".
5896 17.13. The test phase
5900 17.14. The install phase
5902 Once the build stage has completed, the final step is to install the software
5903 in public directories, so users can access the programs and files.
5905 In the install phase, a rough equivalent of the following code is executed.
5906 Additionally, before and after this code, much magic is performed to do
5907 consistency checks, registering the package, and so on.
5909 .for d in ${INSTALL_DIRS}
5912 && env ${MAKE_ENV} \
5913 ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \
5918 The variable's meanings are analogous to the ones in the build phase.
5919 INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is "install" by default,
5920 plus "install.man" if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
5923 In the install phase, the following variables are useful. They are all
5924 variations of the install(1) command that have the owner, group and permissions
5925 preset. INSTALL is the plain install command. The specialized variants,
5926 together with their intended use, are:
5930 directories that contain binaries
5934 directories that contain scripts
5938 directories that contain shared and static libraries
5942 directories that contain data files
5946 directories that contain man pages
5950 binaries that can be stripped from debugging symbols
5954 binaries that cannot be stripped
5962 shared and static libraries
5970 data files for games
5976 Some other variables are:
5980 A list of directories relative to PREFIX that are created by pkgsrc at the
5981 beginning of the install phase. The package is supposed to create all
5982 needed directories itself before installing files to it and list all other
5985 In the rare cases that a package shouldn't install anything, set NO_INSTALL to
5986 "yes". This is mostly relevant for packages in the regress category.
5988 17.15. The package phase
5990 Once the install stage has completed, a binary package of the installed files
5991 can be built. These binary packages can be used for quick installation without
5992 previous compilation, e.g. by the make bin-install or by using pkg_add.
5994 By default, the binary packages are created in ${PACKAGES}/All and symlinks are
5995 created in ${PACKAGES}/category, one for each category in the CATEGORIES
5996 variable. PACKAGES defaults to pkgsrc/packages.
6000 Once you're finished with a package, you can clean the work directory by
6001 running make clean. If you want to clean the work directories of all
6002 dependencies too, use make clean-depends.
6004 17.17. Other helpful targets
6008 For any of the main targets described in the previous section, two
6009 auxiliary targets exist with "pre-" and "post-" used as a prefix for the
6010 main target's name. These targets are invoked before and after the main
6011 target is called, allowing extra configuration or installation steps be
6012 performed from a package's Makefile, for example, which a program's
6013 configure script or install target omitted.
6017 Should one of the main targets do the wrong thing, and should there be no
6018 variable to fix this, you can redefine it with the do-* target. (Note that
6019 redefining the target itself instead of the do-* target is a bad idea, as
6020 the pre-* and post-* targets won't be called anymore, etc.) You will not
6021 usually need to do this.
6025 If you did a make install and you noticed some file was not installed
6026 properly, you can repeat the installation with this target, which will
6027 ignore the "already installed" flag.
6029 This is the default value of DEPENDS_TARGET except in the case of make
6030 update and make package, where the defaults are "package" and "update",
6035 This target does a pkg_delete(1) in the current directory, effectively
6036 de-installing the package. The following variables can be used to tune the
6041 Add a "-v" to the pkg_delete(1) command.
6045 Remove all packages that require (depend on) the given package. This
6046 can be used to remove any packages that may have been pulled in by a
6047 given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
6048 pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding "-R
6049 " to the pkg_delete(1) command line.
6053 Install a binary package from local disk and via FTP from a list of sites
6054 (see the BINPKG_SITES variable), and do a make package if no binary package
6055 is available anywhere. The arguments given to pkg_add can be set via
6056 BIN_INSTALL_FLAGS e.g., to do verbose operation, etc.
6060 This target causes the current package to be updated to the latest version.
6061 The package and all depending packages first get de-installed, then current
6062 versions of the corresponding packages get compiled and installed. This is
6063 similar to manually noting which packages are currently installed, then
6064 performing a series of make deinstall and make install (or whatever
6065 UPDATE_TARGET is set to) for these packages.
6067 You can use the "update" target to resume package updating in case a
6068 previous make update was interrupted for some reason. However, in this
6069 case, make sure you don't call make clean or otherwise remove the list of
6070 dependent packages in WRKDIR. Otherwise, you lose the ability to
6071 automatically update the current package along with the dependent packages
6074 Resuming an interrupted make update will only work as long as the package
6075 tree remains unchanged. If the source code for one of the packages to be
6076 updated has been changed, resuming make update will most certainly fail!
6078 The following variables can be used either on the command line or in
6079 mk.conf to alter the behaviour of make update:
6083 Install target to recursively use for the updated package and the
6084 dependent packages. Defaults to DEPENDS_TARGET if set, "install"
6085 otherwise for make update. Other good targets are "package" or "
6086 bin-install". Do not set this to "update" or you will get stuck in an
6091 Don't clean up after updating. Useful if you want to leave the work
6092 sources of the updated packages around for inspection or other
6093 purposes. Be sure you eventually clean up the source tree (see the "
6094 clean-update" target below) or you may run into troubles with old
6095 source code still lying around on your next make or make update.
6099 Deinstall each package before installing (making DEPENDS_TARGET). This
6100 may be necessary if the "clean-update" target (see below) was called
6101 after interrupting a running make update.
6105 Allows you to disable recursion and hardcode the target for packages.
6106 The default is "update" for the update target, facilitating a recursive
6107 update of prerequisite packages. Only set DEPENDS_TARGET if you want to
6108 disable recursive updates. Use UPDATE_TARGET instead to just set a
6109 specific target for each package to be installed during make update
6114 Clean the source tree for all packages that would get updated if make
6115 update was called from the current directory. This target should not be
6116 used if the current package (or any of its depending packages) have already
6117 been de-installed (e.g., after calling make update) or you may lose some
6118 packages you intended to update. As a rule of thumb: only use this target
6119 before the first time you run make update and only if you have a dirty
6120 package tree (e.g., if you used NOCLEAN).
6122 If you are unsure about whether your tree is clean, you can either perform
6123 a make clean at the top of the tree, or use the following sequence of
6124 commands from the directory of the package you want to update (before
6125 running make update for the first time, otherwise you lose all the packages
6126 you wanted to update!):
6129 # make clean CLEANDEPENDS=YES
6133 The following variables can be used either on the command line or in
6134 mk.conf to alter the behaviour of make clean-update:
6138 After make clean, do not reconstruct the list of directories to update
6139 for this package. Only use this if make update successfully installed
6140 all packages you wanted to update. Normally, this is done automatically
6141 on make update, but may have been suppressed by the NOCLEAN variable
6146 Update the installation of the current package. This differs from update in
6147 that it does not replace dependent packages. You will need to install
6148 pkgtools/pkg_tarup for this target to work.
6150 Be careful when using this target! There are no guarantees that dependent
6151 packages will still work, in particular they will most certainly break if
6152 you make replace a library package whose shared library major version
6153 changed between your installed version and the new one. For this reason,
6154 this target is not officially supported and only recommended for advanced
6159 This target invokes pkg_info(1) for the current package. You can use this
6160 to check which version of a package is installed.
6164 This is a top-level command, i.e. it should be used in the pkgsrc
6165 directory. It creates a database of all packages in the local pkgsrc tree,
6166 including dependencies, comment, maintainer, and some other useful
6167 information. Individual entries are created by running make describe in the
6168 packages' directories. This index file is saved as pkgsrc/INDEX. It can be
6169 displayed in verbose format by running make print-index. You can search in
6170 it with make search key=something. You can extract a list of all packages
6171 that depend on a particular one by running make show-deps PKG=somepackage.
6173 Running this command takes a very long time, some hours even on fast
6178 This target generates a README.html file, which can be viewed using a
6179 browser such as www/firefox or www/links. The generated files contain
6180 references to any packages which are in the PACKAGES directory on the local
6181 host. The generated files can be made to refer to URLs based on
6182 FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate
6183 README.html files which pointed to binary packages on the local machine, in
6184 the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
6185 FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
6186 subdirectories will be searched for all the binary packages.
6188 The target can be run at the toplevel or in category directories, in which
6189 case it descends recursively.
6193 This is a top-level command, run it in pkgsrc. Use this target to create a
6194 file README-all.html which contains a list of all packages currently
6195 available in the NetBSD Packages Collection, together with the category
6196 they belong to and a short description. This file is compiled from the
6197 pkgsrc/*/README.html files, so be sure to run this after a make readme.
6201 This is very much the same as the "readme" target (see above), but is to be
6202 used when generating a pkgsrc tree to be written to a CD-ROM. This target
6203 also produces README.html files, and can be made to refer to URLs based on
6204 CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
6208 This target shows which distfiles and patchfiles are needed to build the
6209 package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not
6214 This target shows nothing if the package is not installed. If a version of
6215 this package is installed, but is not the version provided in this version
6216 of pkgsrc, then a warning message is displayed. This target can be used to
6217 show which of your installed packages are downlevel, and so the old
6218 versions can be deleted, and the current ones added.
6222 This target shows the directory in the pkgsrc hierarchy from which the
6223 package can be built and installed. This may not be the same directory as
6224 the one from which the package was installed. This target is intended to be
6225 used by people who may wish to upgrade many packages on a single host, and
6226 can be invoked from the top-level pkgsrc Makefile by using the "
6227 show-host-specific-pkgs" target.
6229 show-installed-depends
6231 This target shows which installed packages match the current package's
6232 DEPENDS. Useful if out of date dependencies are causing build problems.
6236 After a package is installed, check all its binaries and (on ELF platforms)
6237 shared libraries to see if they find the shared libs they need. Run by
6238 default if PKG_DEVELOPER is set in mk.conf.
6242 After a "make install" from a new or upgraded pkg, this prints out an
6243 attempt to generate a new PLIST from a find -newer work/.extract_done. An
6244 attempt is made to care for shared libs etc., but it is strongly
6245 recommended to review the result before putting it into PLIST. On upgrades,
6246 it's useful to diff the output of this command against an already existing
6249 If the package installs files via tar(1) or other methods that don't update
6250 file access times, be sure to add these files manually to your PLIST, as
6251 the "find -newer" command used by this target won't catch them!
6253 See Section 13.3, "Tweaking output of make print-PLIST" for more
6254 information on this target.
6258 Used to do bulk builds. If an appropriate binary package already exists, no
6259 action is taken. If not, this target will compile, install and package it
6260 (and its depends, if PKG_DEPENDS is set properly. See Section 7.3.1,
6261 "Configuration"). After creating the binary package, the sources, the
6262 just-installed package and its required packages are removed, preserving
6265 Beware that this target may deinstall all packages installed on a system!
6269 Used during bulk-installs to install required packages. If an up-to-date
6270 binary package is available, it will be installed via pkg_add(1). If not,
6271 make bulk-package will be executed, but the installed binary won't be
6274 A binary package is considered "up-to-date" to be installed via pkg_add(1)
6277 * None of the package's files (Makefile, ...) were modified since it was
6280 * None of the package's required (binary) packages were modified since it
6283 Beware that this target may deinstall all packages installed on a system!
6285 Chapter 18. Tools needed for building or running
6289 18.1. Tools for pkgsrc builds
6290 18.2. Tools needed by packages
6291 18.3. Tools provided by platforms
6292 18.4. Questions regarding the tools
6294 The USE_TOOLS definition is used both internally by pkgsrc and also for
6295 individual packages to define what commands are needed for building a package
6296 (like BUILD_DEPENDS) or for later run-time of an installed packaged (such as
6297 DEPENDS). If the native system provides an adequate tool, then in many cases, a
6298 pkgsrc package will not be used.
6300 When building a package, the replacement tools are made available in a
6301 directory (as symlinks or wrapper scripts) that is early in the executable
6302 search path. Just like the buildlink system, this helps with consistent builds.
6304 A tool may be needed to help build a specific package. For example, perl, GNU
6305 make (gmake) or yacc may be needed.
6307 Also a tool may be needed, for example, because the native system's supplied
6308 tool may be inefficient for building a package with pkgsrc. For example, a
6309 package may need GNU awk, bison (instead of yacc) or a better sed.
6311 The tools used by a package can be listed by running make show-tools.
6313 18.1. Tools for pkgsrc builds
6315 The default set of tools used by pkgsrc is defined in bsd.pkg.mk. This includes
6316 standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be
6317 seen by running: make show-var VARNAME=USE_TOOLS.
6319 If a package needs a specific program to build then the USE_TOOLS variable can
6320 be used to define the tools needed.
6322 18.2. Tools needed by packages
6324 In the following examples, the :pkgsrc means to use the pkgsrc version and not
6325 the native version for a build dependency. And the :run means that it is used
6326 for a run-time dependencies also (and becomes a DEPENDS). The default is a
6327 build dependency which can be set with :build. (So in this example, it is the
6328 same as gmake:build and pkg-config:build.)
6330 USE_TOOLS+= mktemp:pkgsrc
6331 USE_TOOLS+= gmake perl:run pkg-config
6333 When using the tools framework, a TOOLS_PATH.foo variable is defined which
6334 contains the full path to the appropriate tool. For example, TOOLS_PATH.bash
6335 could be "/bin/bash" on Linux systems.
6337 If you always need a pkgsrc version of the tool at run-time, then just use
6340 18.3. Tools provided by platforms
6342 When improving or porting pkgsrc to a new platform, have a look at (or create)
6343 the corresponding platform specific make file fragment under pkgsrc/mk/tools/
6344 tools.${OPSYS}.mk which defines the name of the common tools. For example:
6346 .if exists(/usr/bin/bzcat)
6347 TOOLS_PLATFORM.bzcat?= /usr/bin/bzcat
6348 .elif exists(/usr/bin/bzip2)
6349 TOOLS_PLATFORM.bzcat?= /usr/bin/bzip2 -cd
6352 TOOLS_PLATFORM.true?= true # shell builtin
6354 18.4. Questions regarding the tools
6356 18.4.1. How do I add a new tool?
6357 18.4.2. How do I get a list of all available tools?
6358 18.4.3. How can I get a list of all the tools that a package is using while
6359 being built? I want to know whether it uses sed or not.
6361 18.4.1. How do I add a new tool?
6365 18.4.2. How do I get a list of all available tools?
6369 18.4.3. How can I get a list of all the tools that a package is using while
6370 being built? I want to know whether it uses sed or not.
6372 Currently, you can't. (TODO: But I want to be able to do it.)
6374 Chapter 19. Making your package work
6378 19.1. General operation
6380 19.1.1. Portability of packages
6381 19.1.2. How to pull in user-settable variables from mk.conf
6382 19.1.3. User interaction
6383 19.1.4. Handling licenses
6384 19.1.5. Restricted packages
6385 19.1.6. Handling dependencies
6386 19.1.7. Handling conflicts with other packages
6387 19.1.8. Packages that cannot or should not be built
6388 19.1.9. Packages which should not be deleted, once installed
6389 19.1.10. Handling packages with security problems
6390 19.1.11. How to handle incrementing versions when fixing an existing
6392 19.1.12. Substituting variable text in the package files (the SUBST
6395 19.2. Fixing problems in the fetch phase
6397 19.2.1. Packages whose distfiles aren't available for plain downloading
6398 19.2.2. How to handle modified distfiles with the 'old' name
6400 19.3. Fixing problems in the configure phase
6402 19.3.1. Shared libraries - libtool
6403 19.3.2. Using libtool on GNU packages that already support libtool
6404 19.3.3. GNU Autoconf/Automake
6406 19.4. Programming languages
6408 19.4.1. C, C++, and Fortran
6410 19.4.3. Packages containing perl scripts
6411 19.4.4. Other programming languages
6413 19.5. Fixing problems in the build phase
6415 19.5.1. Compiling C and C++ code conditionally
6416 19.5.2. How to handle compiler bugs
6417 19.5.3. Undefined reference to "..."
6418 19.5.4. Running out of memory
6420 19.6. Fixing problems in the install phase
6422 19.6.1. Creating needed directories
6423 19.6.2. Where to install documentation
6424 19.6.3. Installing highscore files
6425 19.6.4. Adding DESTDIR support to packages
6426 19.6.5. Packages with hardcoded paths to other interpreters
6427 19.6.6. Packages installing perl modules
6428 19.6.7. Packages installing info files
6429 19.6.8. Packages installing man pages
6430 19.6.9. Packages installing GConf data files
6431 19.6.10. Packages installing scrollkeeper/rarian data files
6432 19.6.11. Packages installing X11 fonts
6433 19.6.12. Packages installing GTK2 modules
6434 19.6.13. Packages installing SGML or XML data
6435 19.6.14. Packages installing extensions to the MIME database
6436 19.6.15. Packages using intltool
6437 19.6.16. Packages installing startup scripts
6438 19.6.17. Packages installing TeX modules
6439 19.6.18. Packages supporting running binaries in emulation
6440 19.6.19. Packages installing hicolor theme icons
6441 19.6.20. Packages installing desktop files
6443 19.7. Marking packages as having problems
6445 19.1. General operation
6447 19.1.1. Portability of packages
6449 One appealing feature of pkgsrc is that it runs on many different platforms. As
6450 a result, it is important to ensure, where possible, that packages in pkgsrc
6451 are portable. This chapter mentions some particular details you should pay
6452 attention to while working on pkgsrc.
6454 19.1.2. How to pull in user-settable variables from mk.conf
6456 The pkgsrc user can configure pkgsrc by overriding several variables in the
6457 file pointed to by MAKECONF, which is mk.conf by default. When you want to use
6458 those variables in the preprocessor directives of make(1) (for example .if or
6459 .for), you need to include the file ../../mk/bsd.prefs.mk before, which in turn
6460 loads the user preferences.
6462 But note that some variables may not be completely defined after ../../mk/
6463 bsd.prefs.mk has been included, as they may contain references to variables
6464 that are not yet defined. In shell commands this is no problem, since variables
6465 are actually macros, which are only expanded when they are used. But in the
6466 preprocessor directives mentioned above and in dependency lines (of the form
6467 target: dependencies) the variables are expanded at load time.
6471 Currently there is no exhaustive list of all variables that tells you whether
6472 they can be used at load time or only at run time, but it is in preparation.
6474 19.1.3. User interaction
6476 Occasionally, packages require interaction from the user, and this can be in a
6479 * When fetching the distfiles, some packages require user interaction such as
6480 entering username/password or accepting a license on a web page.
6482 * When extracting the distfiles, some packages may ask for passwords.
6484 * help to configure the package before it is built
6486 * help during the build process
6488 * help during the installation of a package
6490 The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of
6491 an interactive stage which will be needed, and this should be set in the
6492 package's Makefile, e.g.:
6494 INTERACTIVE_STAGE= build
6497 Multiple interactive stages can be specified:
6499 INTERACTIVE_STAGE= configure install
6502 The user can then decide to skip this package by setting the BATCH variable.
6504 19.1.4. Handling licenses
6506 Authors of software can choose the licence under which software can be copied.
6507 This is due to copyright law, and reasons for license choices are outside the
6508 scope of pkgsrc. The pkgsrc system recognizes that there are a number of
6509 licenses which some users may find objectionable or difficult or impossible to
6510 comply with. The Free Software Foundation has declared some licenses "Free",
6511 and the Open Source Initiative has a definition of "Open Source". The pkgsrc
6512 system, as a policy choice, does not label packages which have licenses that
6513 are Free or Open Source. However, packages without a license meeting either of
6514 those tests are labeled with a license tag denoting the license. Note that a
6515 package with no license to copy trivially does not meet either the Free or Open
6518 For packages which are not Free or Open Source, pkgsrc will not build the
6519 package unless the user has indicated to pkgsrc that packages with that
6520 particular license may be built. Note that this documentation avoids the term
6521 "accepted the license". The pkgsrc system is merely providing a mechanism to
6522 avoid accidentally building a package with a non-free license; judgement and
6523 responsibility remain with the user. (Installation of binary packages are not
6524 currently subject to this mechanism; this is a bug.)
6526 One might want to only install packages with a BSD license, or the GPL, and not
6527 the other. The free licenses are added to the default ACCEPTABLE_LICENSES
6528 variable. The user can override the default by setting the ACCEPTABLE_LICENSES
6529 variable with "=" instead of "+=". The licenses accepted by default are:
6532 gnu-gpl-v2 gnu-lgpl-v2
6533 gnu-gpl-v3 gnu-lgpl-v3
6534 original-bsd modified-bsd
6541 The license tag mechanism is intended to address copyright-related issues
6542 surrounding building, installing and using a package, and not to address
6543 redistribution issues (see RESTRICTED and NO_SRC_ON_FTP, etc.). Packages with
6544 redistribution restrictions should set these tags.
6546 Denoting that a package may be copied according to a particular license is done
6547 by placing the license in pkgsrc/licenses and setting the LICENSE variable to a
6548 string identifying the license, e.g. in graphics/xv:
6553 When trying to build, the user will get a notice that the package is covered by
6554 a license which has not been placed in the ACCEPTABLE_LICENSES variable:
6557 ===> xv-3.10anb9 has an unacceptable license: xv-license.
6558 ===> To view the license, enter "/usr/bin/make show-license".
6559 ===> To indicate acceptance, add this line to your /etc/mk.conf:
6560 ===> ACCEPTABLE_LICENSES+=xv-license
6564 The license can be viewed with make show-license, and if the user so chooses,
6565 the line printed above can be added to mk.conf to convey to pkgsrc that it
6566 should not in the future fail because of that license:
6568 ACCEPTABLE_LICENSES+=xv-license
6571 When adding a package with a new license, the license text should be added to
6572 pkgsrc/licenses for displaying. A list of known licenses can be seen in this
6575 When the license changes (in a way other than formatting), please make sure
6576 that the new license has a different name (e.g., append the version number if
6577 it exists, or the date). Just because a user told pkgsrc to build programs
6578 under a previous version of a license does not mean that pkgsrc should build
6579 programs under the new licenses. The higher-level point is that pkgsrc does not
6580 evaluate licenses for reasonableness; the only test is a mechanistic test of
6581 whether a particular text has been approved by either of two bodies.
6583 The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar language
6584 is deprecated because it does not crisply refer to a particular license text.
6585 Another problem with such usage is that it does not enable a user to tell
6586 pkgsrc to proceed for a single package without also telling pkgsrc to proceed
6587 for all packages with that tag.
6589 19.1.5. Restricted packages
6591 Some licenses restrict how software may be re-distributed. Because a license
6592 tag is required unless the package is Free or Open Source, all packages with
6593 restrictions should have license tags. By declaring the restrictions, package
6594 tools can automatically refrain from e.g. placing binary packages on FTP sites.
6596 There are four restrictions that may be encoded, which are the cross product of
6597 sources (distfiles) and binaries not being placed on FTP sites and CD-ROMs.
6598 Because this is rarely the exact language in any license, and because non-Free
6599 licenses tend to be different from each other, pkgsrc adopts a definition of
6600 FTP and CD-ROM. Pkgsrc uses "FTP" to mean that the source or binary file should
6601 not be made available over the Internet at no charge. Pkgsrc uses "CD-ROM" to
6602 mean that the source or binary may not be made available on some kind of media,
6603 together with other source and binary packages, and which is sold for a
6604 distribution charge.
6606 In order to encode these restrictions, the package system defines five make
6607 variables that can be set to note these restrictions:
6611 This variable should be set whenever a restriction exists (regardless of
6612 its kind). Set this variable to a string containing the reason for the
6613 restriction. It should be understood that those wanting to understand the
6614 restriction will have to read the license, and perhaps seek advice of
6619 Binaries may not be placed on CD-ROM containing other binary packages, for
6620 which a distribution charge may be made. In this case, set this variable to
6625 Binaries may not made available on the Internet without charge. In this
6626 case, set this variable to ${RESTRICTED}. If this variable is set, binary
6627 packages will not be included on ftp.NetBSD.org.
6631 Distfiles may not be placed on CD-ROM, together with other distfiles, for
6632 which a fee may be charged. In this case, set this variable to $
6637 Distfiles may not made available via FTP at no charge. In this case, set
6638 this variable to ${RESTRICTED}. If this variable is set, the distfile(s)
6639 will not be mirrored on ftp.NetBSD.org.
6641 19.1.6. Handling dependencies
6643 Your package may depend on some other package being present - and there are
6644 various ways of expressing this dependency. pkgsrc supports the BUILD_DEPENDS
6645 and DEPENDS definitions, the USE_TOOLS definition, as well as dependencies via
6646 buildlink3.mk, which is the preferred way to handle dependencies, and which
6647 uses the variables named above. See Chapter 14, Buildlink methodology for more
6650 The basic difference between the two variables is as follows: The DEPENDS
6651 definition registers that pre-requisite in the binary package so it will be
6652 pulled in when the binary package is later installed, whilst the BUILD_DEPENDS
6653 definition does not, marking a dependency that is only needed for building the
6656 This means that if you only need a package present whilst you are building, it
6657 should be noted as a BUILD_DEPENDS.
6659 The format for a BUILD_DEPENDS and a DEPENDS definition is:
6661 <pre-req-package-name>:../../<category>/<pre-req-package>
6664 Please note that the "pre-req-package-name" may include any of the wildcard
6665 version numbers recognized by pkg_info(1).
6667 1. If your package needs another package's binaries or libraries to build or
6668 run, and if that package has a buildlink3.mk file available, use it:
6670 .include "../../graphics/jpeg/buildlink3.mk"
6673 2. If your package needs to use another package to build itself and there is
6674 no buildlink3.mk file available, use the BUILD_DEPENDS definition:
6676 BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
6679 3. If your package needs a library with which to link and again there is no
6680 buildlink3.mk file available, this is specified using the DEPENDS
6681 definition. For example:
6683 DEPENDS+= xpm-3.4j:../../graphics/xpm
6686 You can also use wildcards in package dependencies:
6688 DEPENDS+= xpm-[0-9]*:../../graphics/xpm
6691 Note that such wildcard dependencies are retained when creating binary
6692 packages. The dependency is checked when installing the binary package and
6693 any package which matches the pattern will be used. Wildcard dependencies
6694 should be used with care.
6696 The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
6697 matches such as "tk-postgresql" matching a "tk-*" DEPENDS.
6699 Wildcards can also be used to specify that a package will only build
6700 against a certain minimum version of a pre-requisite:
6702 DEPENDS+= tiff>=3.5.4:../../graphics/tiff
6705 This means that the package will build against version 3.5.4 of the tiff
6706 library or newer. Such a dependency may be warranted if, for example, the
6707 API of the library has changed with version 3.5.4 and a package would not
6708 compile against an earlier version of tiff.
6710 Please note that such dependencies should only be updated if a package
6711 requires a newer pre-requisite, but not to denote recommendations such as
6712 ABI changes that do not prevent a package from building correctly. Such
6713 recommendations can be expressed using ABI_DEPENDS:
6715 ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff
6718 In addition to the above DEPENDS line, this denotes that while a package
6719 will build against tiff>=3.5.4, at least version 3.6.1 is recommended.
6720 ABI_DEPENDS entries will be turned into dependencies unless explicitly
6721 ignored (in which case a warning will be printed).
6723 To ignore these ABI dependency recommendations and just use the required
6724 DEPENDS, set USE_ABI_DEPENDS=NO. This may make it easier and faster to
6725 update packages built using pkgsrc, since older compatible dependencies can
6726 continue to be used. This is useful for people who watch their rebuilds
6727 very carefully; it is not very good as a general-purpose hammer. If you use
6728 it, you need to be mindful of possible ABI changes, including those from
6731 Packages that are built with recommendations ignored may not be uploaded to
6732 ftp.NetBSD.org by developers and should not be used across different
6733 systems that may have different versions of binary packages installed.
6735 For security fixes, please update the package vulnerabilities file. See
6736 Section 19.1.10, "Handling packages with security problems" for more
6739 4. If your package needs some executable to be able to run correctly and if
6740 there's no buildlink3.mk file, this is specified using the DEPENDS
6741 variable. The print/lyx package needs to be able to execute the latex
6742 binary from the teTeX package when it runs, and that is specified:
6744 DEPENDS+= teTeX-[0-9]*:../../print/teTeX
6747 The comment about wildcard dependencies from previous paragraph applies
6750 If your package needs files from another package to build, add the relevant
6751 distribution files to DISTFILES, so they will be extracted automatically. See
6752 the print/ghostscript package for an example. (It relies on the jpeg sources
6753 being present in source form during the build.)
6755 19.1.7. Handling conflicts with other packages
6757 Your package may conflict with other packages a user might already have
6758 installed on his system, e.g. if your package installs the same set of files as
6759 another package in the pkgsrc tree.
6761 In this case you can set CONFLICTS to a space-separated list of packages
6762 (including version string) your package conflicts with.
6764 For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus
6765 you set in pkgsrc/x11/Xaw3d/Makefile:
6767 CONFLICTS= Xaw-Xpm-[0-9]*
6770 and in pkgsrc/x11/Xaw-Xpm/Makefile:
6772 CONFLICTS= Xaw3d-[0-9]*
6775 Packages will automatically conflict with other packages with the name prefix
6776 and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
6777 with the older version "Xaw3d-1.3".
6779 19.1.8. Packages that cannot or should not be built
6781 There are several reasons why a package might be instructed to not build under
6782 certain circumstances. If the package builds and runs on most platforms, the
6783 exceptions should be noted with NOT_FOR_PLATFORM. If the package builds and
6784 runs on a small handful of platforms, set ONLY_FOR_PLATFORM instead. Both
6785 ONLY_FOR_PLATFORM and NOT_FOR_PLATFORM are OS triples (OS-version-platform)
6786 that can use glob-style wildcards.
6788 Some packages are tightly bound to a specific version of an operating system,
6789 e.g. LKMs or sysutils/lsof. Such binary packages are not backwards compatible
6790 with other versions of the OS, and should be uploaded to a version specific
6791 directory on the FTP server. Mark these packages by setting OSVERSION_SPECIFIC
6792 to "yes". This variable is not currently used by any of the package system
6793 internals, but may be used in the future.
6795 If the package should be skipped (for example, because it provides
6796 functionality already provided by the system), set PKG_SKIP_REASON to a
6797 descriptive message. If the package should fail because some preconditions are
6798 not met, set PKG_FAIL_REASON to a descriptive message.
6800 19.1.9. Packages which should not be deleted, once installed
6802 To ensure that a package may not be deleted, once it has been installed, the
6803 PKG_PRESERVE definition should be set in the package Makefile. This will be
6804 carried into any binary package that is made from this pkgsrc entry. A "
6805 preserved" package will not be deleted using pkg_delete(1) unless the "-f"
6808 19.1.10. Handling packages with security problems
6810 When a vulnerability is found, this should be noted in localsrc/security/
6811 advisories/pkg-vulnerabilities, and after committing that file, use make upload
6812 in the same directory to update the file on ftp.NetBSD.org.
6814 After fixing the vulnerability by a patch, its PKGREVISION should be increased
6815 (this is of course not necessary if the problem is fixed by using a newer
6816 release of the software).
6818 Also, if the fix should be applied to the stable pkgsrc branch, be sure to
6819 submit a pullup request!
6821 Binary packages already on ftp.NetBSD.org will be handled semi-automatically by
6824 19.1.11. How to handle incrementing versions when fixing an existing package
6826 When making fixes to an existing package it can be useful to change the version
6827 number in PKGNAME. To avoid conflicting with future versions by the original
6828 author, a "nb1", "nb2", ... suffix can be used on package versions by setting
6829 PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools.
6836 will result in a PKGNAME of "foo-17.42nb9". If you want to use the original
6837 value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use
6840 When a new release of the package is released, the PKGREVISION should be
6841 removed, e.g. on a new minor release of the above package, things should be
6847 PKGREVISION should be incremented for any non-trivial change in the resulting
6848 binary package. Without a PKGREVISION bump, someone with the previous version
6849 installed has no way of knowing that their package is out of date. Thus,
6850 changes without increasing PKGREVISION are essentially labeled "this is so
6851 trivial that no reasonable person would want to upgrade", and this is the rough
6852 test for when increasing PKGREVISION is appropriate. Examples of changes that
6853 do not merit increasing PKGREVISION are:
6855 * Changing HOMEPAGE, MAINTAINER, OWNER, or comments in Makefile.
6857 * Changing build variables if the resulting binary package is the same.
6861 * Adding PKG_OPTIONS if the default options don't change.
6863 Examples of changes that do merit an increase to PKGREVISION include:
6867 * Changes or additions to a patch file
6869 * Changes to the PLIST
6871 * A dependency is changed or renamed.
6873 PKGREVISION must also be incremented when dependencies have ABI changes.
6875 19.1.12. Substituting variable text in the package files (the SUBST framework)
6877 When you want to replace the same text in multiple files or when the
6878 replacement text varies, patches alone cannot help. This is where the SUBST
6879 framework comes in. It provides an easy-to-use interface for replacing text in
6882 SUBST_CLASSES+= fix-paths
6883 SUBST_STAGE.fix-paths= pre-configure
6884 SUBST_MESSAGE.fix-paths= Fixing absolute paths.
6885 SUBST_FILES.fix-paths= src/*.c
6886 SUBST_FILES.fix-paths+= scripts/*.sh
6887 SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g'
6888 SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g'
6891 SUBST_CLASSES is a list of identifiers that are used to identify the different
6892 SUBST blocks that are defined. The SUBST framework is heavily used by pkgsrc,
6893 so it is important to always use the += operator with this variable. Otherwise
6894 some substitutions may be skipped.
6896 The remaining variables of each SUBST block are parameterized with the
6897 identifier from the first line (fix-paths in this case.) They can be seen as
6898 parameters to a function call.
6900 SUBST_STAGE.* specifies the stage at which the replacement will take place. All
6901 combinations of pre-, do- and post- together with a phase name are possible,
6902 though only few are actually used. Most commonly used are post-patch and
6903 pre-configure. Of these two, pre-configure should be preferred because then it
6904 is possible to run bmake patch and have the state after applying the patches
6905 but before making any other changes. This is especially useful when you are
6906 debugging a package in order to create new patches for it. Similarly,
6907 post-build is preferred over pre-install, because the install phase should
6908 generally be kept as simple as possible. When you use post-build, you have the
6909 same files in the working directory that will be installed later, so you can
6910 check if the substitution has succeeded.
6912 SUBST_MESSAGE.* is an optional text that is printed just before the
6913 substitution is done.
6915 SUBST_FILES.* is the list of shell globbing patterns that specifies the files
6916 in which the substitution will take place. The patterns are interpreted
6917 relatively to the WRKSRC directory.
6919 SUBST_SED.* is a list of arguments to sed(1) that specify the actual
6920 substitution. Every sed command should be prefixed with -e, so that all SUBST
6921 blocks look uniform.
6923 There are some more variables, but they are so seldomly used that they are only
6924 documented in the mk/subst.mk file.
6926 19.2. Fixing problems in the fetch phase
6928 19.2.1. Packages whose distfiles aren't available for plain downloading
6930 If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
6931 a make fetch will call files/getsite.sh with the name of each file to download
6932 as an argument, expecting it to output the URL of the directory from which to
6933 download it. graphics/ns-cult3d is an example of this usage.
6935 If the download can't be automated, because the user must submit personal
6936 information to apply for a password, or must pay for the source, or whatever,
6937 you can set FETCH_MESSAGE to a list of lines that are displayed to the user
6938 before aborting the build. Example:
6940 FETCH_MESSAGE= "Please download the files"
6941 FETCH_MESSAGE+= " "${DISTFILES:Q}
6942 FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
6945 19.2.2. How to handle modified distfiles with the 'old' name
6947 Sometimes authors of a software package make some modifications after the
6948 software was released, and they put up a new distfile without changing the
6949 package's version number. If a package is already in pkgsrc at that time, the
6950 checksum will no longer match. The contents of the new distfile should be
6951 compared against the old one before changing anything, to make sure the
6952 distfile was really updated on purpose, and that no trojan horse or so crept
6953 in. Please mention that the distfiles were compared and what was found in your
6954 commit message. Then, the correct way to work around this is to set DIST_SUBDIR
6955 to a unique directory name, usually based on PKGNAME_NOREV. All DISTFILES and
6956 PATCHFILES for this package will be put in that subdirectory of the local
6957 distfiles directory. (See Section 19.1.11, "How to handle incrementing versions
6958 when fixing an existing package" for more details.) In case this happens more
6959 often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can
6960 be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget regenerating the
6961 distinfo file after that, since it contains the DIST_SUBDIR path in the
6962 filenames. Also increase the PKGREVISION if the installed package is different.
6963 Furthermore, a mail to the package's authors seems appropriate telling them
6964 that changing distfiles after releases without changing the file names is not
6967 19.3. Fixing problems in the configure phase
6969 19.3.1. Shared libraries - libtool
6971 pkgsrc supports many different machines, with different object formats like
6972 a.out and ELF, and varying abilities to do shared library and dynamic loading
6973 at all. To accompany this, varying commands and options have to be passed to
6974 the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
6975 especially if you don't have all the machines at your hand to test things. The
6976 devel/libtool pkg can help here, as it just "knows" how to build both static
6977 and dynamic libraries from a set of source files, thus being
6978 platform-independent.
6980 Here's how to use libtool in a package in seven simple steps:
6982 1. Add USE_LIBTOOL=yes to the package Makefile.
6984 2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
6985 {CC}". You could even add it to the definition of CC, if only libraries are
6986 being built in a given Makefile. This one command will build both PIC and
6987 non-PIC library objects, so you need not have separate shared and
6988 non-shared library rules.
6990 3. For the linking of the library, remove any "ar", "ranlib", and "ld
6991 -Bshareable" commands, and instead use:
6993 ${LIBTOOL} --mode=link \
6994 ${CC} -o ${.TARGET:.a=.la} \
6996 -rpath ${PREFIX}/lib \
6997 -version-info major:minor
7000 Note that the library is changed to have a .la extension, and the objects
7001 are changed to have a .lo extension. Change OBJS as necessary. This
7002 automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
7003 necessary) in the build directory. Be sure to include "-version-info",
7004 especially when major and minor are zero, as libtool will otherwise strip
7005 off the shared library version.
7007 From the libtool manual:
7009 So, libtool library versions are described by three integers:
7012 The most recent interface number that this library implements.
7015 The implementation number of the CURRENT interface.
7018 The difference between the newest and oldest interfaces that
7019 this library implements. In other words, the library implements
7020 all the interface numbers in the range from number `CURRENT -
7023 If two libraries have identical CURRENT and AGE numbers, then the
7024 dynamic linker chooses the library with the greater REVISION number.
7027 The "-release" option will produce different results for a.out and ELF
7028 (excluding symlinks) in only one case. An ELF library of the form "
7029 libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
7030 platform. This is handled automatically.
7032 The "-rpath argument" is the install directory of the library being built.
7034 In the PLIST, include only the .la file, the other files will be added
7037 4. When linking shared object (.so) files, i.e. files that are loaded via
7038 dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
7039 them getting version tacked on.
7041 The PLIST file gets the foo.so entry.
7043 5. When linking programs that depend on these libraries before they are
7044 installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
7045 and it will find the correct libraries (static or shared), but please be
7046 aware that libtool will not allow you to specify a relative path in -L
7047 (such as "-L../somelib"), because it expects you to change that argument to
7048 be the .la file. e.g.
7050 ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
7053 should be changed to:
7055 ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
7058 and it will do the right thing with the libraries.
7060 6. When installing libraries, preface the install(1) or cp(1) command with "$
7061 {LIBTOOL} --mode=install", and change the library name to .la. e.g.
7063 ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
7066 This will install the static .a, shared library, any needed symlinks, and
7069 7. In your PLIST, include only the .la file (this is a change from previous
7072 19.3.2. Using libtool on GNU packages that already support libtool
7074 Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
7075 own libtool in most cases. For older libtool using packages, libtool is made by
7076 ltconfig script during the do-configure step; you can check the libtool script
7077 location by doing make configure; find work*/ -name libtool.
7079 LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
7080 override. By default, it is set to "libtool */libtool */*/libtool". If this
7081 does not match the location of the package's libtool script(s), set it as
7084 If you do not need *.a static libraries built and installed, then use
7085 SHLIBTOOL_OVERRIDE instead.
7087 If your package makes use of the platform-independent library for loading
7088 dynamic shared objects, that comes with libtool (libltdl), you should include
7089 devel/libltdl/buildlink3.mk.
7091 Some packages use libtool incorrectly so that the package may not work or build
7092 in some circumstances. Some of the more common errors are:
7094 * The inclusion of a shared object (-module) as a dependent library in an
7095 executable or library. This in itself isn't a problem if one of two things
7098 1. The shared object is named correctly, i.e. libfoo.la, not foo.la
7100 2. The -dlopen option is used when linking an executable.
7102 * The use of libltdl without the correct calls to initialisation routines.
7103 The function lt_dlinit() should be called and the macro
7104 LTDL_SET_PRELOADED_SYMBOLS included in executables.
7106 19.3.3. GNU Autoconf/Automake
7108 If a package needs GNU autoconf or automake to be executed to regenerate the
7109 configure script and Makefile.in makefile templates, then they should be
7110 executed in a pre-configure target.
7112 For packages that need only autoconf:
7114 AUTOCONF_REQD= 2.50 # if default version is not good enough
7115 USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13
7119 cd ${WRKSRC} && autoconf
7124 and for packages that need automake and autoconf:
7126 AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
7127 USE_TOOLS+= automake # use "automake14" for automake-1.4
7131 set -e; cd ${WRKSRC}; \
7132 aclocal; autoheader; automake -a --foreign -i; autoconf
7137 Packages which use GNU Automake will almost certainly require GNU Make.
7139 There are times when the configure process makes additional changes to the
7140 generated files, which then causes the build process to try to re-execute the
7141 automake sequence. This is prevented by touching various files in the configure
7142 stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
7143 NO in the package Makefile.
7145 19.4. Programming languages
7147 19.4.1. C, C++, and Fortran
7149 Compilers for the C, C++, and Fortran languages comes with the NetBSD base
7150 system. By default, pkgsrc assumes that a package is written in C and will hide
7151 all other compilers (via the wrapper framework, see Chapter 14, Buildlink
7154 To declare which language's compiler a package needs, set the USE_LANGUAGES
7155 variable. Allowed values currently are "c", "c++", and "fortran" (and any
7156 combination). The default is "c". Packages using GNU configure scripts, even if
7157 written in C++, usually need a C compiler for the configure phase.
7161 If a program is written in Java, use the Java framework in pkgsrc. The package
7162 must include ../../mk/java-vm.mk. This Makefile fragment provides the following
7165 * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is
7166 set to "run", then there is only a runtime dependency on the JDK. The
7167 default is "yes", which also adds a build dependency on the JDK.
7169 * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The
7170 supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2
7171 implementation, "1.4" insists on versions 1.4 or above, and "1.5" only
7172 accepts versions 1.5 or above. This variable is not set by default.
7174 * PKG_JAVA_HOME is automatically set to the runtime location of the used Java
7175 implementation dependency. It may be used to set JAVA_HOME to a good value
7176 if the program needs this variable to be defined.
7178 19.4.3. Packages containing perl scripts
7180 If your package contains interpreted perl scripts, add "perl" to the USE_TOOLS
7181 variable and set REPLACE_PERL to ensure that the proper interpreter path is
7182 set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that
7183 you want adjusted. Every occurrence of */bin/perl will be replaced with the
7184 full path to the perl executable.
7186 If a particular version of perl is needed, set the PERL5_REQD variable to the
7187 version number. The default is "5.0".
7189 See Section 19.6.6, "Packages installing perl modules" for information about
7190 handling perl modules.
7192 19.4.4. Other programming languages
7194 Currently, there is no special handling for other languages in pkgsrc. If a
7195 compiler package provides a buildlink3.mk file, include that, otherwise just
7196 add a (build) dependency on the appropriate compiler package.
7198 19.5. Fixing problems in the build phase
7200 The most common failures when building a package are that some platforms do not
7201 provide certain header files, functions or libraries, or they provide the
7202 functions in a library that the original package author didn't know. To work
7203 around this, you can rewrite the source code in most cases so that it does not
7204 use the missing functions or provides a replacement function.
7206 19.5.1. Compiling C and C++ code conditionally
7208 If a package already comes with a GNU configure script, the preferred way to
7209 fix the build failure is to change the configure script, not the code. In the
7210 other cases, you can utilize the C preprocessor, which defines certain macros
7211 depending on the operating system and hardware architecture it compiles for.
7212 These macros can be queried using for example #if defined(__i386). Almost every
7213 operating system, hardware architecture and compiler has its own macro. For
7214 example, if the macros __GNUC__, __i386__ and __NetBSD__ are all defined, you
7215 know that you are using NetBSD on an i386 compatible CPU, and your compiler is
7218 The list of the following macros for hardware and operating system depends on
7219 the compiler that is used. For example, if you want to conditionally compile
7220 code on Solaris, don't use __sun__, as the SunPro compiler does not define it.
7223 19.5.1.1. C preprocessor macros to identify the operating system
7225 To distinguish between 4.4 BSD-derived systems and the rest of the world, you
7226 should use the following code.
7228 #include <sys/param.h>
7229 #if (defined(BSD) && BSD >= 199306)
7230 /* BSD-specific code goes here */
7232 /* non-BSD-specific code goes here */
7235 If this distinction is not fine enough, you can also test for the following
7239 DragonFly __DragonFly__
7241 IRIX __sgi (TODO: get a definite source for this)
7242 Linux linux, __linux, __linux__
7247 19.5.1.2. C preprocessor macros to identify the hardware architecture
7249 i386 i386, __i386, __i386__
7251 SPARC sparc, __sparc
7253 19.5.1.3. C preprocessor macros to identify the compiler
7255 GCC __GNUC__ (major version), __GNUC_MINOR__
7256 MIPSpro _COMPILER_VERSION (0x741 for MIPSpro 7.41)
7257 SunPro __SUNPRO_C (0x570 for Sun C 5.7)
7258 SunPro C++ __SUNPRO_CC (0x580 for Sun C++ 5.8)
7260 19.5.2. How to handle compiler bugs
7262 Some source files trigger bugs in the compiler, based on combinations of
7263 compiler version and architecture and almost always relation to optimisation
7264 being enabled. Common symptoms are gcc internal errors or never finishing
7267 Typically, a workaround involves testing the MACHINE_ARCH and compiler version,
7268 disabling optimisation for that combination of file, MACHINE_ARCH and compiler,
7269 and documenting it in pkgsrc/doc/HACKS. See that file for a number of examples.
7271 19.5.3. Undefined reference to "..."
7273 This error message often means that a package did not link to a shared library
7274 it needs. The following functions are known to cause this error message over
7277 +-----------------------------------------------------+
7278 | Function |Library |Affected platforms|
7279 |-------------------------+--------+------------------|
7280 |accept, bind, connect |-lsocket|Solaris |
7281 |-------------------------+--------+------------------|
7282 |crypt |-lcrypt |DragonFly, NetBSD |
7283 |-------------------------+--------+------------------|
7284 |dlopen, dlsym |-ldl |Linux |
7285 |-------------------------+--------+------------------|
7286 |gethost* |-lnsl |Solaris |
7287 |-------------------------+--------+------------------|
7288 |inet_aton |-lresolv|Solaris |
7289 |-------------------------+--------+------------------|
7290 |nanosleep, sem_*, timer_*|-lrt |Solaris |
7291 |-------------------------+--------+------------------|
7292 |openpty |-lutil |Linux |
7293 +-----------------------------------------------------+
7295 To fix these linker errors, it is often sufficient to say LIBS.OperatingSystem+
7296 = -lfoo to the package Makefile and then say bmake clean; bmake.
7298 19.5.3.1. Special issue: The SunPro compiler
7300 When you are using the SunPro compiler, there is another possibility. That
7301 compiler cannot handle the following code:
7303 extern int extern_func(int);
7308 return extern_func(x);
7316 It generates the code for inline_func even if that function is never used. This
7317 code then refers to extern_func, which can usually not be resolved. To solve
7318 this problem you can try to tell the package to disable inlining of functions.
7320 19.5.4. Running out of memory
7322 Sometimes packages fail to build because the compiler runs into an operating
7323 system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be
7324 told to unlimit the resources. Currently, the allowed values are "datasize" and
7325 "stacksize" (or both). Setting this variable is similar to running the shell
7326 builtin ulimit command to raise the maximum data segment size or maximum stack
7327 size of a process, respectively, to their hard limits.
7329 19.6. Fixing problems in the install phase
7331 19.6.1. Creating needed directories
7333 The BSD-compatible install supplied with some operating systems cannot create
7334 more than one directory at a time. As such, you should call ${INSTALL_*_DIR}
7337 ${INSTALL_DATA_DIR} ${PREFIX}/dir1
7338 ${INSTALL_DATA_DIR} ${PREFIX}/dir2
7341 You can also just append "dir1 dir2" to the INSTALLATION_DIRS variable, which
7342 will automatically do the right thing.
7344 19.6.2. Where to install documentation
7346 In general, documentation should be installed into ${PREFIX}/share/doc/$
7347 {PKGBASE} or ${PREFIX}/share/doc/${PKGNAME} (the latter includes the version
7348 number of the package).
7350 Many modern packages using GNU autoconf allow to set the directory where HTML
7351 documentation is installed with the "--with-html-dir" option. Sometimes using
7352 this flag is needed because otherwise the documentation ends up in ${PREFIX}/
7353 share/doc/html or other places.
7355 An exception to the above is that library API documentation generated with the
7356 textproc/gtk-doc tools, for use by special browsers (devhelp) should be left at
7357 their default location, which is ${PREFIX}/share/gtk-doc. Such documentation
7358 can be recognized from files ending in .devhelp or .devhelp2. (It is also
7359 acceptable to install such files in ${PREFIX}/share/doc/${PKGBASE} or ${PREFIX}
7360 /share/doc/${PKGNAME}; the .devhelp* file must be directly in that directory
7361 then, no additional subdirectory level is allowed in this case. This is usually
7362 achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/
7363 gtk-doc is preferred though.)
7365 19.6.3. Installing highscore files
7367 Certain packages, most of them in the games category, install a score file that
7368 allows all users on the system to record their highscores. In order for this to
7369 work, the binaries need to be installed setgid and the score files owned by the
7370 appropriate group and/or owner (traditionally the "games" user/group). The
7371 following variables, documented in more detail in mk/defaults/mk.conf, control
7372 this behaviour: SETGIDGAME, GAMEDATAMODE, GAMEGRP, GAMEMODE, GAMEOWN.
7374 Note that per default, setgid installation of games is disabled; setting
7375 SETGIDGAME=YES will set all the other variables accordingly.
7377 A package should therefore never hard code file ownership or access permissions
7378 but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly.
7380 19.6.4. Adding DESTDIR support to packages
7382 DESTDIR support means that a package installs into a staging directory, not the
7383 final location of the files. Then a binary package is created which can be used
7384 for installation as usual. There are two ways: Either the package must install
7385 as root ("destdir") or the package can install as non-root user ("user-destdir"
7388 * PKG_DESTDIR_SUPPORT has to be set to "destdir" or "user-destdir". If
7389 bsd.prefs.mk is included in the Makefile, PKG_DESTDIR_SUPPORT needs to be
7390 set before the inclusion.
7392 * All installation operations have to be prefixed with ${DESTDIR}.
7394 * automake gets this DESTDIR mostly right automatically. Many manual rules
7395 and pre/post-install often are incorrect; fix them.
7397 * If files are installed with special owner/group use SPECIAL_PERMS.
7399 * In general, packages should support UNPRIVILEGED to be able to use DESTDIR.
7401 19.6.5. Packages with hardcoded paths to other interpreters
7403 Your package may also contain scripts with hardcoded paths to other
7404 interpreters besides (or as well as) perl. To correct the full pathname to the
7405 script interpreter, you need to set the following definitions in your Makefile
7406 (we shall use tclsh in this example):
7408 REPLACE_INTERPRETER+= tcl
7409 REPLACE.tcl.old= .*/bin/tclsh
7410 REPLACE.tcl.new= ${PREFIX}/bin/tclsh
7411 REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed,
7412 # relative to ${WRKSRC}, just as in REPLACE_PERL
7417 Before March 2006, these variables were called _REPLACE.* and _REPLACE_FILES.*.
7419 19.6.6. Packages installing perl modules
7421 Makefiles of packages providing perl5 modules should include the Makefile
7422 fragment ../../lang/perl5/module.mk. It provides a do-configure target for the
7423 standard perl configuration for such modules as well as various hooks to tune
7424 this configuration. See comments in this file for details.
7426 Perl5 modules will install into different places depending on the version of
7427 perl used during the build process. To address this, pkgsrc will append lines
7428 to the PLIST corresponding to the files listed in the installed .packlist file
7429 generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to
7430 a space-separated list of paths to packlist files, e.g.:
7432 PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
7435 The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent the
7436 three locations in which perl5 modules may be installed, and may be used by
7437 perl5 packages that don't have a packlist. These three variables are also
7438 substituted for in the PLIST.
7440 19.6.7. Packages installing info files
7442 Some packages install info files or use the "makeinfo" or "install-info"
7443 commands. INFO_FILES should be defined in the package Makefile so that INSTALL
7444 and DEINSTALL scripts will be generated to handle registration of the info
7445 files in the Info directory file. The "install-info" command used for the info
7446 files registration is either provided by the system, or by a special purpose
7447 package automatically added as dependency if needed.
7449 PKGINFODIR is the directory under ${PREFIX} where info files are primarily
7450 located. PKGINFODIR defaults to "info" and can be overridden by the user.
7452 The info files for the package should be listed in the package PLIST; however
7453 any split info files need not be listed.
7455 A package which needs the "makeinfo" command at build time must add "makeinfo"
7456 to USE_TOOLS in its Makefile. If a minimum version of the "makeinfo" command is
7457 needed it should be noted with the TEXINFO_REQD variable in the package
7458 Makefile. By default, a minimum version of 3.12 is required. If the system does
7459 not provide a makeinfo command or if it does not match the required minimum, a
7460 build dependency on the devel/gtexinfo package will be added automatically.
7462 The build and installation process of the software provided by the package
7463 should not use the install-info command as the registration of info files is
7464 the task of the package INSTALL script, and it must use the appropriate
7467 To achieve this goal, the pkgsrc infrastructure creates overriding scripts for
7468 the install-info and makeinfo commands in a directory listed early in PATH.
7470 The script overriding install-info has no effect except the logging of a
7471 message. The script overriding makeinfo logs a message and according to the
7472 value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on
7475 19.6.8. Packages installing man pages
7477 All packages that install manual pages should install them into the same
7478 directory, so that there is one common place to look for them. In pkgsrc, this
7479 place is ${PREFIX}/${PKGMANDIR}, and this expression should be used in
7480 packages. The default for PKGMANDIR is "man". Another often-used value is "
7485 The support for a custom PKGMANDIR is far from complete.
7487 The PLIST files can just use man/ as the top level directory for the man page
7488 file entries, and the pkgsrc framework will convert as needed. In all other
7489 places, the correct PKGMANDIR must be used.
7491 Packages that are configured with GNU_CONFIGURE set as "yes", by default will
7492 use the ./configure --mandir switch to set where the man pages should be
7493 installed. The path is GNU_CONFIGURE_MANDIR which defaults to ${PREFIX}/$
7496 Packages that use GNU_CONFIGURE but do not use --mandir, can set
7497 CONFIGURE_HAS_MANDIR to "no". Or if the ./configure script uses a non-standard
7498 use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed.
7500 See Section 13.5, "Man page compression" for information on installation of
7501 compressed manual pages.
7503 19.6.9. Packages installing GConf data files
7505 If a package installs .schemas or .entries files, used by GConf, you need to
7506 take some extra steps to make sure they get registered in the database:
7508 1. Include ../../devel/GConf/schemas.mk instead of its buildlink3.mk file.
7509 This takes care of rebuilding the GConf database at installation and
7510 deinstallation time, and tells the package where to install GConf data
7511 files using some standard configure arguments. It also disallows any access
7512 to the database directly from the package.
7514 2. Ensure that the package installs its .schemas files under ${PREFIX}/share/
7515 gconf/schemas. If they get installed under ${PREFIX}/etc, you will need to
7516 manually patch the package.
7518 3. Check the PLIST and remove any entries under the etc/gconf directory, as
7519 they will be handled automatically. See Section 9.13, "How do I change the
7520 location of configuration files?" for more information.
7522 4. Define the GCONF_SCHEMAS variable in your Makefile with a list of all
7523 .schemas files installed by the package, if any. Names must not contain any
7524 directories in them.
7526 5. Define the GCONF_ENTRIES variable in your Makefile with a list of all
7527 .entries files installed by the package, if any. Names must not contain any
7528 directories in them.
7530 19.6.10. Packages installing scrollkeeper/rarian data files
7532 If a package installs .omf files, used by scrollkeeper/rarian, you need to take
7533 some extra steps to make sure they get registered in the database:
7535 1. Include ../../mk/omf-scrollkeeper.mk instead of rarian's buildlink3.mk
7536 file. This takes care of rebuilding the scrollkeeper database at
7537 installation and deinstallation time, and disallows any access to it
7538 directly from the package.
7540 2. Check the PLIST and remove any entries under the libdata/scrollkeeper
7541 directory, as they will be handled automatically.
7543 3. Remove the share/omf directory from the PLIST. It will be handled by
7544 rarian. (make print-PLIST does this automatically.)
7546 19.6.11. Packages installing X11 fonts
7548 If a package installs font files, you will need to rebuild the fonts database
7549 in the directory where they get installed at installation and deinstallation
7550 time. This can be automatically done by using the pkginstall framework.
7552 You can list the directories where fonts are installed in the FONTS_DIRS.type
7553 variables, where type can be one of "ttf", "type1" or "x11". Also make sure
7554 that the database file fonts.dir is not listed in the PLIST.
7556 Note that you should not create new directories for fonts; instead use the
7557 standard ones to avoid that the user needs to manually configure his X server
7560 19.6.12. Packages installing GTK2 modules
7562 If a package installs GTK2 immodules or loaders, you need to take some extra
7563 steps to get them registered in the GTK2 database properly:
7565 1. Include ../../x11/gtk2/modules.mk instead of its buildlink3.mk file. This
7566 takes care of rebuilding the database at installation and deinstallation
7569 2. Set GTK2_IMMODULES=YES if your package installs GTK2 immodules.
7571 3. Set GTK2_LOADERS=YES if your package installs GTK2 loaders.
7573 4. Patch the package to not touch any of the GTK2 databases directly. These
7576 * libdata/gtk-2.0/gdk-pixbuf.loaders
7578 * libdata/gtk-2.0/gtk.immodules
7580 5. Check the PLIST and remove any entries under the libdata/gtk-2.0 directory,
7581 as they will be handled automatically.
7583 19.6.13. Packages installing SGML or XML data
7585 If a package installs SGML or XML data files that need to be registered in
7586 system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
7589 1. Include ../../textproc/xmlcatmgr/catalogs.mk in your Makefile, which takes
7590 care of registering those files in system-wide catalogs at installation and
7591 deinstallation time.
7593 2. Set SGML_CATALOGS to the full path of any SGML catalogs installed by the
7596 3. Set XML_CATALOGS to the full path of any XML catalogs installed by the
7599 4. Set SGML_ENTRIES to individual entries to be added to the SGML catalog.
7600 These come in groups of three strings; see xmlcatmgr(1) for more
7601 information (specifically, arguments recognized by the 'add' action). Note
7602 that you will normally not use this variable.
7604 5. Set XML_ENTRIES to individual entries to be added to the XML catalog. These
7605 come in groups of three strings; see xmlcatmgr(1) for more information
7606 (specifically, arguments recognized by the 'add' action). Note that you
7607 will normally not use this variable.
7609 19.6.14. Packages installing extensions to the MIME database
7611 If a package provides extensions to the MIME database by installing .xml files
7612 inside ${PREFIX}/share/mime/packages, you need to take some extra steps to
7613 ensure that the database is kept consistent with respect to these new files:
7615 1. Include ../../databases/shared-mime-info/mimedb.mk (avoid using the
7616 buildlink3.mk file from this same directory, which is reserved for
7617 inclusion from other buildlink3.mk files). It takes care of rebuilding the
7618 MIME database at installation and deinstallation time, and disallows any
7619 access to it directly from the package.
7621 2. Check the PLIST and remove any entries under the share/mime directory,
7622 except for files saved under share/mime/packages. The former are handled
7623 automatically by the update-mime-database program, but the latter are
7624 package-dependent and must be removed by the package that installed them in
7627 3. Remove any share/mime/* directories from the PLIST. They will be handled by
7628 the shared-mime-info package.
7630 19.6.15. Packages using intltool
7632 If a package uses intltool during its build, add intltool to the USE_TOOLS,
7633 which forces it to use the intltool package provided by pkgsrc, instead of the
7634 one bundled with the distribution file.
7636 This tracks intltool's build-time dependencies and uses the latest available
7637 version; this way, the package benefits of any bug fixes that may have appeared
7638 since it was released.
7640 19.6.16. Packages installing startup scripts
7642 If a package contains a rc.d script, it won't be copied into the startup
7643 directory by default, but you can enable it, by adding the option
7644 PKG_RCD_SCRIPTS=YES in mk.conf. This option will copy the scripts into /etc/
7645 rc.d when a package is installed, and it will automatically remove the scripts
7646 when the package is deinstalled.
7648 19.6.17. Packages installing TeX modules
7650 If a package installs TeX packages into the texmf tree, the ls-R database of
7651 the tree needs to be updated.
7655 Except the main TeX packages such as kpathsea, packages should install files
7656 into ${PREFIX}/share/texmf-dist, not ${PREFIX}/share/texmf.
7658 1. Include ../../print/kpathsea/texmf.mk. This takes care of rebuilding the
7659 ls-R database at installation and deinstallation time.
7661 2. If your package installs files into a texmf tree other than the one at $
7662 {PREFIX}/share/texmf-dist, set TEX_TEXMF_DIRS to the list of all texmf
7663 trees that need database update.
7665 If your package also installs font map files that need to be registered
7666 using updmap, include ../../print/texlive-tetex/map.mk and set
7667 TEX_MAP_FILES and/or TEX_MIXEDMAP_FILES to the list of all such font map
7668 files. Then updmap will be run automatically at installation/deinstallation
7669 to enable/disable font map files for TeX output drivers.
7671 3. Make sure that none of ls-R databases are included in PLIST, as they will
7672 be removed only by the teTeX-bin package.
7674 19.6.18. Packages supporting running binaries in emulation
7676 There are some packages that provide libraries and executables for running
7677 binaries from a one operating system on a different one (if the latter supports
7678 it). One example is running Linux binaries on NetBSD.
7680 The pkgtools/rpm2pkg helps in extracting and packaging Linux rpm packages.
7682 The CHECK_SHLIBS can be set to no to avoid the check-shlibs target, which tests
7683 if all libraries for each installed executable can be found by the dynamic
7684 linker. Since the standard dynamic linker is run, this fails for emulation
7685 packages, because the libraries used by the emulation are not in the standard
7688 19.6.19. Packages installing hicolor theme icons
7690 If a package installs images under the share/icons/hicolor and/or updates the
7691 share/icons/hicolor/icon-theme.cache database, you need to take some extra
7692 steps to make sure that the shared theme directory is handled appropriately and
7693 that the cache database is rebuilt:
7695 1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk.
7697 2. Check the PLIST and remove the entry that refers to the theme cache.
7699 3. Ensure that the PLIST does not remove the shared icon directories from the
7700 share/icons/hicolor hierarchy because they will be handled automatically.
7702 The best way to verify that the PLIST is correct with respect to the last two
7703 points is to regenerate it using make print-PLIST.
7705 19.6.20. Packages installing desktop files
7707 If a package installs .desktop files under share/applications and these include
7708 MIME information, you need to take extra steps to ensure that they are
7709 registered into the MIME database:
7711 1. Include ../../sysutils/desktop-file-utils/desktopdb.mk.
7713 2. Check the PLIST and remove the entry that refers to the share/applications/
7714 mimeinfo.cache file. It will be handled automatically.
7716 The best way to verify that the PLIST is correct with respect to the last point
7717 is to regenerate it using make print-PLIST.
7719 19.7. Marking packages as having problems
7721 In some cases one does not have the time to solve a problem immediately. In
7722 this case, one can plainly mark a package as broken. For this, one just sets
7723 the variable BROKEN to the reason why the package is broken (similar to the
7724 RESTRICTED variable). A user trying to build the package will immediately be
7725 shown this message, and the build will not be even tried.
7727 BROKEN packages are removed from pkgsrc in irregular intervals.
7729 Chapter 20. Debugging
7731 To check out all the gotchas when building a package, here are the steps that I
7732 do in order to get a package working. Please note this is basically the same as
7733 what was explained in the previous sections, only with some debugging aids.
7735 * Be sure to set PKG_DEVELOPER=yes in mk.conf.
7737 * Install pkgtools/url2pkg, create a directory for a new package, change into
7738 it, then run url2pkg:
7740 % mkdir /usr/pkgsrc/category/examplepkg
7741 % cd /usr/pkgsrc/category/examplepkg
7742 % url2pkg http://www.example.com/path/to/distfile.tar.gz
7744 * Edit the Makefile as requested.
7746 * Fill in the DESCR file
7748 * Run make configure
7750 * Add any dependencies glimpsed from documentation and the configure step to
7751 the package's Makefile.
7753 * Make the package compile, doing multiple rounds of
7756 % pkgvi ${WRKSRC}/some/file/that/does/not/compile
7759 % mv ${WRKDIR}/.newpatches/* patches
7763 Doing this step as non-root user will ensure that no files are modified
7764 that shouldn't be, especially during the build phase. mkpatches, patchdiff
7765 and pkgvi are from the pkgtools/pkgdiff package.
7767 * Look at the Makefile, fix if necessary; see Section 11.1, "Makefile".
7772 # make print-PLIST >PLIST
7777 You usually need to be root to do this. Look if there are any files left:
7781 If this reveals any files that are missing in PLIST, add them.
7783 * Now that the PLIST is OK, install the package again and make a binary
7789 * Delete the installed package:
7791 # pkg_delete examplepkg
7793 * Repeat the above make print-PLIST command, which shouldn't find anything
7798 * Reinstall the binary package:
7800 # pkg_add .../examplepkg.tgz
7802 * Play with it. Make sure everything works.
7804 * Run pkglint from pkgtools/pkglint, and fix the problems it reports:
7808 * Submit (or commit, if you have cvs access); see Chapter 21, Submitting and
7811 Chapter 21. Submitting and Committing
7815 21.1. Submitting binary packages
7816 21.2. Submitting source packages (for non-NetBSD-developers)
7817 21.3. General notes when adding, updating, or removing packages
7818 21.4. Committing: Importing a package into CVS
7819 21.5. Updating a package to a newer version
7820 21.6. Renaming a package in pkgsrc
7821 21.7. Moving a package in pkgsrc
7823 21.1. Submitting binary packages
7825 Our policy is that we accept binaries only from pkgsrc developers to guarantee
7826 that the packages don't contain any trojan horses etc. This is not to annoy
7827 anyone but rather to protect our users! You're still free to put up your
7828 home-made binary packages and tell the world where to get them. NetBSD
7829 developers doing bulk builds and wanting to upload them please see
7830 Section 7.3.8, "Uploading results of a bulk build".
7832 21.2. Submitting source packages (for non-NetBSD-developers)
7834 First, check that your package is complete, compiles and runs well; see
7835 Chapter 20, Debugging and the rest of this document. Next, generate an
7836 uuencoded gzipped tar(1) archive that contains all files that make up the
7837 package. Finally, send this package to the pkgsrc bug tracking system, either
7838 with the send-pr(1) command, or if you don't have that, go to the web page
7839 http://www.NetBSD.org/support/send-pr.html, which contains some instructions
7840 and a link to a form where you can submit packages. The sysutils/gtk-send-pr
7841 package is also available as a substitute for either of the above two tools.
7843 In the form of the problem report, the category should be "pkg", the synopsis
7844 should include the package name and version number, and the description field
7845 should contain a short description of your package (contents of the COMMENT
7846 variable or DESCR file are OK). The uuencoded package data should go into the "
7849 If you want to submit several packages, please send a separate PR for each one,
7850 it's easier for us to track things that way.
7852 Alternatively, you can also import new packages into pkgsrc-wip ("pkgsrc
7853 work-in-progress"); see the homepage at http://pkgsrc-wip.sourceforge.net/ for
7856 21.3. General notes when adding, updating, or removing packages
7858 Please note all package additions, updates, moves, and removals in pkgsrc/doc/
7859 CHANGES-YYYY. It's very important to keep this file up to date and conforming
7860 to the existing format, because it will be used by scripts to automatically
7861 update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/
7862 doc/TODO file and remove the entry for the package you updated or removed, in
7863 case it was mentioned there.
7865 When the PKGREVISION of a package is bumped, the change should appear in pkgsrc
7866 /doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps
7867 that result from a dependency being updated should not be mentioned. In all
7868 other cases it's the developer's decision.
7870 There is a make target that helps in creating proper CHANGES-YYYY entries: make
7871 changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The
7872 general usage is to first make sure that your CHANGES-YYYY file is up-to-date
7873 (to avoid having to resolve conflicts later-on) and then to cd to the package
7874 directory. For package updates, make changes-entry is enough. For new packages,
7875 or package moves or removals, set the CTYPE variable on the command line to
7876 "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if
7877 your local login name is not the same as your NetBSD login name. The target
7878 also automatically removes possibly existing entries for the package in the
7879 TODO file. Don't forget to commit the changes, e.g. by using make
7880 changes-entry-commit! If you are not using a checkout directly from
7881 cvs.NetBSD.org, but e.g. a local copy of the repository, you can set
7882 USE_NETBSD_REPO=yes. This makes the cvs commands use the main repository.
7884 21.4. Committing: Importing a package into CVS
7886 This section is only of interest for pkgsrc developers with write access to the
7887 pkgsrc repository. Please remember that cvs imports files relative to the
7888 current working directory, and that the pathname that you give the cvs import
7889 command is so that it knows where to place the files in the repository. Newly
7890 created packages should be imported with a vendor tag of "TNF" and a release
7891 tag of "pkgsrc-base", e.g:
7893 $ cd .../pkgsrc/category/pkgname
7894 $ cvs import pkgsrc/category/pkgname TNF pkgsrc-base
7896 Remember to move the directory from which you imported out of the way, or cvs
7897 will complain the next time you "cvs update" your source tree. Also don't
7898 forget to add the new package to the category's Makefile.
7900 The commit message of the initial import should include part of the DESCR file,
7901 so people reading the mailing lists know what the package is/does.
7903 For new packages, "cvs import" is preferred to "cvs add" because the former
7904 gets everything with a single command, and provides a consistent tag.
7906 21.5. Updating a package to a newer version
7908 Please always put a concise, appropriate and relevant summary of the changes
7909 between old and new versions into the commit log when updating a package. There
7910 are various reasons for this:
7912 * A URL is volatile, and can change over time. It may go away completely or
7913 its information may be overwritten by newer information.
7915 * Having the change information between old and new versions in our CVS
7916 repository is very useful for people who use either cvs or anoncvs.
7918 * Having the change information between old and new versions in our CVS
7919 repository is very useful for people who read the pkgsrc-changes mailing
7920 list, so that they can make tactical decisions about when to upgrade the
7923 Please also recognize that, just because a new version of a package has been
7924 released, it should not automatically be upgraded in the CVS repository. We
7925 prefer to be conservative in the packages that are included in pkgsrc -
7926 development or beta packages are not really the best thing for most places in
7927 which pkgsrc is used. Please use your judgement about what should go into
7928 pkgsrc, and bear in mind that stability is to be preferred above new and
7929 possibly untested features.
7931 21.6. Renaming a package in pkgsrc
7933 Renaming packages is not recommended.
7935 When renaming packages, be sure to fix any references to old name in other
7936 Makefiles, options, buildlink files, etc.
7938 Also When renaming a package, please define SUPERSEDES to the package name and
7939 dewey version pattern(s) of the previous package name. This may be repeated for
7940 multiple renames. The new package would be an exact replacement.
7942 Note that "successor" in the CHANGES-YYYY file doesn't necessarily mean that it
7943 supersedes, as that successor may not be an exact replacement but is a
7944 suggestion for the replaced functionality.
7946 21.7. Moving a package in pkgsrc
7948 It is preferred that packages are not renamed or moved, but if needed please
7951 1. Make a copy of the directory somewhere else.
7953 2. Remove all CVS dirs.
7955 Alternatively to the first two steps you can also do:
7957 % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
7959 and use that for further work.
7961 3. Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of
7962 "../../category/package".
7964 4. In the modified package's Makefile, consider setting PREV_PKGPATH to the
7965 previous category/package pathname. The PREV_PKGPATH can be used by tools
7966 for doing an update using pkgsrc building; for example, it can search the
7967 pkg_summary(5) database for PREV_PKGPATH (if no SUPERSEDES) and then use
7968 the corresponding new PKGPATH for that moved package. Note that it may have
7969 multiple matches, so the tool should also check on the PKGBASE too. The
7970 PREV_PKGPATH probably has no value unless SUPERSEDES is not set, i.e.
7971 PKGBASE stays the same.
7973 5. cvs import the modified package in the new place.
7975 6. Check if any package depends on it:
7978 % grep /package */*/Makefile* */*/buildlink*
7980 7. Fix paths in packages from step 5 to point to new location.
7982 8. cvs rm (-f) the package at the old location.
7984 9. Remove from oldcategory/Makefile.
7986 10. Add to newcategory/Makefile.
7988 11. Commit the changed and removed files:
7990 % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
7992 (and any packages from step 5, of course).
7994 Chapter 22. Frequently Asked Questions
7996 This section contains the answers to questions that may arise when you are
7997 writing a package. If you don't find your question answered here, first have a
7998 look in the other chapters, and if you still don't have the answer, ask on the
7999 pkgsrc-users mailing list.
8001 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
8002 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
8003 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
8004 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
8006 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
8007 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
8009 22.7. Which mailing lists are there for package developers?
8010 22.8. Where is the pkgsrc documentation?
8011 22.9. I have a little time to kill. What shall I do?
8013 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
8015 MAKEFLAGS are the flags passed to the pkgsrc-internal invocations of make
8016 (1), while MAKE_FLAGS are the flags that are passed to the MAKE_PROGRAM
8017 when building the package. [FIXME: What is .MAKEFLAGS for?]
8019 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
8021 MAKE is the path to the make(1) program that is used in the pkgsrc
8022 infrastructure. GMAKE is the path to GNU Make, but you need to say
8023 USE_TOOLS+=gmake to use that. MAKE_PROGRAM is the path to the Make
8024 program that is used for building the package.
8026 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
8028 CC is the path to the real C compiler, which can be configured by the
8029 pkgsrc user. PKG_CC is the path to the compiler wrapper. PKGSRC_COMPILER
8030 is not a path to a compiler, but the type of compiler that should be
8031 used. See mk/compiler.mk for more information about the latter variable.
8033 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
8038 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
8040 For optimization reasons, some variables are only available in the "
8041 wrapper" phase and later. To "simulate" the wrapper phase, append
8042 PKG_PHASE=wrapper to the above command.
8044 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
8047 The := is not really an assignment operator, like you might expect at
8048 first sight. Instead, it is a degenerate form of ${LIST:old_string=
8049 new_string}, which is documented in the make(1) man page and which you
8050 may have seen as in ${SRCS:.c=.o}. In the case of MASTER_SITE_*,
8051 old_string is the empty string and new_string is package/. That's where
8052 the : and the = fall together.
8054 22.7. Which mailing lists are there for package developers?
8058 This is a list for technical discussions related to pkgsrc
8059 development, e.g. soliciting feedback for changes to pkgsrc
8060 infrastructure, proposed new features, questions related to porting
8061 pkgsrc to a new platform, advice for maintaining a package, patches
8062 that affect many packages, help requests moved from pkgsrc-users when
8063 an infrastructure bug is found, etc.
8067 All bug reports in category "pkg" sent with send-pr(1) appear here.
8068 Please do not report your bugs here directly; use one of the other
8071 22.8. Where is the pkgsrc documentation?
8073 There are many places where you can find documentation about pkgsrc:
8075 * The pkgsrc guide (this document) is a collection of chapters that
8076 explain large parts of pkgsrc, but some chapters tend to be outdated.
8077 Which ones they are is hard to say.
8079 * On the mailing list archives (see http://mail-index.NetBSD.org/), you
8080 can find discussions about certain features, announcements of new
8081 parts of the pkgsrc infrastructure and sometimes even announcements
8082 that a certain feature has been marked as obsolete. The benefit here
8083 is that each message has a date appended to it.
8085 * Many of the files in the mk/ directory start with a comment that
8086 describes the purpose of the file and how it can be used by the
8087 pkgsrc user and package authors. An easy way to find this
8088 documentation is to run bmake help.
8090 * The CVS log messages are a rich source of information, but they tend
8091 to be highly abbreviated, especially for actions that occur often.
8092 Some contain a detailed description of what has changed, but they are
8093 geared towards the other pkgsrc developers, not towards an average
8094 pkgsrc user. They also only document changes, so if you don't know
8095 what has been before, these messages may not be worth too much to
8098 * Some parts of pkgsrc are only "implicitly documented", that is the
8099 documentation exists only in the mind of the developer who wrote the
8100 code. To get this information, use the cvs annotate command to see
8101 who has written it and ask on the tech-pkg mailing list, so that
8102 others can find your questions later (see above). To be sure that the
8103 developer in charge reads the mail, you may CC him or her.
8105 22.9. I have a little time to kill. What shall I do?
8107 This is not really an FAQ yet, but here's the answer anyway.
8109 * Run pkg_chk -N (from the pkgtools/pkg_chk package). It will tell you
8110 about newer versions of installed packages that are available, but
8111 not yet updated in pkgsrc.
8113 * Browse pkgsrc/doc/TODO ? it contains a list of suggested new packages
8114 and a list of cleanups and enhancements for pkgsrc that would be nice
8117 * Review packages for which review was requested on the pkgsrc-wip
8118 review mailing list.
8120 Chapter 23. GNOME packaging and porting
8125 23.2. Packaging a GNOME application
8126 23.3. Updating GNOME to a newer version
8127 23.4. Patching guidelines
8129 Quoting GNOME's web site:
8131 The GNOME project provides two things: The GNOME desktop environment, an
8132 intuitive and attractive desktop for users, and the GNOME development
8133 platform, an extensive framework for building applications that integrate
8134 into the rest of the desktop.
8136 pkgsrc provides a seamless way to automatically build and install a complete
8137 GNOME environment under many different platforms. We can say with confidence
8138 that pkgsrc is one of the most advanced build and packaging systems for GNOME
8139 due to its included technologies buildlink3, the wrappers and tools framework
8140 and automatic configuration file management. Lots of efforts are put into
8141 achieving a completely clean deinstallation of installed software components.
8143 Given that pkgsrc is NetBSD's official packaging system, the above also means
8144 that great efforts are put into making GNOME work under this operating system.
8145 Recently, DragonFly BSD also adopted pkgsrc as its preferred packaging system,
8146 contributing lots of portability fixes to make GNOME build and install under
8149 This chapter is aimed at pkgsrc developers and other people interested in
8150 helping our GNOME porting and packaging efforts. It provides instructions on
8151 how to manage the existing packages and some important information regarding
8156 Should you have some spare cycles to devote to NetBSD, pkgsrc and GNOME and are
8157 willing to learn new exciting stuff, please jump straight to the pending work
8158 list! There is still a long way to go to get a fully-functional GNOME desktop
8159 under NetBSD and we need your help to achieve it!
8163 pkgsrc includes three GNOME-related meta packages:
8165 * meta-pkgs/gnome-base: Provides the core GNOME desktop environment. It only
8166 includes the necessary bits to get it to boot correctly, although it may
8167 lack important functionality for daily operation. The idea behind this
8168 package is to let end users build their own configurations on top of this
8169 one, first installing this meta package to achieve a functional setup and
8170 then adding individual applications.
8172 * meta-pkgs/gnome: Provides a complete installation of the GNOME platform and
8173 desktop as defined by the GNOME project; this is based on the components
8174 distributed in the platform/x.y/x.y.z/sources and desktop/x.y/x.y.z/sources
8175 directories of the official FTP server. Developer-only tools found in those
8176 directories are not installed unless required by some other component to
8177 work properly. Similarly, packages from the bindings set (bindings/x.y/
8178 x.y.z/sources) are not pulled in unless required as a dependency for an
8179 end-user component. This package "extends" meta-pkgs/gnome-base.
8181 * meta-pkgs/gnome-devel: Installs all the tools required to build a GNOME
8182 component when fetched from the CVS repository. These are required to let
8183 the autogen.sh scripts work appropriately.
8185 In all these packages, the DEPENDS lines are sorted in a way that eases
8186 updates: a package may depend on other packages listed before it but not on any
8187 listed after it. It is very important to keep this order to ease updates so...
8188 do not change it to alphabetical sorting!
8190 23.2. Packaging a GNOME application
8192 Almost all GNOME applications are written in C and use a common set of tools as
8193 their build system. Things get different with the new bindings to other
8194 languages (such as Python), but the following will give you a general idea on
8195 the minimum required tools:
8197 * Almost all GNOME applications use the GNU Autotools as their build system.
8198 As a general rule you will need to tell this to your package:
8204 * If the package uses pkg-config to detect dependencies, add this tool to the
8205 list of required utilities:
8207 USE_TOOLS+=pkg-config
8209 Also use pkgtools/verifypc at the end of the build process to ensure that
8210 you did not miss to specify any dependency in your package and that the
8211 version requirements are all correct.
8213 * If the package uses intltool, be sure to add intltool to the USE_TOOLS to
8214 handle dependencies and to force the package to use the latest available
8217 * If the package uses gtk-doc (a documentation generation utility), do not
8218 add a dependency on it. The tool is rather big and the distfile should come
8219 with pregenerated documentation anyway; if it does not, it is a bug that
8220 you ought to report. For such packages you should disable gtk-doc (unless
8223 CONFIGURE_ARGS+=--disable-gtk-doc
8225 The default location of installed HTML files (share/gtk-doc/<package-name>)
8226 is correct and should not be changed unless the package insists on
8227 installing them somewhere else. Otherwise programs as devhelp will not be
8228 able to open them. You can do that with an entry similar to:
8230 CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
8232 GNOME uses multiple shared directories and files under the installation prefix
8233 to maintain databases. In this context, shared means that those exact same
8234 directories and files are used among several different packages, leading to
8235 conflicts in the PLIST. pkgsrc currently includes functionality to handle the
8236 most common cases, so you have to forget about using @unexec ${RMDIR} lines in
8237 your file lists and omitting shared files from them. If you find yourself doing
8238 those, your package is most likely incorrect.
8240 The following table lists the common situations that result in using shared
8241 directories or files. For each of them, the appropriate solution is given.
8242 After applying the solution be sure to regenerate the package's file list with
8243 make print-PLIST and ensure it is correct.
8245 Table 23.1. PLIST handling for GNOME packages
8247 +-----------------------------------------------------------------------------+
8248 | If the package... | Then... |
8249 |-------------------------------------------+---------------------------------|
8250 | |See Section 19.6.10, "Packages |
8251 |Installs OMF files under share/omf. |installing scrollkeeper/rarian |
8253 |-------------------------------------------+---------------------------------|
8254 |Installs icons under the share/icons/ |See Section 19.6.19, "Packages |
8255 |hicolor hierarchy or updates share/icons/ |installing hicolor theme icons". |
8256 |hicolor/icon-theme.cache. | |
8257 |-------------------------------------------+---------------------------------|
8258 | |See Section 19.6.14, "Packages |
8259 |Installs files under share/mime/packages. |installing extensions to the MIME|
8261 |-------------------------------------------+---------------------------------|
8262 |Installs .desktop files under share/ |See Section 19.6.20, "Packages |
8263 |applications and these include MIME |installing desktop files". |
8265 +-----------------------------------------------------------------------------+
8268 23.3. Updating GNOME to a newer version
8270 When seeing GNOME as a whole, there are two kinds of updates:
8274 Given that there is still a very long way for GNOME 3 (if it ever appears),
8275 we consider a major update one that goes from a 2.X version to a 2.Y one,
8276 where Y is even and greater than X. These are hard to achieve because they
8277 introduce lots of changes in the components' code and almost all GNOME
8278 distfiles are updated to newer versions. Some of them can even break API
8279 and ABI compatibility with the previous major version series. As a result,
8280 the update needs to be done all at once to minimize breakage.
8282 A major update typically consists of around 80 package updates and the
8283 addition of some new ones.
8287 We consider a minor update one that goes from a 2.A.X version to a 2.A.Y
8288 one where Y is greater than X. These are easy to achieve because they do
8289 not update all GNOME components, can be done in an incremental way and do
8290 not break API nor ABI compatibility.
8292 A minor update typically consists of around 50 package updates, although
8293 the numbers here may vary a lot.
8295 In order to update the GNOME components in pkgsrc to a new stable release
8296 (either major or minor), the following steps should be followed:
8298 1. Get a list of all the tarballs that form the new release by using the
8299 following commands. These will leave the full list of the components'
8300 distfiles into the list.txt file:
8302 % echo ls "*.tar.bz2" | \
8303 ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
8304 awk '{ print $9 }' >list.txt
8305 % echo ls "*.tar.bz2" | \
8306 ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
8307 awk '{ print $9 }' >>list.txt
8309 2. Open each meta package's Makefile and bump their version to the release you
8310 are updating them to. The three meta packages should be always consistent
8311 with versioning. Obviously remove any PKGREVISIONs that might be in them.
8313 3. For each meta package, update all its DEPENDS lines to match the latest
8314 versions as shown by the above commands. Do not list any newer version
8315 (even if found in the FTP) because the meta packages are supposed to list
8316 the exact versions that form a specific GNOME release. Exceptions are
8317 permitted here if a newer version solves a serious issue in the overall
8318 desktop experience; these typically come in the form of a revision bump in
8319 pkgsrc, not in newer versions from the developers.
8321 Packages not listed in the list.txt file should be updated to the latest
8322 version available (if found in pkgsrc). This is the case, for example, of
8323 the dependencies on the GNU Autotools in the meta-pkgs/gnome-devel meta
8326 4. Generate a patch from the modified meta packages and extract the list of
8327 "new" lines. This will provide you an outline on what packages need to be
8328 updated in pkgsrc and in what order:
8330 % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt
8332 5. For major desktop updates it is recommended to zap all your installed
8333 packages and start over from scratch at this point.
8335 6. Now comes the longest step by far: iterate over the contents of todo.txt
8336 and update the packages listed in it in order. For major desktop updates
8337 none of these should be committed until the entire set is completed because
8338 there are chances of breaking not-yet-updated packages.
8340 7. Once the packages are up to date and working, commit them to the tree one
8341 by one with appropriate log messages. At the end, commit the three meta
8342 package updates and all the corresponding changes to the doc/CHANGES-<YEAR>
8343 and pkgsrc/doc/TODO files.
8345 23.4. Patching guidelines
8347 GNOME is a very big component in pkgsrc which approaches 100 packages. Please,
8348 it is very important that you always, always, always feed back any portability
8349 fixes you do to a GNOME package to the mainstream developers (see
8350 Section 11.3.5, "Feedback to the author"). This is the only way to get their
8351 attention on portability issues and to ensure that future versions can be built
8352 out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further
8353 updates are. Those developers in charge of issuing major GNOME updates will be
8354 grateful if you do that.
8356 The most common places to report bugs are the GNOME's Bugzilla and the
8357 freedesktop.org's Bugzilla. Not all components use these to track bugs, but
8358 most of them do. Do not be short on your reports: always provide detailed
8359 explanations of the current failure, how it can be improved to achieve maximum
8360 portability and, if at all possible, provide a patch against CVS head. The more
8361 verbose you are, the higher chances of your patch being accepted.
8363 Also, please avoid using preprocessor magic to fix portability issues. While
8364 the FreeBSD GNOME people are doing a great job in porting GNOME to their
8365 operating system, the official GNOME sources are now plagued by conditionals
8366 that check for __FreeBSD__ and similar macros. This hurts portability. Please
8367 see our patching guidelines (Section 11.3.4, "Patching guidelines") for more
8370 Part III. The pkgsrc infrastructure internals
8372 This part of the guide deals with everything from the infrastructure that is
8373 behind the interfaces described in the developer's guide. A casual package
8374 maintainer should not need anything from this part.
8378 24. Design of the pkgsrc infrastructure
8380 24.1. The meaning of variable definitions
8381 24.2. Avoiding problems before they arise
8382 24.3. Variable evaluation
8384 24.3.1. At load time
8387 24.4. How can variables be specified?
8388 24.5. Designing interfaces for Makefile fragments
8390 24.5.1. Procedures with parameters
8391 24.5.2. Actions taken on behalf of parameters
8393 24.6. The order in which files are loaded
8395 24.6.1. The order in bsd.prefs.mk
8396 24.6.2. The order in bsd.pkg.mk
8398 25. Regression tests
8400 25.1. The regression tests framework
8401 25.2. Running the regression tests
8402 25.3. Adding a new regression test
8404 25.3.1. Overridable functions
8405 25.3.2. Helper functions
8409 26.1. Porting pkgsrc to a new operating system
8410 26.2. Adding support for a new compiler
8412 Chapter 24. Design of the pkgsrc infrastructure
8416 24.1. The meaning of variable definitions
8417 24.2. Avoiding problems before they arise
8418 24.3. Variable evaluation
8420 24.3.1. At load time
8423 24.4. How can variables be specified?
8424 24.5. Designing interfaces for Makefile fragments
8426 24.5.1. Procedures with parameters
8427 24.5.2. Actions taken on behalf of parameters
8429 24.6. The order in which files are loaded
8431 24.6.1. The order in bsd.prefs.mk
8432 24.6.2. The order in bsd.pkg.mk
8434 The pkgsrc infrastructure consists of many small Makefile fragments. Each such
8435 fragment needs a properly specified interface. This chapter explains how such
8436 an interface looks like.
8438 24.1. The meaning of variable definitions
8440 Whenever a variable is defined in the pkgsrc infrastructure, the location and
8441 the way of definition provide much information about the intended use of that
8442 variable. Additionally, more documentation may be found in a header comment or
8443 in this pkgsrc guide.
8445 A special file is mk/defaults/mk.conf, which lists all variables that are
8446 intended to be user-defined. They are either defined using the ?= operator or
8447 they are left undefined because defining them to anything would effectively
8448 mean "yes". All these variables may be overridden by the pkgsrc user in the
8451 Outside this file, the following conventions apply: Variables that are defined
8452 using the ?= operator may be overridden by a package.
8454 Variables that are defined using the = operator may be used read-only at
8457 Variables whose name starts with an underscore must not be accessed outside the
8458 pkgsrc infrastructure at all. They may change without further notice.
8462 These conventions are currently not applied consistently to the complete pkgsrc
8465 24.2. Avoiding problems before they arise
8467 All variables that contain lists of things should default to being empty. Two
8468 examples that do not follow this rule are USE_LANGUAGES and DISTFILES. These
8469 variables cannot simply be modified using the += operator in package Makefiles
8470 (or other files included by them), since there is no guarantee whether the
8471 variable is already set or not, and what its value is. In the case of
8472 DISTFILES, the packages "know" the default value and just define it as in the
8475 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
8477 Because of the selection of this default value, the same value appears in many
8478 package Makefiles. Similarly for USE_LANGUAGES, but in this case the default
8479 value ("c") is so short that it doesn't stand out. Nevertheless it is mentioned
8482 24.3. Variable evaluation
8484 24.3.1. At load time
8486 Variable evaluation takes place either at load time or at runtime, depending on
8487 the context in which they occur. The contexts where variables are evaluated at
8490 * The right hand side of the := and != operators,
8492 * Make directives like .if or .for,
8496 A special exception are references to the iteration variables of .for loops,
8497 which are expanded inline, no matter in which context they appear.
8499 As the values of variables may change during load time, care must be taken not
8500 to evaluate them by accident. Typical examples for variables that should not be
8501 evaluated at load time are DEPENDS and CONFIGURE_ARGS. To make the effect more
8502 clear, here is an example:
8504 CONFIGURE_ARGS= # none
8506 CONFIGURE_ARGS+= CFLAGS=${CFLAGS:Q}
8508 CONFIGURE_ARGS:= ${CONFIGURE_ARGS}
8513 This code shows how the use of the := operator can quickly lead to unexpected
8514 results. The first paragraph is fairly common code. The second paragraph
8515 evaluates the CONFIGURE_ARGS variable, which results in CFLAGS=-O. In the third
8516 paragraph, the -Wall is appended to the CFLAGS, but this addition will not
8517 appear in CONFIGURE_ARGS. In actual code, the three paragraphs from above
8518 typically occur in completely unrelated files.
8522 After all the files have been loaded, the values of the variables cannot be
8523 changed anymore. Variables that are used in the shell commands are expanded at
8526 24.4. How can variables be specified?
8528 There are many ways in which the definition and use of a variable can be
8529 restricted in order to detect bugs and violations of the (mostly unwritten)
8530 policies. See the pkglint developer's documentation for further details.
8532 24.5. Designing interfaces for Makefile fragments
8534 Most of the .mk files fall into one of the following classes. Cases where a
8535 file falls into more than one class should be avoided as it often leads to
8538 24.5.1. Procedures with parameters
8540 In a traditional imperative programming language some of the .mk files could be
8541 described as procedures. They take some input parameters and?after
8542 inclusion?provide a result in output parameters. Since all variables in
8543 Makefiles have global scope care must be taken not to use parameter names that
8544 have already another meaning. For example, PKGNAME is a bad choice for a
8547 Procedures are completely evaluated at preprocessing time. That is, when
8548 calling a procedure all input parameters must be completely resolvable. For
8549 example, CONFIGURE_ARGS should never be an input parameter since it is very
8550 likely that further text will be added after calling the procedure, which would
8551 effectively apply the procedure to only a part of the variable. Also,
8552 references to other variables wit will be modified after calling the procedure.
8554 A procedure can declare its output parameters either as suitable for use in
8555 preprocessing directives or as only available at runtime. The latter
8556 alternative is for variables that contain references to other runtime
8559 Procedures shall be written such that it is possible to call the procedure more
8560 than once. That is, the file must not contain multiple-inclusion guards.
8562 Examples for procedures are mk/bsd.options.mk and mk/buildlink3/bsd.builtin.mk.
8563 To express that the parameters are evaluated at load time, they should be
8564 assigned using the := operator, which should be used only for this purpose.
8566 24.5.2. Actions taken on behalf of parameters
8568 Action files take some input parameters and may define runtime variables. They
8569 shall not define loadtime variables. There are action files that are included
8570 implicitly by the pkgsrc infrastructure, while other must be included
8573 An example for action files is mk/subst.mk.
8575 24.6. The order in which files are loaded
8577 Package Makefiles usually consist of a set of variable definitions, and include
8578 the file ../../mk/bsd.pkg.mk in the very last line. Before that, they may also
8579 include various other *.mk files if they need to query the availability of
8580 certain features like the type of compiler or the X11 implementation. Due to
8581 the heavy use of preprocessor directives like .if and .for, the order in which
8582 the files are loaded matters.
8584 This section describes at which point the various files are loaded and gives
8585 reasons for that order.
8587 24.6.1. The order in bsd.prefs.mk
8589 The very first action in bsd.prefs.mk is to define some essential variables
8590 like OPSYS, OS_VERSION and MACHINE_ARCH.
8592 Then, the user settings are loaded from the file specified in MAKECONF, which
8593 is usually mk.conf. After that, those variables that have not been overridden
8594 by the user are loaded from mk/defaults/mk.conf.
8596 After the user settings, the system settings and platform settings are loaded,
8597 which may override the user settings.
8599 Then, the tool definitions are loaded. The tool wrappers are not yet in effect.
8600 This only happens when building a package, so the proper variables must be used
8601 instead of the direct tool names.
8603 As the last steps, some essential variables from the wrapper and the package
8604 system flavor are loaded, as well as the variables that have been cached in
8605 earlier phases of a package build.
8607 24.6.2. The order in bsd.pkg.mk
8609 First, bsd.prefs.mk is loaded.
8611 Then, the various *-vars.mk files are loaded, which fill default values for
8612 those variables that have not been defined by the package. These variables may
8613 later be used even in unrelated files.
8615 Then, the file bsd.pkg.error.mk provides the target error-check that is added
8616 as a special dependency to all other targets that use DELAYED_ERROR_MSG or
8617 DELAYED_WARNING_MSG.
8619 Then, the package-specific hacks from hacks.mk are included.
8621 Then, various other files follow. Most of them don't have any dependencies on
8622 what they need to have included before or after them, though some do.
8624 The code to check PKG_FAIL_REASON and PKG_SKIP_REASON is then executed, which
8625 restricts the use of these variables to all the files that have been included
8626 before. Appearances in later files will be silently ignored.
8628 Then, the files for the main targets are included, in the order of later
8629 execution, though the actual order should not matter.
8631 At last, some more files are included that don't set any interesting variables
8632 but rather just define make targets to be executed.
8634 Chapter 25. Regression tests
8638 25.1. The regression tests framework
8639 25.2. Running the regression tests
8640 25.3. Adding a new regression test
8642 25.3.1. Overridable functions
8643 25.3.2. Helper functions
8645 The pkgsrc infrastructure consists of a large codebase, and there are many
8646 corners where every little bit of a file is well thought out, making pkgsrc
8647 likely to fail as soon as anything is changed near those parts. To prevent most
8648 changes from breaking anything, a suite of regression tests should go along
8649 with every important part of the pkgsrc infrastructure. This chapter describes
8650 how regression tests work in pkgsrc and how you can add new tests.
8652 25.1. The regression tests framework
8654 25.2. Running the regression tests
8656 You first need to install the pkgtools/pkg_regress package, which provides the
8657 pkg_regress command. Then you can simply run that command, which will run all
8658 tests in the regress category.
8660 25.3. Adding a new regression test
8662 Every directory in the regress category that contains a file called spec is
8663 considered a regression test. This file is a shell program that is included by
8664 the pkg_regress command. The following functions can be overridden to suit your
8667 25.3.1. Overridable functions
8669 These functions do not take any parameters. They are all called in "set -e"
8670 mode, so you should be careful to check the exitcodes of any commands you run
8675 This function prepares the environment for the test. By default it does
8680 This function runs the actual test. By default, it calls TEST_MAKE with the
8681 arguments MAKEARGS_TEST and writes its output including error messages into
8682 the file TEST_OUTFILE.
8686 This function is run after the test and is typically used to compare the
8687 actual output from the one that is expected. It can make use of the various
8688 helper functions from the next section.
8692 This function cleans everything up after the test has been run. By default
8695 25.3.2. Helper functions
8697 exit_status(expected)
8699 This function compares the exitcode of the do_test() function with its
8700 first parameter. If they differ, the test will fail.
8702 output_require(regex...)
8704 This function checks for each of its parameters if the output from do_test
8705 () matches the extended regular expression. If it does not, the test will
8708 output_prohibit(regex...)
8710 This function checks for each of its parameters if the output from do_test
8711 () does not match the extended regular expression. If any of the regular
8712 expressions matches, the test will fail.
8714 Chapter 26. Porting pkgsrc
8718 26.1. Porting pkgsrc to a new operating system
8719 26.2. Adding support for a new compiler
8721 The pkgsrc system has already been ported to many operating systems, hardware
8722 architectures and compilers. This chapter explains the necessary steps to make
8723 pkgsrc even more portable.
8725 26.1. Porting pkgsrc to a new operating system
8727 To port pkgsrc to a new operating system (called MyOS in this example), you
8728 need to touch the following files:
8730 pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk
8732 This file contains some basic definitions, for example the name of the C
8737 Insert code that defines the variables OPSYS, OS_VERSION, LOWER_OS_VERSION,
8738 LOWER_VENDOR, MACHINE_ARCH, OBJECT_FMT, APPEND_ELF, and the other variables
8739 that appear in this file.
8743 This file contains the platform-specific definitions that are used by
8744 pkgsrc. Start by copying one of the other files and edit it to your needs.
8746 mk/platform/MyOS.pkg.dist
8748 This file contains a list of directories, together with their permission
8749 bits and ownership. These directories will be created automatically with
8750 every package that explicitly sets USE_MTREE. This feature will be removed.
8752 mk/platform/MyOS.x11.dist
8754 Just copy one of the pre-existing x11.dist files to your MyOS.x11.dist.
8756 mk/tools/bootstrap.mk
8758 On some operating systems, the tools that are provided with the base system
8759 are not good enough for pkgsrc. For example, there are many versions of sed
8760 (1) that have a narrow limit on the line length they can process. Therefore
8761 pkgsrc brings its own tools, which can be enabled here.
8763 mk/tools/tools.MyOS.mk
8765 This file defines the paths to all the tools that are needed by one or the
8766 other package in pkgsrc, as well as by pkgsrc itself. Find out where these
8767 tools are on your platform and add them.
8769 Now, you should be able to build some basic packages, like lang/perl5, shells/
8772 26.2. Adding support for a new compiler
8776 Appendix A. A simple example package: bison
8785 A.1.4. Checking a package with pkglint
8787 A.2. Steps for building, installing, packaging
8789 We checked to find a piece of software that wasn't in the packages collection,
8790 and picked GNU bison. Quite why someone would want to have bison when Berkeley
8791 yacc is already present in the tree is beyond us, but it's useful for the
8792 purposes of this exercise.
8801 DISTNAME= bison-1.25
8803 MASTER_SITES= ${MASTER_SITE_GNU}
8805 MAINTAINER= thorpej@NetBSD.org
8806 HOMEPAGE= http://www.gnu.org/software/bison/bison.html
8807 COMMENT= GNU yacc clone
8810 INFO_FILES= bison.info
8812 .include "../../mk/bsd.pkg.mk"
8816 GNU version of yacc. Can make re-entrant parsers, and numerous other
8817 improvements. Why you would want this when Berkeley yacc(1) is part
8818 of the NetBSD source tree is beyond me.
8828 A.1.4. Checking a package with pkglint
8830 The NetBSD package system comes with pkgtools/pkglint which helps to check the
8831 contents of these files. After installation it is quite easy to use, just
8832 change to the directory of the package you wish to examine and execute pkglint:
8837 Depending on the supplied command line arguments (see pkglint(1)), more checks
8838 will be performed. Use e.g. pkglint -Call -Wall for a very thorough check.
8840 A.2. Steps for building, installing, packaging
8842 Create the directory where the package lives, plus any auxiliary directories:
8844 # cd /usr/pkgsrc/lang
8849 Create Makefile, DESCR and PLIST (see Chapter 11, Package components - files,
8850 directories and contents) then continue with fetching the distfile:
8853 >> bison-1.25.tar.gz doesn't seem to exist on this system.
8854 >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
8855 Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
8856 ftp: Error retrieving file: 500 Internal error
8858 >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
8859 Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
8860 ftp: Error retrieving file: 500 Internal error
8862 >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
8863 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
8864 Successfully retrieved file.
8866 Generate the checksum of the distfile into distinfo:
8873 >> Checksum OK for bison-1.25.tar.gz.
8874 ===> Extracting for bison-1.25
8875 ===> Patching for bison-1.25
8876 ===> Ignoring empty patch directory
8877 ===> Configuring for bison-1.25
8878 creating cache ./config.cache
8879 checking for gcc... cc
8880 checking whether we are using GNU C... yes
8881 checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
8882 checking how to run the C preprocessor... cc -E
8883 checking for minix/config.h... no
8884 checking for POSIXized ISC... no
8885 checking whether cross-compiling... no
8886 checking for ANSI C header files... yes
8887 checking for string.h... yes
8888 checking for stdlib.h... yes
8889 checking for memory.h... yes
8890 checking for working const... yes
8891 checking for working alloca.h... no
8892 checking for alloca... yes
8893 checking for strerror... yes
8894 updating cache ./config.cache
8895 creating ./config.status
8897 ===> Building for bison-1.25
8898 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
8899 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
8900 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
8901 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
8902 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g derives.c
8903 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
8904 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getargs.c
8905 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g gram.c
8906 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lalr.c
8907 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
8908 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g main.c
8909 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g nullable.c
8910 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g output.c
8911 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g print.c
8912 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reader.c
8913 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reduce.c
8914 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g symtab.c
8915 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g warshall.c
8916 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g version.c
8917 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt.c
8918 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt1.c
8919 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
8920 ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
8922 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
8924 Everything seems OK, so install the files:
8927 >> Checksum OK for bison-1.25.tar.gz.
8928 ===> Installing for bison-1.25
8929 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
8930 rm -f /usr/pkg/bin/bison
8931 cd /usr/pkg/share; rm -f bison.simple bison.hairy
8932 rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
8933 install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison
8934 /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
8935 /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
8936 cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
8937 /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
8938 ===> Registering installation for bison-1.25
8940 You can now use bison, and also - if you decide so - remove it with pkg_delete
8941 bison. Should you decide that you want a binary package, do this now:
8944 >> Checksum OK for bison-1.25.tar.gz.
8945 ===> Building package for bison-1.25
8946 Creating package bison-1.25.tgz
8947 Registering depends:.
8948 Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
8950 Now that you don't need the source and object files any more, clean up:
8953 ===> Cleaning for bison-1.25
8955 Appendix B. Build logs
8959 B.1. Building figlet
8960 B.2. Packaging figlet
8962 B.1. Building figlet
8965 ===> Checking for vulnerabilities in figlet-2.2.1nb2
8966 => figlet221.tar.gz doesn't seem to exist on this system.
8967 => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
8969 Connected to ftp.plig.net.
8970 220 ftp.plig.org NcFTPd Server (licensed copy) ready.
8971 331 Guest login ok, send your complete e-mail address as password.
8972 230-You are user #5 of 500 simultaneous users allowed.
8975 230- | _| |_ ___ ___| |_|___ ___ ___ ___
8976 230- | _| _| . |_| . | | | . |_| . | _| . |
8977 230- |_| |_| | _|_| _|_|_|_ |_|___|_| |_ |
8978 230- |_| |_| |___| |___|
8980 230-** Welcome to ftp.plig.org **
8982 230-Please note that all transfers from this FTP site are logged. If you
8983 230-do not like this, please disconnect now.
8985 230-This archive is available via
8987 230-HTTP: http://ftp.plig.org/
8988 230-FTP: ftp://ftp.plig.org/ (max 500 connections)
8989 230-RSYNC: rsync://ftp.plig.org/ (max 30 connections)
8991 230-Please email comments, bug reports and requests for packages to be
8992 230-mirrored to ftp-admin@plig.org.
8995 230 Logged in anonymously.
8996 Remote system type is UNIX.
8997 Using binary mode to transfer files.
8999 250 "/pub" is new cwd.
9000 250-"/pub/figlet" is new cwd.
9002 250-Welcome to the figlet archive at ftp.figlet.org
9004 250- ftp://ftp.figlet.org/pub/figlet/
9006 250-The official FIGlet web page is:
9007 250- http://www.figlet.org/
9009 250-If you have questions, please mailto:info@figlet.org. If you want to
9010 250-contribute a font or something else, you can email us.
9012 250 "/pub/figlet/program" is new cwd.
9013 250 "/pub/figlet/program/unix" is new cwd.
9014 local: figlet221.tar.gz remote: figlet221.tar.gz
9015 502 Unimplemented command.
9016 227 Entering Passive Mode (195,40,6,41,246,104)
9017 150 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
9018 38% |************** | 65800 64.16 KB/s 00:01 ETA
9019 226 Transfer completed.
9020 172219 bytes received in 00:02 (75.99 KB/s)
9022 => Checksum OK for figlet221.tar.gz.
9023 ===> Extracting for figlet-2.2.1nb2
9024 ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found
9025 ===> Patching for figlet-2.2.1nb2
9026 ===> Applying pkgsrc patches for figlet-2.2.1nb2
9027 ===> Overriding tools for figlet-2.2.1nb2
9028 ===> Creating toolchain wrappers for figlet-2.2.1nb2
9029 ===> Configuring for figlet-2.2.1nb2
9030 ===> Building for figlet-2.2.1nb2
9031 gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\" -DDEFAULTFONTFILE=\"standard.flf\" figlet.c zipio.c crc.c inflate.c -o figlet
9033 gcc -O2 -o chkfont chkfont.c
9034 => Unwrapping files-to-be-installed.
9037 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9038 ===> Installing for figlet-2.2.1nb2
9039 install -d -o root -g wheel -m 755 /usr/pkg/bin
9040 install -d -o root -g wheel -m 755 /usr/pkg/man/man6
9041 mkdir -p /usr/pkg/share/figlet
9042 cp figlet /usr/pkg/bin
9043 cp chkfont /usr/pkg/bin
9044 chmod 555 figlist showfigfonts
9045 cp figlist /usr/pkg/bin
9046 cp showfigfonts /usr/pkg/bin
9047 cp fonts/*.flf /usr/pkg/share/figlet
9048 cp fonts/*.flc /usr/pkg/share/figlet
9049 cp figlet.6 /usr/pkg/man/man6
9050 ===> Registering installation for figlet-2.2.1nb2
9053 B.2. Packaging figlet
9056 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9057 ===> Packaging figlet-2.2.1nb2
9058 ===> Building binary package for figlet-2.2.1nb2
9059 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
9060 Using SrcDir value of /usr/pkg
9061 Registering depends:.
9064 Appendix C. Directory layout of the pkgsrc FTP server
9068 C.1. distfiles: The distributed source files
9069 C.2. misc: Miscellaneous things
9070 C.3. packages: Binary packages
9071 C.4. reports: Bulk build reports
9072 C.5. current, pkgsrc-20xxQy: source packages
9074 As in other big projects, the directory layout of pkgsrc is quite complex for
9075 newbies. This chapter explains where you find things on the FTP server. The
9076 base directory on ftp.NetBSD.org is /pub/pkgsrc/. On other servers it may be
9077 different, but inside this directory, everything should look the same, no
9078 matter on which server you are. This directory contains some subdirectories,
9079 which are explained below.
9081 C.1. distfiles: The distributed source files
9083 The directory distfiles contains lots of archive files from all pkgsrc
9084 packages, which are mirrored here. The subdirectories are called after their
9085 package names and are used when the distributed files have names that don't
9086 explicitly contain a version number or are otherwise too generic (for example
9089 C.2. misc: Miscellaneous things
9091 This directory contains things that individual pkgsrc developers find worth
9094 C.3. packages: Binary packages
9096 This directory contains binary packages for the various platforms that are
9097 supported by pkgsrc. Each subdirectory is of the form OPSYS/ARCH/OSVERSION_TAG.
9098 The meaning of these variables is:
9100 * OPSYS is the name of the operating system for which the packages have been
9101 built. The name is taken from the output of the uname command, so it may
9102 differ from the one you are used to hear.
9104 * ARCH is the hardware architecture of the platform for which the packages
9105 have been built. It also includes the ABI (Application Binary Interface)
9106 for platforms that have several of them.
9108 * OSVERSION is the version of the operating system. For version numbers that
9109 change often (for example NetBSD-current), the often-changing part should
9110 be replaced with an x, for example 4.99.x.
9112 * TAG is either 20xxQy for a stable branch, or head for packages built from
9113 the HEAD branch. The latter should only be used when the packages are
9114 updated on a regular basis. Otherwise the date from checking out pkgsrc
9115 should be appended, for example head_20071015.
9117 The rationale for exactly this scheme is that the pkgsrc users looking for
9118 binary packages can quickly click through the directories on the server and
9119 find the best binary packages for their machines. Since they usually know the
9120 operating system and the hardware architecture, OPSYS and ARCH are placed
9121 first. After these choices, they can select the best combination of OSVERSION
9122 and TAG together, since it is usually the case that packages stay compatible
9123 between different version of the operating system.
9125 In each of these directories, there is a whole binary packages collection for a
9126 specific platform. It has a directory called All which contains all binary
9127 packages. Besides that, there are various category directories that contain
9128 symbolic links to the real binary packages.
9130 C.4. reports: Bulk build reports
9132 Here are the reports from bulk builds, for those who want to fix packages that
9133 didn't build on some of the platforms. The structure of subdirectories should
9134 look like the one in Section C.3, "packages: Binary packages".
9136 C.5. current, pkgsrc-20xxQy: source packages
9138 These directories contain the "real" pkgsrc, that is the files that define how
9139 to create binary packages from source archives.
9141 The directory pkgsrc contains a snapshot of the CVS repository, which is
9142 updated regularly. The file pkgsrc.tar.gz contains the same as the directory,
9143 ready to be downloaded as a whole.
9145 In the directories for the quarterly branches, there is an additional file
9146 called pkgsrc-20xxQy.tar.gz, which contains the state of pkgsrc when it was
9149 Appendix D. Editing guidelines for the pkgsrc guide
9156 This section contains information on editing the pkgsrc guide itself.
9160 The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several
9161 files are created from it:
9163 * pkgsrc/doc/pkgsrc.txt
9165 * pkgsrc/doc/pkgsrc.html
9167 * http://www.NetBSD.org/docs/pkgsrc/
9169 * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.pdf: The PDF version of the pkgsrc
9172 * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps: PostScript version of the
9177 The procedure to edit the pkgsrc guide is:
9179 1. Make sure you have the packages needed to regenerate the pkgsrc guide (and
9180 other XML-based NetBSD documentation) installed. These are meta-pkgs/
9181 netbsd-doc for creating the ASCII and HTML versions, and meta-pkgs/
9182 netbsd-doc-print for the PostScript and PDF versions. You will need both
9183 packages installed, to make sure documentation is consistent across all
9186 2. Run cd doc/guide to get to the right directory. All further steps will take
9189 3. Edit the XML file(s) in files/.
9191 4. Run bmake to check the pkgsrc guide for valid XML and to build the final
9192 output files. If you get any errors at this stage, you can just edit the
9193 files, as there are only symbolic links in the working directory, pointing
9194 to the files in files/.
9196 5. (cd files && cvs commit)
9198 6. Run bmake clean && bmake to regenerate the output files with the proper RCS
9201 7. Run bmake regen to install and commit the files in both pkgsrc/doc and
9206 If you have added, removed or renamed some chapters, you need to
9207 synchronize them using cvs add or cvs delete in the htdocs directory.