Fixup fromcvs/togit conversion
[minix-pkgsrc.git] / doc / pkgsrc.txt
blobb841779522cd3db940f140b6c39e3d68f4406878
1 The pkgsrc guide
3 Documentation on the NetBSD packages system
5 Alistair Crooks
7 <agc@NetBSD.org>
9 Hubert Feyrer
11 <hubertf@NetBSD.org>
13 The pkgsrc Developers
15 Copyright   1994-2007 The NetBSD Foundation, Inc
17 $NetBSD: pkgsrc.xml,v 1.26 2007/09/18 08:17:21 rillig Exp $
19 Abstract
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 -------------------------------------------------------------------------------
28 Table of Contents
30 1. What is pkgsrc?
32     1.1. Introduction
34         1.1.1. Why pkgsrc?
35         1.1.2. Supported platforms
37     1.2. Overview
38     1.3. Terminology
40         1.3.1. Roles involved in pkgsrc
42     1.4. Typography
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
50             2.1.1. As tar archive
51             2.1.2. Via anonymous CVS
53         2.2. Keeping pkgsrc up-to-date
55             2.2.1. Via tar files
56             2.2.2. Via CVS
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. Cygwin
65             3.3.2. Darwin (Mac OS X)
66             3.3.3. FreeBSD
67             3.3.4. Interix
68             3.3.5. IRIX
69             3.3.6. Linux
70             3.3.7. OpenBSD
71             3.3.8. Solaris
73     4. Using pkgsrc
75         4.1. Using binary packages
77             4.1.1. Finding binary packages
78             4.1.2. Installing binary packages
79             4.1.3. Deinstalling packages
80             4.1.4. Getting information about installed packages
81             4.1.5. Checking for security vulnerabilities in installed packages
82             4.1.6. Finding if newer versions of your installed packages are in
83                 pkgsrc
84             4.1.7. Other administrative functions
85             4.1.8. A word of warning
87         4.2. Building packages from source
89             4.2.1. Requirements
90             4.2.2. Fetching distfiles
91             4.2.3. How to build and install
93     5. Configuring pkgsrc
95         5.1. General configuration
96         5.2. Variables affecting the build process
97         5.3. Variables affecting the installation process
98         5.4. Selecting and configuring the compiler
100             5.4.1. Selecting the compiler
101             5.4.2. Additional flags to the compiler (CFLAGS)
102             5.4.3. Additional flags to the linker (LDFLAGS)
104         5.5. Developer/advanced settings
105         5.6. Selecting Build Options
107     6. Creating binary packages
109         6.1. Building a single binary package
110         6.2. Settings for creation of binary packages
112     7. Creating binary packages for everything in pkgsrc (bulk builds)
114         7.1. Think first, build later
115         7.2. Requirements of a bulk build
116         7.3. Running an old-style bulk build
118             7.3.1. Configuration
119             7.3.2. Other environmental considerations
120             7.3.3. Operation
121             7.3.4. What it does
122             7.3.5. Disk space requirements
123             7.3.6. Setting up a sandbox for chrooted builds
124             7.3.7. Building a partial set of packages
125             7.3.8. Uploading results of a bulk build
127         7.4. Running a pbulk-style bulk build
129             7.4.1. Preparation
130             7.4.2. Configuration
132         7.5. Creating a multiple CD-ROM packages collection
134             7.5.1. Example of cdpack
136     8. Directory layout of the installed files
138         8.1. File system layout in ${LOCALBASE}
139         8.2. File system layout in ${VARBASE}
141     9. Frequently Asked Questions
143         9.1. Are there any mailing lists for pkg-related discussion?
144         9.2. Where's the pkgviews documentation?
145         9.3. Utilities for package management (pkgtools)
146         9.4. How to use pkgsrc as non-root
147         9.5. How to resume transfers when fetching distfiles?
148         9.6. How can I install/use modular X.org from pkgsrc?
149         9.7. How to fetch files from behind a firewall
150         9.8. How do I tell make fetch to do passive FTP?
151         9.9. How to fetch all distfiles at once
152         9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc"
153             mean?
154         9.11. What does "Could not find bsd.own.mk" mean?
155         9.12. Using 'sudo' with pkgsrc
156         9.13. How do I change the location of configuration files?
157         9.14. Automated security checks
158         9.15. Why do some packages ignore my CFLAGS?
159         9.16. A package does not build. What shall I do?
160         9.17. What does "Makefile appears to contain unresolved cvs/rcs/???
161             merge conflicts" mean?
163 II. The pkgsrc developer's guide
165     10. Creating a new pkgsrc package from scratch
167         10.1. Common types of packages
169             10.1.1. Perl modules
170             10.1.2. KDE applications
171             10.1.3. Python modules and programs
173         10.2. Examples
175             10.2.1. How the www/nvu package came into pkgsrc
177     11. Package components - files, directories and contents
179         11.1. Makefile
180         11.2. distinfo
181         11.3. patches/*
183             11.3.1. Structure of a single patch file
184             11.3.2. Creating patch files
185             11.3.3. Sources where the patch files come from
186             11.3.4. Patching guidelines
187             11.3.5. Feedback to the author
189         11.4. Other mandatory files
190         11.5. Optional files
192             11.5.1. Files affecting the binary package
193             11.5.2. Files affecting the build process
194             11.5.3. Files affecting nothing at all
196         11.6. work*
197         11.7. files/*
199     12. Programming in Makefiles
201         12.1. Caveats
202         12.2. Makefile variables
204             12.2.1. Naming conventions
206         12.3. Code snippets
208             12.3.1. Adding things to a list
209             12.3.2. Converting an internal list into an external list
210             12.3.3. Passing variables to a shell command
211             12.3.4. Quoting guideline
212             12.3.5. Workaround for a bug in BSD Make
214     13. PLIST issues
216         13.1. RCS ID
217         13.2. Semi-automatic PLIST generation
218         13.3. Tweaking output of make print-PLIST
219         13.4. Variable substitution in PLIST
220         13.5. Man page compression
221         13.6. Changing PLIST source with PLIST_SRC
222         13.7. Platform-specific and differing PLISTs
223         13.8. Sharing directories between packages
225     14. Buildlink methodology
227         14.1. Converting packages to use buildlink3
228         14.2. Writing buildlink3.mk files
230             14.2.1. Anatomy of a buildlink3.mk file
231             14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and
232                 BUILDLINK_ABI_DEPENDS.pkg in buildlink3.mk files
234         14.3. Writing builtin.mk files
236             14.3.1. Anatomy of a builtin.mk file
237             14.3.2. Global preferences for native or pkgsrc software
239     15. The pkginstall framework
241         15.1. Files and directories outside the installation prefix
243             15.1.1. Directory manipulation
244             15.1.2. File manipulation
246         15.2. Configuration files
248             15.2.1. How PKG_SYSCONFDIR is set
249             15.2.2. Telling the software where configuration files are
250             15.2.3. Patching installations
251             15.2.4. Disabling handling of configuration files
253         15.3. System startup scripts
255             15.3.1. Disabling handling of system startup scripts
257         15.4. System users and groups
258         15.5. System shells
260             15.5.1. Disabling shell registration
262         15.6. Fonts
264             15.6.1. Disabling automatic update of the fonts databases
266     16. Options handling
268         16.1. Global default options
269         16.2. Converting packages to use bsd.options.mk
270         16.3. Option Names
271         16.4. Determining the options of dependencies
273     17. The build process
275         17.1. Introduction
276         17.2. Program location
277         17.3. Directories used during the build process
278         17.4. Running a phase
279         17.5. The fetch phase
281             17.5.1. What to fetch and where to get it from
282             17.5.2. How are the files fetched?
284         17.6. The checksum phase
285         17.7. The extract phase
286         17.8. The patch phase
287         17.9. The tools phase
288         17.10. The wrapper phase
289         17.11. The configure phase
290         17.12. The build phase
291         17.13. The test phase
292         17.14. The install phase
293         17.15. The package phase
294         17.16. Cleaning up
295         17.17. Other helpful targets
297     18. Tools needed for building or running
299         18.1. Tools for pkgsrc builds
300         18.2. Tools needed by packages
301         18.3. Tools provided by platforms
302         18.4. Questions regarding the tools
304     19. Making your package work
306         19.1. General operation
308             19.1.1. Portability of packages
309             19.1.2. How to pull in user-settable variables from mk.conf
310             19.1.3. User interaction
311             19.1.4. Handling licenses
312             19.1.5. Restricted packages
313             19.1.6. Handling dependencies
314             19.1.7. Handling conflicts with other packages
315             19.1.8. Packages that cannot or should not be built
316             19.1.9. Packages which should not be deleted, once installed
317             19.1.10. Handling packages with security problems
318             19.1.11. How to handle incrementing versions when fixing an
319                 existing package
320             19.1.12. Substituting variable text in the package files (the SUBST
321                 framework)
323         19.2. Fixing problems in the fetch phase
325             19.2.1. Packages whose distfiles aren't available for plain
326                 downloading
327             19.2.2. How to handle modified distfiles with the 'old' name
329         19.3. Fixing problems in the configure phase
331             19.3.1. Shared libraries - libtool
332             19.3.2. Using libtool on GNU packages that already support libtool
333             19.3.3. GNU Autoconf/Automake
335         19.4. Programming languages
337             19.4.1. C, C++, and Fortran
338             19.4.2. Java
339             19.4.3. Packages containing perl scripts
340             19.4.4. Packages containing shell scripts
341             19.4.5. Other programming languages
343         19.5. Fixing problems in the build phase
345             19.5.1. Compiling C and C++ code conditionally
346             19.5.2. How to handle compiler bugs
347             19.5.3. Undefined reference to "..."
348             19.5.4. Running out of memory
350         19.6. Fixing problems in the install phase
352             19.6.1. Creating needed directories
353             19.6.2. Where to install documentation
354             19.6.3. Installing highscore files
355             19.6.4. Adding DESTDIR support to packages
356             19.6.5. Packages with hardcoded paths to other interpreters
357             19.6.6. Packages installing perl modules
358             19.6.7. Packages installing info files
359             19.6.8. Packages installing man pages
360             19.6.9. Packages installing GConf data files
361             19.6.10. Packages installing scrollkeeper/rarian data files
362             19.6.11. Packages installing X11 fonts
363             19.6.12. Packages installing GTK2 modules
364             19.6.13. Packages installing SGML or XML data
365             19.6.14. Packages installing extensions to the MIME database
366             19.6.15. Packages using intltool
367             19.6.16. Packages installing startup scripts
368             19.6.17. Packages installing TeX modules
369             19.6.18. Packages supporting running binaries in emulation
370             19.6.19. Packages installing hicolor theme icons
371             19.6.20. Packages installing desktop files
373         19.7. Marking packages as having problems
375     20. Debugging
376     21. Submitting and Committing
378         21.1. Submitting binary packages
379         21.2. Submitting source packages (for non-NetBSD-developers)
380         21.3. General notes when adding, updating, or removing packages
381         21.4. Committing: Adding a package to CVS
382         21.5. Updating a package to a newer version
383         21.6. Renaming a package in pkgsrc
384         21.7. Moving a package in pkgsrc
386     22. Frequently Asked Questions
387     23. GNOME packaging and porting
389         23.1. Meta packages
390         23.2. Packaging a GNOME application
391         23.3. Updating GNOME to a newer version
392         23.4. Patching guidelines
394 III. The pkgsrc infrastructure internals
396     24. Design of the pkgsrc infrastructure
398         24.1. The meaning of variable definitions
399         24.2. Avoiding problems before they arise
400         24.3. Variable evaluation
402             24.3.1. At load time
403             24.3.2. At runtime
405         24.4. How can variables be specified?
406         24.5. Designing interfaces for Makefile fragments
408             24.5.1. Procedures with parameters
409             24.5.2. Actions taken on behalf of parameters
411         24.6. The order in which files are loaded
413             24.6.1. The order in bsd.prefs.mk
414             24.6.2. The order in bsd.pkg.mk
416     25. Regression tests
418         25.1. The regression tests framework
419         25.2. Running the regression tests
420         25.3. Adding a new regression test
422             25.3.1. Overridable functions
423             25.3.2. Helper functions
425     26. Porting pkgsrc
427         26.1. Porting pkgsrc to a new operating system
428         26.2. Adding support for a new compiler
430 A. A simple example package: bison
432     A.1. files
434         A.1.1. Makefile
435         A.1.2. DESCR
436         A.1.3. PLIST
437         A.1.4. Checking a package with pkglint
439     A.2. Steps for building, installing, packaging
441 B. Build logs
443     B.1. Building figlet
444     B.2. Packaging figlet
446 C. Directory layout of the pkgsrc FTP server
448     C.1. distfiles: The distributed source files
449     C.2. misc: Miscellaneous things
450     C.3. packages: Binary packages
451     C.4. reports: Bulk build reports
452     C.5. current, pkgsrc-20xxQy: source packages
454 D. Editing guidelines for the pkgsrc guide
456     D.1. Make targets
457     D.2. Procedure
459 List of Tables
461 1.1. Platforms supported by pkgsrc
462 11.1. Patching examples
463 23.1. PLIST handling for GNOME packages
465 Chapter 1. What is pkgsrc?
467 Table of Contents
469 1.1. Introduction
471     1.1.1. Why pkgsrc?
472     1.1.2. Supported platforms
474 1.2. Overview
475 1.3. Terminology
477     1.3.1. Roles involved in pkgsrc
479 1.4. Typography
481 1.1. Introduction
483 There is a lot of software freely available for Unix-based systems, which is
484 usually available in form of the source code. Before such software can be used,
485 it needs to be configured to the local system, compiled and installed, and this
486 is exactly what The NetBSD Packages Collection (pkgsrc) does. pkgsrc also has
487 some basic commands to handle binary packages, so that not every user has to
488 build the packages for himself, which is a time-costly task.
490 pkgsrc currently contains several thousand packages, including:
492   * www/apache - The Apache web server
494   * www/firefox - The Firefox web browser
496   * meta-pkgs/gnome - The GNOME Desktop Environment
498   * meta-pkgs/kde3 - The K Desktop Environment
500 ...just to name a few.
502 pkgsrc has built-in support for handling varying dependencies, such as pthreads
503 and X11, and extended features such as IPv6 support on a range of platforms.
505 1.1.1. Why pkgsrc?
507 pkgsrc provides the following key features:
509   * Easy building of software from source as well as the creation and
510     installation of binary packages. The source and latest patches are
511     retrieved from a master or mirror download site, checksum verified, then
512     built on your system. Support for binary-only distributions is available
513     for both native platforms and NetBSD emulated platforms.
515   * All packages are installed in a consistent directory tree, including
516     binaries, libraries, man pages and other documentation.
518   * Package dependencies, including when performing package updates, are
519     handled automatically. The configuration files of various packages are
520     handled automatically during updates, so local changes are preserved.
522   * Like NetBSD, pkgsrc is designed with portability in mind and consists of
523     highly portable code. This allows the greatest speed of development when
524     porting to a new platform. This portability also ensures that pkgsrc is 
525     consistent across all platforms.
527   * The installation prefix, acceptable software licenses, international
528     encryption requirements and build-time options for a large number of
529     packages are all set in a simple, central configuration file.
531   * The entire source (not including the distribution files) is freely
532     available under a BSD license, so you may extend and adapt pkgsrc to your
533     needs. Support for local packages and patches is available right out of the
534     box, so you can configure it specifically for your environment.
536 The following principles are basic to pkgsrc:
538   * "It should only work if it's right." ? That means, if a package contains
539     bugs, it's better to find them and to complain about them rather than to
540     just install the package and hope that it works. There are numerous checks
541     in pkgsrc that try to find such bugs: Static analysis tools (pkgtools/
542     pkglint), build-time checks (portability of shell scripts), and
543     post-installation checks (installed files, references to shared libraries,
544     script interpreters).
546   * "If it works, it should work everywhere" ? Like NetBSD has been ported to
547     many hardware architectures, pkgsrc has been ported to many operating
548     systems. Care is taken that packages behave the same on all platforms.
550 1.1.2. Supported platforms
552 pkgsrc consists of both a source distribution and a binary distribution for
553 these operating systems. After retrieving the required source or binaries, you
554 can be up and running with pkgsrc in just minutes!
556 pkgsrc was derived from FreeBSD's ports system, and initially developed for
557 NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
558 platforms:
560 Table 1.1. Platforms supported by pkgsrc
562 +----------------------------------------------------------------+
563 |                  Platform                   |Date Support Added|
564 |---------------------------------------------+------------------|
565 |NetBSD                                       |     Aug 1997     |
566 |---------------------------------------------+------------------|
567 |Solaris                                      |     Mar 1999     |
568 |---------------------------------------------+------------------|
569 |Linux                                        |     Jun 1999     |
570 |---------------------------------------------+------------------|
571 |Darwin (Mac OS X)                            |     Oct 2001     |
572 |---------------------------------------------+------------------|
573 |FreeBSD                                      |     Nov 2002     |
574 |---------------------------------------------+------------------|
575 |OpenBSD                                      |     Nov 2002     |
576 |---------------------------------------------+------------------|
577 |IRIX                                         |     Dec 2002     |
578 |---------------------------------------------+------------------|
579 |BSD/OS                                       |     Dec 2003     |
580 |---------------------------------------------+------------------|
581 |AIX                                          |     Dec 2003     |
582 |---------------------------------------------+------------------|
583 |Interix (Microsoft Windows Services for Unix)|     Mar 2004     |
584 |---------------------------------------------+------------------|
585 |DragonFlyBSD                                 |     Oct 2004     |
586 |---------------------------------------------+------------------|
587 |OSF/1                                        |     Nov 2004     |
588 |---------------------------------------------+------------------|
589 |HP-UX                                        |     Apr 2007     |
590 |---------------------------------------------+------------------|
591 |Haiku                                        |     Sep 2010     |
592 |---------------------------------------------+------------------|
593 |MirBSD                                       |     Aug 2011     |
594 |---------------------------------------------+------------------|
595 |Minix3                                       |     Nov 2011     |
596 |---------------------------------------------+------------------|
597 |Cygwin                                       |     Mar 2013     |
598 +----------------------------------------------------------------+
601 1.2. Overview
603 This document is divided into three parts. The first, The pkgsrc user's guide,
604 describes how one can use one of the packages in the Package Collection, either
605 by installing a precompiled binary package, or by building one's own copy using
606 the NetBSD package system. The second part, The pkgsrc developer's guide,
607 explains how to prepare a package so it can be easily built by other NetBSD
608 users without knowing about the package's building details. The third part, The
609 pkgsrc infrastructure internals is intended for those who want to understand
610 how pkgsrc is implemented.
612 This document is available in various formats: HTML, PDF, PS, TXT.
614 1.3. Terminology
616 There has been a lot of talk about "ports", "packages", etc. so far. Here is a
617 description of all the terminology used within this document.
619 Package
621     A set of files and building instructions that describe what's necessary to
622     build a certain piece of software using pkgsrc. Packages are traditionally
623     stored under /usr/pkgsrc.
625 The NetBSD package system
627     This is the former name of "pkgsrc". It is part of the NetBSD operating
628     system and can be bootstrapped to run on non-NetBSD operating systems as
629     well. It handles building (compiling), installing, and removing of
630     packages.
632 Distfile
634     This term describes the file or files that are provided by the author of
635     the piece of software to distribute his work. All the changes necessary to
636     build on NetBSD are reflected in the corresponding package. Usually the
637     distfile is in the form of a compressed tar-archive, but other types are
638     possible, too. Distfiles are usually stored below /usr/pkgsrc/distfiles.
640 Port
642     This is the term used by FreeBSD and OpenBSD people for what we call a
643     package. In NetBSD terminology, "port" refers to a different architecture.
645 Precompiled/binary package
647     A set of binaries built with pkgsrc from a distfile and stuffed together in
648     a single .tgz file so it can be installed on machines of the same machine
649     architecture without the need to recompile. Packages are usually generated
650     in /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.
652     Sometimes, this is referred to by the term "package" too, especially in the
653     context of precompiled packages.
655 Program
657     The piece of software to be installed which will be constructed from all
658     the files in the distfile by the actions defined in the corresponding
659     package.
661 1.3.1. Roles involved in pkgsrc
663 pkgsrc users
665     The pkgsrc users are people who use the packages provided by pkgsrc.
666     Typically they are system administrators. The people using the software
667     that is inside the packages (maybe called "end users") are not covered by
668     the pkgsrc guide.
670     There are two kinds of pkgsrc users: Some only want to install pre-built
671     binary packages. Others build the pkgsrc packages from source, either for
672     installing them directly or for building binary packages themselves. For
673     pkgsrc users Part I, "The pkgsrc user's guide" should provide all necessary
674     documentation.
676 package maintainers
678     A package maintainer creates packages as described in Part II, "The pkgsrc
679     developer's guide".
681 infrastructure developers
683     These people are involved in all those files that live in the mk/ directory
684     and below. Only these people should need to read through Part III, "The
685     pkgsrc infrastructure internals", though others might be curious, too.
687 1.4. Typography
689 When giving examples for commands, shell prompts are used to show if the
690 command should/can be issued as root, or if "normal" user privileges are
691 sufficient. We use a # for root's shell prompt, and a % for users' shell
692 prompt, assuming they use the C-shell or tcsh.
694 Part I. The pkgsrc user's guide
696 Table of Contents
698 2. Where to get pkgsrc and how to keep it up-to-date
700     2.1. Getting pkgsrc for the first time
702         2.1.1. As tar archive
703         2.1.2. Via anonymous CVS
705     2.2. Keeping pkgsrc up-to-date
707         2.2.1. Via tar files
708         2.2.2. Via CVS
710 3. Using pkgsrc on systems other than NetBSD
712     3.1. Binary distribution
713     3.2. Bootstrapping pkgsrc
714     3.3. Platform-specific notes
716         3.3.1. Cygwin
717         3.3.2. Darwin (Mac OS X)
718         3.3.3. FreeBSD
719         3.3.4. Interix
720         3.3.5. IRIX
721         3.3.6. Linux
722         3.3.7. OpenBSD
723         3.3.8. Solaris
725 4. Using pkgsrc
727     4.1. Using binary packages
729         4.1.1. Finding binary packages
730         4.1.2. Installing binary packages
731         4.1.3. Deinstalling packages
732         4.1.4. Getting information about installed packages
733         4.1.5. Checking for security vulnerabilities in installed packages
734         4.1.6. Finding if newer versions of your installed packages are in
735             pkgsrc
736         4.1.7. Other administrative functions
737         4.1.8. A word of warning
739     4.2. Building packages from source
741         4.2.1. Requirements
742         4.2.2. Fetching distfiles
743         4.2.3. How to build and install
745 5. Configuring pkgsrc
747     5.1. General configuration
748     5.2. Variables affecting the build process
749     5.3. Variables affecting the installation process
750     5.4. Selecting and configuring the compiler
752         5.4.1. Selecting the compiler
753         5.4.2. Additional flags to the compiler (CFLAGS)
754         5.4.3. Additional flags to the linker (LDFLAGS)
756     5.5. Developer/advanced settings
757     5.6. Selecting Build Options
759 6. Creating binary packages
761     6.1. Building a single binary package
762     6.2. Settings for creation of binary packages
764 7. Creating binary packages for everything in pkgsrc (bulk builds)
766     7.1. Think first, build later
767     7.2. Requirements of a bulk build
768     7.3. Running an old-style bulk build
770         7.3.1. Configuration
771         7.3.2. Other environmental considerations
772         7.3.3. Operation
773         7.3.4. What it does
774         7.3.5. Disk space requirements
775         7.3.6. Setting up a sandbox for chrooted builds
776         7.3.7. Building a partial set of packages
777         7.3.8. Uploading results of a bulk build
779     7.4. Running a pbulk-style bulk build
781         7.4.1. Preparation
782         7.4.2. Configuration
784     7.5. Creating a multiple CD-ROM packages collection
786         7.5.1. Example of cdpack
788 8. Directory layout of the installed files
790     8.1. File system layout in ${LOCALBASE}
791     8.2. File system layout in ${VARBASE}
793 9. Frequently Asked Questions
795     9.1. Are there any mailing lists for pkg-related discussion?
796     9.2. Where's the pkgviews documentation?
797     9.3. Utilities for package management (pkgtools)
798     9.4. How to use pkgsrc as non-root
799     9.5. How to resume transfers when fetching distfiles?
800     9.6. How can I install/use modular X.org from pkgsrc?
801     9.7. How to fetch files from behind a firewall
802     9.8. How do I tell make fetch to do passive FTP?
803     9.9. How to fetch all distfiles at once
804     9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
805     9.11. What does "Could not find bsd.own.mk" mean?
806     9.12. Using 'sudo' with pkgsrc
807     9.13. How do I change the location of configuration files?
808     9.14. Automated security checks
809     9.15. Why do some packages ignore my CFLAGS?
810     9.16. A package does not build. What shall I do?
811     9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
812         conflicts" mean?
814 Chapter 2. Where to get pkgsrc and how to keep it up-to-date
816 Table of Contents
818 2.1. Getting pkgsrc for the first time
820     2.1.1. As tar archive
821     2.1.2. Via anonymous CVS
823 2.2. Keeping pkgsrc up-to-date
825     2.2.1. Via tar files
826     2.2.2. Via CVS
828 Before you download and extract the files, you need to decide where you want to
829 extract them. When using pkgsrc as root user, pkgsrc is usually installed in /
830 usr/pkgsrc. You are though free to install the sources and binary packages
831 wherever you want in your filesystem, provided that the pathname does not
832 contain white-space or other characters that are interpreted specially by the
833 shell and some other programs. A safe bet is to use only letters, digits,
834 underscores and dashes.
836 2.1. Getting pkgsrc for the first time
838 Before you download any pkgsrc files, you should decide whether you want the 
839 current branch or the stable branch. The latter is forked on a quarterly basis
840 from the current branch and only gets modified for security updates. The names
841 of the stable branches are built from the year and the quarter, for example
842 2009Q1.
844 The second step is to decide how you want to download pkgsrc. You can get it as
845 a tar file or via CVS. Both ways are described here.
847 Note that tar archive contains CVS working copy. Thus you can switch to using
848 CVS at any later time.
850 Note also that quarterly branch is not frozen in stone. It receives critical
851 updates.
853 2.1.1. As tar archive
855 The primary download location for all pkgsrc files is http://ftp.NetBSD.org/pub
856 /pkgsrc/ or ftp://ftp.NetBSD.org/pub/pkgsrc/ (it points to the same location).
857 There are a number of subdirectories for different purposes, which are
858 described in detail in Appendix C, Directory layout of the pkgsrc FTP server.
860 The tar archive for the current branch is in the directory current and is
861 called pkgsrc.tar.gz. It is autogenerated daily.
863 To save download time we provide bzip2- and xz-compressed archives which are
864 published at pkgsrc.tar.bz2 and pkgsrc.tar.xz respectively.
866 You can fetch the same files using FTP.
868 The tar file for the stable branch 2009Q1 is in the directory pkgsrc-2009Q1 and
869 is also called pkgsrc-2009Q1.tar.gz.
871 To download a pkgsrc stable tarball, run:
873 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-20xxQy/pkgsrc-20xxQy.tar.gz
875 Where pkgsrc-20xxQy is the stable branch to be downloaded, for example, "
876 pkgsrc-2009Q1".
878 You can use fetch it also using "wget", "curl", or your web browser.
880 Then, extract it with:
882 $ tar -xzf pkgsrc-20xxQy.tar.gz -C /usr
884 This will create the directory pkgsrc/ in /usr/ and all the package source will
885 be stored under /usr/pkgsrc/.
887 To download pkgsrc-current, run:
889 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
891 2.1.2. Via anonymous CVS
893 To fetch a specific pkgsrc stable branch, run:
895 $ cd /usr && cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-20xxQy -P pkgsrc
897 Where pkgsrc-20xxQy is the stable branch to be checked out, for example, "
898 pkgsrc-2009Q1"
900 This will create the directory pkgsrc/ in your /usr/ directory and all the
901 package source will be stored under /usr/pkgsrc/.
903 To fetch the pkgsrc current branch, run:
905 $ cd /usr && cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
907 Refer to the list of available mirrors to choose a faster CVS mirror, if
908 needed.
910 If you get error messages from rsh, you need to set CVS_RSH variable. E.g.:
912 $ cd /usr && env CVS_RSH=ssh cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
914 Refer to documentation on your command shell how to set CVS_RSH=ssh
915 permanently. For Bourne shells, you can set it in your .profile or better
916 globally in /etc/profile:
918 # set CVS remote shell command
919 CVS_RSH=ssh
920 export CVS_RSH
922 By default, CVS doesn't do things like most people would expect it to do. But
923 there is a way to convince CVS, by creating a file called .cvsrc in your home
924 directory and saving the following lines to it. This file will save you lots of
925 headache and some bug reports, so we strongly recommend it. You can find an
926 explanation of this file in the CVS documentation.
928 # recommended CVS configuration file from the pkgsrc guide
929 cvs -q -z2
930 checkout -P
931 update -dP
932 diff -upN
933 rdiff -u
934 release -d
936 2.2. Keeping pkgsrc up-to-date
938 The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you
939 have first installed it via a tar file). It saves bandwidth and hard disk
940 activity, compared to downloading the tar file again.
942 2.2.1. Via tar files
944 Warning
946 When updating from a tar file, you first need to completely remove the old
947 pkgsrc directory. Otherwise those files that have been removed from pkgsrc in
948 the mean time will not be removed on your local disk, resulting in
949 inconsistencies. When removing the old files, any changes that you have done to
950 the pkgsrc files will be lost after updating. Therefore updating via CVS is
951 strongly recommended.
953 Note that by default the distfiles and the binary packages are saved in the
954 pkgsrc tree, so don't forget to rescue them before updating. You can also
955 configure pkgsrc to use other than the default directories by setting the
956 DISTDIR and PACKAGES variables. See Chapter 5, Configuring pkgsrc for the
957 details.
959 To update pkgsrc from a tar file, download the tar file as explained above.
960 Then, make sure that you have not made any changes to the files in the pkgsrc
961 directory. Remove the pkgsrc directory and extract the new tar file. Done.
963 2.2.2. Via CVS
965 To update pkgsrc via CVS, change to the pkgsrc directory and run cvs:
967 $ cd /usr/pkgsrc && cvs update -dP
969 If you get error messages from rsh, you need to set CVS_RSH variable as
970 described above. E.g.:
972 $ cd /usr/pkgsrc && env CVS_RSH=ssh cvs up -dP
974 2.2.2.1. Switching between different pkgsrc branches
976 When updating pkgsrc, the CVS program keeps track of the branch you selected.
977 But if you, for whatever reason, want to switch from the stable branch to the
978 current one, you can do it by adding the option "-A" after the "update"
979 keyword. To switch from the current branch back to the stable branch, add the "
980 -rpkgsrc-2009Q3" option.
982 2.2.2.2. What happens to my changes when updating?
984 When you update pkgsrc, the CVS program will only touch those files that are
985 registered in the CVS repository. That means that any packages that you created
986 on your own will stay unmodified. If you change files that are managed by CVS,
987 later updates will try to merge your changes with those that have been done by
988 others. See the CVS manual, chapter "update" for details.
990 Chapter 3. Using pkgsrc on systems other than NetBSD
992 Table of Contents
994 3.1. Binary distribution
995 3.2. Bootstrapping pkgsrc
996 3.3. Platform-specific notes
998     3.3.1. Cygwin
999     3.3.2. Darwin (Mac OS X)
1000     3.3.3. FreeBSD
1001     3.3.4. Interix
1002     3.3.5. IRIX
1003     3.3.6. Linux
1004     3.3.7. OpenBSD
1005     3.3.8. Solaris
1007 3.1. Binary distribution
1009 See Section 4.1, "Using binary packages".
1011 3.2. Bootstrapping pkgsrc
1013 pkgsrc can be bootstrapped for use in two different modes: privileged and
1014 unprivileged one. In unprivileged mode in contrast to privileged one all
1015 programs are installed under one particular user and cannot utilise privileged
1016 operations (packages don't create special users and all special file
1017 permissions like setuid are ignored).
1019 Installing the bootstrap kit from source should be as simple as:
1021 # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
1022 # cd pkgsrc/bootstrap
1023 # ./bootstrap
1026 To bootstrap in unprivileged mode pass "--unprivileged" flag to bootstrap
1028 By default, in privileged mode pkgsrc uses /usr/pkg for prefix where programs
1029 will be installed in, and /var/db/pkg for the package database directory where
1030 pkgsrc will do its internal bookkeeping, /var is used as varbase, where
1031 packages install their persistent data. In unprivileged mode pkgsrc uses ~/pkg
1032 for prefix, ~/pkg/var/db/pkg for the package database, and ~/pkg/var for 
1033 varbase.
1035 You can change default layout using command-line arguments. Run "./bootstrap
1036 --help" to get details.
1038 Note
1040 The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
1041 For examples in this guide, use bmake instead of "make".
1043 Note
1045 It is possible to bootstrap multiple instances of pkgsrc using non-intersecting
1046 directories. Use bmake corresponding to the installation you're working with to
1047 build and install packages.
1049 3.3. Platform-specific notes
1051 Here are some platform-specific notes you should be aware of.
1053 3.3.1. Cygwin
1055 Cygwin 1.7.x and later are supported.
1057 You need to install minimal base packages in `Base' category plus any of
1058 compiler, gcc, gcc4, and/or clang. For gcc and gcc4, C and C++ compiler will be
1059 installed by default, but you can install Fortran compiler additionally because
1060 it will be required to use libtool. If it is not installed (or too old),
1061 Fortran compiler will be installed with pkgsrc automatically.
1063 As noted in Cygwin FAQ: `Why doesn't su work?', su(1) command has been in
1064 Cygwin distribution, but it has never worked. Unless you bootstrap pkgsrc with
1065 the --unprivileged option, workaround is:
1067   * Right click "Cygwin Terminal" in your Start Menu, then pick "Run as
1068     administrator".
1070 3.3.2. Darwin (Mac OS X)
1072 Darwin 5.x and up are supported.
1074 Before you start, you need to download and install the Mac OS X Developer Tools
1075 from Apple's Developer Connection. This requires (free) membership. See http://
1076 developer.apple.com/macosx/ for details. Also, make sure you install X11 (an
1077 optional package included with the Developer Tools) if you intend to build
1078 packages that use the X11 Window System. (If you don't want or need the full
1079 Xcode GUI, download and install Command Line Tools for Xcode.)
1081 3.3.3. FreeBSD
1083 FreeBSD 8.3 and 9.0 have been tested and are supported, other versions may
1084 work.
1086 Care should be taken so that the tools that this kit installs do not conflict
1087 with the FreeBSD userland tools. There are several steps:
1089  1. FreeBSD stores its ports pkg database in /var/db/pkg. It is therefore
1090     recommended that you choose a different location (e.g. /usr/pkgdb) by using
1091     the --pkgdbdir option to the bootstrap script.
1093  2. If you do not intend to use the FreeBSD ports tools, it's probably a good
1094     idea to move them out of the way to avoid confusion, e.g.
1096     # cd /usr/sbin
1097     # mv pkg_add pkg_add.orig
1098     # mv pkg_create pkg_create.orig
1099     # mv pkg_delete pkg_delete.orig
1100     # mv pkg_info pkg_info.orig
1103  3. An example mk.conf file will be placed in /etc/mk.conf.example file when
1104     you use the bootstrap script.
1106 3.3.4. Interix
1108 Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a
1109 Unix-like environment with a tighter kernel integration than available with
1110 Cygwin. It is part of the Windows Services for Unix package, available for free
1111 for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU
1112 can be downloaded from http://www.microsoft.com/windows/sfu/.
1114 Services for Unix 3.5 has been tested. 3.0 or 3.1 may work, but are not
1115 officially supported. (The main difference in 3.0/3.1 is lack of pthreads, but
1116 other parts of libc may also be lacking.)
1118 Services for Unix Applications (aka SUA) is an integrated component of Windows
1119 Server 2003 R2 (5.2), Windows Vista and Windows Server 2008 (6.0), Windows 7
1120 and Windows Server 2008 R2 (6.1). As of this writing, the SUA's Interix 6.0
1121 (32bit) and 6.1 (64bit) subsystems have been tested. Other versions may work as
1122 well. The Interix 5.x subsystem has not yet been tested with pkgsrc.
1124 3.3.4.1. When installing Interix/SFU
1126 At an absolute minimum, the following packages must be installed from the
1127 Windows Services for Unix 3.5 distribution in order to use pkgsrc:
1129   * Utilities -> Base Utilities
1131   * Interix GNU Components -> (all)
1133   * Remote Connectivity
1135   * Interix SDK
1137 When using pkgsrc on Interix, DO NOT install the Utilities subcomponent "UNIX
1138 Perl". That is Perl 5.6 without shared module support, installed to /usr/local,
1139 and will only cause confusion. Instead, install Perl 5.8 from pkgsrc (or from a
1140 binary package).
1142 The Remote Connectivity subcomponent "Windows Remote Shell Service" does not
1143 need to be installed, but Remote Connectivity itself should be installed in
1144 order to have a working inetd.
1146 During installation you may be asked whether to enable setuid behavior for
1147 Interix programs, and whether to make pathnames default to case-sensitive.
1148 Setuid should be enabled, and case-sensitivity MUST be enabled. (Without
1149 case-sensitivity, a large number of packages including perl will not build.)
1151 NOTE: Newer Windows service packs change the way binary execution works (via
1152 the Data Execution Prevention feature). In order to use pkgsrc and other
1153 gcc-compiled binaries reliably, a hotfix containing POSIX.EXE, PSXDLL.DLL,
1154 PSXRUN.EXE, and PSXSS.EXE (899522 or newer) must be installed. Hotfixes are
1155 available from Microsoft through a support contract; however, Debian Interix
1156 Port has made most Interix hotfixes available for personal use from http://
1157 www.debian-interix.net/hotfixes/.
1159 In addition to the hotfix noted above, it may be necessary to disable Data
1160 Execution Prevention entirely to make Interix functional. This may happen only
1161 with certain types of CPUs; the cause is not fully understood at this time. If
1162 gcc or other applications still segfault repeatedly after installing one of the
1163 hotfixes note above, the following option can be added to the appropriate
1164 "boot.ini" line on the Windows boot drive: /NoExecute=AlwaysOff (WARNING, this
1165 will disable DEP completely, which may be a security risk if applications are
1166 often run as a user in the Administrators group!)
1168 3.3.4.2. What to do if Interix/SFU is already installed
1170 If SFU is already installed and you wish to alter these settings to work with
1171 pkgsrc, note the following things.
1173   * To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft Windows
1174     Services for UNIX, then click Change. In the installer, choose Add or
1175     Remove, then uncheck Utilities->UNIX Perl.
1177   * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change
1178     the following registry key:
1180     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
1182     Set the DWORD value "obcaseinsensitive" to 0; then reboot.
1184   * To enable setuid binaries (optional), run REGEDIT.EXE, and change the
1185     following registry key:
1187     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX
1189     Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.
1191 3.3.4.3. Important notes for using pkgsrc
1193 The package manager (either the pkgsrc "su" user, or the user running
1194 "pkg_add") must be a member of the local Administrators group. Such a user must
1195 also be used to run the bootstrap. This is slightly relaxed from the normal
1196 pkgsrc requirement of "root".
1198 The package manager should use a umask of 002. "make install" will
1199 automatically complain if this is not the case. This ensures that directories
1200 written in /var/db/pkg are Administrators-group writeable.
1202 The popular Interix binary packages from http://www.interopsystems.com/ use an
1203 older version of pkgsrc's pkg_* tools. Ideally, these should NOT be used in
1204 conjunction with pkgsrc. If you choose to use them at the same time as the
1205 pkgsrc packages, ensure that you use the proper pkg_* tools for each type of
1206 binary package.
1208 The TERM setting used for DOS-type console windows (including those invoked by
1209 the csh and ksh startup shortcuts) is "interix". Most systems don't have a
1210 termcap/terminfo entry for it, but the following .termcap entry provides
1211 adequate emulation in most cases:
1213 interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
1216 3.3.4.4. Limitations of the Interix platform
1218 Though Interix suffices as a familiar and flexible substitute for a full
1219 Unix-like platform, it has some drawbacks that should be noted for those
1220 desiring to make the most of Interix.
1222   * X11:
1224     Interix comes with the standard set of X11R6 client libraries, and can run
1225     X11 based applications, but it does not come with an X server. Some options
1226     are StarNet X-Win32, Hummingbird Exceed (available in a trimmed version for
1227     Interix from Interop Systems as the Interop X Server), and the free X11
1228     server included with Cygwin.
1230   * X11 acceleration:
1232     Because Interix runs in a completely different NT subsystem from Win32
1233     applications, it does not currently support various X11 protocol extensions
1234     for acceleration (such as MIT-SHM or DGA). Most interactive applications to
1235     a local X server will run reasonably fast, but full motion video and other
1236     graphics intensive applications may require a faster-than-expected CPU.
1238   * Audio:
1240     Interix has no native support for audio output. For audio support, pkgsrc
1241     uses the esound client/server audio system on Interix. Unlike on most
1242     platforms, the audio/esound package does not contain the esd server
1243     component. To output audio via an Interix host, the emulators/cygwin_esound
1244     package must also be installed.
1246   * CD/DVDs, USB, and SCSI:
1248     Direct device access is not currently supported in Interix, so it is not
1249     currently possible to access CD/DVD drives, USB devices, or SCSI devices
1250     through non-filesystem means. Among other things, this makes it impossible
1251     to use Interix directly for CD/DVD burning.
1253   * Tape drives:
1255     Due to the same limitations as for CD-ROMs and SCSI devices, tape drives
1256     are also not directly accessible in Interix. However, support is in work to
1257     make tape drive access possible by using Cygwin as a bridge (similarly to
1258     audio bridged via Cygwin's esound server).
1260 3.3.4.5. Known issues for pkgsrc on Interix
1262 It is not necessary, in general, to have a "root" user on the Windows system;
1263 any member of the local Administrators group will suffice. However, some
1264 packages currently assume that the user named "root" is the privileged user. To
1265 accommodate these, you may create such a user; make sure it is in the local
1266 group Administrators (or your language equivalent).
1268 pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time
1269 being, install packages as the local Administrator (or your language
1270 equivalent), or run the following command after installing a package to work
1271 around the issue:
1273 # chmod -R g+w $PKG_DBDIR
1276 3.3.5. IRIX
1278 You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro
1279 compiler (cc/c89). Please set the CC environment variable according to your
1280 preference. If you do not have a license for the MIPSpro compiler suite, you
1281 can download a gcc tardist file from http://freeware.sgi.com/.
1283 Please note that you will need IRIX 6.5.17 or higher, as this is the earliest
1284 version of IRIX providing support for if_indextoname(3), if_nametoindex(3),
1285 etc.
1287 At this point in time, pkgsrc only supports one ABI at a time. That is, you
1288 cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit
1289 ABI. If you start out using "abi=n32", that's what all your packages will be
1290 built with.
1292 Therefore, please make sure that you have no conflicting CFLAGS in your
1293 environment or the mk.conf. Particularly, make sure that you do not try to link
1294 n32 object files with lib64 or vice versa. Check your /etc/compiler.defaults!
1296 If you have the actual pkgsrc tree mounted via NFS from a different host,
1297 please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX
1298 linker occasionally runs into issues when trying to link over a network-mounted
1299 file system.
1301 The bootstrapping process should set all the right options for programs such as
1302 imake(1), but you may want to set some options depending on your local setup.
1303 Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages
1304 for details.
1306 If you are using SGI's MIPSPro compiler, please set
1308 PKGSRC_COMPILER=        mipspro
1311 in mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up
1312 passing invalid flags to the compiler. Note that bootstrap should create an
1313 appropriate mk.conf.example by default.
1315 If you have both the MIPSPro compiler chain installed as well as gcc, but want
1316 to make sure that MIPSPro is used, please set your PATH to not include the
1317 location of gcc (often /usr/freeware/bin), and (important) pass the
1318 '--preserve-path' flag.
1320 3.3.6. Linux
1322 Some versions of Linux (for example Debian GNU/Linux) need either libtermcap or
1323 libcurses (libncurses). Installing the distributions libncurses-dev package (or
1324 equivalent) should fix the problem.
1326 pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++
1327 Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested.
1329 To bootstrap using icc, assuming the default icc installation directory:
1331 env ICCBASE=/opt/intel/cc/10.1.008 ./bootstrap --compiler=icc
1334 Note
1336 For icc 8.0 you must add `LDFLAGS=-static-libcxa' to this.
1338 For icc 8.1 you must add `LDFLAGS=-i-static' instead.
1340 For icc 10.1 neither of these appears to be necessary.
1342 Use a value for ICCBASE that corresponds to the directory where icc is
1343 installed. After bootstrapping, set ICCBASE in mk.conf:
1345 ICCBASE=                /opt/intel/cc/10.1.008
1348 The pkgsrc default for ICCBASE is /opt/intel_cc_80. This is the default install
1349 directory for icc 8.0. If you are using a more recent version, be sure to set
1350 the correct path explicitly.
1352 pkgsrc uses the static linking method of the runtime libraries provided by icc,
1353 so binaries can be run on other systems which do not have the shared libraries
1354 installed.
1356 Libtool, however, extracts a list of libraries from the ld(1) command run when
1357 linking a C++ shared library and records it, throwing away the -Bstatic and
1358 -Bdynamic options interspersed between the libraries. This means that
1359 libtool-linked C++ shared libraries will have a runtime dependency on the icc
1360 libraries until this is fixed in libtool.
1362 3.3.7. OpenBSD
1364 OpenBSD 5.1 has been tested and supported, other versions may work.
1366 Care should be taken so that the tools that this kit installs do not conflict
1367 with the OpenBSD userland tools. There are several steps:
1369  1. OpenBSD stores its ports pkg database in /var/db/pkg. It is therefore
1370     recommended that you choose a different location (e.g. /usr/pkgdb) by using
1371     the --pkgdbdir option to the bootstrap script.
1373  2. If you do not intend to use the OpenBSD ports tools, it's probably a good
1374     idea to move them out of the way to avoid confusion, e.g.
1376     # cd /usr/sbin
1377     # mv pkg_add pkg_add.orig
1378     # mv pkg_create pkg_create.orig
1379     # mv pkg_delete pkg_delete.orig
1380     # mv pkg_info pkg_info.orig
1383  3. An example mk.conf file will be placed in /etc/mk.conf.example file when
1384     you use the bootstrap script. OpenBSD's make program uses mk.conf as well.
1385     You can work around this by enclosing all the pkgsrc-specific parts of the
1386     file with:
1388     .ifdef BSD_PKG_MK
1389     # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
1390     .else
1391     # OpenBSD stuff
1392     .endif
1395 3.3.8. Solaris
1397 Solaris 2.6 through 10 are supported on both x86 and sparc. You will need a
1398 working C compiler. Both gcc 4.5.3 and Sun WorkShop 5 have been tested.
1400 The following packages are required on Solaris 8 for the bootstrap process and
1401 to build packages.
1403   * SUNWsprot
1405   * SUNWarc
1407   * SUNWbtool
1409   * SUNWtoo
1411   * SUNWlibm
1413 Please note that the use of GNU binutils on Solaris is not supported, as of
1414 June 2006.
1416 Whichever compiler you use, please ensure the compiler tools and your $prefix
1417 are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/
1418 {bin,sbin}.
1420 3.3.8.1. If you are using gcc
1422 It makes life much simpler if you only use the same gcc consistently for
1423 building all packages.
1425 It is recommended that an external gcc be used only for bootstrapping, then
1426 either build gcc from lang/gcc46 or install a binary gcc package, then remove
1427 gcc used during bootstrapping.
1429 Binary packages of gcc can be found through http://www.sunfreeware.com/.
1431 3.3.8.2. If you are using Sun WorkShop
1433 You will need at least the following packages installed (from WorkShop 5.0)
1435   * SPROcc - Sun WorkShop Compiler C 5.0
1437   * SPROcpl - Sun WorkShop Compiler C++ 5.0
1439   * SPROild - Sun WorkShop Incremental Linker
1441   * SPROlang - Sun WorkShop Compilers common components
1443 You should set the following variables in your mk.conf file:
1445 CC=     cc
1446 CXX=    CC
1447 CPP=    cc -E
1448 CXXCPP= CC -E
1450 Note
1452 The CPP setting might break some packages that use the C preprocessor for
1453 processing things other than C source code.
1455 3.3.8.3. Building 64-bit binaries with SunPro
1457 To build 64-bit packages, you just need to have the following lines in your
1458 mk.conf file:
1460 PKGSRC_COMPILER=        sunpro
1461 ABI=                    64
1463 Note
1465 This setting has been tested for the SPARC architecture. Intel and AMD machines
1466 need some more work.
1468 3.3.8.4. Common problems
1470 Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The
1471 workaround is to use another shell for the configure scripts, for example by
1472 installing shells/bash and adding the following lines to your mk.conf:
1474 CONFIG_SHELL=   ${LOCALBASE}/bin/bash
1475 WRAPPER_SHELL=  ${LOCALBASE}/bin/bash
1478 Then, rebuild the devel/libtool-base package.
1480 Chapter 4. Using pkgsrc
1482 Table of Contents
1484 4.1. Using binary packages
1486     4.1.1. Finding binary packages
1487     4.1.2. Installing binary packages
1488     4.1.3. Deinstalling packages
1489     4.1.4. Getting information about installed packages
1490     4.1.5. Checking for security vulnerabilities in installed packages
1491     4.1.6. Finding if newer versions of your installed packages are in pkgsrc
1492     4.1.7. Other administrative functions
1493     4.1.8. A word of warning
1495 4.2. Building packages from source
1497     4.2.1. Requirements
1498     4.2.2. Fetching distfiles
1499     4.2.3. How to build and install
1501 Basically, there are two ways of using pkgsrc. The first is to only install the
1502 package tools and to use binary packages that someone else has prepared. This
1503 is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
1504 Then you are able to build your own packages, and you can still use binary
1505 packages from someone else.
1507 4.1. Using binary packages
1509 On the ftp.NetBSD.org server and its mirrors, there are collections of binary
1510 packages, ready to be installed. These binary packages have been built using
1511 the default settings for the directories, that is:
1513   * /usr/pkg for LOCALBASE, where most of the files are installed,
1515   * /usr/pkg/etc for configuration files,
1517   * /var for VARBASE, where those files are installed that may change after
1518     installation.
1520 If you cannot use these directories for whatever reasons (maybe because you're
1521 not root), you cannot use these binary packages, but have to build the packages
1522 yourself, which is explained in Section 3.2, "Bootstrapping pkgsrc".
1524 4.1.1. Finding binary packages
1526 To install binary packages, you first need to know from where to get them. The
1527 first place where you should look is on the main pkgsrc FTP server in the
1528 directory /pub/pkgsrc/packages.
1530 This directory contains binary packages for multiple platforms. First, select
1531 your operating system. (Ignore the directories with version numbers attached to
1532 it, they just exist for legacy reasons.) Then, select your hardware
1533 architecture, and in the third step, the OS version and the "version" of
1534 pkgsrc.
1536 In this directory, you often find a file called bootstrap.tar.gz which contains
1537 the package management tools. If the file is missing, it is likely that your
1538 operating system already provides those tools. Download the file and extract it
1539 in the / directory. It will create the directories /usr/pkg (containing the
1540 tools for managing binary packages) and /var/db/pkg (the database of installed
1541 packages).
1543 4.1.2. Installing binary packages
1545 In the directory from the last section, there is a subdirectory called All,
1546 which contains all the binary packages that are available for the platform,
1547 excluding those that may not be distributed via FTP or CDROM (depending on
1548 which medium you are using).
1550 To install packages directly from an FTP or HTTP server, run the following
1551 commands in a Bourne-compatible shell (be sure to su to root first):
1553 # PATH="/usr/pkg/sbin:$PATH"
1554 # PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All"
1555 # export PATH PKG_PATH
1557 Instead of URLs, you can also use local paths, for example if you are
1558 installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want
1559 to install packages from multiple sources, you can separate them by a semicolon
1560 in PKG_PATH.
1562 After these preparations, installing a package is very easy:
1564 # pkg_add openoffice2
1565 # pkg_add kde-3.5.7
1566 # pkg_add ap2-php5-*
1568 Note that any prerequisite packages needed to run the package in question will
1569 be installed, too, assuming they are present where you install from.
1571 Adding packages might install vulnerable packages. Thus you should run 
1572 pkg_admin audit regularly, especially after installing new packages, and verify
1573 that the vulnerabilities are acceptable for your configuration.
1575 After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
1576 in your PATH so you can actually start the just installed program.
1578 4.1.3. Deinstalling packages
1580 To deinstall a package, it does not matter whether it was installed from source
1581 code or from a binary package. The pkg_delete command does not know it anyway.
1582 To delete a package, you can just run pkg_delete package-name. The package name
1583 can be given with or without version number. Wildcards can also be used to
1584 deinstall a set of packages, for example *emacs*. Be sure to include them in
1585 quotes, so that the shell does not expand them before pkg_delete sees them.
1587 The -r option is very powerful: it removes all the packages that require the
1588 package in question and then removes the package itself. For example:
1590 # pkg_delete -r jpeg
1593 will remove jpeg and all the packages that used it; this allows upgrading the
1594 jpeg package.
1596 4.1.4. Getting information about installed packages
1598 The pkg_info shows information about installed packages or binary package
1599 files.
1601 4.1.5. Checking for security vulnerabilities in installed packages
1603 The NetBSD Security-Officer and Packages Groups maintain a list of known
1604 security vulnerabilities to packages which are (or have been) included in
1605 pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/
1606 pub/pkgsrc/distfiles/vulnerabilities.
1608 Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded
1609 automatically, and a security audit of all packages installed on a system can
1610 take place.
1612 There are two components to auditing. The first step, pkg_admin
1613 fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
1614 the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of
1615 your installed packages are vulnerable. If a package is vulnerable, you will
1616 see output similar to the following:
1618 Package samba-2.0.9 has a local-root-shell vulnerability, see
1619     http://www.samba.org/samba/whatsnew/macroexploit.html
1621 You may wish to have the vulnerabilities file downloaded daily so that it
1622 remains current. This may be done by adding an appropriate entry to the root
1623 users crontab(5) entry. For example the entry
1625 # download vulnerabilities file
1626 0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
1629 will update the vulnerability list every day at 3AM. You may wish to do this
1630 more often than once a day. In addition, you may wish to run the package audit
1631 from the daily security script. This may be accomplished by adding the
1632 following line to /etc/security.local:
1634 /usr/sbin/pkg_admin audit
1637 4.1.6. Finding if newer versions of your installed packages are in pkgsrc
1639 Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
1640 if your packages are up-to-date, e.g.
1642 % lintpkgsrc -i
1644 Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
1647 You can then use make update to update the package on your system and rebuild
1648 any dependencies.
1650 4.1.7. Other administrative functions
1652 The pkg_admin executes various administrative functions on the package system.
1654 4.1.8. A word of warning
1656 Please pay very careful attention to the warnings expressed in the pkg_add(1)
1657 manual page about the inherent dangers of installing binary packages which you
1658 did not create yourself, and the security holes that can be introduced onto
1659 your system by indiscriminate adding of such files.
1661 The same warning of course applies to every package you install from source
1662 when you haven't completely read and understood the source code of the package,
1663 the compiler that is used to build the package and all the other tools that are
1664 involved.
1666 4.2. Building packages from source
1668 After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
1669 organized into categories. You can browse the online index of packages, or run 
1670 make readme from the pkgsrc directory to build local README.html files for all
1671 packages, viewable with any web browser such as www/lynx or www/firefox.
1673 The default prefix for installed packages is /usr/pkg. If you wish to change
1674 this, you should do so by setting LOCALBASE in mk.conf. You should not try to
1675 use multiple different LOCALBASE definitions on the same system (inside a
1676 chroot is an exception).
1678 The rest of this chapter assumes that the package is already in pkgsrc. If it
1679 is not, see Part II, "The pkgsrc developer's guide" for instructions how to
1680 create your own packages.
1682 4.2.1. Requirements
1684 To build packages from source, you need a working C compiler. On NetBSD, you
1685 need to install the "comp" and the "text" distribution sets. If you want to
1686 build X11-related packages, the "xbase" and "xcomp" distribution sets are
1687 required, too.
1689 4.2.2. Fetching distfiles
1691 The first step for building a package is downloading the distfiles (i.e. the
1692 unmodified source). If they have not yet been downloaded, pkgsrc will fetch
1693 them automatically.
1695 If you have all files that you need in the distfiles directory, you don't need
1696 to connect. If the distfiles are on CD-ROM, you can mount the CD-ROM on /cdrom
1697 and add:
1699 DISTDIR=/cdrom/pkgsrc/distfiles
1701 to your mk.conf.
1703 By default a list of distribution sites will be randomly intermixed to prevent
1704 huge load on servers which holding popular packages (for example,
1705 SourceForge.net mirrors). Thus, every time when you need to fetch yet another
1706 distfile all the mirrors will be tried in new (random) order. You can turn this
1707 feature off by setting MASTER_SORT_RANDOM=NO (for PKG_DEVELOPERs it's already
1708 disabled).
1710 You can overwrite some of the major distribution sites to fit to sites that are
1711 close to your own. By setting one or two variables you can modify the order in
1712 which the master sites are accessed. MASTER_SORT contains a whitespace
1713 delimited list of domain suffixes. MASTER_SORT_REGEX is even more flexible, it
1714 contains a whitespace delimited list of regular expressions. It has higher
1715 priority than MASTER_SORT. Have a look at pkgsrc/mk/defaults/mk.conf to find
1716 some examples. This may save some of your bandwidth and time.
1718 You can change these settings either in your shell's environment, or, if you
1719 want to keep the settings, by editing the mk.conf file, and adding the
1720 definitions there.
1722 If a package depends on many other packages (such as meta-pkgs/kde3), the build
1723 process may alternate between periods of downloading source, and compiling. To
1724 ensure you have all the source downloaded initially you can run the command:
1726 % make fetch-list | sh
1728 which will output and run a set of shell commands to fetch the necessary files
1729 into the distfiles directory. You can also choose to download the files
1730 manually.
1732 4.2.3. How to build and install
1734 Once the software has downloaded, any patches will be applied, then it will be
1735 compiled for you. This may take some time depending on your computer, and how
1736 many other packages the software depends on and their compile time.
1738 Note
1740 If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
1741 command instead of "make" in the examples in this guide.
1743 For example, type
1745 % cd misc/figlet
1746 % make
1749 at the shell prompt to build the various components of the package.
1751 The next stage is to actually install the newly compiled program onto your
1752 system. Do this by entering:
1754 % make install
1757 while you are still in the directory for whatever package you are installing.
1759 Installing the package on your system may require you to be root. However,
1760 pkgsrc has a just-in-time-su feature, which allows you to only become root for
1761 the actual installation step.
1763 That's it, the software should now be installed and setup for use. You can now
1764 enter:
1766 % make clean
1769 to remove the compiled files in the work directory, as you shouldn't need them
1770 any more. If other packages were also added to your system (dependencies) to
1771 allow your program to compile, you can tidy these up also with the command:
1773 % make clean-depends
1776 Taking the figlet utility as an example, we can install it on our system by
1777 building as shown in Appendix B, Build logs.
1779 The program is installed under the default root of the packages tree - /usr/
1780 pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
1781 environment, and it will use that value as the root of your packages tree. So,
1782 to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
1783 that you should use a directory which is dedicated to packages and not shared
1784 with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
1785 not try to add any of your own files or directories (such as src/, obj/, or
1786 pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
1787 between programs and other files installed by the package system and whatever
1788 else may have been installed there.
1790 Some packages look in mk.conf to alter some configuration options at build
1791 time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will
1792 be set there by default. Environment variables such as LOCALBASE can be set in
1793 mk.conf to save having to remember to set them each time you want to use
1794 pkgsrc.
1796 Occasionally, people want to "look under the covers" to see what is going on
1797 when a package is building or being installed. This may be for debugging
1798 purposes, or out of simple curiosity. A number of utility values have been
1799 added to help with this.
1801  1. If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a huge
1802     amount of information will be displayed. For example,
1804     make patch PKG_DEBUG_LEVEL=2
1806     will show all the commands that are invoked, up to and including the "patch
1807     " stage.
1809  2. If you want to know the value of a certain make(1) definition, then the
1810     VARNAME definition should be used, in conjunction with the show-var target.
1811     e.g. to show the expansion of the make(1) variable LOCALBASE:
1813     % make show-var VARNAME=LOCALBASE
1814     /usr/pkg
1815     %
1818 If you want to install a binary package that you've either created yourself
1819 (see next section), that you put into pkgsrc/packages manually or that is
1820 located on a remote FTP server, you can use the "bin-install" target. This
1821 target will install a binary package - if available - via pkg_add(1), else do a
1822 make package. The list of remote FTP sites searched is kept in the variable
1823 BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
1824 to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
1825 for more details.
1827 A final word of warning: If you set up a system that has a non-standard setting
1828 for LOCALBASE, be sure to set that before any packages are installed, as you
1829 cannot use several directories for the same purpose. Doing so will result in
1830 pkgsrc not being able to properly detect your installed packages, and fail
1831 miserably. Note also that precompiled binary packages are usually built with
1832 the default LOCALBASE of /usr/pkg, and that you should not install any if you
1833 use a non-standard LOCALBASE.
1835 Chapter 5. Configuring pkgsrc
1837 Table of Contents
1839 5.1. General configuration
1840 5.2. Variables affecting the build process
1841 5.3. Variables affecting the installation process
1842 5.4. Selecting and configuring the compiler
1844     5.4.1. Selecting the compiler
1845     5.4.2. Additional flags to the compiler (CFLAGS)
1846     5.4.3. Additional flags to the linker (LDFLAGS)
1848 5.5. Developer/advanced settings
1849 5.6. Selecting Build Options
1851 The whole pkgsrc system is configured in a single file, usually called mk.conf.
1852 In which directory pkgsrc looks for that file depends on the installation. On
1853 NetBSD, when you use make(1) from the base system, it is in the directory /etc
1854 /. In all other cases the default location is ${PREFIX}/etc/, depending on
1855 where you told the bootstrap program to install the binary packages.
1857 During the bootstrap, an example configuration file is created. To use that,
1858 you have to create the directory ${PREFIX}/etc and copy the example file there.
1860 The format of the configuration file is that of the usual BSD-style Makefiles.
1861 The whole pkgsrc configuration is done by setting variables in this file. Note
1862 that you can define all kinds of variables, and no special error checking (for
1863 example for spelling mistakes) takes place, so you have to try it out to see if
1864 it works.
1866 5.1. General configuration
1868 In this section, you can find some variables that apply to all pkgsrc packages.
1869 A complete list of the variables that can be configured by the user is
1870 available in mk/defaults/mk.conf, together with some comments that describe
1871 each variable's intent.
1873   * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
1874     not mix binary packages with different LOCALBASEs!
1876   * CROSSBASE: Where "cross" category packages will be installed. The default
1877     is ${LOCALBASE}/cross.
1879   * X11BASE: Where X11 is installed on the system. The default is /usr/X11R6.
1881   * DISTDIR: Where to store the downloaded copies of the original source
1882     distributions used for building pkgsrc packages. The default is $
1883     {PKGSRCDIR}/distfiles.
1885   * PKG_DBDIR: Where the database about installed packages is stored. The
1886     default is /var/db/pkg.
1888   * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
1889     value.
1891   * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
1892     files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
1893     respectively. The defaults are ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/$
1894     {DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$
1895     {DIST_SUBDIR}/.
1897   * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
1898     with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
1900   * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
1901     case-sensitive. Whenever you try to build a package whose license is not in
1902     this list, you will get an error message. If the license condition is
1903     simple enough, the error message will include specific instructions on how
1904     to change this variable.
1906 5.2. Variables affecting the build process
1910   * PACKAGES: The top level directory for the binary packages. The default is $
1911     {PKGSRCDIR}/packages.
1913   * WRKOBJDIR: The top level directory where, if defined, the separate working
1914     directories will get created, and symbolically linked to from ${WRKDIR}
1915     (see below). This is useful for building packages on several architectures,
1916     then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
1917     architecture. (It should be noted that PKGSRCDIR should not be set by the
1918     user ? it is an internal definition which refers to the root of the pkgsrc
1919     tree. It is possible to have many pkgsrc tree instances.)
1921   * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
1922     Section 11.3, "patches/*" for more information.
1924   * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
1925     Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
1926     up settings used by builds in /usr/src.
1928   * DEPENDS_TARGET: By default, dependencies are only installed, and no binary
1929     package is created for them. You can set this variable to package to
1930     automatically create binary packages after installing dependencies.
1932 5.3. Variables affecting the installation process
1934 Most packages support installation into a subdirectory of WRKDIR. This allows a
1935 package to be built, before the actual filesystem is touched. DESTDIR support
1936 exists in two variations:
1938   * Basic DESTDIR support means that the package installation and packaging is
1939     still run as root.
1941   * Full DESTDIR support can run the complete build, installation and packaging
1942     as normal user. Root privileges are only needed to add packages.
1944 DESTDIR support is now the default. To switch back to non-DESTDIR, you can set
1945 USE_DESTDIR=no; this setting will be deprecated though, so it's preferable to
1946 convert a package to DESTDIR instead.
1948 DESTDIR support changes the behaviour of various targets slightly. To install a
1949 package after building it, use package-install. package and install don't do
1950 that any longer. package-install can be used as DEPENDS_TARGET. bin-install
1951 will ask for the root password to install the package and fail, package-install
1952 will ask again.
1954 With basic DESTDIR support, make clean needs to be run as root.
1956 Considering the foo/bar package, DESTDIR full support can be tested using the
1957 following commands
1959 $ id
1960 uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
1961 $ mkdir $HOME/packages
1962 $ cd $PKGSRCDIR/foo/bar
1964 Verify DESTDIR full support, no root privileges should be needed
1966 $ make USE_DESTDIR=yes install
1968 Create a package without root privileges
1970 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package
1972 For the following command, you must be able to gain root privileges using su(1)
1974 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install
1976 Then, as a simple user
1978 $ make clean
1980 5.4. Selecting and configuring the compiler
1982 5.4.1. Selecting the compiler
1984 By default, pkgsrc will use GCC to build packages. This may be overridden by
1985 setting the following variables in /etc/mk.conf:
1987 PKGSRC_COMPILER:
1989     This is a list of values specifying the chain of compilers to invoke when
1990     building packages. Valid values are:
1992       + distcc: distributed C/C++ (chainable)
1994       + ccache: compiler cache (chainable)
1996       + gcc: GNU C/C++ Compiler
1998       + mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)
2000       + mipspro: Silicon Graphics, Inc. MIPSpro (o32)
2002       + sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio
2004     The default is "gcc". You can use ccache and/or distcc with an appropriate
2005     PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
2006     terminated with a value for a real compiler. Note that only one real
2007     compiler should be listed (e.g. "sunpro gcc" is not allowed).
2009 GCC_REQD:
2011     This specifies the minimum version of GCC to use when building packages. If
2012     the system GCC doesn't satisfy this requirement, then pkgsrc will build and
2013     install one of the GCC packages to use instead.
2015 5.4.2. Additional flags to the compiler (CFLAGS)
2017 If you wish to set the CFLAGS variable, please make sure to use the += operator
2018 instead of the = operator:
2020 CFLAGS+=        -your -flags
2022 Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
2023 need to add their own flags. You may want to take a look at the devel/cpuflags
2024 package if you're interested in optimization specifically for the current CPU.
2026 5.4.3. Additional flags to the linker (LDFLAGS)
2028 If you want to pass flags to the linker, both in the configure step and the
2029 build step, you can do this in two ways. Either set LDFLAGS or LIBS. The
2030 difference between the two is that LIBS will be appended to the command line,
2031 while LDFLAGS come earlier. LDFLAGS is pre-loaded with rpath settings for ELF
2032 machines depending on the setting of USE_IMAKE or the inclusion of mk/
2033 x11.buildlink3.mk. As with CFLAGS, if you do not wish to override these
2034 settings, use the += operator:
2036 LDFLAGS+=        -your -linkerflags
2038 5.5. Developer/advanced settings
2042   * PKG_DEVELOPER: Run some sanity checks that package developers want:
2044       + make sure patches apply with zero fuzz
2046       + run check-shlibs to see that all binaries will find their shared libs.
2048   * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst
2049     making and installing the package. The default value for this is 0, which
2050     will not display the commands as they are executed (normal, default, quiet
2051     operation); the value 1 will display all shell commands before their
2052     invocation, and the value 2 will display both the shell commands before
2053     their invocation, and their actual execution progress with set -x will be
2054     displayed.
2056 5.6. Selecting Build Options
2058 Some packages have build time options, usually to select between different
2059 dependencies, enable optional support for big dependencies or enable
2060 experimental features.
2062 To see which options, if any, a package supports, and which options are
2063 mutually exclusive, run make show-options, for example:
2065     The following options are supported by this package:
2066         ssl      Enable SSL support.
2067     Exactly one of the following gecko options is required:
2068         firefox  Use firefox as gecko rendering engine.
2069         mozilla  Use mozilla as gecko rendering engine.
2070     At most one of the following database options may be selected:
2071         mysql    Enable support for MySQL database.
2072         pgsql    Enable support for PostgreSQL database.
2074     These options are enabled by default: firefox
2075     These options are currently enabled: mozilla ssl
2077 The following variables can be defined in mk.conf to select which options to
2078 enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
2079 disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
2080 which can be used to select or disable options specifically for package pkgbase
2081 . Options listed in these variables are selected, options preceded by "-" are
2082 disabled. A few examples:
2084 $ grep "PKG.*OPTION" mk.conf
2085 PKG_DEFAULT_OPTIONS=    -arts -dvdread -esound
2086 PKG_OPTIONS.kdebase=    debug -sasl
2087 PKG_OPTIONS.apache=     suexec
2089 It is important to note that options that were specifically suggested by the
2090 package maintainer must be explicitly removed if you do not wish to include the
2091 option. If you are unsure you can view the current state with make show-options
2094 The following settings are consulted in the order given, and the last setting
2095 that selects or disables an option is used:
2097  1. the default options as suggested by the package maintainer
2099  2. the options implied by the settings of legacy variables (see below)
2101  3. PKG_DEFAULT_OPTIONS
2103  4. PKG_OPTIONS.pkgbase
2105 For groups of mutually exclusive options, the last option selected is used, all
2106 others are automatically disabled. If an option of the group is explicitly
2107 disabled, the previously selected option, if any, is used. It is an error if no
2108 option from a required group of options is selected, and building the package
2109 will fail.
2111 Before the options framework was introduced, build options were selected by
2112 setting a variable (often named USE_FOO) in mk.conf for each option. To ease
2113 transition to the options framework for the user, these legacy variables are
2114 converted to the appropriate options setting (PKG_OPTIONS.pkgbase)
2115 automatically. A warning is issued to prompt the user to update mk.conf to use
2116 the options framework directly. Support for the legacy variables will be
2117 removed eventually.
2119 Chapter 6. Creating binary packages
2121 Table of Contents
2123 6.1. Building a single binary package
2124 6.2. Settings for creation of binary packages
2126 6.1. Building a single binary package
2128 Once you have built and installed a package, you can create a binary package
2129 which can be installed on another system with pkg_add(1). This saves having to
2130 build the same package on a group of hosts and wasting CPU time. It also
2131 provides a simple means for others to install your package, should you
2132 distribute it.
2134 To create a binary package, change into the appropriate directory in pkgsrc,
2135 and run make package:
2137 # cd misc/figlet
2138 # make package
2141 This will build and install your package (if not already done), and then build
2142 a binary package from what was installed. You can then use the pkg_* tools to
2143 manipulate it. Binary packages are created by default in /usr/pkgsrc/packages,
2144 in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a
2145 continuation of the above misc/figlet example.
2147 See Chapter 21, Submitting and Committing for information on how to submit such
2148 a binary package.
2150 6.2. Settings for creation of binary packages
2152 See Section 17.17, "Other helpful targets".
2154 Chapter 7. Creating binary packages for everything in pkgsrc (bulk builds)
2156 Table of Contents
2158 7.1. Think first, build later
2159 7.2. Requirements of a bulk build
2160 7.3. Running an old-style bulk build
2162     7.3.1. Configuration
2163     7.3.2. Other environmental considerations
2164     7.3.3. Operation
2165     7.3.4. What it does
2166     7.3.5. Disk space requirements
2167     7.3.6. Setting up a sandbox for chrooted builds
2168     7.3.7. Building a partial set of packages
2169     7.3.8. Uploading results of a bulk build
2171 7.4. Running a pbulk-style bulk build
2173     7.4.1. Preparation
2174     7.4.2. Configuration
2176 7.5. Creating a multiple CD-ROM packages collection
2178     7.5.1. Example of cdpack
2180 When you have multiple machines that should run the same packages, it is wasted
2181 time if they all build their packages themselves from source. There are two
2182 ways of getting a set of binary packages: The old bulk build system, or the new
2183 (as of 2007) parallel bulk build (pbulk) system. This chapter describes how to
2184 set them up so that the packages are most likely to be usable later.
2186 7.1. Think first, build later
2188 Since a bulk build takes several days or even weeks to finish, you should think
2189 about the setup before you start everything. Pay attention to at least the
2190 following points:
2192   * If you want to upload the binary packages to ftp.NetBSD.org, make sure the
2193     setup complies to the requirements for binary packages:
2195       + To end up on ftp.NetBSD.org, the packages must be built by a NetBSD
2196         developer on a trusted machine (that is, where you and only you have
2197         root access).
2199       + Packages on ftp.NetBSD.org should only be created from the stable
2200         branches (like 2009Q1), so that users browsing the available
2201         collections can see at a glance how old the packages are.
2203       + The packages must be built as root, since some packages require set-uid
2204         binaries at runtime, and creating those packages as unprivileged user
2205         doesn't work well at the moment.
2207   * Make sure that the bulk build cannot break anything in your system. Most
2208     bulk builds run as root, so they should be run at least in a chroot
2209     environment or something even more restrictive, depending on what the
2210     operating system provides. There have been numerous cases where certain
2211     packages tried to install files outside the LOCALBASE or wanted to edit
2212     some files in /etc. Furthermore, the bulk builds install and deinstall
2213     packages in /usr/pkg (or whatever LOCALBASE is) during their operation, so
2214     be sure that you don't need any package during the build.
2216 7.2. Requirements of a bulk build
2218 A complete bulk build requires lots of disk space. Some of the disk space can
2219 be read-only, some other must be writable. Some can be on remote filesystems
2220 (such as NFS) and some should be local. Some can be temporary filesystems,
2221 others must survive a sudden reboot.
2223   * 10 GB for the distfiles (read-write, remote, temporary)
2225   * 10 GB for the binary packages (read-write, remote, permanent)
2227   * 400 MB for the pkgsrc tree (read-only, remote, permanent)
2229   * 5 GB for LOCALBASE (read-write, local, temporary for pbulk, permanent for
2230     old-bulk)
2232   * 5 GB for the log files (read-write, remote, permanent)
2234   * 5 GB for temporary files (read-write, local, temporary)
2236 7.3. Running an old-style bulk build
2238 Note
2240 There are two ways of doing a bulk build. The old-style one and the new-style "
2241 pbulk". The latter is the recommended way.
2243 7.3.1. Configuration
2245 7.3.1.1. build.conf
2247 The build.conf file is the main configuration file for bulk builds. You can
2248 configure how your copy of pkgsrc is kept up to date, how the distfiles are
2249 downloaded, how the packages are built and how the report is generated. You can
2250 find an annotated example file in pkgsrc/mk/bulk/build.conf-example. To use it,
2251 copy build.conf-example to build.conf and edit it, following the comments in
2252 that file.
2254 7.3.1.2. mk.conf
2256 You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf
2257 for details of the default settings. You will want to ensure that
2258 ACCEPTABLE_LICENSES meet your local policy. As used in this example,
2259 SKIP_LICENSE_CHECK=yes completely bypasses the license check.
2261 PACKAGES?=      ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
2262 WRKOBJDIR?=     /usr/tmp/pkgsrc   # build here instead of in pkgsrc
2263 BSDSRCDIR=      /usr/src
2264 BSDXSRCDIR=     /usr/xsrc         # for x11/xservers
2265 OBJHOSTNAME?=   yes               # use work.`hostname`
2266 FAILOVER_FETCH= yes               # insist on the correct checksum
2267 PKG_DEVELOPER?= yes
2268 SKIP_LICENSE_CHECK=    yes
2270 Some options that are especially useful for bulk builds can be found at the top
2271 lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are
2272 briefly described here.
2274   * If you are on a slow machine, you may want to set USE_BULK_BROKEN_CHECK to 
2275     "no".
2277   * If you are doing bulk builds from a read-only copy of pkgsrc, you have to
2278     set BULKFILESDIR to the directory where all log files are created.
2279     Otherwise the log files are created in the pkgsrc directory.
2281   * Another important variable is BULK_PREREQ, which is a list of packages that
2282     should be always available while building other packages.
2284 Some other options are scattered in the pkgsrc infrastructure:
2286   * ALLOW_VULNERABLE_PACKAGES should be set to yes. The purpose of the bulk
2287     builds is creating binary packages, no matter if they are vulnerable or
2288     not. Leaving this variable unset would prevent the bulk build system from
2289     even trying to build them, so possible building errors would not show up.
2291   * CHECK_FILES (pkgsrc/mk/check/check-files.mk) can be set to "yes" to check
2292     that the installed set of files matches the PLIST.
2294   * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to "yes
2295     " to check that the installed "#!"-scripts will find their interpreter.
2297   * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before
2298     installing it. Note that some packages make heavy use of "good" random
2299     numbers, so you need to assure that the machine on which you are doing the
2300     bulk builds is not completely idle. Otherwise some test programs will seem
2301     to hang, while they are just waiting for new random data to be available.
2303 7.3.1.3. pre-build.local
2305 It is possible to configure the bulk build to perform certain site-specific
2306 tasks at the end of the pre-build stage. If the file pre-build.local exists in
2307 /usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the
2308 usual pre-build stage. An example use of pre-build.local is to have the line:
2310 echo "I do not have enough disk space to build this pig." \
2311         > misc/openoffice/$BROKENF
2313 to prevent the system from trying to build a particular package which requires
2314 nearly 3 GB of disk space.
2316 7.3.2. Other environmental considerations
2318 As /usr/pkg will be completely deleted at the start of bulk builds, make sure
2319 your login shell is placed somewhere else. Either drop it into /usr/local/bin
2320 (and adjust your login shell in the passwd file), or (re-)install it via
2321 pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that
2322 your current process won't die if the package is removed, you just can't start
2323 any new instances of the shell any more). Also, if you use NetBSD earlier than
2324 1.5, or you still want to use the pkgsrc version of ssh for some reason, be
2325 sure to install ssh before starting it from rc.local:
2327 (cd /usr/pkgsrc/security/ssh && make bulk-install)
2328 if [ -f /usr/pkg/etc/rc.d/sshd ]; then
2329   /usr/pkg/etc/rc.d/sshd
2332 Not doing so will result in you being not able to log in via ssh after the bulk
2333 build is finished or if the machine gets rebooted or crashes. You have been
2334 warned! :)
2336 7.3.3. Operation
2338 Make sure you don't need any of the packages still installed.
2340 Warning
2342 During the bulk build, all packages, their configuration files and some more
2343 files from /var, /home and possibly other locations will be removed! So don't
2344 run a bulk build with privileges that might harm your system.
2346 Be sure to remove all other things that might interfere with builds, like some
2347 libs installed in /usr/local, etc. then become root and type:
2349 # cd /usr/pkgsrc
2350 # sh mk/bulk/build
2353 If for some reason your last build didn't complete (power failure, system
2354 panic, ...), you can continue it by running:
2356 # sh mk/bulk/build restart
2358 At the end of the bulk build, you will get a summary via mail, and find build
2359 logs in the directory specified by FTP in the build.conf file.
2361 7.3.4. What it does
2363 The bulk builds consist of three steps:
2365 1. pre-build
2367     The script updates your pkgsrc tree via (anon)cvs, then cleans out any
2368     broken distfiles, and removes all packages installed.
2370 2. the bulk build
2372     This is basically "make bulk-package" with an optimised order in which
2373     packages will be built. Packages that don't require other packages will be
2374     built first, and packages with many dependencies will be built later.
2376 3. post-build
2378     Generates a report that's placed in the directory specified in the
2379     build.conf file named broken.html, a short version of that report will also
2380     be mailed to the build's admin.
2382 During the build, a list of broken packages will be compiled in /usr/pkgsrc
2383 /.broken (or .../.broken.${MACHINE} if OBJMACHINE is set), individual build
2384 logs of broken builds can be found in the package's directory. These files are
2385 used by the bulk-targets to mark broken builds to not waste time trying to
2386 rebuild them, and they can be used to debug these broken package builds later.
2388 7.3.5. Disk space requirements
2390 Currently, roughly the following requirements are valid for NetBSD 2.0/i386:
2392   * 10 GB - distfiles (NFS ok)
2394   * 8 GB - full set of all binaries (NFS ok)
2396   * 5 GB - temp space for compiling (local disk recommended)
2398 Note that all pkgs will be de-installed as soon as they are turned into a
2399 binary package, and that sources are removed, so there is no excessively huge
2400 demand to disk space. Afterwards, if the package is needed again, it will be
2401 installed via pkg_add(1) instead of building again, so there are no cycles
2402 wasted by recompiling.
2404 7.3.6. Setting up a sandbox for chrooted builds
2406 If you don't want all the packages nuked from a machine (rendering it useless
2407 for anything but pkg compiling), there is the possibility of doing the package
2408 bulk build inside a chroot environment.
2410 The first step is to set up a chroot sandbox, e.g. /usr/sandbox. This can be
2411 done by using null mounts, or manually.
2413 There is a shell script called mksandbox installed by the pkgtools/mksandbox
2414 package, which will set up the sandbox environment using null mounts. It will
2415 also create a script called sandbox in the root of the sandbox environment,
2416 which will allow the null mounts to be activated using the sandbox mount
2417 command and deactivated using the sandbox umount command.
2419 To set up a sandbox environment by hand, after extracting all the sets from a
2420 NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in /usr/
2421 src/etc, be sure the following items are present and properly configured:
2423  1. Kernel
2425     # cp /netbsd /usr/sandbox
2427  2. /dev/*
2429     # cd /usr/sandbox/dev ; sh MAKEDEV all
2431  3. /etc/resolv.conf (for security/smtpd and mail):
2433     # cp /etc/resolv.conf /usr/sandbox/etc
2435  4. Working(!) mail config (hostname, sendmail.cf):
2437     # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
2439  5. /etc/localtime (for security/smtpd):
2441     # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
2443  6. /usr/src (system sources, e. g. for sysutils/aperture):
2445     # ln -s ../disk1/cvs .
2446               # ln -s cvs/src-2.0 src
2448  7. Create /var/db/pkg (not part of default install):
2450     # mkdir /usr/sandbox/var/db/pkg
2452  8. Create /usr/pkg (not part of default install):
2454     # mkdir /usr/sandbox/usr/pkg
2456  9. Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:
2458     # cd /usr/sandbox/usr
2459     # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
2462     Do not mount/link this to the copy of your pkgsrc tree you do development
2463     in, as this will likely cause problems!
2465 10. Make /usr/sandbox/usr/pkgsrc/packages and .../distfiles point somewhere
2466     appropriate. NFS- and/or nullfs-mounts may come in handy!
2468 11. Edit mk.conf, see Section 7.3.1.2, "mk.conf".
2470 12. Adjust mk/bulk/build.conf to suit your needs.
2472 When the chroot sandbox is set up, you can start the build with the following
2473 steps:
2475 # cd /usr/sandbox/usr/pkgsrc
2476 # sh mk/bulk/do-sandbox-build
2479 This will just jump inside the sandbox and start building. At the end of the
2480 build, mail will be sent with the results of the build. Created binary pkgs
2481 will be in /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/
2482 from).
2484 7.3.7. Building a partial set of packages
2486 In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk
2487 /bulk/build script may be used to build a subset of the packages contained in
2488 pkgsrc. By setting SPECIFIC_PKGS in mk.conf, the variables
2490   * SITE_SPECIFIC_PKGS
2492   * HOST_SPECIFIC_PKGS
2494   * GROUP_SPECIFIC_PKGS
2496   * USER_SPECIFIC_PKGS
2498 will define the set of packages which should be built. The bulk build code will
2499 also include any packages which are needed as dependencies for the explicitly
2500 listed packages.
2502 One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
2503 periodically to have a complete set of the binary packages needed for your site
2504 available without the overhead of building extra packages that are not needed.
2506 7.3.8. Uploading results of a bulk build
2508 This section describes how pkgsrc developers can upload binary pkgs built by
2509 bulk builds to ftp.NetBSD.org.
2511 If you would like to automatically create checksum files for the binary
2512 packages you intend to upload, remember to set MKSUMS=yes in your mk/bulk/
2513 build.conf.
2515 If you would like to PGP sign the checksum files (highly recommended!),
2516 remember to set SIGN_AS=username@NetBSD.org in your mk/bulk/build.conf. This
2517 will prompt you for your GPG password to sign the files before uploading
2518 everything.
2520 Then, make sure that you have RSYNC_DST set properly in your mk/bulk/build.conf
2521 file, i.e. adjust it to something like one of the following:
2523 RSYNC_DST=ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload
2525 Please use appropriate values for "20xxQy" (the branch), "a.b.c" (the OS
2526 version) and "arch" here. If your login on ftp.NetBSD.org is different from
2527 your local login, write your login directly into the variable, e.g. my local
2528 account is "feyrer", but for my login "hubertf", I use:
2530 RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload
2532 A separate upload directory is used here to allow "closing" the directory
2533 during upload. To do so, run the following command on ftp.NetBSD.org next:
2535 nbftp% mkdir -p -m 750 /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload
2537 Before uploading the binary pkgs, ssh authentication needs to be set up. This
2538 example shows how to set up temporary keys for the root account inside the
2539 sandbox (assuming that no keys should be present there usually):
2541 # chroot /usr/sandbox
2542 chroot-# rm $HOME/.ssh/id-dsa*
2543 chroot-# ssh-keygen -t rsa
2544 chroot-# cat $HOME/.ssh/id-rsa.pub
2547 Now take the output of id-rsa.pub and append it to your ~/.ssh/authorized_keys
2548 file on ftp.NetBSD.org. You should remove the key after the upload is done!
2550 Next, test if your ssh connection really works:
2552 chroot-# ssh ftp.NetBSD.org date
2554 Use "-l yourNetBSDlogin" here as appropriate!
2556 Now after all this works, you can exit the sandbox and start the upload:
2558 chroot-# exit
2559 # cd /usr/sandbox/usr/pkgsrc
2560 # sh mk/bulk/do-sandbox-upload
2563 The upload process may take quite some time. Use ls(1) or du(1) on the FTP
2564 server to monitor progress of the upload. The upload script will take care of
2565 not uploading restricted packages.
2567 After the upload has ended, first thing is to revoke ssh access:
2569 nbftp% vi ~/.ssh/authorized_keys
2570       Gdd:x!
2572 Use whatever is needed to remove the key you've entered before! Last, move the
2573 uploaded packages out of the upload directory to have them accessible to
2574 everyone:
2576 nbftp% cd /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy
2577 nbftp% mv upload/* .
2578 nbftp% rmdir upload
2579 nbftp% chgrp -R netbsd .
2580 nbftp% find . -type d | xargs chmod 775
2583 7.4. Running a pbulk-style bulk build
2585 Running a pbulk-style bulk build works roughly as follows:
2587   * First, build the pbulk infrastructure in a fresh pkgsrc location.
2589   * Then, build each of the packages from a clean installation directory using
2590     the infrastructure.
2592 7.4.1. Preparation
2594 First, you need to create a pkgsrc installation for the pbulk infrastructure.
2595 No matter on which platform you are (even on NetBSD), you should bootstrap into
2596 its own directory. Let's take the directory /usr/pbulk or $HOME/pbulk for it.
2597 This installation will be bootstrapped and all the tools that are required for
2598 the bulk build will be installed there.
2600 $ cd /usr/pkgsrc
2601 $ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap
2602 $ rm -rf /tmp/pbulk-bootstrap
2604 Now the basic environment for the pbulk infrastructure is installed. The
2605 specific tools are still missing. This is a good time to edit the pkgsrc
2606 configuration file /usr/pbulk/etc/mk.conf to fit your needs. Typical things you
2607 might set now are:
2609   * PKG_DEVELOPER=yes, to enable many consistency checks,
2611   * WRKOBJDIR=/tmp/pbulk-outer, to keep /usr/pkgsrc free from any
2612     modifications,
2614   * DISTDIR=/distfiles, to have only one directory in which all distfiles (for
2615     the infrastructure and for the actual packages) are downloaded,
2617   * ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual
2618     Free/Open Source licenses that are acceptable to you,
2620   * SKIP_LICENSE_CHECK=yes, to bypass the license checks.
2622 Now you are ready to build the rest of the pbulk infrastructure.
2624 $ cd pkgtools/pbulk
2625 $ /usr/pbulk/bin/bmake install
2626 $ rm -rf /tmp/pbulk-outer
2628 Now the pbulk infrastructure is built and installed. It still needs to be
2629 configured, and after some more preparation, we will be able to start the real
2630 bulk build.
2632 7.4.2. Configuration
2634 TODO; see pkgsrc/doc/HOWTO-pbulk for more information.
2636 TODO: continue writing
2638 7.5. Creating a multiple CD-ROM packages collection
2640 After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
2641 of the resulting binary packages to assist in installing packages on other
2642 machines. The pkgtools/cdpack package provides a simple tool for creating the
2643 ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
2644 keeps all the dependencies for a given package on the same CD as that package.
2646 7.5.1. Example of cdpack
2648 Complete documentation for cdpack is found in the cdpack(1) man page. The
2649 following short example assumes that the binary packages are left in /usr/
2650 pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
2651 ISO 9660 images.
2653 # mkdir /u2/images
2654 # pkg_add /usr/pkgsrc/packages/All/cdpack
2655 # cdpack /usr/pkgsrc/packages/All /u2/images
2658 If you wish to include a common set of files (COPYRIGHT, README, etc.) on each
2659 CD in the collection, then you need to create a directory which contains these
2660 files. e.g.
2662 # mkdir /tmp/common
2663 # echo "This is a README" > /tmp/common/README
2664 # echo "Another file" > /tmp/common/COPYING
2665 # mkdir /tmp/common/bin
2666 # echo "#!/bin/sh" > /tmp/common/bin/myscript
2667 # echo "echo Hello world" >> /tmp/common/bin/myscript
2668 # chmod 755 /tmp/common/bin/myscript
2671 Now create the images:
2673 # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
2675 Each image will contain README, COPYING, and bin/myscript in their root
2676 directories.
2678 Chapter 8. Directory layout of the installed files
2680 Table of Contents
2682 8.1. File system layout in ${LOCALBASE}
2683 8.2. File system layout in ${VARBASE}
2685 The files that are installed by pkgsrc are organized in a way that is similar
2686 to what you find in the /usr directory of the base system. But some details are
2687 different. This is because pkgsrc initially came from FreeBSD and had adopted
2688 its file system hierarchy. Later it was largely influenced by NetBSD. But no
2689 matter which operating system you are using pkgsrc with, you can expect the
2690 same layout for pkgsrc.
2692 There are mainly four root directories for pkgsrc, which are all configurable
2693 in the bootstrap/bootstrap script. When pkgsrc has been installed as root, the
2694 default locations are:
2696 LOCALBASE=              /usr/pkg
2697 PKG_SYSCONFBASE=        /usr/pkg/etc
2698 VARBASE=                /var
2699 PKG_DBDIR=              /var/db/pkg
2701 In unprivileged mode (when pkgsrc has been installed as any other user), the
2702 default locations are:
2704 LOCALBASE=              ${HOME}/pkg
2705 PKG_SYSCONFBASE=        ${HOME}/pkg/etc
2706 VARBASE=                ${HOME}/pkg/var
2707 PKG_DBDIR=              ${HOME}/pkg/var/db/pkg
2709 What these four directories are for, and what they look like is explained
2710 below.
2712   * LOCALBASE corresponds to the /usr directory in the base system. It is the "
2713     main" directory where the files are installed and contains the well-known
2714     subdirectories like bin, include, lib, share and sbin.
2716   * VARBASE corresponds to /var in the base system. Some programs (especially
2717     games, network daemons) need write access to it during normal operation.
2719   * PKG_SYSCONFDIR corresponds to /etc in the base system. It contains
2720     configuration files of the packages, as well as pkgsrc's mk.conf itself.
2722 8.1. File system layout in ${LOCALBASE}
2724 The following directories exist in a typical pkgsrc installation in $
2725 {LOCALBASE}.
2729     Contains executable programs that are intended to be directly used by the
2730     end user.
2732 emul
2734     Contains files for the emulation layers of various other operating systems,
2735     especially for NetBSD.
2737 etc (the usual location of ${PKG_SYSCONFDIR})
2739     Contains the configuration files.
2741 include
2743     Contains headers for the C and C++ programming languages.
2745 info
2747     Contains GNU info files of various packages.
2751     Contains shared and static libraries.
2753 libdata
2755     Contains data files that don't change after installation. Other data files
2756     belong into ${VARBASE}.
2758 libexec
2760     Contains programs that are not intended to be used by end users, such as
2761     helper programs or network daemons.
2763 libexec/cgi-bin
2765     Contains programs that are intended to be executed as CGI scripts by a web
2766     server.
2768 man (the usual value of ${PKGMANDIR})
2770     Contains brief documentation in form of manual pages.
2772 sbin
2774     Contains programs that are intended to be used only by the super-user.
2776 share
2778     Contains platform-independent data files that don't change after
2779     installation.
2781 share/doc
2783     Contains documentation files provided by the packages.
2785 share/examples
2787     Contains example files provided by the packages. Among others, the original
2788     configuration files are saved here and copied to ${PKG_SYSCONFDIR} during
2789     installation.
2791 share/examples/rc.d
2793     Contains the original files for rc.d scripts.
2795 var (the usual location of ${VARBASE})
2797     Contains files that may be modified after installation.
2799 8.2. File system layout in ${VARBASE}
2801 db/pkg (the usual location of ${PKG_DBDIR})
2803     Contains information about the currently installed packages.
2805 games
2807     Contains highscore files.
2811     Contains log files.
2815     Contains informational files about daemons that are currently running.
2817 Chapter 9. Frequently Asked Questions
2819 Table of Contents
2821 9.1. Are there any mailing lists for pkg-related discussion?
2822 9.2. Where's the pkgviews documentation?
2823 9.3. Utilities for package management (pkgtools)
2824 9.4. How to use pkgsrc as non-root
2825 9.5. How to resume transfers when fetching distfiles?
2826 9.6. How can I install/use modular X.org from pkgsrc?
2827 9.7. How to fetch files from behind a firewall
2828 9.8. How do I tell make fetch to do passive FTP?
2829 9.9. How to fetch all distfiles at once
2830 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
2831 9.11. What does "Could not find bsd.own.mk" mean?
2832 9.12. Using 'sudo' with pkgsrc
2833 9.13. How do I change the location of configuration files?
2834 9.14. Automated security checks
2835 9.15. Why do some packages ignore my CFLAGS?
2836 9.16. A package does not build. What shall I do?
2837 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
2838     conflicts" mean?
2840 This section contains hints, tips & tricks on special things in pkgsrc that we
2841 didn't find a better place for in the previous chapters, and it contains items
2842 for both pkgsrc users and developers.
2844 9.1. Are there any mailing lists for pkg-related discussion?
2846 The following mailing lists may be of interest to pkgsrc users:
2848   * pkgsrc-users: This is a general purpose list for most issues regarding
2849     pkgsrc, regardless of platform, e.g. soliciting user help for pkgsrc
2850     configuration, unexpected build failures, using particular packages,
2851     upgrading pkgsrc installations, questions regarding the pkgsrc release
2852     branches, etc. General announcements or proposals for changes that impact
2853     the pkgsrc user community, e.g. major infrastructure changes, new features,
2854     package removals, etc., may also be posted.
2856   * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and
2857     discussed.
2859   * pkgsrc-changes: This list is for those who are interested in getting a
2860     commit message for every change committed to pkgsrc. It is also available
2861     in digest form, meaning one daily message containing all commit messages
2862     for changes to the package source tree in that 24 hour period.
2864 To subscribe, do:
2866 % echo subscribe listname | mail majordomo@NetBSD.org
2868 Archives for all these mailing lists are available from http://
2869 mail-index.NetBSD.org/.
2871 9.2. Where's the pkgviews documentation?
2873 Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's
2874 guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.
2876 9.3. Utilities for package management (pkgtools)
2878 The directory pkgsrc/pkgtools contains a number of useful utilities for both
2879 users and developers of pkgsrc. This section attempts only to make the reader
2880 aware of the utilities and when they might be useful, and not to duplicate the
2881 documentation that comes with each package.
2883 Utilities used by pkgsrc (automatically installed when needed):
2885   * pkgtools/x11-links: Symlinks for use by buildlink.
2887 OS tool augmentation (automatically installed when needed):
2889   * pkgtools/digest: Calculates various kinds of checksums (including SHA1).
2891   * pkgtools/libnbcompat: Compatibility library for pkgsrc tools.
2893   * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree.
2895   * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or
2896     for use on operating systems where pkg_install is not present.
2898 Utilities used by pkgsrc (not automatically installed):
2900   * pkgtools/pkg_tarup: Create a binary package from an already-installed
2901     package. Used by make replace to save the old package.
2903   * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch
2904     distfiles from multiple locations. It currently supports the following
2905     methods: multiple CD-ROMs and network FTP/HTTP connections.
2907   * pkgtools/xpkgwedge: Put X11 packages someplace else (enabled by default).
2909   * devel/cpuflags: Determine the best compiler flags to optimise code for your
2910     current CPU and compiler.
2912 Utilities for keeping track of installed packages, being up to date, etc:
2914   * pkgtools/pkg_chk: Reports on packages whose installed versions do not match
2915     the latest pkgsrc entries.
2917   * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a
2918     strategy for updating.
2920   * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses
2921     graphviz).
2923   * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors.
2925   * pkgtools/lintpkgsrc: The lintpkgsrc(1) program does various checks on the
2926     complete pkgsrc system.
2928   * pkgtools/pkgsurvey: Report what packages you have installed.
2930 Utilities for people maintaining or creating individual packages:
2932   * pkgtools/pkgdiff: Automate making and maintaining patches for a package
2933     (includes pkgdiff, pkgvi, mkpatches, etc.).
2935   * pkgtools/rpm2pkg, pkgtools/url2pkg: Aids in converting to pkgsrc.
2937   * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package.
2939 Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
2941   * pkgtools/pkg_comp: Build packages in a chrooted area.
2943   * pkgtools/libkver: Spoof kernel version for chrooted cross builds.
2945 9.4. How to use pkgsrc as non-root
2947 If you want to use pkgsrc as non-root user, you can set some variables to make
2948 pkgsrc work under these conditions. At the very least, you need to set
2949 UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple
2950 related variables to allow installation of packages as non-root.
2952 In case the defaults are not enough, you may want to tune some other variables
2953 used. For example, if the automatic user/group detection leads to incorrect
2954 values (or not the ones you would like to use), you can change them by setting
2955 UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively.
2957 As regards bootstrapping, please note that the bootstrap script will ease
2958 non-root configuration when given the "--ignore-user-check" flag, as it will
2959 choose and use multiple default directories under ~/pkg as the installation
2960 targets. These directories can be overridden by the "--prefix" flag provided by
2961 the script, as well as some others that allow finer tuning of the tree layout.
2963 9.5. How to resume transfers when fetching distfiles?
2965 By default, resuming transfers in pkgsrc is disabled, but you can enable this
2966 feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
2967 a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.
2969 You can also use a different program than the default ftp(1) by changing the
2970 FETCH_USING variable. You can specify the program by using of ftp, fetch, wget
2971 or curl. Alternatively, fetching can be disabled by using the value manual. A
2972 value of custom disables the system defaults and dependency tracking for the
2973 fetch program. In that case you have to provide FETCH_CMD, FETCH_BEFORE_ARGS,
2974 FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.
2976 For example, if you want to use wget to download, you'll have to use something
2977 like:
2979 FETCH_USING=    wget
2981 9.6. How can I install/use modular X.org from pkgsrc?
2983 If you want to use modular X.org from pkgsrc instead of your system's own X11
2984 (/usr/X11R6, /usr/openwin, ...) you will have to add the following line into
2985 mk.conf:
2987 X11_TYPE=modular
2989 Note
2991 The DragonFly operating system defaults to using modular X.org from pkgsrc.
2993 9.7. How to fetch files from behind a firewall
2995 If you are sitting behind a firewall which does not allow direct connections to
2996 Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
2997 is done using an environment variable in the form of a URL, e.g. in Amdahl, the
2998 machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
2999 the proxy port number. So the proxy environment variables are:
3001 ftp_proxy=ftp://orpheus.amdahl.com:80/
3002 http_proxy=http://orpheus.amdahl.com:80/
3004 9.8. How do I tell make fetch to do passive FTP?
3006 This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
3007 FETCH_CMD is assigned the first available command from the following list:
3009   * ${LOCALBASE}/bin/ftp
3011   * /usr/bin/ftp
3013 On a default NetBSD installation, this will be /usr/bin/ftp, which
3014 automatically tries passive connections first, and falls back to active
3015 connections if the server refuses to do passive. For the other tools, add the
3016 following to your mk.conf file: PASSIVE_FETCH=1.
3018 Having that option present will prevent /usr/bin/ftp from falling back to
3019 active transfers.
3021 9.9. How to fetch all distfiles at once
3023 You would like to download all the distfiles in a single batch from work or
3024 university, where you can't run a make fetch. There is an archive of distfiles
3025 on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
3027 The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
3028 subdirectories, carry the resulting list to your machine at work/school and use
3029 it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work,
3030 don't forget to set FETCH_CMD to something that fetches a URL:
3032 At home:
3034 % cd /usr/pkgsrc
3035 % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
3036 % scp /tmp/fetch.sh work:/tmp
3038 At work:
3040 % sh /tmp/fetch.sh
3042 then tar up /tmp/distfiles and take it home.
3044 If you have a machine running NetBSD, and you want to get all distfiles (even
3045 ones that aren't for your machine architecture), you can do so by using the
3046 above-mentioned make fetch-list approach, or fetch the distfiles directly by
3047 running:
3049 % make mirror-distfiles
3051 If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can get
3052 everything by running:
3054 % make fetch NO_SKIP=yes
3056 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
3058 When compiling the pkgtools/pkg_install package, you get the error from make
3059 that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
3060 that you don't have installed the "text" set (nroff, ...) from the NetBSD base
3061 distribution on your machine. It is recommended to do that to format man pages.
3063 In the case of the pkgtools/pkg_install package, you can get away with setting
3064 NOMAN=YES either in the environment or in mk.conf.
3066 9.11. What does "Could not find bsd.own.mk" mean?
3068 You didn't install the compiler set, comp.tgz, when you installed your NetBSD
3069 machine. Please get and install it, by extracting it in /:
3071 # cd /
3072 # tar --unlink -zxvpf .../comp.tgz
3074 comp.tgz is part of every NetBSD release. Get the one that corresponds to your
3075 release (determine via uname -r).
3077 9.12. Using 'sudo' with pkgsrc
3079 When installing packages as non-root user and using the just-in-time su(1)
3080 feature of pkgsrc, it can become annoying to type in the root password for each
3081 required package installed. To avoid this, the sudo package can be used, which
3082 does password caching over a limited time. To use it, install sudo (either as
3083 binary package or from security/sudo) and then put the following into your
3084 mk.conf, somewhere after the definition of the LOCALBASE variable:
3086 .if exists(${LOCALBASE}/bin/sudo)
3087 SU_CMD=        ${LOCALBASE}/bin/sudo /bin/sh -c
3088 .endif
3090 9.13. How do I change the location of configuration files?
3092 As the system administrator, you can choose where configuration files are
3093 installed. The default settings make all these files go into ${PREFIX}/etc or
3094 some of its subdirectories; this may be suboptimal depending on your
3095 expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine
3096 configuration of the provided packages).
3098 In order to change the defaults, you can modify the PKG_SYSCONFBASE variable
3099 (in mk.conf) to point to your preferred configuration directory; some common
3100 examples include /etc or /etc/pkg.
3102 Furthermore, you can change this value on a per-package basis by setting the
3103 PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
3104 matches the name of the package you would like to modify, that is, the contents
3105 of PKGBASE.
3107 Note that after changing these settings, you must rebuild and reinstall any
3108 affected packages.
3110 9.14. Automated security checks
3112 Please be aware that there can often be bugs in third-party software, and some
3113 of these bugs can leave a machine vulnerable to exploitation by attackers. In
3114 an effort to lessen the exposure, the NetBSD packages team maintains a database
3115 of known-exploits to packages which have at one time been included in pkgsrc.
3116 The database can be downloaded automatically, and a security audit of all
3117 packages installed on a system can take place. To do this, refer to the
3118 following two tools (installed as part of the pkgtools/pkg_install package):
3120  1. pkg_admin fetch-pkg-vulnerabilities, an easy way to download a list of the
3121     security vulnerabilities information. This list is kept up to date by the
3122     pkgsrc security team, and is distributed from the NetBSD ftp server:
3124     ftp://ftp.NetBSD.org/pkgsrc/distfiles/pkg-vulnerabilities
3126  2. pkg_admin audit, an easy way to audit the current machine, checking each
3127     known vulnerability. If a vulnerable package is installed, it will be shown
3128     by output to stdout, including a description of the type of vulnerability,
3129     and a URL containing more information.
3131 Use of these tools is strongly recommended! After "pkg_install" is installed,
3132 please read the package's message, which you can get by running pkg_info -D
3133 pkg_install.
3135 If this package is installed, pkgsrc builds will use it to perform a security
3136 check before building any package. See Section 5.2, "Variables affecting the
3137 build process" for ways to control this check.
3139 9.15. Why do some packages ignore my CFLAGS?
3141 When you add your own preferences to the CFLAGS variable in your mk.conf, these
3142 flags are passed in environment variables to the ./configure scripts and to
3143 make(1). Some package authors ignore the CFLAGS from the environment variable
3144 by overriding them in the Makefiles of their package.
3146 Currently there is no solution to this problem. If you really need the package
3147 to use your CFLAGS you should run make patch in the package directory and then
3148 inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly.
3149 Usually you can remove these lines. But be aware that some "smart" programmers
3150 write so bad code that it only works for the specific combination of CFLAGS
3151 they have chosen.
3153 9.16. A package does not build. What shall I do?
3155  1. Make sure that your copy of pkgsrc is consistent. A case that occurs often
3156     is that people only update pkgsrc in parts, because of performance reasons.
3157     Since pkgsrc is one large system, not a collection of many small systems,
3158     there are sometimes changes that only work when the whole pkgsrc tree is
3159     updated.
3161  2. Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or "
3162     >>>>>>" in all your pkgsrc files.
3164  3. Make sure that you don't have old copies of the packages extracted. Run 
3165     make clean clean-depends to verify this.
3167  4. If the problem still exists, write a mail to the pkgsrc-users mailing list.
3169 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
3170 conflicts" mean?
3172 You have modified a file from pkgsrc, and someone else has modified that same
3173 file afterwards in the CVS repository. Both changes are in the same region of
3174 the file, so when you updated pkgsrc, the cvs command marked the conflicting
3175 changes in the file. Because of these markers, the file is no longer a valid
3176 Makefile.
3178 Have a look at that file, and if you don't need your local changes anymore, you
3179 can remove that file and run cvs -q update -dP in that directory to download
3180 the current version.
3182 Part II. The pkgsrc developer's guide
3184 This part of the book deals with creating and modifying packages. It starts
3185 with a "HOWTO"-like guide on creating a new package. The remaining chapters are
3186 more like a reference manual for pkgsrc.
3188 Table of Contents
3190 10. Creating a new pkgsrc package from scratch
3192     10.1. Common types of packages
3194         10.1.1. Perl modules
3195         10.1.2. KDE applications
3196         10.1.3. Python modules and programs
3198     10.2. Examples
3200         10.2.1. How the www/nvu package came into pkgsrc
3202 11. Package components - files, directories and contents
3204     11.1. Makefile
3205     11.2. distinfo
3206     11.3. patches/*
3208         11.3.1. Structure of a single patch file
3209         11.3.2. Creating patch files
3210         11.3.3. Sources where the patch files come from
3211         11.3.4. Patching guidelines
3212         11.3.5. Feedback to the author
3214     11.4. Other mandatory files
3215     11.5. Optional files
3217         11.5.1. Files affecting the binary package
3218         11.5.2. Files affecting the build process
3219         11.5.3. Files affecting nothing at all
3221     11.6. work*
3222     11.7. files/*
3224 12. Programming in Makefiles
3226     12.1. Caveats
3227     12.2. Makefile variables
3229         12.2.1. Naming conventions
3231     12.3. Code snippets
3233         12.3.1. Adding things to a list
3234         12.3.2. Converting an internal list into an external list
3235         12.3.3. Passing variables to a shell command
3236         12.3.4. Quoting guideline
3237         12.3.5. Workaround for a bug in BSD Make
3239 13. PLIST issues
3241     13.1. RCS ID
3242     13.2. Semi-automatic PLIST generation
3243     13.3. Tweaking output of make print-PLIST
3244     13.4. Variable substitution in PLIST
3245     13.5. Man page compression
3246     13.6. Changing PLIST source with PLIST_SRC
3247     13.7. Platform-specific and differing PLISTs
3248     13.8. Sharing directories between packages
3250 14. Buildlink methodology
3252     14.1. Converting packages to use buildlink3
3253     14.2. Writing buildlink3.mk files
3255         14.2.1. Anatomy of a buildlink3.mk file
3256         14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.
3257             pkg in buildlink3.mk files
3259     14.3. Writing builtin.mk files
3261         14.3.1. Anatomy of a builtin.mk file
3262         14.3.2. Global preferences for native or pkgsrc software
3264 15. The pkginstall framework
3266     15.1. Files and directories outside the installation prefix
3268         15.1.1. Directory manipulation
3269         15.1.2. File manipulation
3271     15.2. Configuration files
3273         15.2.1. How PKG_SYSCONFDIR is set
3274         15.2.2. Telling the software where configuration files are
3275         15.2.3. Patching installations
3276         15.2.4. Disabling handling of configuration files
3278     15.3. System startup scripts
3280         15.3.1. Disabling handling of system startup scripts
3282     15.4. System users and groups
3283     15.5. System shells
3285         15.5.1. Disabling shell registration
3287     15.6. Fonts
3289         15.6.1. Disabling automatic update of the fonts databases
3291 16. Options handling
3293     16.1. Global default options
3294     16.2. Converting packages to use bsd.options.mk
3295     16.3. Option Names
3296     16.4. Determining the options of dependencies
3298 17. The build process
3300     17.1. Introduction
3301     17.2. Program location
3302     17.3. Directories used during the build process
3303     17.4. Running a phase
3304     17.5. The fetch phase
3306         17.5.1. What to fetch and where to get it from
3307         17.5.2. How are the files fetched?
3309     17.6. The checksum phase
3310     17.7. The extract phase
3311     17.8. The patch phase
3312     17.9. The tools phase
3313     17.10. The wrapper phase
3314     17.11. The configure phase
3315     17.12. The build phase
3316     17.13. The test phase
3317     17.14. The install phase
3318     17.15. The package phase
3319     17.16. Cleaning up
3320     17.17. Other helpful targets
3322 18. Tools needed for building or running
3324     18.1. Tools for pkgsrc builds
3325     18.2. Tools needed by packages
3326     18.3. Tools provided by platforms
3327     18.4. Questions regarding the tools
3329 19. Making your package work
3331     19.1. General operation
3333         19.1.1. Portability of packages
3334         19.1.2. How to pull in user-settable variables from mk.conf
3335         19.1.3. User interaction
3336         19.1.4. Handling licenses
3337         19.1.5. Restricted packages
3338         19.1.6. Handling dependencies
3339         19.1.7. Handling conflicts with other packages
3340         19.1.8. Packages that cannot or should not be built
3341         19.1.9. Packages which should not be deleted, once installed
3342         19.1.10. Handling packages with security problems
3343         19.1.11. How to handle incrementing versions when fixing an existing
3344             package
3345         19.1.12. Substituting variable text in the package files (the SUBST
3346             framework)
3348     19.2. Fixing problems in the fetch phase
3350         19.2.1. Packages whose distfiles aren't available for plain downloading
3351         19.2.2. How to handle modified distfiles with the 'old' name
3353     19.3. Fixing problems in the configure phase
3355         19.3.1. Shared libraries - libtool
3356         19.3.2. Using libtool on GNU packages that already support libtool
3357         19.3.3. GNU Autoconf/Automake
3359     19.4. Programming languages
3361         19.4.1. C, C++, and Fortran
3362         19.4.2. Java
3363         19.4.3. Packages containing perl scripts
3364         19.4.4. Packages containing shell scripts
3365         19.4.5. Other programming languages
3367     19.5. Fixing problems in the build phase
3369         19.5.1. Compiling C and C++ code conditionally
3370         19.5.2. How to handle compiler bugs
3371         19.5.3. Undefined reference to "..."
3372         19.5.4. Running out of memory
3374     19.6. Fixing problems in the install phase
3376         19.6.1. Creating needed directories
3377         19.6.2. Where to install documentation
3378         19.6.3. Installing highscore files
3379         19.6.4. Adding DESTDIR support to packages
3380         19.6.5. Packages with hardcoded paths to other interpreters
3381         19.6.6. Packages installing perl modules
3382         19.6.7. Packages installing info files
3383         19.6.8. Packages installing man pages
3384         19.6.9. Packages installing GConf data files
3385         19.6.10. Packages installing scrollkeeper/rarian data files
3386         19.6.11. Packages installing X11 fonts
3387         19.6.12. Packages installing GTK2 modules
3388         19.6.13. Packages installing SGML or XML data
3389         19.6.14. Packages installing extensions to the MIME database
3390         19.6.15. Packages using intltool
3391         19.6.16. Packages installing startup scripts
3392         19.6.17. Packages installing TeX modules
3393         19.6.18. Packages supporting running binaries in emulation
3394         19.6.19. Packages installing hicolor theme icons
3395         19.6.20. Packages installing desktop files
3397     19.7. Marking packages as having problems
3399 20. Debugging
3400 21. Submitting and Committing
3402     21.1. Submitting binary packages
3403     21.2. Submitting source packages (for non-NetBSD-developers)
3404     21.3. General notes when adding, updating, or removing packages
3405     21.4. Committing: Adding a package to CVS
3406     21.5. Updating a package to a newer version
3407     21.6. Renaming a package in pkgsrc
3408     21.7. Moving a package in pkgsrc
3410 22. Frequently Asked Questions
3411 23. GNOME packaging and porting
3413     23.1. Meta packages
3414     23.2. Packaging a GNOME application
3415     23.3. Updating GNOME to a newer version
3416     23.4. Patching guidelines
3418 Chapter 10. Creating a new pkgsrc package from scratch
3420 Table of Contents
3422 10.1. Common types of packages
3424     10.1.1. Perl modules
3425     10.1.2. KDE applications
3426     10.1.3. Python modules and programs
3428 10.2. Examples
3430     10.2.1. How the www/nvu package came into pkgsrc
3432 When you find a package that is not yet in pkgsrc, you most likely have a URL
3433 from where you can download the source code. Starting with this URL, creating a
3434 package involves only a few steps.
3436  1. First, install the packages pkgtools/url2pkg and pkgtools/pkglint.
3438  2. Then, choose one of the top-level directories as the category in which you
3439     want to place your package. You can also create a directory of your own
3440     (maybe called local). In that category directory, create another directory
3441     for your package and change into it.
3443  3. Run the program url2pkg, which will ask you for a URL. Enter the URL of the
3444     distribution file (in most cases a .tar.gz file) and watch how the basic
3445     ingredients of your package are created automatically. The distribution
3446     file is extracted automatically to fill in some details in the Makefile
3447     that would otherwise have to be done manually.
3449  4. Examine the extracted files to determine the dependencies of your package.
3450     Ideally, this is mentioned in some README file, but things may differ. For
3451     each of these dependencies, look where it exists in pkgsrc, and if there is
3452     a file called buildlink3.mk in that directory, add a line to your package
3453     Makefile which includes that file just before the last line. If the
3454     buildlink3.mk file does not exist, it must be created first. The
3455     buildlink3.mk file makes sure that the package's include files and
3456     libraries are provided.
3458     If you just need binaries from a package, add a DEPENDS line to the
3459     Makefile, which specifies the version of the dependency and where it can be
3460     found in pkgsrc. This line should be placed in the third paragraph. If the
3461     dependency is only needed for building the package, but not when using it,
3462     use BUILD_DEPENDS instead of DEPENDS. Your package may then look like this:
3464     [...]
3466     BUILD_DEPENDS+= lua>=5.0:../../lang/lua
3467     DEPENDS+=       screen-[0-9]*:../../misc/screen
3468     DEPENDS+=       screen>=4.0:../../misc/screen
3470     [...]
3472     .include "../../category/package/buildlink3.mk"
3473     .include "../../devel/glib2/buildlink3.mk"
3474     .include "../../mk/bsd.pkg.mk"
3476  5. Run pkglint to see what things still need to be done to make your package a
3477     "good" one. If you don't know what pkglint's warnings want to tell you, try
3478     pkglint --explain or pkglint -e, which outputs additional explanations.
3480  6. In many cases the package is not yet ready to build. You can find
3481     instructions for the most common cases in the next section, Section 10.1,
3482     "Common types of packages". After you have followed the instructions over
3483     there, you can hopefully continue here.
3485  7. Run bmake clean to clean the working directory from the extracted files.
3486     Besides these files, a lot of cache files and other system information has
3487     been saved in the working directory, which may become wrong after you
3488     edited the Makefile.
3490  8. Now, run bmake to build the package. For the various things that can go
3491     wrong in this phase, consult Chapter 19, Making your package work.
3493  9. When the package builds fine, the next step is to install the package. Run 
3494     bmake install and hope that everything works.
3496 10. Up to now, the file PLIST, which contains a list of the files that are
3497     installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to
3498     generate a probably correct list. Check the file using your preferred text
3499     editor to see if the list of files looks plausible.
3501 11. Run pkglint again to see if the generated PLIST contains garbage or not.
3503 12. When you ran bmake install, the package has been registered in the database
3504     of installed files, but with an empty list of files. To fix this, run bmake
3505     deinstall and bmake install again. Now the package is registered with the
3506     list of files from PLIST.
3508 13. Run bmake package to create a binary package from the set of installed
3509     files.
3511 10.1. Common types of packages
3513 10.1.1. Perl modules
3515 Simple Perl modules are handled automatically by url2pkg, including
3516 dependencies.
3518 10.1.2. KDE applications
3520 KDE applications should always include meta-pkgs/kde3/kde3.mk, which contains
3521 numerous settings that are typical of KDE packages.
3523 10.1.3. Python modules and programs
3525 Python modules and programs packages are easily created using a set of
3526 predefined variables.
3528 Most Python packages use either "distutils" or easy-setup ("eggs"). If the
3529 software uses "distutils", set the PYDISTUTILSPKG variable to "yes" so pkgsrc
3530 will make use of this framework. "distutils" uses a script called setup.py, if
3531 the "distutils" driver is not called setup.py, set the PYSETUP variable to the
3532 name of the script.
3534 If the default Python versions are not supported by the software, set the
3535 PYTHON_VERSIONS_ACCEPTED variable to the Python versions the software is known
3536 to work with, from the most recent to the older one, e.g.
3538 PYTHON_VERSIONS_ACCEPTED=       31 27 26
3540 If the packaged software is a Python module, include "../../lang/python/
3541 extension.mk". In this case, the package directory should be called "
3542 py-software" and PKGNAME should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.
3544 DISTNAME=   foopymodule-1.2.10
3545 PKGNAME=    ${PYPKGPREFIX}-${DISTNAME}
3547 If it is an application, also include "../../lang/python/application.mk" before
3548 "extension.mk".
3550 If the packaged software, either it is an application or a module, is
3551 egg-aware, you only need to include "../../lang/python/egg.mk".
3553 In order to correctly set the path to the Python interpreter, use the
3554 REPLACE_PYTHON variable and set it to the list of files (paths relative to
3555 WRKSRC) that must be corrected. For example :
3557 REPLACE_PYTHON=   *.py
3559 10.2. Examples
3561 10.2.1. How the www/nvu package came into pkgsrc
3563 10.2.1.1. The initial package
3565 Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet
3566 been imported into pkgsrc. As the description says it has to do with the web,
3567 the obvious choice for the category is "www".
3569 $ mkdir www/nvu
3570 $ cd www/nvu
3572 The web site says that the sources are available as a tar file, so I fed that
3573 URL to the url2pkg program:
3575 $ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
3577 My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the
3578 package name should not have the word "sources" in it. I also filled in the
3579 MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like
3580 that:
3582 # $NetBSD$
3585 DISTNAME=       nvu-1.0-sources
3586 PKGNAME=        nvu-1.0
3587 CATEGORIES=     www
3588 MASTER_SITES=   http://cvs.nvu.com/download/
3589 EXTRACT_SUFX=   .tar.bz2
3591 MAINTAINER=     rillig@NetBSD.org
3592 HOMEPAGE=       http://cvs.nvu.com/
3593 COMMENT=        Web Authoring System
3595 # url2pkg-marker (please do not remove this line.)
3596 .include "../../mk/bsd.pkg.mk"
3598 Then, I quit the editor and watched pkgsrc downloading a large source archive:
3600 url2pkg> Running "make makesum" ...
3601 => Required installed package digest>=20010302: digest-20060826 found
3602 => Fetching nvu-1.0-sources.tar.bz2
3603 Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
3604 100% |*************************************| 28992 KB  150.77 KB/s00:00 ETA
3605 29687976 bytes retrieved in 03:12 (150.77 KB/s)
3606 url2pkg> Running "make extract" ...
3607 => Required installed package digest>=20010302: digest-20060826 found
3608 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
3609 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
3610 work.bacc -> /tmp/roland/pkgsrc/www/nvu/work.bacc
3611 ===> Installing dependencies for nvu-1.0
3612 ===> Overriding tools for nvu-1.0
3613 ===> Extracting for nvu-1.0
3614 url2pkg> Adjusting the Makefile.
3616 Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done!
3618 Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)
3620 10.2.1.2. Fixing all kinds of problems to make the package work
3622 Now that the package has been extracted, let's see what's inside it. The
3623 package has a README.txt, but that only says something about mozilla, so it's
3624 probably useless for seeing what dependencies this package has. But since there
3625 is a GNU configure script in the package, let's hope that it will complain
3626 about everything it needs.
3628 $ bmake
3629 => Required installed package digest>=20010302: digest-20060826 found
3630 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
3631 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
3632 ===> Patching for nvu-1.0
3633 ===> Creating toolchain wrappers for nvu-1.0
3634 ===> Configuring for nvu-1.0
3635 [...]
3636 configure: error: Perl 5.004 or higher is required.
3637 [...]
3638 WARNING: Please add USE_TOOLS+=perl to the package Makefile.
3639 [...]
3641 That worked quite well. So I opened the package Makefile in my editor, and
3642 since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
3643 dependencies of the package have changed now, and since a perl wrapper is
3644 automatically installed in the "tools" phase, I need to build the package from
3645 scratch.
3647 $ bmake clean
3648 ===> Cleaning for nvu-1.0
3649 $ bmake
3650 [...]
3651 *** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \
3652 GNU Make.  You will not be able to build Mozilla without GNU Make.
3653 [...]
3655 So I added "gmake" to the USE_TOOLS line and tried again (from scratch).
3657 [...]
3658 checking for GTK - version >= 1.2.0... no
3659 *** Could not run GTK test program, checking why...
3660 [...]
3662 Now to the other dependencies. The first question is: Where is the GTK package
3663 hidden in pkgsrc?
3665 $ echo ../../*/gtk*
3666 [many packages ...]
3667 $ echo ../../*/gtk
3668 ../../x11/gtk
3669 $ echo ../../*/gtk2
3670 ../../x11/gtk2
3671 $ echo ../../*/gtk2/bui*
3672 ../../x11/gtk2/buildlink3.mk
3674 The first try was definitely too broad. The second one had exactly one result,
3675 which is very good. But there is one pitfall with GNOME packages. Before GNOME
3676 2 had been released, there were already many GNOME 1 packages in pkgsrc. To be
3677 able to continue to use these packages, the GNOME 2 packages were imported as
3678 separate packages, and their names usually have a "2" appended. So I checked
3679 whether this was the case here, and indeed it was.
3681 Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
3682 easy. I just inserted an .include line before the last line of the package
3683 Makefile, so that it now looks like this:
3685 [...]
3686 .include "../../x11/gtk2/buildlink3.mk"
3687 .include "../../mk/bsd.pkg.mk
3689 After another bmake clean && bmake, the answer was:
3691 [...]
3692 checking for gtk-config... /home/roland/pkg/bin/gtk-config
3693 checking for GTK - version >= 1.2.0... no
3694 *** Could not run GTK test program, checking why...
3695 *** The test program failed to compile or link. See the file config.log for the
3696 *** exact error that occured. This usually means GTK was incorrectly installed
3697 *** or that you have moved GTK since it was installed. In the latter case, you
3698 *** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config
3699 configure: error: Test for GTK failed.
3700 [...]
3702 In this particular case, the assumption that "every package prefers GNOME 2"
3703 had been wrong. The first of the lines above told me that this package really
3704 wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
3705 it would have looked for pkg-config instead of gtk-config. So I changed the x11
3706 /gtk2 to x11/gtk in the package Makefile, and tried again.
3708 [...]
3709 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
3710 In file included from xpidl.c:42:
3711 xpidl.h:53:24: libIDL/IDL.h: No such file or directory
3712 In file included from xpidl.c:42:
3713 xpidl.h:132: error: parse error before "IDL_ns"
3714 [...]
3716 The package still does not find all of its dependencies. Now the question is:
3717 Which package provides the libIDL/IDL.h header file?
3719 $ echo ../../*/*idl*
3720 ../../devel/py-idle ../../wip/idled ../../x11/acidlaunch
3721 $ echo ../../*/*IDL*
3722 ../../net/libIDL
3724 Let's take the one from the second try. So I included the ../../net/libIDL/
3725 buildlink3.mk file and tried again. But the error didn't change. After digging
3726 through some of the code, I concluded that the build process of the package was
3727 broken and couldn't have ever worked, but since the Mozilla source tree is
3728 quite large, I didn't want to fix it. So I added the following to the package
3729 Makefile and tried again:
3731 CPPFLAGS+=              -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0
3732 BUILDLINK_TRANSFORM+=   -l:IDL:IDL-2
3734 The latter line is needed because the package expects the library libIDL.so,
3735 but only libIDL-2.so is available. So I told the compiler wrapper to rewrite
3736 that on the fly.
3738 The next problem was related to a recent change of the FreeType interface. I
3739 looked up in www/seamonkey which patch files were relevant for this issue and
3740 copied them to the patches directory. Then I retried, fixed the patches so that
3741 they applied cleanly and retried again. This time, everything worked.
3743 10.2.1.3. Installing the package
3745 $ bmake CHECK_FILES=no install
3746 [...]
3747 $ bmake print-PLIST >PLIST
3748 $ bmake deinstall
3749 $ bmake install
3751 Chapter 11. Package components - files, directories and contents
3753 Table of Contents
3755 11.1. Makefile
3756 11.2. distinfo
3757 11.3. patches/*
3759     11.3.1. Structure of a single patch file
3760     11.3.2. Creating patch files
3761     11.3.3. Sources where the patch files come from
3762     11.3.4. Patching guidelines
3763     11.3.5. Feedback to the author
3765 11.4. Other mandatory files
3766 11.5. Optional files
3768     11.5.1. Files affecting the binary package
3769     11.5.2. Files affecting the build process
3770     11.5.3. Files affecting nothing at all
3772 11.6. work*
3773 11.7. files/*
3775 Whenever you're preparing a package, there are a number of files involved which
3776 are described in the following sections.
3778 11.1. Makefile
3780 Building, installation and creation of a binary package are all controlled by
3781 the package's Makefile. The Makefile describes various things about a package,
3782 for example from where to get it, how to configure, build, and install it.
3784 A package Makefile contains several sections that describe the package.
3786 In the first section there are the following variables, which should appear
3787 exactly in the order given here. The order and grouping of the variables is
3788 mostly historical and has no further meaning.
3790   * DISTNAME is the basename of the distribution file to be downloaded from the
3791     package's website.
3793   * PKGNAME is the name of the package, as used by pkgsrc. You only need to
3794     provide it if DISTNAME (which is the default) is not a good name for the
3795     package in pkgsrc. Usually it is the pkgsrc directory name together with
3796     the version number. It must match the regular expression ^[A-Za-z0-9]
3797     [A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains
3798     only letters, digits, dashes, underscores, dots and plus signs.
3800   * SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't
3801     unique on a SVR4 system. The default is PKGNAME, which may be shortened
3802     when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not
3803     produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME
3804     is limited to 5 characters.
3806   * CATEGORIES is a list of categories which the package fits in. You can
3807     choose any of the top-level directories of pkgsrc for it.
3809     Currently the following values are available for CATEGORIES. If more than
3810     one is used, they need to be separated by spaces:
3812     archivers     cross         geography     meta-pkgs     security
3813     audio         databases     graphics      misc          shells
3814     benchmarks    devel         ham           multimedia    sysutils
3815     biology       editors       inputmethod   net           textproc
3816     cad           emulators     lang          news          time
3817     chat          finance       mail          parallel      wm
3818     comms         fonts         math          pkgtools      www
3819     converters    games         mbone         print         x11
3821   * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
3822     are discussed in detail in Section 17.5, "The fetch phase".
3824 The second section contains information about separately downloaded patches, if
3825 any.
3827   * PATCHFILES: Name(s) of additional files that contain distribution patches.
3828     There is no default. pkgsrc will look for them at PATCH_SITES. They will
3829     automatically be uncompressed before patching if the names end with .gz or
3830     .Z.
3832   * PATCH_SITES: Primary location(s) for distribution patch files (see
3833     PATCHFILES below) if not found locally.
3835 The third section contains the following variables.
3837   * MAINTAINER is the email address of the person who feels responsible for
3838     this package, and who is most likely to look at problems or questions
3839     regarding this package which have been reported with send-pr(1). Other
3840     developers may contact the MAINTAINER before making changes to the package,
3841     but are not required to do so. When packaging a new program, set MAINTAINER
3842     to yourself. If you really can't maintain the package for future updates,
3843     set it to <pkgsrc-users@NetBSD.org>.
3845   * OWNER should be used instead of MAINTAINER when you do not want other
3846     developers to update or change the package without contacting you first. A
3847     package Makefile should contain one of MAINTAINER or OWNER, but not both.
3849   * HOMEPAGE is a URL where users can find more information about the package.
3851   * COMMENT is a one-line description of the package (should not include the
3852     package name).
3854 Other variables that affect the build:
3856   * WRKSRC: The directory where the interesting distribution files of the
3857     package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
3858     most packages.
3860     If a package doesn't create a subdirectory for itself (most GNU software
3861     does, for instance), but extracts itself in the current directory, you
3862     should set WRKSRC=${WRKDIR}.
3864     If a package doesn't create a subdirectory with the name of DISTNAME but
3865     some different name, set WRKSRC to point to the proper name in ${WRKDIR},
3866     for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
3867     other examples.
3869     The name of the working directory created by pkgsrc is taken from the
3870     WRKDIR_BASENAME variable. By default, its value is work. If you want to use
3871     the same pkgsrc tree for building different kinds of binary packages, you
3872     can change the variable according to your needs. Two other variables handle
3873     common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
3874     defined in mk.conf, the first component of the host's name is attached to
3875     the directory name. If OBJMACHINE is defined, the platform name is
3876     attached, which might look like work.i386 or work.sparc.
3878 Please pay attention to the following gotchas:
3880   * Add MANCOMPRESSED if man pages are installed in compressed form by the
3881     package. For packages using BSD-style makefiles which honor MANZ, there is
3882     MANCOMPRESSED_IF_MANZ.
3884   * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
3886   * If the package installs any info files, see Section 19.6.7, "Packages
3887     installing info files".
3889 11.2. distinfo
3891 The distinfo file contains the message digest, or checksum, of each distfile
3892 needed for the package. This ensures that the distfiles retrieved from the
3893 Internet have not been corrupted during transfer or altered by a malign force
3894 to introduce a security hole. Due to recent rumor about weaknesses of digest
3895 algorithms, all distfiles are protected using both SHA1 and RMD160 message
3896 digests, as well as the file size.
3898 The distinfo file also contains the checksums for all the patches found in the
3899 patches directory (see Section 11.3, "patches/*").
3901 To regenerate the distinfo file, use the make makedistinfo or make mdi command.
3903 Some packages have different sets of distfiles depending on the platform, for
3904 example lang/openjdk7. These are kept in the same distinfo file and care should
3905 be taken when upgrading such a package to ensure distfile information is not
3906 lost.
3908 11.3. patches/*
3910 Many packages still don't work out-of-the box on the various platforms that are
3911 supported by pkgsrc. Therefore, a number of custom patch files are needed to
3912 make the package work. These patch files are found in the patches/ directory.
3914 In the patch phase, these patches are applied to the files in WRKSRC directory
3915 after extracting them, in alphabetic order.
3917 11.3.1. Structure of a single patch file
3919 The patch-* files should be in diff -bu format, and apply without a fuzz to
3920 avoid problems. (To force patches to apply with fuzz you can set
3921 PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
3922 a single file, and no file should be patched by more than one patch file. This
3923 helps to keep future modifications simple.
3925 Each patch file is structured as follows: In the first line, there is the RCS
3926 Id of the patch itself. The second line should be empty for aesthetic reasons.
3927 After that, there should be a comment for each change that the patch does.
3928 There are a number of standard cases:
3930   * Patches for commonly known vulnerabilities should mention the vulnerability
3931     ID (CAN, CVE).
3933   * Patches that change source code should mention the platform and other
3934     environment (for example, the compiler) that the patch is needed for.
3936 In all, the patch should be commented so that any developer who knows the code
3937 of the application can make some use of the patch. Special care should be taken
3938 for the upstream developers, since we generally want that they accept our
3939 patches, so we have less work in the future.
3941 11.3.2. Creating patch files
3943 One important thing to mention is to pay attention that no RCS IDs get stored
3944 in the patch files, as these will cause problems when later checked into the
3945 NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
3946 avoid these problems.
3948 For even more automation, we recommend using mkpatches from the same package to
3949 make a whole set of patches. You just have to backup files before you edit them
3950 to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using 
3951 pkgvi again from the same package. If you upgrade a package this way, you can
3952 easily compare the new set of patches with the previously existing one with 
3953 patchdiff. The files in patches are replaced by new files, so carefully check
3954 if you want to take all the changes.
3956 When you have finished a package, remember to generate the checksums for the
3957 patch files by using the make makepatchsum command, see Section 11.2,
3958 "distinfo".
3960 When adding a patch that corrects a problem in the distfile (rather than e.g.
3961 enforcing pkgsrc's view of where man pages should go), send the patch as a bug
3962 report to the maintainer. This benefits non-pkgsrc users of the package, and
3963 usually makes it possible to remove the patch in future version.
3965 The file names of the patch files are usually of the form patch-
3966 path_to_file__with__underscores.c. Many packages still use the previous
3967 convention patch-[a-z][a-z], but new patches should be of the form containing
3968 the filename. mkpatches included in pkgtools/pkgdiff takes care of the name
3969 automatically.
3971 11.3.3. Sources where the patch files come from
3973 If you want to share patches between multiple packages in pkgsrc, e.g. because
3974 they use the same distfiles, set PATCHDIR to the path where the patch files can
3975 be found, e.g.:
3977 PATCHDIR= ${.CURDIR}/../xemacs/patches
3979 Patch files that are distributed by the author or other maintainers can be
3980 listed in PATCHFILES.
3982 If it is desired to store any patches that should not be committed into pkgsrc,
3983 they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
3984 directory tree there is expected to have the same "category/package" structure
3985 as pkgsrc, and patches are expected to be stored inside these dirs (also known
3986 as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
3987 for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
3988 files in the named directory are expected to be patch files, and they are
3989 applied after pkgsrc patches are applied.
3991 11.3.4. Patching guidelines
3993 When fixing a portability issue in the code do not use preprocessor magic to
3994 check for the current operating system nor platform. Doing so hurts portability
3995 to other platforms because the OS-specific details are not abstracted
3996 appropriately.
3998 The general rule to follow is: instead of checking for the operating system the
3999 application is being built on, check for the specific features you need. For
4000 example, instead of assuming that kqueue is available under NetBSD and using
4001 the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
4002 kqueue itself ? yes, this generally involves patching the configure script.
4003 There is absolutely nothing that prevents some OSes from adopting interfaces
4004 from other OSes (e.g. Linux implementing kqueue), something that the above
4005 checks cannot take into account.
4007 Of course, checking for features generally involves more work on the
4008 developer's side, but the resulting changes are cleaner and there are chances
4009 they will work on many other platforms. Not to mention that there are higher
4010 chances of being later integrated into the mainstream sources. Remember: It
4011 doesn't work unless it is right!
4013 Some typical examples:
4015 Table 11.1. Patching examples
4017 +-------------------------------------------------------------------------------------------+
4018 |  Where  |        Incorrect         |                       Correct                        |
4019 |---------+--------------------------+------------------------------------------------------|
4020 |         |case ${target_os} in      |                                                      |
4021 |configure|netbsd*) have_kvm=yes ;;  |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)|
4022 |script   |*)       have_kvm=no  ;;  |                                                      |
4023 |         |esac                      |                                                      |
4024 |---------+--------------------------+------------------------------------------------------|
4025 |C source |#if defined(__NetBSD__)   |#if defined(HAVE_SYS_EVENT_H)                         |
4026 |file     |#  include <sys/event.h>  |#  include <sys/event.h>                              |
4027 |         |#endif                    |#endif                                                |
4028 |---------+--------------------------+------------------------------------------------------|
4029 |         |int                       |int                                                   |
4030 |         |monitor_file(...)         |monitor_file(...)                                     |
4031 |         |{                         |{                                                     |
4032 |         |#if defined(__NetBSD__)   |#if defined(HAVE_KQUEUE)                              |
4033 |C source |        int fd = kqueue();|        int fd = kqueue();                            |
4034 |file     |        ...               |        ...                                           |
4035 |         |#else                     |#else                                                 |
4036 |         |        ...               |        ...                                           |
4037 |         |#endif                    |#endif                                                |
4038 |         |}                         |}                                                     |
4039 +-------------------------------------------------------------------------------------------+
4042 For more information, please read the Making packager-friendly software article
4043 (part 1, part 2). It summarizes multiple details on how to make software easier
4044 to package; all the suggestions in it were collected from our experience in
4045 pkgsrc work, so they are possibly helpful when creating patches too.
4047 11.3.5. Feedback to the author
4049 Always, always, always feed back any portability fixes or improvements you do
4050 to a package to the mainstream developers. This is the only way to get their
4051 attention on portability issues and to ensure that future versions can be built
4052 out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will
4053 get the fixes straight from the packaged code.
4055 This generally involves cleaning up the patches (because sometimes the patches
4056 that are added to pkgsrc are quick hacks), filing bug reports in the
4057 appropriate trackers for the projects and working with the mainstream authors
4058 to accept your changes. It is extremely important that you do it so that the
4059 packages in pkgsrc are kept simple and thus further changes can be done without
4060 much hassle.
4062 When you have done this, please add a URL to the upstream bug report to the
4063 patch comment.
4065 Support the idea of free software!
4067 11.4. Other mandatory files
4069 DESCR
4071     A multi-line description of the piece of software. This should include any
4072     credits where they are due. Please bear in mind that others do not share
4073     your sense of humour (or spelling idiosyncrasies), and that others will
4074     read everything that you write here.
4076 PLIST
4078     This file governs the files that are installed on your system: all the
4079     binaries, manual pages, etc. There are other directives which may be
4080     entered in this file, to control the creation and deletion of directories,
4081     and the location of inserted files. See Chapter 13, PLIST issues for more
4082     information.
4084 11.5. Optional files
4086 11.5.1. Files affecting the binary package
4088 INSTALL
4090     This shell script is invoked twice by pkg_add(1). First time after package
4091     extraction and before files are moved in place, the second time after the
4092     files to install are moved in place. This can be used to do any custom
4093     procedures not possible with @exec commands in PLIST. See pkg_add(1) and
4094     pkg_create(1) for more information. See also Section 15.1, "Files and
4095     directories outside the installation prefix". Please note that you can
4096     modify variables in it easily by using FILES_SUBST in the package's
4097     Makefile:
4099     FILES_SUBST+=  SOMEVAR="somevalue"
4101     replaces "@SOMEVAR@" with "somevalue" in the INSTALL. By default,
4102     substitution is performed for PREFIX, LOCALBASE, X11BASE, VARBASE, and a
4103     few others, type make help topic=FILES_SUBST for a complete list.
4105 DEINSTALL
4107     This script is executed before and after any files are removed. It is this
4108     script's responsibility to clean up any additional messy details around the
4109     package's installation, since all pkg_delete knows is how to delete the
4110     files created in the original distribution. See pkg_delete(1) and
4111     pkg_create(1) for more information. The same methods to replace variables
4112     can be used as for the INSTALL file.
4114 MESSAGE
4116     This file is displayed after installation of the package. Useful for things
4117     like legal notices on almost-free software and hints for updating config
4118     files after installing modules for apache, PHP etc. Please note that you
4119     can modify variables in it easily by using MESSAGE_SUBST in the package's
4120     Makefile:
4122     MESSAGE_SUBST+=  SOMEVAR="somevalue"
4124     replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
4125     is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE,
4126     PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.
4128     You can display a different or additional files by setting the MESSAGE_SRC
4129     variable. Its default is MESSAGE, if the file exists.
4131 ALTERNATIVES
4133     FIXME: There is no documentation on the alternatives framework.
4135 11.5.2. Files affecting the build process
4137 Makefile.common
4139     This file contains arbitrary things that could also go into a Makefile, but
4140     its purpose is to be used by more than one package. This file should only
4141     be used when the packages that will use the file are known in advance. For
4142     other purposes it is often better to write a *.mk file and give it a good
4143     name that describes what it does.
4145 buildlink3.mk
4147     This file contains the dependency information for the buildlink3 framework
4148     (see Chapter 14, Buildlink methodology).
4150 hacks.mk
4152     This file contains workarounds for compiler bugs and similar things. It is
4153     included automatically by the pkgsrc infrastructure, so you don't need an
4154     extra .include line for it.
4156 options.mk
4158     This file contains the code for the package-specific options (see
4159     Chapter 16, Options handling) that can be selected by the user. If a
4160     package has only one or two options, it is equally acceptable to put the
4161     code directly into the Makefile.
4163 11.5.3. Files affecting nothing at all
4165 README*
4167     These files do not take place in the creation of a package and thus are
4168     purely informative to the package developer.
4170 TODO
4172     This file contains things that need to be done to make the package even
4173     better.
4175 11.6. work*
4177 When you type make, the distribution files are unpacked into the directory
4178 denoted by WRKDIR. It can be removed by running make clean. Besides the
4179 sources, this directory is also used to keep various timestamp files. The
4180 directory gets removed completely on clean. The default is ${.CURDIR}/work or $
4181 {.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
4183 11.7. files/*
4185 If you have any files that you wish to be placed in the package prior to
4186 configuration or building, you could place these files here and use a ${CP}
4187 command in the "pre-configure" target to achieve this. Alternatively, you could
4188 simply diff the file against /dev/null and use the patch mechanism to manage
4189 the creation of this file.
4191 If you want to share files in this way with other packages, set the FILESDIR
4192 variable to point to the other package's files directory, e.g.:
4194 FILESDIR=${.CURDIR}/../xemacs/files
4196 Chapter 12. Programming in Makefiles
4198 Table of Contents
4200 12.1. Caveats
4201 12.2. Makefile variables
4203     12.2.1. Naming conventions
4205 12.3. Code snippets
4207     12.3.1. Adding things to a list
4208     12.3.2. Converting an internal list into an external list
4209     12.3.3. Passing variables to a shell command
4210     12.3.4. Quoting guideline
4211     12.3.5. Workaround for a bug in BSD Make
4213 Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
4214 part of the pkgsrc system. Using the make(1) system as a programming language
4215 for a big system like pkgsrc requires some discipline to keep the code correct
4216 and understandable.
4218 The basic ingredients for Makefile programming are variables (which are
4219 actually macros) and shell commands. Among these shell commands may even be
4220 more complex ones like awk(1) programs. To make sure that every shell command
4221 runs as intended it is necessary to quote all variables correctly when they are
4222 used.
4224 This chapter describes some patterns, that appear quite often in Makefiles,
4225 including the pitfalls that come along with them.
4227 12.1. Caveats
4229   * When you are creating a file as a target of a rule, always write the data
4230     to a temporary file first and finally rename that file. Otherwise there
4231     might occur an error in the middle of generating the file, and when the
4232     user runs make(1) for the second time, the file exists and will not be
4233     regenerated properly. Example:
4235     wrong:
4236             @echo "line 1" > ${.TARGET}
4237             @echo "line 2" >> ${.TARGET}
4238             @false
4240     correct:
4241             @echo "line 1" > ${.TARGET}.tmp
4242             @echo "line 2" >> ${.TARGET}.tmp
4243             @false
4244             @mv ${.TARGET}.tmp ${.TARGET}
4246     When you run make wrong twice, the file wrong will exist, although there
4247     was an error message in the first run. On the other hand, running make
4248     correct gives an error message twice, as expected.
4250     You might remember that make(1) sometimes removes ${.TARGET} in case of
4251     error, but this only happens when it is interrupted, for example by
4252     pressing ^C. This does not happen when one of the commands fails (like
4253     false(1) above).
4255 12.2. Makefile variables
4257 Makefile variables contain strings that can be processed using the five
4258 operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
4259 make(1) man page.
4261 When a variable's value is parsed from a Makefile, the hash character ``#'' and
4262 the backslash character ``\'' are handled specially. If a backslash is followed
4263 by a newline, any whitespace immediately in front of the backslash, the
4264 backslash, the newline, and any whitespace immediately behind the newline are
4265 replaced with a single space. A backslash character and an immediately
4266 following hash character are replaced with a single hash character. Otherwise,
4267 the backslash is passed as is. In a variable assignment, any hash character
4268 that is not preceded by a backslash starts a comment that continues upto the
4269 end of the logical line.
4271 Note: Because of this parsing algorithm the only way to create a variable
4272 consisting of a single backslash is using the ``!='' operator, for example:
4273 BACKSLASH!=echo "\\".
4275 So far for defining variables. The other thing you can do with variables is
4276 evaluating them. A variable is evaluated when it is part of the right side of
4277 the ``:='' or the ``!='' operator, or directly before executing a shell command
4278 which the variable is part of. In all other cases, make(1) performs lazy
4279 evaluation, that is, variables are not evaluated until there's no other way.
4280 The ``modifiers'' mentioned in the man page also evaluate the variable.
4282 Some of the modifiers split the string into words and then operate on the
4283 words, others operate on the string as a whole. When a string is split into
4284 words, it is split as you would expect it from sh(1).
4286 No rule without exception?the .for loop does not follow the shell quoting rules
4287 but splits at sequences of whitespace.
4289 There are several types of variables that should be handled differently.
4290 Strings and two types of lists.
4292   * Strings can contain arbitrary characters. Nevertheless, you should restrict
4293     yourself to only using printable characters. Examples are PREFIX and
4294     COMMENT.
4296   * Internal lists are lists that are never exported to any shell command.
4297     Their elements are separated by whitespace. Therefore, the elements
4298     themselves cannot have embedded whitespace. Any other characters are
4299     allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
4300     BUILD_DEPENDS.
4302   * External lists are lists that may be exported to a shell command. Their
4303     elements can contain any characters, including whitespace. That's why they
4304     cannot be used in .for loops. Examples are DISTFILES and MASTER_SITES.
4306 12.2.1. Naming conventions
4308   * All variable names starting with an underscore are reserved for use by the
4309     pkgsrc infrastructure. They shall not be used by package Makefiles.
4311   * In .for loops you should use lowercase variable names for the iteration
4312     variables.
4314   * All list variables should have a ``plural'' name, e.g. PKG_OPTIONS or
4315     DISTFILES.
4317 12.3. Code snippets
4319 This section presents you with some code snippets you should use in your own
4320 code. If you don't find anything appropriate here, you should test your code
4321 and add it here.
4323 12.3.1. Adding things to a list
4325 STRING=                 foo * bar `date`
4326 INT_LIST=               # empty
4327 ANOTHER_INT_LIST=       apache-[0-9]*:../../www/apache
4328 EXT_LIST=               # empty
4329 ANOTHER_EXT_LIST=       a=b c=d
4331 INT_LIST+=              ${STRING}               # 1
4332 INT_LIST+=              ${ANOTHER_INT_LIST}     # 2
4333 EXT_LIST+=              ${STRING:Q}             # 3
4334 EXT_LIST+=              ${ANOTHER_EXT_LIST}     # 4
4336 When you add a string to an external list (example 3), it must be quoted. In
4337 all other cases, you must not add a quoting level. You must not merge internal
4338 and external lists, unless you are sure that all entries are correctly
4339 interpreted in both lists.
4341 12.3.2. Converting an internal list into an external list
4343 EXT_LIST=       # empty
4344 .for i in ${INT_LIST}
4345 EXT_LIST+=      ${i:Q}""
4346 .endfor
4348 This code converts the internal list INT_LIST into the external list EXT_LIST.
4349 As the elements of an internal list are unquoted they must be quoted here. The
4350 reason for appending "" is explained below.
4352 12.3.3. Passing variables to a shell command
4354 Sometimes you may want to print an arbitrary string. There are many ways to get
4355 it wrong and only few that can handle every nastiness.
4357 STRING=         foo bar <    > * `date` $$HOME ' "
4358 EXT_LIST=       string=${STRING:Q} x=second\ item
4360 all:
4361         echo ${STRING}                  # 1
4362         echo "${STRING}"                # 2
4363         echo "${STRING:Q}"              # 3
4364         echo ${STRING:Q}                # 4
4365         echo x${STRING:Q} | sed 1s,.,,  # 5
4366         printf "%s\\n" ${STRING:Q}""    # 6
4367         env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
4369 Example 1 leads to a syntax error in the shell, as the characters are just
4370 copied.
4372 Example 2 leads to a syntax error too, and if you leave out the last "
4373 character from ${STRING}, date(1) will be executed. The $HOME shell variable
4374 would be evaluated, too.
4376 Example 3 outputs each space character preceded by a backslash (or not),
4377 depending on the implementation of the echo(1) command.
4379 Example 4 handles correctly every string that does not start with a dash. In
4380 that case, the result depends on the implementation of the echo(1) command. As
4381 long as you can guarantee that your input does not start with a dash, this form
4382 is appropriate.
4384 Example 5 handles even the case of a leading dash correctly.
4386 Example 6 also works with every string and is the light-weight solution, since
4387 it does not involve a pipe, which has its own problems.
4389 The EXT_LIST does not need to be quoted because the quoting has already been
4390 done when adding elements to the list.
4392 As internal lists shall not be passed to the shell, there is no example for it.
4394 12.3.4. Quoting guideline
4396 There are many possible sources of wrongly quoted variables. This section lists
4397 some of the commonly known ones.
4399   * Whenever you use the value of a list, think about what happens to leading
4400     or trailing whitespace. If the list is a well-formed shell expression, you
4401     can apply the :M* modifier to strip leading and trailing whitespace from
4402     each word. The :M operator first splits its argument according to the rules
4403     of the shell, and then creates a new list consisting of all words that
4404     match the shell glob expression *, that is: all. One class of situations
4405     where this is needed is when adding a variable like CPPFLAGS to
4406     CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
4407     strips the leading and trailing whitespace from the variable and then
4408     passes it to the other configure scripts. But these configure scripts
4409     expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
4410     That's why we better pass the CPPFLAGS value properly trimmed. And here is
4411     how we do it:
4413     CPPFLAGS=               # empty
4414     CPPFLAGS+=              -Wundef -DPREFIX=\"${PREFIX:Q}\"
4415     CPPFLAGS+=              ${MY_CPPFLAGS}
4417     CONFIGURE_ARGS+=        CPPFLAGS=${CPPFLAGS:M*:Q}
4419     all:
4420             echo x${CPPFLAGS:Q}x            # leading and trailing whitespace
4421             echo x${CONFIGURE_ARGS}x        # properly trimmed
4423   * The example above contains one bug: The ${PREFIX} is a properly quoted
4424     shell expression, but there is the C compiler after it, which also expects
4425     a properly quoted string (this time in C syntax). The version above is
4426     therefore only correct if ${PREFIX} does not have embedded backslashes or
4427     double quotes. If you want to allow these, you have to add another layer of
4428     quoting to each variable that is used as a C string literal. You cannot use
4429     the :Q operator for it, as this operator only works for the shell.
4431   * Whenever a variable can be empty, the :Q operator can have surprising
4432     results. Here are two completely different cases which can be solved with
4433     the same trick.
4435     EMPTY=                  # empty
4436     empty_test:
4437             for i in a ${EMPTY:Q} c; do \
4438                 echo "$$i"; \
4439             done
4441     for_test:
4442     .for i in a:\ a:\test.txt
4443             echo ${i:Q}
4444             echo "foo"
4445     .endfor
4447     The first example will only print two of the three lines we might have
4448     expected. This is because ${EMPTY:Q} expands to the empty string, which the
4449     shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
4450     be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
4451     these are wrong).
4453     The second example will only print three lines instead of four. The first
4454     line looks like a:\ echo foo. This is because the backslash of the value a:
4455     \ is interpreted as a line-continuation by make(1), which makes the second
4456     line the arguments of the echo(1) command from the first line. To avoid
4457     this, write ${i:Q}"".
4459 12.3.5. Workaround for a bug in BSD Make
4461 The pkgsrc bmake program does not handle the following assignment correctly. In
4462 case _othervar_ contains a ``-'' character, one of the closing braces is
4463 included in ${VAR} after this code executes.
4465 VAR:=   ${VAR:N${_othervar_:C/-//}}
4467 For a more complex code snippet and a workaround, see the package regress/
4468 make-quoting, testcase bug1.
4470 Chapter 13. PLIST issues
4472 Table of Contents
4474 13.1. RCS ID
4475 13.2. Semi-automatic PLIST generation
4476 13.3. Tweaking output of make print-PLIST
4477 13.4. Variable substitution in PLIST
4478 13.5. Man page compression
4479 13.6. Changing PLIST source with PLIST_SRC
4480 13.7. Platform-specific and differing PLISTs
4481 13.8. Sharing directories between packages
4483 The PLIST file contains a package's "packing list", i.e. a list of files that
4484 belong to the package (relative to the ${PREFIX} directory it's been installed
4485 in) plus some additional statements - see the pkg_create(1) man page for a full
4486 list. This chapter addresses some issues that need attention when dealing with
4487 the PLIST file (or files, see below!).
4489 13.1. RCS ID
4491 Be sure to add a RCS ID line as the first thing in any PLIST file you write:
4493 @comment $NetBSD$
4496 13.2. Semi-automatic PLIST generation
4498 You can use the make print-PLIST command to output a PLIST that matches any new
4499 files since the package was extracted. See Section 17.17, "Other helpful
4500 targets" for more information on this target.
4502 13.3. Tweaking output of make print-PLIST
4504 If you have used any of the *-dirs packages, as explained in Section 13.8,
4505 "Sharing directories between packages", you may have noticed that make
4506 print-PLIST outputs a set of @comments instead of real @dirrm lines. You can
4507 also do this for specific directories and files, so that the results of that
4508 command are very close to reality. This helps a lot during the update of
4509 packages.
4511 The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
4512 used to filter the output of print-PLIST. You can append any chunk of AWK
4513 scripting you like to it, but be careful with quoting.
4515 For example, to get all files inside the libdata/foo directory removed from the
4516 resulting PLIST:
4518 PRINT_PLIST_AWK+=       /^libdata\/foo/ { next; }
4521 And to get all the @dirrm lines referring to a specific (shared) directory
4522 converted to @comments:
4524 PRINT_PLIST_AWK+=       /^@dirrm share\/specific/ { print "@comment " $$0; next; }
4527 13.4. Variable substitution in PLIST
4529 A number of variables are substituted automatically in PLISTs when a package is
4530 installed on a system. This includes the following variables:
4532 ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
4534     Some packages like emacs and perl embed information about which
4535     architecture they were built on into the pathnames where they install their
4536     files. To handle this case, PLIST will be preprocessed before actually
4537     used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
4538     gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
4539     PLIST somewhere - use this on packages that have GNU autoconf-created
4540     configure scripts.
4542     Legacy note
4544     There used to be a symbol "$ARCH" that was replaced by the output of uname
4545     -m, but that's no longer supported and has been removed.
4547 ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
4549     Some packages want to embed the OS name and version into some paths. To do
4550     this, use these variables in the PLIST:
4552       + ${OPSYS} - output of "uname -s"
4554       + ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
4556       + ${OS_VERSION} - "uname -r"
4558 For a complete list of values which are replaced by default, please look in
4559 bsd.pkg.mk (and search for PLIST_SUBST).
4561 If you want to change other variables not listed above, you can add variables
4562 and their expansions to this variable in the following way, similar to
4563 MESSAGE_SUBST (see Section 11.5, "Optional files"):
4565 PLIST_SUBST+=   SOMEVAR="somevalue"
4568 This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".
4570 The PLIST_VARS variable can be used to simplify the common case of
4571 conditionally including some PLIST entries. It can be done by adding
4572 PLIST_VARS+=foo and setting the corresponding PLIST.foo variable to yes if the
4573 entry should be included. This will substitute "${PLIST.foo}" in the PLIST with
4574 either """" or ""@comment "". For example, in Makefile:
4576 PLIST_VARS+=    foo
4577 .if condition
4578 PLIST.foo=      yes
4579 .else
4582 And then in PLIST:
4584 @comment $NetBSD$
4585 bin/bar
4586 man/man1/bar.1
4587 ${PLIST.foo}bin/foo
4588 ${PLIST.foo}man/man1/foo.1
4589 ${PLIST.foo}share/bar/foo.data
4590 ${PLIST.foo}@dirrm share/bar
4593 13.5. Man page compression
4595 Man pages should be installed in compressed form if MANZ is set (in
4596 bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
4597 suffix ".gz" is appended/removed automatically for man pages according to MANZ
4598 and MANCOMPRESSED being set or not, see above for details. This modification of
4599 the PLIST file is done on a copy of it, not PLIST itself.
4601 13.6. Changing PLIST source with PLIST_SRC
4603 To use one or more files as source for the PLIST used in generating the binary
4604 package, set the variable PLIST_SRC to the names of that file(s). The files are
4605 later concatenated using cat(1), and the order of things is important. The
4606 default for PLIST_SRC is ${PKGDIR}/PLIST.
4608 13.7. Platform-specific and differing PLISTs
4610 Some packages decide to install a different set of files based on the operating
4611 system being used. These differences can be automatically handled by using the
4612 following files:
4614   * PLIST.common
4616   * PLIST.${OPSYS}
4618   * PLIST.${MACHINE_ARCH}
4620   * PLIST.${OPSYS}-${MACHINE_ARCH}
4622   * PLIST.common_end
4624 13.8. Sharing directories between packages
4626 A "shared directory" is a directory where multiple (and unrelated) packages
4627 install files. These directories were problematic because you had to add
4628 special tricks in the PLIST to conditionally remove them, or have some
4629 centralized package handle them.
4631 In pkgsrc, it is now easy: Each package should create directories and install
4632 files as needed; pkg_delete will remove any directories left empty after
4633 uninstalling a package.
4635 If a package needs an empty directory to work, create the directory during
4636 installation as usual, and also add an entry to the PLIST:
4638 @pkgdir path/to/empty/directory
4641 Chapter 14. Buildlink methodology
4643 Table of Contents
4645 14.1. Converting packages to use buildlink3
4646 14.2. Writing buildlink3.mk files
4648     14.2.1. Anatomy of a buildlink3.mk file
4649     14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.pkg in
4650         buildlink3.mk files
4652 14.3. Writing builtin.mk files
4654     14.3.1. Anatomy of a builtin.mk file
4655     14.3.2. Global preferences for native or pkgsrc software
4657 Buildlink is a framework in pkgsrc that controls what headers and libraries are
4658 seen by a package's configure and build processes. This is implemented in a two
4659 step process:
4661  1. Symlink headers and libraries for dependencies into BUILDLINK_DIR, which by
4662     default is a subdirectory of WRKDIR.
4664  2. Create wrapper scripts that are used in place of the normal compiler tools
4665     that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib into
4666     references to BUILDLINK_DIR. The wrapper scripts also make native compiler
4667     on some operating systems look like GCC, so that packages that expect GCC
4668     won't require modifications to build with those native compilers.
4670 This normalizes the environment in which a package is built so that the package
4671 may be built consistently despite what other software may be installed. Please
4672 note that the normal system header and library paths, e.g. /usr/include, /usr/
4673 lib, etc., are always searched -- buildlink3 is designed to insulate the
4674 package build from non-system-supplied software.
4676 14.1. Converting packages to use buildlink3
4678 The process of converting packages to use the buildlink3 framework ("bl3ifying"
4679 ) is fairly straightforward. The things to keep in mind are:
4681  1. Ensure that the build always calls the wrapper scripts instead of the
4682     actual toolchain. Some packages are tricky, and the only way to know for
4683     sure is the check ${WRKDIR}/.work.log to see if the wrappers are being
4684     invoked.
4686  2. Don't override PREFIX from within the package Makefile, e.g. Java VMs,
4687     standalone shells, etc., because the code to symlink files into $
4688     {BUILDLINK_DIR} looks for files relative to "pkg_info -qp pkgname".
4690  3. Remember that only the buildlink3.mk files that you list in a package's
4691     Makefile are added as dependencies for that package.
4693 If a dependency on a particular package is required for its libraries and
4694 headers, then we replace:
4696 DEPENDS+=       foo>=1.1.0:../../category/foo
4698 with
4700 .include "../../category/foo/buildlink3.mk"
4702 The buildlink3.mk files usually define the required dependencies. If you need a
4703 newer version of the dependency when using buildlink3.mk files, then you can
4704 define it in your Makefile; for example:
4706 BUILDLINK_API_DEPENDS.foo+=   foo>=1.1.0
4707 .include "../../category/foo/buildlink3.mk"
4709 There are several buildlink3.mk files in pkgsrc/mk that handle special package
4710 issues:
4712   * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
4713     implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.
4715   * curses.buildlink3.mk: If the system comes with neither Curses nor NCurses,
4716     this will take care to install the devel/ncurses package.
4718   * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding
4719     a dependency on Heimdal or MIT-krb5 for packages that require a Kerberos 5
4720     implementation.
4722   * motif.buildlink3.mk checks for a system-provided Motif installation or adds
4723     a dependency on x11/lesstif, x11/motif or x11/openmotif. The user can set
4724     MOTIF_TYPE to "dt", "lesstif", "motif" or "openmotif" to choose which Motif
4725     version will be used.
4727   * oss.buildlink3.mk defines several variables that may be used by packages
4728     that use the Open Sound System (OSS) API.
4730   * pgsql.buildlink3.mk will accept any of the Postgres versions in the
4731     variable PGSQL_VERSIONS_ACCEPTED and default to the version
4732     PGSQL_VERSION_DEFAULT. See the file for more information.
4734   * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native
4735     pthreads or adds a dependency on devel/pth as needed.
4737   * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena
4738     widgets library.
4740 The comments in those buildlink3.mk files provide a more complete description
4741 of how to use them properly.
4743 14.2. Writing buildlink3.mk files
4745 A package's buildlink3.mk file is included by Makefiles to indicate the need to
4746 compile and link against header files and libraries provided by the package. A
4747 buildlink3.mk file should always provide enough information to add the correct
4748 type of dependency relationship and include any other buildlink3.mk files that
4749 it needs to find headers and libraries that it needs in turn.
4751 To generate an initial buildlink3.mk file for further editing, Rene Hexel's
4752 pkgtools/createbuildlink package is highly recommended. For most packages, the
4753 following command will generate a good starting point for buildlink3.mk files:
4755 % cd pkgsrc/category/pkgdir
4756 % createbuildlink >buildlink3.mk
4759 14.2.1. Anatomy of a buildlink3.mk file
4761 The following real-life example buildlink3.mk is taken from pkgsrc/graphics/
4762 tiff:
4764 # $NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp $
4766 BUILDLINK_TREE+=        tiff
4768 .if !defined(TIFF_BUILDLINK3_MK)
4769 TIFF_BUILDLINK3_MK:=
4771 BUILDLINK_API_DEPENDS.tiff+=    tiff>=3.6.1
4772 BUILDLINK_ABI_DEPENDS.tiff+=    tiff>=3.7.2nb1
4773 BUILDLINK_PKGSRCDIR.tiff?=      ../../graphics/tiff
4775 .include "../../devel/zlib/buildlink3.mk"
4776 .include "../../graphics/jpeg/buildlink3.mk"
4777 .endif # TIFF_BUILDLINK3_MK
4779 BUILDLINK_TREE+=        -tiff
4781 The header and footer manipulate BUILDLINK_TREE, which is common across all
4782 buildlink3.mk files and is used to track the dependency tree.
4784 The main section is protected from multiple inclusion and controls how the
4785 dependency on pkg is added. Several important variables are set in the section:
4787   * BUILDLINK_API_DEPENDS.pkg is the actual dependency recorded in the
4788     installed package; this should always be set using += to ensure that we're
4789     appending to any pre-existing list of values. This variable should be set
4790     to the first version of the package that had an backwards-incompatible API
4791     change.
4793   * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory.
4795   * BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
4796     BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
4797     is selected by setting BUILDLINK_DEPMETHOD.pkg to "build". By default, the
4798     full dependency is used.
4800   * BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS.pkg (not shown above) are lists
4801     of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and
4802     library search paths. These default to "include" and "lib" respectively.
4804   * BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags
4805     to add to CPPFLAGS, which are passed on to the configure and build phases.
4806     The "-I" option should be avoided and instead be handled using
4807     BUILDLINK_INCDIRS.pkg as above.
4809 The following variables are all optionally defined within this second section
4810 (protected against multiple inclusion) and control which package files are
4811 symlinked into ${BUILDLINK_DIR} and how their names are transformed during the
4812 symlinking:
4814   * BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to $
4815     {BUILDLINK_PREFIX.pkg} to be symlinked into ${BUILDLINK_DIR}, e.g. include/
4816     *.h.
4818   * BUILDLINK_FILES_CMD.pkg (not shown above) is a shell pipeline that outputs
4819     to stdout a list of files relative to ${BUILDLINK_PREFIX.pkg}. The
4820     resulting files are to be symlinked into ${BUILDLINK_DIR}. By default, this
4821     takes the +CONTENTS of a pkg and filters it through $
4822     {BUILDLINK_CONTENTS_FILTER.pkg}.
4824   * BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that
4825     filters +CONTENTS input into a list of files relative to $
4826     {BUILDLINK_PREFIX.pkg} on stdout. By default for overwrite packages,
4827     BUILDLINK_CONTENTS_FILTER.pkg outputs the contents of the include and lib
4828     directories in the package +CONTENTS, and for pkgviews packages, it outputs
4829     any libtool archives in lib directories.
4831   * BUILDLINK_FNAME_TRANSFORM.pkg (not shown above) is a list of sed arguments
4832     used to transform the name of the source filename into a destination
4833     filename, e.g. -e "s|/curses.h|/ncurses.h|g".
4835 This section can additionally include any buildlink3.mk needed for pkg's
4836 library dependencies. Including these buildlink3.mk files means that the
4837 headers and libraries for these dependencies are also symlinked into $
4838 {BUILDLINK_DIR} whenever the pkg buildlink3.mk file is included. Dependencies
4839 are only added for directly include buildlink3.mk files.
4841 When providing a buildlink3.mk and including other buildlink3.mk files in it,
4842 please only add necessary ones, i.e., those whose libraries or header files are
4843 automatically exposed when the package is use.
4845 In particular, if only an executable (bin/foo) is linked against a library,
4846 that library does not need to be propagated in the buildlink3.mk file.
4848 The following steps should help you decide if a buildlink3.mk file needs to be
4849 included:
4851   * Look at the installed header files: What headers do they include? The
4852     packages providing these files must be buildlinked.
4854   * Run ldd on all installed libraries and look against what other libraries
4855     they link. Some of the packages providing these probably need to be
4856     buildlinked; however, it's not automatic, since e.g. GTK on some systems
4857     pulls in the X libraries, so they will show up in the ldd output, while on
4858     others (like OS X) it won't. ldd output can thus only be used as a hint.
4860 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.pkg in
4861 buildlink3.mk files
4863 These two variables differ in that one describes source compatibility (API) and
4864 the other binary compatibility (ABI). The difference is that a change in the
4865 API breaks compilation of programs while changes in the ABI stop compiled
4866 programs from running.
4868 Changes to the BUILDLINK_API_DEPENDS.pkg variable in a buildlink3.mk file
4869 happen very rarely. One possible reason is that all packages depending on this
4870 already need a newer version. In case it is bumped see the description below.
4872 The most common example of an ABI change is that the major version of a shared
4873 library is increased. In this case, BUILDLINK_ABI_DEPENDS.pkg should be
4874 adjusted to require at least the new package version. Then the packages that
4875 depend on this package need their PKGREVISIONs increased and, if they have
4876 buildlink3.mk files, their BUILDLINK_ABI_DEPENDS.pkg adjusted, too. This is
4877 needed so pkgsrc will require the correct package dependency and not settle for
4878 an older one when building the source.
4880 See Section 19.1.6, "Handling dependencies" for more information about
4881 dependencies on other packages, including the BUILDLINK_ABI_DEPENDS and
4882 ABI_DEPENDS definitions.
4884 Please take careful consideration before adjusting BUILDLINK_API_DEPENDS.pkg or
4885 BUILDLINK_ABI_DEPENDS.pkg as we don't want to cause unneeded package deletions
4886 and rebuilds. In many cases, new versions of packages work just fine with older
4887 dependencies.
4889 Also it is not needed to set BUILDLINK_ABI_DEPENDS.pkg when it is identical to
4890 BUILDLINK_API_DEPENDS.pkg.
4892 14.3. Writing builtin.mk files
4894 Some packages in pkgsrc install headers and libraries that coincide with
4895 headers and libraries present in the base system. Aside from a buildlink3.mk
4896 file, these packages should also include a builtin.mk file that includes the
4897 necessary checks to decide whether using the built-in software or the pkgsrc
4898 software is appropriate.
4900 The only requirements of a builtin.mk file for pkg are:
4902  1. It should set USE_BUILTIN.pkg to either "yes" or "no" after it is included.
4904  2. It should not override any USE_BUILTIN.pkg which is already set before the
4905     builtin.mk file is included.
4907  3. It should be written to allow multiple inclusion. This is very important
4908     and takes careful attention to Makefile coding.
4910 14.3.1. Anatomy of a builtin.mk file
4912 The following is the recommended template for builtin.mk files:
4914 .if !defined(IS_BUILTIN.foo)
4916 # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
4917 # genuinely exists in the system or not.
4919 IS_BUILTIN.foo?=        no
4921 # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
4922 # version can be determined.
4924 .  if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
4925 BUILTIN_PKG.foo?=       foo-1.0
4926 .  endif
4927 .endif  # IS_BUILTIN.foo
4929 .if !defined(USE_BUILTIN.foo)
4930 USE_BUILTIN.foo?=       ${IS_BUILTIN.foo}
4931 .  if defined(BUILTIN_PKG.foo)
4932 .    for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
4933 .      if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
4934 USE_BUILTIN.foo!=                                                       \
4935         ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}            \
4936         && ${ECHO} "yes" || ${ECHO} "no"
4937 .      endif
4938 .    endfor
4939 .  endif
4940 .endif  # USE_BUILTIN.foo
4942 CHECK_BUILTIN.foo?=     no
4943 .if !empty(CHECK_BUILTIN.foo:M[nN][oO])
4945 # Here we place code that depends on whether USE_BUILTIN.foo is set to
4946 # "yes" or "no".
4948 .endif  # CHECK_BUILTIN.foo
4950 The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the
4951 base system. This should not be a base system software with similar
4952 functionality to pkg; it should only be "yes" if the actual package is included
4953 as part of the base system. This variable is only used internally within the
4954 builtin.mk file.
4956 The second section sets BUILTIN_PKG.pkg to the version of pkg in the base
4957 system if it exists (if IS_BUILTIN.pkg is "yes"). This variable is only used
4958 internally within the builtin.mk file.
4960 The third section sets USE_BUILTIN.pkg and is required in all builtin.mk files.
4961 The code in this section must make the determination whether the built-in
4962 software is adequate to satisfy the dependencies listed in
4963 BUILDLINK_API_DEPENDS.pkg. This is typically done by comparing BUILTIN_PKG.pkg
4964 against each of the dependencies in BUILDLINK_API_DEPENDS.pkg. USE_BUILTIN.pkg 
4965 must be set to the correct value by the end of the builtin.mk file. Note that
4966 USE_BUILTIN.pkg may be "yes" even if IS_BUILTIN.pkg is "no" because we may make
4967 the determination that the built-in version of the software is similar enough
4968 to be used as a replacement.
4970 The last section is guarded by CHECK_BUILTIN.pkg, and includes code that uses
4971 the value of USE_BUILTIN.pkg set in the previous section. This typically
4972 includes, e.g., adding additional dependency restrictions and listing
4973 additional files to symlink into ${BUILDLINK_DIR} (via BUILDLINK_FILES.pkg).
4975 14.3.2. Global preferences for native or pkgsrc software
4977 When building packages, it's possible to choose whether to set a global
4978 preference for using either the built-in (native) version or the pkgsrc version
4979 of software to satisfy a dependency. This is controlled by setting
4980 PREFER_PKGSRC and PREFER_NATIVE. These variables take values of either "yes", "
4981 no", or a list of packages. PREFER_PKGSRC tells pkgsrc to use the pkgsrc
4982 versions of software, while PREFER_NATIVE tells pkgsrc to use the built-in
4983 versions. Preferences are determined by the most specific instance of the
4984 package in either PREFER_PKGSRC or PREFER_NATIVE. If a package is specified in
4985 neither or in both variables, then PREFER_PKGSRC has precedence over
4986 PREFER_NATIVE. For example, to require using pkgsrc versions of software for
4987 all but the most basic bits on a NetBSD system, you can set:
4989 PREFER_PKGSRC=  yes
4990 PREFER_NATIVE=  getopt skey tcp_wrappers
4992 A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise
4993 it is simply ignored in that list.
4995 Chapter 15. The pkginstall framework
4997 Table of Contents
4999 15.1. Files and directories outside the installation prefix
5001     15.1.1. Directory manipulation
5002     15.1.2. File manipulation
5004 15.2. Configuration files
5006     15.2.1. How PKG_SYSCONFDIR is set
5007     15.2.2. Telling the software where configuration files are
5008     15.2.3. Patching installations
5009     15.2.4. Disabling handling of configuration files
5011 15.3. System startup scripts
5013     15.3.1. Disabling handling of system startup scripts
5015 15.4. System users and groups
5016 15.5. System shells
5018     15.5.1. Disabling shell registration
5020 15.6. Fonts
5022     15.6.1. Disabling automatic update of the fonts databases
5024 This chapter describes the framework known as pkginstall, whose key features
5025 are:
5027   * Generic installation and manipulation of directories and files outside the
5028     pkgsrc-handled tree, LOCALBASE.
5030   * Automatic handling of configuration files during installation, provided
5031     that packages are correctly designed.
5033   * Generation and installation of system startup scripts.
5035   * Registration of system users and groups.
5037   * Registration of system shells.
5039   * Automatic updating of fonts databases.
5041 The following sections inspect each of the above points in detail.
5043 You may be thinking that many of the things described here could be easily done
5044 with simple code in the package's post-installation target (post-install). This
5045 is incorrect, as the code in them is only executed when building from source.
5046 Machines using binary packages could not benefit from it at all (as the code
5047 itself could be unavailable). Therefore, the only way to achieve any of the
5048 items described above is by means of the installation scripts, which are
5049 automatically generated by pkginstall.
5051 15.1. Files and directories outside the installation prefix
5053 As you already know, the PLIST file holds a list of files and directories that
5054 belong to a package. The names used in it are relative to the installation
5055 prefix (${PREFIX}), which means that it cannot register files outside this
5056 directory (absolute path names are not allowed). Despite this restriction, some
5057 packages need to install files outside this location; e.g., under ${VARBASE} or
5058 ${PKG_SYSCONFDIR}. The only way to achieve this is to create such files during
5059 installation time by using installation scripts.
5061 The generic installation scripts are shell scripts that can contain arbitrary
5062 code. The list of scripts to execute is taken from the INSTALL_FILE variable,
5063 which defaults to INSTALL. A similar variable exists for package removal
5064 (DEINSTALL_FILE, whose default is DEINSTALL). These scripts can run arbitrary
5065 commands, so they have the potential to create and manage files anywhere in the
5066 file system.
5068 Using these general installation files is not recommended, but may be needed in
5069 some special cases. One reason for avoiding them is that the user has to trust
5070 the packager that there is no unwanted or simply erroneous code included in the
5071 installation script. Also, previously there were many similar scripts for the
5072 same functionality, and fixing a common error involved finding and changing all
5073 of them.
5075 The pkginstall framework offers another, standardized way. It provides generic
5076 scripts to abstract the manipulation of such files and directories based on
5077 variables set in the package's Makefile. The rest of this section describes
5078 these variables.
5080 15.1.1. Directory manipulation
5082 The following variables can be set to request the creation of directories
5083 anywhere in the file system:
5085   * MAKE_DIRS and OWN_DIRS contain a list of directories that should be created
5086     and should attempt to be destroyed by the installation scripts. The
5087     difference between the two is that the latter prompts the administrator to
5088     remove any directories that may be left after deinstallation (because they
5089     were not empty), while the former does not.
5091   * MAKE_DIRS_PERMS and OWN_DIRS_PERMS contain a list of tuples describing
5092     which directories should be created and should attempt to be destroyed by
5093     the installation scripts. Each tuple holds the following values, separated
5094     by spaces: the directory name, its owner, its group and its numerical mode.
5095     For example:
5097     MAKE_DIRS_PERMS+=         ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
5099     The difference between the two is exactly the same as their non-PERMS
5100     counterparts.
5102 15.1.2. File manipulation
5104 Creating non-empty files outside the installation prefix is tricky because the
5105 PLIST forces all files to be inside it. To overcome this problem, the only
5106 solution is to extract the file in the known place (i.e., inside the
5107 installation prefix) and copy it to the appropriate location during
5108 installation (done by the installation scripts generated by pkginstall). We
5109 will call the former the master file in the following paragraphs, which
5110 describe the variables that can be used to automatically and consistently
5111 handle files outside the installation prefix:
5113   * CONF_FILES and REQD_FILES are pairs of master and target files. During
5114     installation time, the master file is copied to the target one if and only
5115     if the latter does not exist. Upon deinstallation, the target file is
5116     removed provided that it was not modified by the installation.
5118     The difference between the two is that the latter prompts the administrator
5119     to remove any files that may be left after deinstallation (because they
5120     were not empty), while the former does not.
5122   * CONF_FILES_PERMS and REQD_FILES_PERMS contain tuples describing master
5123     files as well as their target locations. For each of them, it also
5124     specifies their owner, their group and their numeric permissions, in this
5125     order. For example:
5127     REQD_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
5129     The difference between the two is exactly the same as their non-PERMS
5130     counterparts.
5132 15.2. Configuration files
5134 Configuration files are special in the sense that they are installed in their
5135 own specific directory, PKG_SYSCONFDIR, and need special treatment during
5136 installation (most of which is automated by pkginstall). The main concept you
5137 must bear in mind is that files marked as configuration files are automatically
5138 copied to the right place (somewhere inside PKG_SYSCONFDIR) during installation
5139 if and only if they didn't exist before. Similarly, they will not be removed if
5140 they have local modifications. This ensures that administrators never lose any
5141 custom changes they may have made.
5143 15.2.1. How PKG_SYSCONFDIR is set
5145 As said before, the PKG_SYSCONFDIR variable specifies where configuration files
5146 shall be installed. Its contents are set based upon the following variables:
5148   * PKG_SYSCONFBASE: The configuration's root directory. Defaults to ${PREFIX}/
5149     etc although it may be overridden by the user to point to his preferred
5150     location (e.g., /etc, /etc/pkg, etc.). Packages must not use it directly.
5152   * PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the
5153     configuration files for the package being built shall be installed. The
5154     definition of this variable only makes sense in the package's Makefile
5155     (i.e., it is not user-customizable).
5157     As an example, consider the Apache package, www/apache2, which places its
5158     configuration files under the httpd/ subdirectory of PKG_SYSCONFBASE. This
5159     should be set in the package Makefile.
5161   * PKG_SYSCONFVAR: Specifies the name of the variable that holds this
5162     package's configuration directory (if different from PKG_SYSCONFBASE). It
5163     defaults to PKGBASE's value, and is always prefixed with PKG_SYSCONFDIR.
5165   * PKG_SYSCONFDIR.${PKG_SYSCONFVAR}: Holds the directory where the
5166     configuration files for the package identified by PKG_SYSCONFVAR's shall be
5167     placed.
5169 Based on the above variables, pkginstall determines the value of
5170 PKG_SYSCONFDIR, which is the only variable that can be used within a package to
5171 refer to its configuration directory. The algorithm used to set its value is
5172 basically the following:
5174  1. If PKG_SYSCONFDIR.${PKG_SYSCONFVAR} is set, its value is used.
5176  2. If the previous variable is not defined but PKG_SYSCONFSUBDIR is set in the
5177     package's Makefile, the resulting value is ${PKG_SYSCONFBASE}/$
5178     {PKG_SYSCONFSUBDIR}.
5180  3. Otherwise, it is set to ${PKG_SYSCONFBASE}.
5182 It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
5183 OWN_DIRS. See Section 15.1.1, "Directory manipulation" what this means. This
5184 does not apply to subdirectories of ${PKG_SYSCONFDIR}, they still have to be
5185 created with OWN_DIRS or MAKE_DIRS.
5187 15.2.2. Telling the software where configuration files are
5189 Given that pkgsrc (and users!) expect configuration files to be in a known
5190 place, you need to teach each package where it shall install its files. In some
5191 cases you will have to patch the package Makefiles to achieve it. If you are
5192 lucky, though, it may be as easy as passing an extra flag to the configuration
5193 script; this is the case of GNU Autoconf- generated files:
5195 CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
5197 Note that this specifies where the package has to look for its configuration
5198 files, not where they will be originally installed (although the difference is
5199 never explicit, unfortunately).
5201 15.2.3. Patching installations
5203 As said before, pkginstall automatically handles configuration files. This
5204 means that the packages themselves must not touch the contents of $
5205 {PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts
5206 will, out of the box, mess with the contents of that directory. So what is the
5207 correct procedure to fix this issue?
5209 You must teach the package (usually by manually patching it) to install any
5210 configuration files under the examples hierarchy, share/examples/${PKGBASE}/.
5211 This way, the PLIST registers them and the administrator always has the
5212 original copies available.
5214 Once the required configuration files are in place (i.e., under the examples
5215 hierarchy), the pkginstall framework can use them as master copies during the
5216 package installation to update what is in ${PKG_SYSCONFDIR}. To achieve this,
5217 the variables CONF_FILES and CONF_FILES_PERMS are used. Check out
5218 Section 15.1.2, "File manipulation" for information about their syntax and
5219 their purpose. Here is an example, taken from the mail/mutt package:
5221 EGDIR=        ${PREFIX}/share/doc/mutt/samples
5222 CONF_FILES=   ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
5224 Note that the EGDIR variable is specific to that package and has no meaning
5225 outside it.
5227 15.2.4. Disabling handling of configuration files
5229 The automatic copying of config files can be toggled by setting the environment
5230 variable PKG_CONFIG prior to package installation.
5232 15.3. System startup scripts
5234 System startup scripts are special files because they must be installed in a
5235 place known by the underlying OS, usually outside the installation prefix.
5236 Therefore, the same rules described in Section 15.1, "Files and directories
5237 outside the installation prefix" apply, and the same solutions can be used.
5238 However, pkginstall provides a special mechanism to handle these files.
5240 In order to provide system startup scripts, the package has to:
5242  1. Store the script inside ${FILESDIR}, with the .sh suffix appended.
5243     Considering the print/cups package as an example, it has a cupsd.sh in its
5244     files directory.
5246  2. Tell pkginstall to handle it, appending the name of the script, without its
5247     extension, to the RCD_SCRIPTS variable. Continuing the previous example:
5249     RCD_SCRIPTS+=   cupsd
5251 Once this is done, pkginstall will do the following steps for each script in an
5252 automated fashion:
5254  1. Process the file found in the files directory applying all the
5255     substitutions described in the FILES_SUBST variable.
5257  2. Copy the script from the files directory to the examples hierarchy, $
5258     {PREFIX}/share/examples/rc.d/. Note that this master file must be
5259     explicitly registered in the PLIST.
5261  3. Add code to the installation scripts to copy the startup script from the
5262     examples hierarchy into the system-wide startup scripts directory.
5264 15.3.1. Disabling handling of system startup scripts
5266 The automatic copying of config files can be toggled by setting the environment
5267 variable PKG_RCD_SCRIPTS prior to package installation. Note that the scripts
5268 will be always copied inside the examples hierarchy, ${PREFIX}/share/examples/
5269 rc.d/, no matter what the value of this variable is.
5271 15.4. System users and groups
5273 If a package needs to create special users and/or groups during installation,
5274 it can do so by using the pkginstall framework.
5276 Users can be created by adding entries to the PKG_USERS variable. Each entry
5277 has the following syntax:
5279 user:group
5281 Further specification of user details may be done by setting per-user
5282 variables. PKG_UID.user is the numeric UID for the user. PKG_GECOS.user is the
5283 user's description or comment. PKG_HOME.user is the user's home directory, and
5284 defaults to /nonexistent if not specified. PKG_SHELL.user is the user's shell,
5285 and defaults to /sbin/nologin if not specified.
5287 Similarly, groups can be created by adding entries to the PKG_GROUPS variable,
5288 whose syntax is:
5290 group
5292 The numeric GID of the group may be set by defining PKG_GID.group.
5294 If a package needs to create the users and groups at an earlier stage, then it
5295 can set USERGROUP_PHASE to either configure or build to indicate the phase
5296 before which the users and groups are created. In this case, the numeric UIDs
5297 and GIDs of the created users and groups are automatically hardcoded into the
5298 final installation scripts.
5300 15.5. System shells
5302 Packages that install system shells should register them in the shell database,
5303 /etc/shells, to make things easier to the administrator. This must be done from
5304 the installation scripts to keep binary packages working on any system.
5305 pkginstall provides an easy way to accomplish this task.
5307 When a package provides a shell interpreter, it has to set the PKG_SHELL
5308 variable to its absolute file name. This will add some hooks to the
5309 installation scripts to handle it. Consider the following example, taken from
5310 shells/zsh:
5312 PKG_SHELL=      ${PREFIX}/bin/zsh
5314 15.5.1. Disabling shell registration
5316 The automatic registration of shell interpreters can be disabled by the
5317 administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.
5319 15.6. Fonts
5321 Packages that install X11 fonts should update the database files that index the
5322 fonts within each fonts directory. This can easily be accomplished within the
5323 pkginstall framework.
5325 When a package installs X11 fonts, it must list the directories in which fonts
5326 are installed in the FONTS_DIRS.type variables, where type can be one of "ttf",
5327 "type1" or "x11". This will add hooks to the installation scripts to run the
5328 appropriate commands to update the fonts database files within each of those
5329 directories. For convenience, if the directory path is relative, it is taken to
5330 be relative to the package's installation prefix. Consider the following
5331 example, taken from fonts/dbz-ttf:
5333 FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF
5335 15.6.1. Disabling automatic update of the fonts databases
5337 The automatic update of fonts databases can be disabled by the administrator by
5338 setting the PKG_UPDATE_FONTS_DB environment variable to NO.
5340 Chapter 16. Options handling
5342 Table of Contents
5344 16.1. Global default options
5345 16.2. Converting packages to use bsd.options.mk
5346 16.3. Option Names
5347 16.4. Determining the options of dependencies
5349 Many packages have the ability to be built to support different sets of
5350 features. bsd.options.mk is a framework in pkgsrc that provides generic
5351 handling of those options that determine different ways in which the packages
5352 can be built. It's possible for the user to specify exactly which sets of
5353 options will be built into a package or to allow a set of global default
5354 options apply.
5356 There are two broad classes of behaviors that one might want to control via
5357 options. One is whether some particular feature is enabled in a program that
5358 will be built anyway, often by including or not including a dependency on some
5359 other package. The other is whether or not an additional program will be built
5360 as part of the package. Generally, it is better to make a split package for
5361 such additional programs instead of using options, because it enables binary
5362 packages to be built which can then be added separately. For example, the foo
5363 package might have minimal dependencies (those packages without which foo
5364 doesn't make sense), and then the foo-gfoo package might include the GTK
5365 frontend program gfoo. This is better than including a gtk option to foo that
5366 adds gfoo, because either that option is default, in which case binary users
5367 can't get foo without gfoo, or not default, in which case they can't get gfoo.
5368 With split packages, they can install foo without having GTK, and later decide
5369 to install gfoo (pulling in GTK at that time). This is an advantage to source
5370 users too, avoiding the need for rebuilds.
5372 Plugins with widely varying dependencies should usually be split instead of
5373 options.
5375 It is often more work to maintain split packages, especially if the upstream
5376 package does not support this. The decision of split vs. option should be made
5377 based on the likelihood that users will want or object to the various pieces,
5378 the size of the dependencies that are included, and the amount of work.
5380 A further consideration is licensing. Non-free parts, or parts that depend on
5381 non-free dependencies (especially plugins) should almost always be split if
5382 feasible.
5384 16.1. Global default options
5386 Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of
5387 the options that should be built into every package if that option is
5388 supported. This variable should be set in mk.conf.
5390 16.2. Converting packages to use bsd.options.mk
5392 The following example shows how bsd.options.mk should be used by the
5393 hypothetical ``wibble'' package, either in the package Makefile, or in a file,
5394 e.g. options.mk, that is included by the main package Makefile.
5396 PKG_OPTIONS_VAR=                PKG_OPTIONS.wibble
5397 PKG_SUPPORTED_OPTIONS=          wibble-foo ldap
5398 PKG_OPTIONS_OPTIONAL_GROUPS=    database
5399 PKG_OPTIONS_GROUP.database=     mysql pgsql
5400 PKG_SUGGESTED_OPTIONS=          wibble-foo
5401 PKG_OPTIONS_LEGACY_VARS+=       WIBBLE_USE_OPENLDAP:ldap
5402 PKG_OPTIONS_LEGACY_OPTS+=       foo:wibble-foo
5404 .include "../../mk/bsd.prefs.mk"
5406 # this package was previously named wibble2
5407 .if defined(PKG_OPTIONS.wibble2)
5408 PKG_LEGACY_OPTIONS+=            ${PKG_OPTIONS.wibble2}
5409 PKG_OPTIONS_DEPRECATED_WARNINGS+= \
5410         "Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR} instead."
5411 .endif
5413 .include "../../mk/bsd.options.mk"
5415 # Package-specific option-handling
5418 ### FOO support
5420 .if !empty(PKG_OPTIONS:Mwibble-foo)
5421 CONFIGURE_ARGS+=    --enable-foo
5422 .endif
5425 ### LDAP support
5427 .if !empty(PKG_OPTIONS:Mldap)
5428 .  include "../../databases/openldap-client/buildlink3.mk"
5429 CONFIGURE_ARGS+=    --enable-ldap=${BUILDLINK_PREFIX.openldap-client}
5430 .endif
5433 ### database support
5435 .if !empty(PKG_OPTIONS:Mmysql)
5436 .  include "../../mk/mysql.buildlink3.mk"
5437 .endif
5438 .if !empty(PKG_OPTIONS:Mpgsql)
5439 .  include "../../mk/pgsql.buildlink3.mk"
5440 .endif
5442 The first section contains the information about which build options are
5443 supported by the package, and any default options settings if needed.
5445  1. PKG_OPTIONS_VAR is the name of the make(1) variable that the user can set
5446     to override the default options. It should be set to PKG_OPTIONS.pkgbase.
5447     Do not set it to PKG_OPTIONS.${PKGBASE}, since PKGBASE is not defined at
5448     the point where the options are processed.
5450  2. PKG_SUPPORTED_OPTIONS is a list of build options supported by the package.
5452  3. PKG_OPTIONS_OPTIONAL_GROUPS is a list of names of groups of mutually
5453     exclusive options. The options in each group are listed in
5454     PKG_OPTIONS_GROUP.groupname. The most specific setting of any option from
5455     the group takes precedence over all other options in the group. Options
5456     from the groups will be automatically added to PKG_SUPPORTED_OPTIONS.
5458  4. PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, but
5459     building the packages will fail if no option from the group is selected.
5461  5. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of options. At least
5462     one option from each set must be selected. The options in each set are
5463     listed in PKG_OPTIONS_SET.setname. Options from the sets will be
5464     automatically added to PKG_SUPPORTED_OPTIONS. Building the package will
5465     fail if no option from the set is selected.
5467  6. PKG_SUGGESTED_OPTIONS is a list of build options which are enabled by
5468     default.
5470  7. PKG_OPTIONS_LEGACY_VARS is a list of "USE_VARIABLE:option" pairs that map
5471     legacy mk.conf variables to their option counterparts. Pairs should be
5472     added with "+=" to keep the listing of global legacy variables. A warning
5473     will be issued if the user uses a legacy variable.
5475  8. PKG_OPTIONS_LEGACY_OPTS is a list of "old-option:new-option" pairs that map
5476     options that have been renamed to their new counterparts. Pairs should be
5477     added with "+=" to keep the listing of global legacy options. A warning
5478     will be issued if the user uses a legacy option.
5480  9. PKG_LEGACY_OPTIONS is a list of options implied by deprecated variables
5481     used. This can be used for cases that neither PKG_OPTIONS_LEGACY_VARS nor
5482     PKG_OPTIONS_LEGACY_OPTS can handle, e. g. when PKG_OPTIONS_VAR is renamed.
5484 10. PKG_OPTIONS_DEPRECATED_WARNINGS is a list of warnings about deprecated
5485     variables or options used, and what to use instead.
5487 A package should never modify PKG_DEFAULT_OPTIONS or the variable named in
5488 PKG_OPTIONS_VAR. These are strictly user-settable. To suggest a default set of
5489 options, use PKG_SUGGESTED_OPTIONS.
5491 PKG_OPTIONS_VAR must be defined before including bsd.options.mk. If none of
5492 PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, and
5493 PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform-specific
5494 options if none of them is supported on the current platform), PKG_OPTIONS is
5495 set to the empty list and the package is otherwise treated as not using the
5496 options framework.
5498 After the inclusion of bsd.options.mk, the variable PKG_OPTIONS contains the
5499 list of selected build options, properly filtered to remove unsupported and
5500 duplicate options.
5502 The remaining sections contain the logic that is specific to each option. The
5503 correct way to check for an option is to check whether it is listed in
5504 PKG_OPTIONS:
5506 .if !empty(PKG_OPTIONS:Moption)
5508 16.3. Option Names
5510 Options that enable similar features in different packages (like optional
5511 support for a library) should use a common name in all packages that support it
5512 (like the name of the library). If another package already has an option with
5513 the same meaning, use the same name.
5515 Options that enable features specific to one package, where it's unlikely that
5516 another (unrelated) package has the same (or a similar) optional feature,
5517 should use a name prefixed with pkgname-.
5519 If a group of related packages share an optional feature specific to that
5520 group, prefix it with the name of the "main" package (e. g.
5521 djbware-errno-hack).
5523 For new options, add a line to mk/defaults/options.description. Lines have two
5524 fields, separated by tab. The first field is the option name, the second its
5525 description. The description should be a whole sentence (starting with an
5526 uppercase letter and ending with a period) that describes what enabling the
5527 option does. E. g. "Enable ispell support." The file is sorted by option names.
5529 16.4. Determining the options of dependencies
5531 When writing buildlink3.mk files, it is often necessary to list different
5532 dependencies based on the options with which the package was built. For
5533 querying these options, the file pkgsrc/mk/pkg-build-options.mk should be used.
5534 A typical example looks like this:
5536 pkgbase := libpurple
5537 .include "../../mk/pkg-build-options.mk"
5539 .if !empty(PKG_BUILD_OPTIONS.libpurple:Mdbus)
5541 .endif
5543 Including pkg-build-options.mk here will set the variable
5544 PKG_BUILD_OPTIONS.libpurple to the build options of the libpurple package,
5545 which can then be queried like PKG_OPTIONS in the options.mk file. See the file
5546 pkg-build-options.mk for more details.
5548 Chapter 17. The build process
5550 Table of Contents
5552 17.1. Introduction
5553 17.2. Program location
5554 17.3. Directories used during the build process
5555 17.4. Running a phase
5556 17.5. The fetch phase
5558     17.5.1. What to fetch and where to get it from
5559     17.5.2. How are the files fetched?
5561 17.6. The checksum phase
5562 17.7. The extract phase
5563 17.8. The patch phase
5564 17.9. The tools phase
5565 17.10. The wrapper phase
5566 17.11. The configure phase
5567 17.12. The build phase
5568 17.13. The test phase
5569 17.14. The install phase
5570 17.15. The package phase
5571 17.16. Cleaning up
5572 17.17. Other helpful targets
5574 17.1. Introduction
5576 This chapter gives a detailed description on how a package is built. Building a
5577 package is separated into different phases (for example fetch, build, install),
5578 all of which are described in the following sections. Each phase is split into
5579 so-called stages, which take the name of the containing phase, prefixed by one
5580 of pre-, do- or post-. (Examples are pre-configure, post-build.) Most of the
5581 actual work is done in the do-* stages.
5583 Never override the regular targets (like fetch), if you have to, override the
5584 do-* ones instead.
5586 The basic steps for building a program are always the same. First the program's
5587 source (distfile) must be brought to the local system and then extracted. After
5588 any pkgsrc-specific patches to compile properly are applied, the software can
5589 be configured, then built (usually by compiling), and finally the generated
5590 binaries, etc. can be put into place on the system.
5592 To get more details about what is happening at each step, you can set the
5593 PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in
5594 more details about the patch step.
5596 17.2. Program location
5598 Before outlining the process performed by the NetBSD package system in the next
5599 section, here's a brief discussion on where programs are installed, and which
5600 variables influence this.
5602 The automatic variable PREFIX indicates where all files of the final program
5603 shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
5604 pkgs in the cross category. The value of PREFIX needs to be put into the
5605 various places in the program's source where paths to these files are encoded.
5606 See Section 11.3, "patches/*" and Section 19.3.1, "Shared libraries - libtool"
5607 for more details.
5609 When choosing which of these variables to use, follow the following rules:
5611   * PREFIX always points to the location where the current pkg will be
5612     installed. When referring to a pkg's own installation path, use "${PREFIX}"
5613     .
5615   * LOCALBASE is where all non-X11 pkgs are installed. If you need to construct
5616     a -I or -L argument to the compiler to find includes and libraries
5617     installed by another non-X11 pkg, use "${LOCALBASE}". The name LOCALBASE
5618     stems from FreeBSD, which installed all packages in /usr/local. As pkgsrc
5619     leaves /usr/local for the system administrator, this variable is a
5620     misnomer.
5622   * X11BASE is where the actual X11 distribution (from xsrc, etc.) is
5623     installed. When looking for standard X11 includes (not those installed by a
5624     package), use "${X11BASE}".
5626   * X11-based packages are special in that they may be installed in either
5627     X11BASE or LOCALBASE.
5629     Usually, X11 packages should be installed under LOCALBASE whenever
5630     possible. Note that you will need to include ../../mk/x11.buildlink3.mk in
5631     them to request the presence of X11 and to get the right compilation flags.
5633     Even though, there are some packages that cannot be installed under
5634     LOCALBASE: those that come with app-defaults files. These packages are
5635     special and they must be placed under X11BASE. To accomplish this, set
5636     either USE_X11BASE or USE_IMAKE in your package.
5638     Some notes: If you need to find includes or libraries installed by a pkg
5639     that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in 
5640     both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages
5641     in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default.
5643   * X11PREFIX should be used to refer to the installed location of an X11
5644     package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed,
5645     and to LOCALBASE if xpkgwedge is installed.
5647   * If xpkgwedge is installed, it is possible to have some packages installed
5648     in X11BASE and some in LOCALBASE. To determine the prefix of an installed
5649     package, the EVAL_PREFIX definition can be used. It takes pairs in the
5650     format "DIRNAME=<package>", and the make(1) variable DIRNAME will be set to
5651     the prefix of the installed package <package>, or "${X11PREFIX}" if the
5652     package is not installed.
5654     This is best illustrated by example.
5656     The following lines are taken from pkgsrc/wm/scwm/Makefile:
5658     EVAL_PREFIX+=           GTKDIR=gtk+
5659     CONFIGURE_ARGS+=        --with-guile-prefix=${LOCALBASE:Q}
5660     CONFIGURE_ARGS+=        --with-gtk-prefix=${GTKDIR:Q}
5661     CONFIGURE_ARGS+=        --enable-multibyte
5663     Specific defaults can be defined for the packages evaluated using
5664     EVAL_PREFIX, by using a definition of the form:
5666     GTKDIR_DEFAULT= ${LOCALBASE}
5668     where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair.
5670   * Within ${PREFIX}, packages should install files according to hier(7), with
5671     the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
5672     man.
5674 17.3. Directories used during the build process
5676 When building a package, various directories are used to store source files,
5677 temporary files, pkgsrc-internal files, and so on. These directories are
5678 explained here.
5680 Some of the directory variables contain relative pathnames. There are two
5681 common base directories for these relative directories: PKGSRCDIR/PKGPATH is
5682 used for directories that are pkgsrc-specific. WRKSRC is used for directories
5683 inside the package itself.
5685 PKGSRCDIR
5687     This is an absolute pathname that points to the pkgsrc root directory.
5688     Generally, you don't need it.
5690 PKGDIR
5692     This is an absolute pathname that points to the current package.
5694 PKGPATH
5696     This is a pathname relative to PKGSRCDIR that points to the current
5697     package.
5699 WRKDIR
5701     This is an absolute pathname pointing to the directory where all work takes
5702     place. The distfiles are extracted to this directory. It also contains
5703     temporary directories and log files used by the various pkgsrc frameworks,
5704     like buildlink or the wrappers.
5706 WRKSRC
5708     This is an absolute pathname pointing to the directory where the distfiles
5709     are extracted. It is usually a direct subdirectory of WRKDIR, and often
5710     it's the only directory entry that isn't hidden. This variable may be
5711     changed by a package Makefile.
5713 The CREATE_WRKDIR_SYMLINK definition takes either the value yes or no and
5714 defaults to no. It indicates whether a symbolic link to the WRKDIR is to be
5715 created in the pkgsrc entry's directory. If users would like to have their
5716 pkgsrc trees behave in a read-only manner, then the value of
5717 CREATE_WRKDIR_SYMLINK should be set to no.
5719 17.4. Running a phase
5721 You can run a particular phase by typing make phase, where phase is the name of
5722 the phase. This will automatically run all phases that are required for this
5723 phase. The default phase is build, that is, when you run make without
5724 parameters in a package directory, the package will be built, but not
5725 installed.
5727 17.5. The fetch phase
5729 The first step in building a package is to fetch the distribution files
5730 (distfiles) from the sites that are providing them. This is the task of the 
5731 fetch phase.
5733 17.5.1. What to fetch and where to get it from
5735 In simple cases, MASTER_SITES defines all URLs from where the distfile, whose
5736 name is derived from the DISTNAME variable, is fetched. The more complicated
5737 cases are described below.
5739 The variable DISTFILES specifies the list of distfiles that have to be fetched.
5740 Its value defaults to ${DISTNAME}${EXTRACT_SUFX}, so that most packages don't
5741 need to define it at all. EXTRACT_SUFX is .tar.gz by default, but can be
5742 changed freely. Note that if your package requires additional distfiles to the
5743 default one, you cannot just append the additional filenames using the +=
5744 operator, but you have write for example:
5746 DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
5748 Each distfile is fetched from a list of sites, usually MASTER_SITES. If the
5749 package has multiple DISTFILES or multiple PATCHFILES from different sites, you
5750 can set SITES.distfile to the list of URLs where the file distfile (including
5751 the suffix) can be found.
5753 DISTFILES=      ${DISTNAME}${EXTRACT_SUFX}
5754 DISTFILES+=     foo-file.tar.gz
5755 SITES.foo-file.tar.gz= \
5756 http://www.somewhere.com/somehow/ \
5757 http://www.somewhereelse.com/mirror/somehow/
5759 When actually fetching the distfiles, each item from MASTER_SITES or SITES.*
5760 gets the name of each distfile appended to it, without an intermediate slash.
5761 Therefore, all site values have to end with a slash or other separator
5762 character. This allows for example to set MASTER_SITES to a URL of a CGI script
5763 that gets the name of the distfile as a parameter. In this case, the definition
5764 would look like:
5766 MASTER_SITES=   http://www.example.com/download.cgi?file=
5768 The exception to this rule are URLs starting with a dash. In that case the URL
5769 is taken as is, fetched and the result stored under the name of the distfile.
5771 There are some predefined values for MASTER_SITES, which can be used in
5772 packages. The names of the variables should speak for themselves.
5774 ${MASTER_SITE_APACHE}
5775 ${MASTER_SITE_BACKUP}
5776 ${MASTER_SITE_CYGWIN}
5777 ${MASTER_SITE_DEBIAN}
5778 ${MASTER_SITE_FREEBSD}
5779 ${MASTER_SITE_FREEBSD_LOCAL}
5780 ${MASTER_SITE_GENTOO}
5781 ${MASTER_SITE_GNOME}
5782 ${MASTER_SITE_GNU}
5783 ${MASTER_SITE_GNUSTEP}
5784 ${MASTER_SITE_IFARCHIVE}
5785 ${MASTER_SITE_KDE}
5786 ${MASTER_SITE_MOZILLA}
5787 ${MASTER_SITE_MYSQL}
5788 ${MASTER_SITE_OPENOFFICE}
5789 ${MASTER_SITE_PERL_CPAN}
5790 ${MASTER_SITE_PGSQL}
5791 ${MASTER_SITE_R_CRAN}
5792 ${MASTER_SITE_SOURCEFORGE}
5793 ${MASTER_SITE_SOURCEFORGE_JP}
5794 ${MASTER_SITE_SUNSITE}
5795 ${MASTER_SITE_SUSE}
5796 ${MASTER_SITE_TEX_CTAN}
5797 ${MASTER_SITE_XCONTRIB}
5798 ${MASTER_SITE_XEMACS}
5800 Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP
5801 contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org/
5802 pub/pkgsrc/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local package
5803 source distributions that are maintained in ftp://ftp.NetBSD.org/pub/pkgsrc/
5804 distfiles/LOCAL_PORTS/.
5806 If you choose one of these predefined sites, you may want to specify a
5807 subdirectory of that site. Since these macros may expand to more than one
5808 actual site, you must use the following construct to specify a subdirectory:
5810 MASTER_SITES=   ${MASTER_SITE_GNU:=subdirectory/name/}
5811 MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=project_name/}
5813 Note the trailing slash after the subdirectory name.
5815 17.5.2. How are the files fetched?
5817 The fetch phase makes sure that all the distfiles exist in a local directory
5818 (DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they
5819 are fetched using commands of the form
5821 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
5823 where ${site} varies through several possibilities in turn: first,
5824 MASTER_SITE_OVERRIDE is tried, then the sites specified in either SITES.file if
5825 defined, else MASTER_SITES or PATCH_SITES, as applies, then finally the value
5826 of MASTER_SITE_BACKUP. The order of all except the first and the last can be
5827 optionally sorted by the user, via setting either MASTER_SORT_RANDOM, and
5828 MASTER_SORT_AWK or MASTER_SORT_REGEX.
5830 The specific command and arguments used depend on the FETCH_USING parameter.
5831 The example above is for FETCH_USING=custom.
5833 The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles
5834 target to mirror the distfiles, if they are freely distributable. Packages
5835 setting NO_SRC_ON_FTP (usually to "${RESTRICTED}") will not have their
5836 distfiles mirrored.
5838 17.6. The checksum phase
5840 After the distfile(s) are fetched, their checksum is generated and compared
5841 with the checksums stored in the distinfo file. If the checksums don't match,
5842 the build is aborted. This is to ensure the same distfile is used for building,
5843 and that the distfile wasn't changed, e.g. by some malign force, deliberately
5844 changed distfiles on the master distribution site or network lossage.
5846 17.7. The extract phase
5848 When the distfiles are present on the local system, they need to be extracted,
5849 as they usually come in the form of some compressed archive format.
5851 By default, all DISTFILES are extracted. If you only need some of them, you can
5852 set the EXTRACT_ONLY variable to the list of those files.
5854 Extracting the files is usually done by a little program, mk/extract/extract,
5855 which already knows how to extract various archive formats, so most likely you
5856 will not need to change anything here. But if you need, the following variables
5857 may help you:
5859 EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}
5861     Use these variables to override the default options for an extract command,
5862     which are defined in mk/extract/extract.
5864 EXTRACT_USING
5866     This variable can be set to bsdtar, gtar, nbtar (which is the default
5867     value), pax, or an absolute pathname pointing to the command with which tar
5868     archives should be extracted. It is preferred to choose bsdtar over gtar if
5869     NetBSD's pax-as-tar is not good enough.
5871 If the extract program doesn't serve your needs, you can also override the
5872 EXTRACT_CMD variable, which holds the command used for extracting the files.
5873 This command is executed in the ${WRKSRC} directory. During execution of this
5874 command, the shell variable extract_file holds the absolute pathname of the
5875 file that is going to be extracted.
5877 And if that still does not suffice, you can override the do-extract target in
5878 the package Makefile.
5880 17.8. The patch phase
5882 After extraction, all the patches named by the PATCHFILES, those present in the
5883 patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
5884 /usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz
5885 are uncompressed before they are applied, files ending in .orig or .rej are
5886 ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See
5887 Section 11.3, "patches/*" for more details.
5889 By default patch(1) is given special args to make it fail if the patches apply
5890 with some lines of fuzz. Please fix (regen) the patches so that they apply
5891 cleanly. The rationale behind this is that patches that don't apply cleanly may
5892 end up being applied in the wrong place, and cause severe harm there.
5894 17.9. The tools phase
5896 This is covered in Chapter 18, Tools needed for building or running.
5898 17.10. The wrapper phase
5900 This phase creates wrapper programs for the compilers and linkers. The
5901 following variables can be used to tweak the wrappers.
5903 ECHO_WRAPPER_MSG
5905     The command used to print progress messages. Does nothing by default. Set
5906     to ${ECHO} to see the progress messages.
5908 WRAPPER_DEBUG
5910     This variable can be set to yes (default) or no, depending on whether you
5911     want additional information in the wrapper log file.
5913 WRAPPER_UPDATE_CACHE
5915     This variable can be set to yes or no, depending on whether the wrapper
5916     should use its cache, which will improve the speed. The default value is
5917     yes, but is forced to no if the platform does not support it.
5919 WRAPPER_REORDER_CMDS
5921     A list of reordering commands. A reordering command has the form reorder:l:
5922     lib1:lib2. It ensures that that -llib1 occurs before -llib2.
5924 WRAPPER_TRANSFORM_CMDS
5926     A list of transformation commands. [TODO: investigate further]
5928 17.11. The configure phase
5930 Most pieces of software need information on the header files, system calls, and
5931 library routines which are available on the platform they run on. The process
5932 of determining this information is known as configuration, and is usually
5933 automated. In most cases, a script is supplied with the distfiles, and its
5934 invocation results in generation of header files, Makefiles, etc.
5936 If the package contains a configure script, this can be invoked by setting
5937 HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you
5938 should set GNU_CONFIGURE to "yes" instead. What happens in the configure phase
5939 is roughly:
5941 .for d in ${CONFIGURE_DIRS}
5942         cd ${WRKSRC} \
5943         && cd ${d} \
5944         && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
5945 .endfor
5947 CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In
5948 each of these directories, the configure script is run with the environment
5949 CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV,
5950 CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed
5951 by the package.
5953 If the program uses the Perl way of configuration (mainly Perl modules, but not
5954 only), i.e. a file called Makefile.PL, it should include ../../lang/perl5/
5955 module.mk. To set any parameter for Makefile.PL use the MAKE_PARAMS variable
5956 (e.g., MAKE_PARAMS+=foo=bar
5958 If the program uses an Imakefile for configuration, the appropriate steps can
5959 be invoked by setting USE_IMAKE to "yes". (If you only want the package
5960 installed in ${X11PREFIX} but xmkmf not being run, set USE_X11BASE instead.)
5961 You can add variables to xmkmf's environment by adding them to the SCRIPTS_ENV
5962 variable.
5964 If the program uses cmake for configuration, the appropriate steps can be
5965 invoked by setting USE_CMAKE to "yes". You can add variables to cmake's
5966 environment by adding them to the CONFIGURE_ENV variable and arguments to cmake
5967 by adding them to the CMAKE_ARGS variable. The top directory argument is given
5968 by the CMAKE_ARG_PATH variable, that defaults to "." (relative to
5969 CONFIGURE_DIRS)
5971 If there is no configure step at all, set NO_CONFIGURE to "yes".
5973 17.12. The build phase
5975 For building a package, a rough equivalent of the following code is executed.
5977 .for d in ${BUILD_DIRS}
5978         cd ${WRKSRC} \
5979         && cd ${d} \
5980         && env ${MAKE_ENV} \
5981             ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \
5982                 -f ${MAKE_FILE} \
5983                 ${BUILD_TARGET}
5984 .endfor
5986 BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of
5987 these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and
5988 arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE
5989 and BUILD_TARGET may all be changed by the package.
5991 The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", "
5992 make" otherwise. The default value of MAKE_FILE is "Makefile", and BUILD_TARGET
5993 defaults to "all".
5995 If there is no build step at all, set NO_BUILD to "yes".
5997 17.13. The test phase
5999 [TODO]
6001 17.14. The install phase
6003 Once the build stage has completed, the final step is to install the software
6004 in public directories, so users can access the programs and files.
6006 In the install phase, a rough equivalent of the following code is executed.
6007 Additionally, before and after this code, much magic is performed to do
6008 consistency checks, registering the package, and so on.
6010 .for d in ${INSTALL_DIRS}
6011         cd ${WRKSRC} \
6012         && cd ${d} \
6013         && env ${MAKE_ENV} \
6014             ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \
6015                 -f ${MAKE_FILE} \
6016                 ${INSTALL_TARGET}
6017 .endfor
6019 The variable's meanings are analogous to the ones in the build phase.
6020 INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is "install" by default,
6021 plus "install.man" if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
6022 defined.
6024 In the install phase, the following variables are useful. They are all
6025 variations of the install(1) command that have the owner, group and permissions
6026 preset. INSTALL is the plain install command. The specialized variants,
6027 together with their intended use, are:
6029 INSTALL_PROGRAM_DIR
6031     directories that contain binaries
6033 INSTALL_SCRIPT_DIR
6035     directories that contain scripts
6037 INSTALL_LIB_DIR
6039     directories that contain shared and static libraries
6041 INSTALL_DATA_DIR
6043     directories that contain data files
6045 INSTALL_MAN_DIR
6047     directories that contain man pages
6049 INSTALL_PROGRAM
6051     binaries that can be stripped from debugging symbols
6053 INSTALL_SCRIPT
6055     binaries that cannot be stripped
6057 INSTALL_GAME
6059     game binaries
6061 INSTALL_LIB
6063     shared and static libraries
6065 INSTALL_DATA
6067     data files
6069 INSTALL_GAME_DATA
6071     data files for games
6073 INSTALL_MAN
6075     man pages
6077 Some other variables are:
6079 INSTALLATION_DIRS
6081     A list of directories relative to PREFIX that are created by pkgsrc at the
6082     beginning of the install phase. The package is supposed to create all
6083     needed directories itself before installing files to it and list all other
6084     directories here.
6086 In the rare cases that a package shouldn't install anything, set NO_INSTALL to 
6087 "yes". This is mostly relevant for packages in the regress category.
6089 17.15. The package phase
6091 Once the install stage has completed, a binary package of the installed files
6092 can be built. These binary packages can be used for quick installation without
6093 previous compilation, e.g. by the make bin-install or by using pkg_add.
6095 By default, the binary packages are created in ${PACKAGES}/All and symlinks are
6096 created in ${PACKAGES}/category, one for each category in the CATEGORIES
6097 variable. PACKAGES defaults to pkgsrc/packages.
6099 17.16. Cleaning up
6101 Once you're finished with a package, you can clean the work directory by
6102 running make clean. If you want to clean the work directories of all
6103 dependencies too, use make clean-depends.
6105 17.17. Other helpful targets
6107 pre/post-*
6109     For any of the main targets described in the previous section, two
6110     auxiliary targets exist with "pre-" and "post-" used as a prefix for the
6111     main target's name. These targets are invoked before and after the main
6112     target is called, allowing extra configuration or installation steps be
6113     performed from a package's Makefile, for example, which a program's
6114     configure script or install target omitted.
6116 do-*
6118     Should one of the main targets do the wrong thing, and should there be no
6119     variable to fix this, you can redefine it with the do-* target. (Note that
6120     redefining the target itself instead of the do-* target is a bad idea, as
6121     the pre-* and post-* targets won't be called anymore, etc.) You will not
6122     usually need to do this.
6124 reinstall
6126     If you did a make install and you noticed some file was not installed
6127     properly, you can repeat the installation with this target, which will
6128     ignore the "already installed" flag.
6130     This is the default value of DEPENDS_TARGET except in the case of make
6131     update and make package, where the defaults are "package" and "update",
6132     respectively.
6134 deinstall
6136     This target does a pkg_delete(1) in the current directory, effectively
6137     de-installing the package. The following variables can be used to tune the
6138     behaviour:
6140     PKG_VERBOSE
6142         Add a "-v" to the pkg_delete(1) command.
6144     DEINSTALLDEPENDS
6146         Remove all packages that require (depend on) the given package. This
6147         can be used to remove any packages that may have been pulled in by a
6148         given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
6149         pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding "-R
6150         " to the pkg_delete(1) command line.
6152 bin-install
6154     Install a binary package from local disk and via FTP from a list of sites
6155     (see the BINPKG_SITES variable), and do a make package if no binary package
6156     is available anywhere. The arguments given to pkg_add can be set via
6157     BIN_INSTALL_FLAGS e.g., to do verbose operation, etc.
6159 update
6161     This target causes the current package to be updated to the latest version.
6162     The package and all depending packages first get de-installed, then current
6163     versions of the corresponding packages get compiled and installed. This is
6164     similar to manually noting which packages are currently installed, then
6165     performing a series of make deinstall and make install (or whatever
6166     UPDATE_TARGET is set to) for these packages.
6168     You can use the "update" target to resume package updating in case a
6169     previous make update was interrupted for some reason. However, in this
6170     case, make sure you don't call make clean or otherwise remove the list of
6171     dependent packages in WRKDIR. Otherwise, you lose the ability to
6172     automatically update the current package along with the dependent packages
6173     you have installed.
6175     Resuming an interrupted make update will only work as long as the package
6176     tree remains unchanged. If the source code for one of the packages to be
6177     updated has been changed, resuming make update will most certainly fail!
6179     The following variables can be used either on the command line or in
6180     mk.conf to alter the behaviour of make update:
6182     UPDATE_TARGET
6184         Install target to recursively use for the updated package and the
6185         dependent packages. Defaults to DEPENDS_TARGET if set, "install"
6186         otherwise for make update. Other good targets are "package" or "
6187         bin-install". Do not set this to "update" or you will get stuck in an
6188         endless loop!
6190     NOCLEAN
6192         Don't clean up after updating. Useful if you want to leave the work
6193         sources of the updated packages around for inspection or other
6194         purposes. Be sure you eventually clean up the source tree (see the "
6195         clean-update" target below) or you may run into troubles with old
6196         source code still lying around on your next make or make update.
6198     REINSTALL
6200         Deinstall each package before installing (making DEPENDS_TARGET). This
6201         may be necessary if the "clean-update" target (see below) was called
6202         after interrupting a running make update.
6204     DEPENDS_TARGET
6206         Allows you to disable recursion and hardcode the target for packages.
6207         The default is "update" for the update target, facilitating a recursive
6208         update of prerequisite packages. Only set DEPENDS_TARGET if you want to
6209         disable recursive updates. Use UPDATE_TARGET instead to just set a
6210         specific target for each package to be installed during make update
6211         (see above).
6213 clean-update
6215     Clean the source tree for all packages that would get updated if make
6216     update was called from the current directory. This target should not be
6217     used if the current package (or any of its depending packages) have already
6218     been de-installed (e.g., after calling make update) or you may lose some
6219     packages you intended to update. As a rule of thumb: only use this target 
6220     before the first time you run make update and only if you have a dirty
6221     package tree (e.g., if you used NOCLEAN).
6223     If you are unsure about whether your tree is clean, you can either perform
6224     a make clean at the top of the tree, or use the following sequence of
6225     commands from the directory of the package you want to update (before
6226     running make update for the first time, otherwise you lose all the packages
6227     you wanted to update!):
6229     # make clean-update
6230     # make clean CLEANDEPENDS=YES
6231     # make update
6234     The following variables can be used either on the command line or in
6235     mk.conf to alter the behaviour of make clean-update:
6237     CLEAR_DIRLIST
6239         After make clean, do not reconstruct the list of directories to update
6240         for this package. Only use this if make update successfully installed
6241         all packages you wanted to update. Normally, this is done automatically
6242         on make update, but may have been suppressed by the NOCLEAN variable
6243         (see above).
6245 replace
6247     Update the installation of the current package. This differs from update in
6248     that it does not replace dependent packages. You will need to install
6249     pkgtools/pkg_tarup for this target to work.
6251     Be careful when using this target! There are no guarantees that dependent
6252     packages will still work, in particular they will most certainly break if
6253     you make replace a library package whose shared library major version
6254     changed between your installed version and the new one. For this reason,
6255     this target is not officially supported and only recommended for advanced
6256     users.
6258 info
6260     This target invokes pkg_info(1) for the current package. You can use this
6261     to check which version of a package is installed.
6263 index
6265     This is a top-level command, i.e. it should be used in the pkgsrc
6266     directory. It creates a database of all packages in the local pkgsrc tree,
6267     including dependencies, comment, maintainer, and some other useful
6268     information. Individual entries are created by running make describe in the
6269     packages' directories. This index file is saved as pkgsrc/INDEX. It can be
6270     displayed in verbose format by running make print-index. You can search in
6271     it with make search key=something. You can extract a list of all packages
6272     that depend on a particular one by running make show-deps PKG=somepackage.
6274     Running this command takes a very long time, some hours even on fast
6275     machines!
6277 readme
6279     This target generates a README.html file, which can be viewed using a
6280     browser such as www/firefox or www/links. The generated files contain
6281     references to any packages which are in the PACKAGES directory on the local
6282     host. The generated files can be made to refer to URLs based on
6283     FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate
6284     README.html files which pointed to binary packages on the local machine, in
6285     the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
6286     FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
6287     subdirectories will be searched for all the binary packages.
6289     The target can be run at the toplevel or in category directories, in which
6290     case it descends recursively.
6292 readme-all
6294     This is a top-level command, run it in pkgsrc. Use this target to create a
6295     file README-all.html which contains a list of all packages currently
6296     available in the NetBSD Packages Collection, together with the category
6297     they belong to and a short description. This file is compiled from the
6298     pkgsrc/*/README.html files, so be sure to run this after a make readme.
6300 cdrom-readme
6302     This is very much the same as the "readme" target (see above), but is to be
6303     used when generating a pkgsrc tree to be written to a CD-ROM. This target
6304     also produces README.html files, and can be made to refer to URLs based on
6305     CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
6307 show-distfiles
6309     This target shows which distfiles and patchfiles are needed to build the
6310     package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not
6311     patches/*).
6313 show-downlevel
6315     This target shows nothing if the package is not installed. If a version of
6316     this package is installed, but is not the version provided in this version
6317     of pkgsrc, then a warning message is displayed. This target can be used to
6318     show which of your installed packages are downlevel, and so the old
6319     versions can be deleted, and the current ones added.
6321 show-pkgsrc-dir
6323     This target shows the directory in the pkgsrc hierarchy from which the
6324     package can be built and installed. This may not be the same directory as
6325     the one from which the package was installed. This target is intended to be
6326     used by people who may wish to upgrade many packages on a single host, and
6327     can be invoked from the top-level pkgsrc Makefile by using the "
6328     show-host-specific-pkgs" target.
6330 show-installed-depends
6332     This target shows which installed packages match the current package's
6333     DEPENDS. Useful if out of date dependencies are causing build problems.
6335 check-shlibs
6337     After a package is installed, check all its binaries and (on ELF platforms)
6338     shared libraries to see if they find the shared libs they need. Run by
6339     default if PKG_DEVELOPER is set in mk.conf.
6341 print-PLIST
6343     After a "make install" from a new or upgraded pkg, this prints out an
6344     attempt to generate a new PLIST from a find -newer work/.extract_done. An
6345     attempt is made to care for shared libs etc., but it is strongly
6346     recommended to review the result before putting it into PLIST. On upgrades,
6347     it's useful to diff the output of this command against an already existing
6348     PLIST file.
6350     If the package installs files via tar(1) or other methods that don't update
6351     file access times, be sure to add these files manually to your PLIST, as
6352     the "find -newer" command used by this target won't catch them!
6354     See Section 13.3, "Tweaking output of make print-PLIST" for more
6355     information on this target.
6357 bulk-package
6359     Used to do bulk builds. If an appropriate binary package already exists, no
6360     action is taken. If not, this target will compile, install and package it
6361     (and its depends, if PKG_DEPENDS is set properly. See Section 7.3.1,
6362     "Configuration"). After creating the binary package, the sources, the
6363     just-installed package and its required packages are removed, preserving
6364     free disk space.
6366     Beware that this target may deinstall all packages installed on a system!
6368 bulk-install
6370     Used during bulk-installs to install required packages. If an up-to-date
6371     binary package is available, it will be installed via pkg_add(1). If not, 
6372     make bulk-package will be executed, but the installed binary won't be
6373     removed.
6375     A binary package is considered "up-to-date" to be installed via pkg_add(1)
6376     if:
6378       + None of the package's files (Makefile, ...) were modified since it was
6379         built.
6381       + None of the package's required (binary) packages were modified since it
6382         was built.
6384     Beware that this target may deinstall all packages installed on a system!
6386 Chapter 18. Tools needed for building or running
6388 Table of Contents
6390 18.1. Tools for pkgsrc builds
6391 18.2. Tools needed by packages
6392 18.3. Tools provided by platforms
6393 18.4. Questions regarding the tools
6395 The USE_TOOLS definition is used both internally by pkgsrc and also for
6396 individual packages to define what commands are needed for building a package
6397 (like BUILD_DEPENDS) or for later run-time of an installed packaged (such as
6398 DEPENDS). If the native system provides an adequate tool, then in many cases, a
6399 pkgsrc package will not be used.
6401 When building a package, the replacement tools are made available in a
6402 directory (as symlinks or wrapper scripts) that is early in the executable
6403 search path. Just like the buildlink system, this helps with consistent builds.
6405 A tool may be needed to help build a specific package. For example, perl, GNU
6406 make (gmake) or yacc may be needed.
6408 Also a tool may be needed, for example, because the native system's supplied
6409 tool may be inefficient for building a package with pkgsrc. For example, a
6410 package may need GNU awk, bison (instead of yacc) or a better sed.
6412 The tools used by a package can be listed by running make show-tools.
6414 18.1. Tools for pkgsrc builds
6416 The default set of tools used by pkgsrc is defined in bsd.pkg.mk. This includes
6417 standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be
6418 seen by running: make show-var VARNAME=USE_TOOLS.
6420 If a package needs a specific program to build then the USE_TOOLS variable can
6421 be used to define the tools needed.
6423 18.2. Tools needed by packages
6425 In the following examples, the :run means that it is needed at run-time (and
6426 becomes a DEPENDS). The default is a build dependency which can be set with
6427 :build. (So in this example, it is the same as gmake:build and
6428 pkg-config:build.)
6430 USE_TOOLS+=     gmake perl:run pkg-config
6432 When using the tools framework, a TOOLS_PATH.foo variable is defined which
6433 contains the full path to the appropriate tool. For example, TOOLS_PATH.bash
6434 could be "/bin/bash" on Linux systems.
6436 If you always need a pkgsrc version of the tool at run-time, then just use
6437 DEPENDS instead.
6439 18.3. Tools provided by platforms
6441 When improving or porting pkgsrc to a new platform, have a look at (or create)
6442 the corresponding platform specific make file fragment under pkgsrc/mk/tools/
6443 tools.${OPSYS}.mk which defines the name of the common tools. For example:
6445 .if exists(/usr/bin/bzcat)
6446 TOOLS_PLATFORM.bzcat?=          /usr/bin/bzcat
6447 .elif exists(/usr/bin/bzip2)
6448 TOOLS_PLATFORM.bzcat?=          /usr/bin/bzip2 -cd
6449 .endif
6451 TOOLS_PLATFORM.true?=           true                    # shell builtin
6453 18.4. Questions regarding the tools
6455 18.4.1. How do I add a new tool?
6456 18.4.2. How do I get a list of all available tools?
6457 18.4.3. How can I get a list of all the tools that a package is using while
6458     being built? I want to know whether it uses sed or not.
6460 18.4.1. How do I add a new tool?
6462         TODO
6464 18.4.2. How do I get a list of all available tools?
6466         TODO
6468 18.4.3. How can I get a list of all the tools that a package is using while
6469         being built? I want to know whether it uses sed or not.
6471         Currently, you can't. (TODO: But I want to be able to do it.)
6473 Chapter 19. Making your package work
6475 Table of Contents
6477 19.1. General operation
6479     19.1.1. Portability of packages
6480     19.1.2. How to pull in user-settable variables from mk.conf
6481     19.1.3. User interaction
6482     19.1.4. Handling licenses
6483     19.1.5. Restricted packages
6484     19.1.6. Handling dependencies
6485     19.1.7. Handling conflicts with other packages
6486     19.1.8. Packages that cannot or should not be built
6487     19.1.9. Packages which should not be deleted, once installed
6488     19.1.10. Handling packages with security problems
6489     19.1.11. How to handle incrementing versions when fixing an existing
6490         package
6491     19.1.12. Substituting variable text in the package files (the SUBST
6492         framework)
6494 19.2. Fixing problems in the fetch phase
6496     19.2.1. Packages whose distfiles aren't available for plain downloading
6497     19.2.2. How to handle modified distfiles with the 'old' name
6499 19.3. Fixing problems in the configure phase
6501     19.3.1. Shared libraries - libtool
6502     19.3.2. Using libtool on GNU packages that already support libtool
6503     19.3.3. GNU Autoconf/Automake
6505 19.4. Programming languages
6507     19.4.1. C, C++, and Fortran
6508     19.4.2. Java
6509     19.4.3. Packages containing perl scripts
6510     19.4.4. Packages containing shell scripts
6511     19.4.5. Other programming languages
6513 19.5. Fixing problems in the build phase
6515     19.5.1. Compiling C and C++ code conditionally
6516     19.5.2. How to handle compiler bugs
6517     19.5.3. Undefined reference to "..."
6518     19.5.4. Running out of memory
6520 19.6. Fixing problems in the install phase
6522     19.6.1. Creating needed directories
6523     19.6.2. Where to install documentation
6524     19.6.3. Installing highscore files
6525     19.6.4. Adding DESTDIR support to packages
6526     19.6.5. Packages with hardcoded paths to other interpreters
6527     19.6.6. Packages installing perl modules
6528     19.6.7. Packages installing info files
6529     19.6.8. Packages installing man pages
6530     19.6.9. Packages installing GConf data files
6531     19.6.10. Packages installing scrollkeeper/rarian data files
6532     19.6.11. Packages installing X11 fonts
6533     19.6.12. Packages installing GTK2 modules
6534     19.6.13. Packages installing SGML or XML data
6535     19.6.14. Packages installing extensions to the MIME database
6536     19.6.15. Packages using intltool
6537     19.6.16. Packages installing startup scripts
6538     19.6.17. Packages installing TeX modules
6539     19.6.18. Packages supporting running binaries in emulation
6540     19.6.19. Packages installing hicolor theme icons
6541     19.6.20. Packages installing desktop files
6543 19.7. Marking packages as having problems
6545 19.1. General operation
6547 19.1.1. Portability of packages
6549 One appealing feature of pkgsrc is that it runs on many different platforms. As
6550 a result, it is important to ensure, where possible, that packages in pkgsrc
6551 are portable. This chapter mentions some particular details you should pay
6552 attention to while working on pkgsrc.
6554 19.1.2. How to pull in user-settable variables from mk.conf
6556 The pkgsrc user can configure pkgsrc by overriding several variables in the
6557 file pointed to by MAKECONF, which is mk.conf by default. When you want to use
6558 those variables in the preprocessor directives of make(1) (for example .if or
6559 .for), you need to include the file ../../mk/bsd.prefs.mk before, which in turn
6560 loads the user preferences.
6562 But note that some variables may not be completely defined after ../../mk/
6563 bsd.prefs.mk has been included, as they may contain references to variables
6564 that are not yet defined. In shell commands this is no problem, since variables
6565 are actually macros, which are only expanded when they are used. But in the
6566 preprocessor directives mentioned above and in dependency lines (of the form
6567 target: dependencies) the variables are expanded at load time.
6569 Note
6571 Currently there is no exhaustive list of all variables that tells you whether
6572 they can be used at load time or only at run time, but it is in preparation.
6574 19.1.3. User interaction
6576 Occasionally, packages require interaction from the user, and this can be in a
6577 number of ways:
6579   * When fetching the distfiles, some packages require user interaction such as
6580     entering username/password or accepting a license on a web page.
6582   * When extracting the distfiles, some packages may ask for passwords.
6584   * help to configure the package before it is built
6586   * help during the build process
6588   * help during the installation of a package
6590 The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of
6591 an interactive stage which will be needed, and this should be set in the
6592 package's Makefile, e.g.:
6594 INTERACTIVE_STAGE=      build
6597 Multiple interactive stages can be specified:
6599 INTERACTIVE_STAGE=      configure install
6602 The user can then decide to skip this package by setting the BATCH variable.
6604 19.1.4. Handling licenses
6606 Authors of software can choose the licence under which software can be copied.
6607 This is due to copyright law, and reasons for license choices are outside the
6608 scope of pkgsrc. The pkgsrc system recognizes that there are a number of
6609 licenses which some users may find objectionable or difficult or impossible to
6610 comply with. The Free Software Foundation has declared some licenses "Free",
6611 and the Open Source Initiative has a definition of "Open Source". The pkgsrc
6612 system, as a policy choice, does not label packages which have licenses that
6613 are Free or Open Source. However, packages without a license meeting either of
6614 those tests are labeled with a license tag denoting the license. Note that a
6615 package with no license to copy trivially does not meet either the Free or Open
6616 Source test.
6618 For packages which are not Free or Open Source, pkgsrc will not build the
6619 package unless the user has indicated to pkgsrc that packages with that
6620 particular license may be built. Note that this documentation avoids the term
6621 "accepted the license". The pkgsrc system is merely providing a mechanism to
6622 avoid accidentally building a package with a non-free license; judgement and
6623 responsibility remain with the user. (Installation of binary packages are not
6624 currently subject to this mechanism; this is a bug.)
6626 One might want to only install packages with a BSD license, or the GPL, and not
6627 the other. The free licenses are added to the default ACCEPTABLE_LICENSES
6628 variable. The user can override the default by setting the ACCEPTABLE_LICENSES
6629 variable with "=" instead of "+=". The licenses accepted by default are:
6631         apache-1.1 apache-2.0
6632         arphic-public
6633         artistic artistic-2.0
6634         boost-license
6635         cc-by-sa-v3.0
6636         cddl-1.0
6637         cpl-1.0
6638         epl-v1.0
6639         gnu-fdl-v1.1 gnu-fdl-v1.2 gnu-fdl-v1.3
6640         gnu-gpl-v1
6641         gnu-gpl-v2 gnu-lgpl-v2 gnu-lgpl-v2.1
6642         gnu-gpl-v3 gnu-lgpl-v3
6643         ibm-public-license-1.0
6644         ipafont
6645         isc
6646         lppl-1.3c
6647         lucent
6648         miros
6649         mit
6650         mpl-1.0 mpl-1.1 mpl-2.0
6651         mplusfont
6652         ofl-v1.0 ofl-v1.1
6653         original-bsd modified-bsd 2-clause-bsd
6654         php
6655         png-license
6656         postgresql-license
6657         public-domain
6658         python-software-foundation
6659         qpl-v1.0
6660         sgi-free-software-b-v2.0
6661         sleepycat-public
6662         unlicense
6663         x11
6664         zlib
6665         zpl
6668 The license tag mechanism is intended to address copyright-related issues
6669 surrounding building, installing and using a package, and not to address
6670 redistribution issues (see RESTRICTED and NO_SRC_ON_FTP, etc.). Packages with
6671 redistribution restrictions should set these tags.
6673 Denoting that a package may be copied according to a particular license is done
6674 by placing the license in pkgsrc/licenses and setting the LICENSE variable to a
6675 string identifying the license, e.g. in graphics/xv:
6677 LICENSE=        xv-license
6680 When trying to build, the user will get a notice that the package is covered by
6681 a license which has not been placed in the ACCEPTABLE_LICENSES variable:
6683 % make
6684 ===> xv-3.10anb9 has an unacceptable license: xv-license.
6685 ===>     To view the license, enter "/usr/bin/make show-license".
6686 ===>     To indicate acceptance, add this line to your /etc/mk.conf:
6687 ===>     ACCEPTABLE_LICENSES+=xv-license
6688 *** Error code 1
6691 The license can be viewed with make show-license, and if the user so chooses,
6692 the line printed above can be added to mk.conf to convey to pkgsrc that it
6693 should not in the future fail because of that license:
6695 ACCEPTABLE_LICENSES+=xv-license
6698 When adding a package with a new license, the following steps are required:
6700  1. Check if the file can avoid the -license filename tag as described above by
6701     referencing Various Licenses and Comments about Them and Licenses by Name |
6702     Open Source Initiative. If this is the case, additionally add the license
6703     filename to:
6705       + DEFAULT_ACCEPTABLE_LICENSES in pkgsrc/mk/license.mk
6707       + default_acceptable_licenses in pkgsrc/pkgtools/pkg_install/files/lib/
6708         license.c
6710       + the ACCEPTABLE_LICENSES list in pkgsrc/doc/guide/files/fixes.xml
6712     with the proper syntax as demonstrated in those files, respectively.
6714  2. The license text should be added to pkgsrc/licenses for displaying. A list
6715     of known licenses can be seen in this directory.
6717 When the license changes (in a way other than formatting), please make sure
6718 that the new license has a different name (e.g., append the version number if
6719 it exists, or the date). Just because a user told pkgsrc to build programs
6720 under a previous version of a license does not mean that pkgsrc should build
6721 programs under the new licenses. The higher-level point is that pkgsrc does not
6722 evaluate licenses for reasonableness; the only test is a mechanistic test of
6723 whether a particular text has been approved by either of two bodies.
6725 The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar language
6726 is deprecated because it does not crisply refer to a particular license text.
6727 Another problem with such usage is that it does not enable a user to tell
6728 pkgsrc to proceed for a single package without also telling pkgsrc to proceed
6729 for all packages with that tag.
6731 19.1.5. Restricted packages
6733 Some licenses restrict how software may be re-distributed. Because a license
6734 tag is required unless the package is Free or Open Source, all packages with
6735 restrictions should have license tags. By declaring the restrictions, package
6736 tools can automatically refrain from e.g. placing binary packages on FTP sites.
6738 There are four restrictions that may be encoded, which are the cross product of
6739 sources (distfiles) and binaries not being placed on FTP sites and CD-ROMs.
6740 Because this is rarely the exact language in any license, and because non-Free
6741 licenses tend to be different from each other, pkgsrc adopts a definition of
6742 FTP and CD-ROM. Pkgsrc uses "FTP" to mean that the source or binary file should
6743 not be made available over the Internet at no charge. Pkgsrc uses "CD-ROM" to
6744 mean that the source or binary may not be made available on some kind of media,
6745 together with other source and binary packages, and which is sold for a
6746 distribution charge.
6748 In order to encode these restrictions, the package system defines five make
6749 variables that can be set to note these restrictions:
6751   * RESTRICTED
6753     This variable should be set whenever a restriction exists (regardless of
6754     its kind). Set this variable to a string containing the reason for the
6755     restriction. It should be understood that those wanting to understand the
6756     restriction will have to read the license, and perhaps seek advice of
6757     counsel.
6759   * NO_BIN_ON_CDROM
6761     Binaries may not be placed on CD-ROM containing other binary packages, for
6762     which a distribution charge may be made. In this case, set this variable to
6763     ${RESTRICTED}.
6765   * NO_BIN_ON_FTP
6767     Binaries may not made available on the Internet without charge. In this
6768     case, set this variable to ${RESTRICTED}. If this variable is set, binary
6769     packages will not be included on ftp.NetBSD.org.
6771   * NO_SRC_ON_CDROM
6773     Distfiles may not be placed on CD-ROM, together with other distfiles, for
6774     which a fee may be charged. In this case, set this variable to $
6775     {RESTRICTED}.
6777   * NO_SRC_ON_FTP
6779     Distfiles may not made available via FTP at no charge. In this case, set
6780     this variable to ${RESTRICTED}. If this variable is set, the distfile(s)
6781     will not be mirrored on ftp.NetBSD.org.
6783 Please note that packages will to be removed from pkgsrc when the distfiles are
6784 not distributable and cannot be obtained for a period of one full quarter
6785 branch. Packages with manual / interactive fetch must have a maintainer and it
6786 is his/her responsibility to ensure this.
6788 19.1.6. Handling dependencies
6790 Your package may depend on some other package being present - and there are
6791 various ways of expressing this dependency. pkgsrc supports the BUILD_DEPENDS
6792 and DEPENDS definitions, the USE_TOOLS definition, as well as dependencies via
6793 buildlink3.mk, which is the preferred way to handle dependencies, and which
6794 uses the variables named above. See Chapter 14, Buildlink methodology for more
6795 information.
6797 The basic difference between the two variables is as follows: The DEPENDS
6798 definition registers that pre-requisite in the binary package so it will be
6799 pulled in when the binary package is later installed, whilst the BUILD_DEPENDS
6800 definition does not, marking a dependency that is only needed for building the
6801 package.
6803 This means that if you only need a package present whilst you are building, it
6804 should be noted as a BUILD_DEPENDS.
6806 The format for a BUILD_DEPENDS and a DEPENDS definition is:
6808 <pre-req-package-name>:../../<category>/<pre-req-package>
6811 Please note that the "pre-req-package-name" may include any of the wildcard
6812 version numbers recognized by pkg_info(1).
6814  1. If your package needs another package's binaries or libraries to build or
6815     run, and if that package has a buildlink3.mk file available, use it:
6817     .include "../../graphics/jpeg/buildlink3.mk"
6820  2. If your package needs binaries from another package to build, use the
6821     BUILD_DEPENDS definition:
6823     BUILD_DEPENDS+= scons-[0-9]*:../../devel/scons
6826  3. If your package needs a library with which to link and there is no
6827     buildlink3.mk file available, create one. Using DEPENDS won't be sufficient
6828     because the include files and libraries will be hidden from the compiler.
6830  4. If your package needs some executable to be able to run correctly and if
6831     there's no buildlink3.mk file, this is specified using the DEPENDS
6832     variable. The print/lyx package needs to be able to execute the latex
6833     binary from the teTeX package when it runs, and that is specified:
6835     DEPENDS+=        teTeX-[0-9]*:../../print/teTeX
6838  5. You can use wildcards in package dependencies. Note that such wildcard
6839     dependencies are retained when creating binary packages. The dependency is
6840     checked when installing the binary package and any package which matches
6841     the pattern will be used. Wildcard dependencies should be used with care.
6843     The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
6844     matches such as "tk-postgresql" matching a "tk-*" DEPENDS.
6846     Wildcards can also be used to specify that a package will only build
6847     against a certain minimum version of a pre-requisite:
6849     DEPENDS+=       ImageMagick>=6.0:../../graphics/ImageMagick
6852     This means that the package will build using version 6.0 of ImageMagick or
6853     newer. Such a dependency may be warranted if, for example, the command line
6854     options of an executable have changed.
6856     If you need to depend on minimum versions of libraries, see the buildlink
6857     section of the pkgsrc guide.
6859     For security fixes, please update the package vulnerabilities file. See
6860     Section 19.1.10, "Handling packages with security problems" for more
6861     information.
6863 If your package needs files from another package to build, add the relevant
6864 distribution files to DISTFILES, so they will be extracted automatically. See
6865 the print/ghostscript package for an example. (It relies on the jpeg sources
6866 being present in source form during the build.)
6868 19.1.7. Handling conflicts with other packages
6870 Your package may conflict with other packages a user might already have
6871 installed on his system, e.g. if your package installs the same set of files as
6872 another package in the pkgsrc tree.
6874 In this case you can set CONFLICTS to a space-separated list of packages
6875 (including version string) your package conflicts with.
6877 For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus
6878 you set in pkgsrc/x11/Xaw3d/Makefile:
6880 CONFLICTS=      Xaw-Xpm-[0-9]*
6883 and in pkgsrc/x11/Xaw-Xpm/Makefile:
6885 CONFLICTS=      Xaw3d-[0-9]*
6888 Packages will automatically conflict with other packages with the name prefix
6889 and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
6890 with the older version "Xaw3d-1.3".
6892 19.1.8. Packages that cannot or should not be built
6894 There are several reasons why a package might be instructed to not build under
6895 certain circumstances. If the package builds and runs on most platforms, the
6896 exceptions should be noted with NOT_FOR_PLATFORM. If the package builds and
6897 runs on a small handful of platforms, set ONLY_FOR_PLATFORM instead. Both
6898 ONLY_FOR_PLATFORM and NOT_FOR_PLATFORM are OS triples (OS-version-platform)
6899 that can use glob-style wildcards.
6901 Some packages are tightly bound to a specific version of an operating system,
6902 e.g. LKMs or sysutils/lsof. Such binary packages are not backwards compatible
6903 with other versions of the OS, and should be uploaded to a version specific
6904 directory on the FTP server. Mark these packages by setting OSVERSION_SPECIFIC
6905 to "yes". This variable is not currently used by any of the package system
6906 internals, but may be used in the future.
6908 If the package should be skipped (for example, because it provides
6909 functionality already provided by the system), set PKG_SKIP_REASON to a
6910 descriptive message. If the package should fail because some preconditions are
6911 not met, set PKG_FAIL_REASON to a descriptive message.
6913 19.1.9. Packages which should not be deleted, once installed
6915 To ensure that a package may not be deleted, once it has been installed, the
6916 PKG_PRESERVE definition should be set in the package Makefile. This will be
6917 carried into any binary package that is made from this pkgsrc entry. A "
6918 preserved" package will not be deleted using pkg_delete(1) unless the "-f"
6919 option is used.
6921 19.1.10. Handling packages with security problems
6923 When a vulnerability is found, this should be noted in localsrc/security/
6924 advisories/pkg-vulnerabilities, and after committing that file, ask
6925 pkgsrc-security@NetBSD.org to update the file on ftp.NetBSD.org.
6927 After fixing the vulnerability by a patch, its PKGREVISION should be increased
6928 (this is of course not necessary if the problem is fixed by using a newer
6929 release of the software), and the pattern in the pkg-vulnerabilities file must
6930 be updated.
6932 Also, if the fix should be applied to the stable pkgsrc branch, be sure to
6933 submit a pullup request!
6935 Binary packages already on ftp.NetBSD.org will be handled semi-automatically by
6936 a weekly cron job.
6938 19.1.11. How to handle incrementing versions when fixing an existing package
6940 When making fixes to an existing package it can be useful to change the version
6941 number in PKGNAME. To avoid conflicting with future versions by the original
6942 author, a "nb1", "nb2", ... suffix can be used on package versions by setting
6943 PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools.
6944 e.g.
6946 DISTNAME=       foo-17.42
6947 PKGREVISION=    9
6950 will result in a PKGNAME of "foo-17.42nb9". If you want to use the original
6951 value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use
6952 PKGNAME_NOREV.
6954 When a new release of the package is released, the PKGREVISION should be
6955 removed, e.g. on a new minor release of the above package, things should be
6956 like:
6958 DISTNAME=       foo-17.43
6961 PKGREVISION should be incremented for any non-trivial change in the resulting
6962 binary package. Without a PKGREVISION bump, someone with the previous version
6963 installed has no way of knowing that their package is out of date. Thus,
6964 changes without increasing PKGREVISION are essentially labeled "this is so
6965 trivial that no reasonable person would want to upgrade", and this is the rough
6966 test for when increasing PKGREVISION is appropriate. Examples of changes that
6967 do not merit increasing PKGREVISION are:
6969   * Changing HOMEPAGE, MAINTAINER, OWNER, or comments in Makefile.
6971   * Changing build variables if the resulting binary package is the same.
6973   * Changing DESCR.
6975   * Adding PKG_OPTIONS if the default options don't change.
6977 Examples of changes that do merit an increase to PKGREVISION include:
6979   * Security fixes
6981   * Changes or additions to a patch file
6983   * Changes to the PLIST
6985   * A dependency is changed or renamed.
6987 PKGREVISION must also be incremented when dependencies have ABI changes.
6989 19.1.12. Substituting variable text in the package files (the SUBST framework)
6991 When you want to replace the same text in multiple files or when the
6992 replacement text varies, patches alone cannot help. This is where the SUBST
6993 framework comes in. It provides an easy-to-use interface for replacing text in
6994 files. Example:
6996 SUBST_CLASSES+=                 fix-paths
6997 SUBST_STAGE.fix-paths=          pre-configure
6998 SUBST_MESSAGE.fix-paths=        Fixing absolute paths.
6999 SUBST_FILES.fix-paths=          src/*.c
7000 SUBST_FILES.fix-paths+=         scripts/*.sh
7001 SUBST_SED.fix-paths=            -e 's,"/usr/local,"${PREFIX},g'
7002 SUBST_SED.fix-paths+=           -e 's,"/var/log,"${VARBASE}/log,g'
7005 SUBST_CLASSES is a list of identifiers that are used to identify the different
7006 SUBST blocks that are defined. The SUBST framework is heavily used by pkgsrc,
7007 so it is important to always use the += operator with this variable. Otherwise
7008 some substitutions may be skipped.
7010 The remaining variables of each SUBST block are parameterized with the
7011 identifier from the first line (fix-paths in this case.) They can be seen as
7012 parameters to a function call.
7014 SUBST_STAGE.* specifies the stage at which the replacement will take place. All
7015 combinations of pre-, do- and post- together with a phase name are possible,
7016 though only few are actually used. Most commonly used are post-patch and
7017 pre-configure. Of these two, pre-configure should be preferred because then it
7018 is possible to run bmake patch and have the state after applying the patches
7019 but before making any other changes. This is especially useful when you are
7020 debugging a package in order to create new patches for it. Similarly,
7021 post-build is preferred over pre-install, because the install phase should
7022 generally be kept as simple as possible. When you use post-build, you have the
7023 same files in the working directory that will be installed later, so you can
7024 check if the substitution has succeeded.
7026 SUBST_MESSAGE.* is an optional text that is printed just before the
7027 substitution is done.
7029 SUBST_FILES.* is the list of shell globbing patterns that specifies the files
7030 in which the substitution will take place. The patterns are interpreted
7031 relatively to the WRKSRC directory.
7033 SUBST_SED.* is a list of arguments to sed(1) that specify the actual
7034 substitution. Every sed command should be prefixed with -e, so that all SUBST
7035 blocks look uniform.
7037 There are some more variables, but they are so seldomly used that they are only
7038 documented in the mk/subst.mk file.
7040 19.2. Fixing problems in the fetch phase
7042 19.2.1. Packages whose distfiles aren't available for plain downloading
7044 If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
7045 a make fetch will call files/getsite.sh with the name of each file to download
7046 as an argument, expecting it to output the URL of the directory from which to
7047 download it. graphics/ns-cult3d is an example of this usage.
7049 If the download can't be automated, because the user must submit personal
7050 information to apply for a password, or must pay for the source, or whatever,
7051 you can set FETCH_MESSAGE to a list of lines that are displayed to the user
7052 before aborting the build. Example:
7054 FETCH_MESSAGE=  "Please download the files"
7055 FETCH_MESSAGE+= "    "${DISTFILES:Q}
7056 FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
7059 19.2.2. How to handle modified distfiles with the 'old' name
7061 Sometimes authors of a software package make some modifications after the
7062 software was released, and they put up a new distfile without changing the
7063 package's version number. If a package is already in pkgsrc at that time, the
7064 checksum will no longer match. The contents of the new distfile should be
7065 compared against the old one before changing anything, to make sure the
7066 distfile was really updated on purpose, and that no trojan horse or so crept
7067 in. Please mention that the distfiles were compared and what was found in your
7068 commit message.
7070 Then, the correct way to work around this is to set DIST_SUBDIR to a unique
7071 directory name, usually based on PKGNAME_NOREV. All DISTFILES and PATCHFILES
7072 for this package will be put in that subdirectory of the local distfiles
7073 directory. (See Section 19.1.11, "How to handle incrementing versions when
7074 fixing an existing package" for more details.) In case this happens more often,
7075 PKGNAME can be used (thus including the nbX suffix) or a date stamp can be
7076 appended, like ${PKGNAME_NOREV}-YYYYMMDD.
7078 DIST_SUBDIR is also used when a distfile's name does not contain a version and
7079 the distfile is apt to change. In cases where the likelihood of this is very
7080 small, DIST_SUBDIR might not be required. Additionally, DIST_SUBDIR must not be
7081 removed unless the distfile name changes, even if a package is being moved or
7082 renamed.
7084 Do not forget regenerating the distinfo file after that, since it contains the
7085 DIST_SUBDIR path in the filenames. Also, increase the PKGREVISION if the
7086 installed package is different. Furthermore, a mail to the package's authors
7087 seems appropriate telling them that changing distfiles after releases without
7088 changing the file names is not good practice.
7090 19.3. Fixing problems in the configure phase
7092 19.3.1. Shared libraries - libtool
7094 pkgsrc supports many different machines, with different object formats like
7095 a.out and ELF, and varying abilities to do shared library and dynamic loading
7096 at all. To accompany this, varying commands and options have to be passed to
7097 the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
7098 especially if you don't have all the machines at your hand to test things. The
7099 devel/libtool pkg can help here, as it just "knows" how to build both static
7100 and dynamic libraries from a set of source files, thus being
7101 platform-independent.
7103 Here's how to use libtool in a package in seven simple steps:
7105  1. Add USE_LIBTOOL=yes to the package Makefile.
7107  2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
7108     {CC}". You could even add it to the definition of CC, if only libraries are
7109     being built in a given Makefile. This one command will build both PIC and
7110     non-PIC library objects, so you need not have separate shared and
7111     non-shared library rules.
7113  3. For the linking of the library, remove any "ar", "ranlib", and "ld
7114     -Bshareable" commands, and instead use:
7116     ${LIBTOOL} --mode=link \
7117         ${CC} -o ${.TARGET:.a=.la} \
7118             ${OBJS:.o=.lo} \
7119             -rpath ${PREFIX}/lib \
7120             -version-info major:minor
7123     Note that the library is changed to have a .la extension, and the objects
7124     are changed to have a .lo extension. Change OBJS as necessary. This
7125     automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
7126     necessary) in the build directory. Be sure to include "-version-info",
7127     especially when major and minor are zero, as libtool will otherwise strip
7128     off the shared library version.
7130     From the libtool manual:
7132     So, libtool library versions are described by three integers:
7134     CURRENT
7135     The most recent interface number that this library implements.
7137     REVISION
7138     The implementation number of the CURRENT interface.
7140     AGE
7141     The difference between the newest and oldest interfaces that
7142     this library implements.  In other words, the library implements
7143     all the interface numbers in the range from number `CURRENT -
7144     AGE' to `CURRENT'.
7146     If two libraries have identical CURRENT and AGE numbers, then the
7147     dynamic linker chooses the library with the greater REVISION number.
7150     The "-release" option will produce different results for a.out and ELF
7151     (excluding symlinks) in only one case. An ELF library of the form "
7152     libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
7153     platform. This is handled automatically.
7155     The "-rpath argument" is the install directory of the library being built.
7157     In the PLIST, include only the .la file, the other files will be added
7158     automatically.
7160  4. When linking shared object (.so) files, i.e. files that are loaded via
7161     dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
7162     them getting version tacked on.
7164     The PLIST file gets the foo.so entry.
7166  5. When linking programs that depend on these libraries before they are
7167     installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
7168     and it will find the correct libraries (static or shared), but please be
7169     aware that libtool will not allow you to specify a relative path in -L
7170     (such as "-L../somelib"), because it expects you to change that argument to
7171     be the .la file. e.g.
7173     ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
7176     should be changed to:
7178     ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
7181     and it will do the right thing with the libraries.
7183  6. When installing libraries, preface the install(1) or cp(1) command with "$
7184     {LIBTOOL} --mode=install", and change the library name to .la. e.g.
7186     ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
7189     This will install the static .a, shared library, any needed symlinks, and
7190     run ldconfig(8).
7192  7. In your PLIST, include only the .la file (this is a change from previous
7193     behaviour).
7195 19.3.2. Using libtool on GNU packages that already support libtool
7197 Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
7198 own libtool in most cases. For older libtool using packages, libtool is made by
7199 ltconfig script during the do-configure step; you can check the libtool script
7200 location by doing make configure; find work*/ -name libtool.
7202 LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
7203 override. By default, it is set to "libtool */libtool */*/libtool". If this
7204 does not match the location of the package's libtool script(s), set it as
7205 appropriate.
7207 If you do not need *.a static libraries built and installed, then use
7208 SHLIBTOOL_OVERRIDE instead.
7210 If your package makes use of the platform-independent library for loading
7211 dynamic shared objects, that comes with libtool (libltdl), you should include
7212 devel/libltdl/buildlink3.mk.
7214 Some packages use libtool incorrectly so that the package may not work or build
7215 in some circumstances. Some of the more common errors are:
7217   * The inclusion of a shared object (-module) as a dependent library in an
7218     executable or library. This in itself isn't a problem if one of two things
7219     has been done:
7221      1. The shared object is named correctly, i.e. libfoo.la, not foo.la
7223      2. The -dlopen option is used when linking an executable.
7225   * The use of libltdl without the correct calls to initialisation routines.
7226     The function lt_dlinit() should be called and the macro
7227     LTDL_SET_PRELOADED_SYMBOLS included in executables.
7229 19.3.3. GNU Autoconf/Automake
7231 If a package needs GNU autoconf or automake to be executed to regenerate the
7232 configure script and Makefile.in makefile templates, then they should be
7233 executed in a pre-configure target.
7235 For packages that need only autoconf:
7237 AUTOCONF_REQD=  2.50            # if default version is not good enough
7238 USE_TOOLS+=     autoconf        # use "autoconf213" for autoconf-2.13
7241 pre-configure:
7242         cd ${WRKSRC} && autoconf
7247 and for packages that need automake and autoconf:
7249 AUTOMAKE_REQD=  1.7.1           # if default version is not good enough
7250 USE_TOOLS+=     automake        # use "automake14" for automake-1.4
7253 pre-configure:
7254         set -e; cd ${WRKSRC}; \
7255         aclocal; autoheader; automake -a --foreign -i; autoconf
7260 Packages which use GNU Automake will almost certainly require GNU Make.
7262 There are times when the configure process makes additional changes to the
7263 generated files, which then causes the build process to try to re-execute the
7264 automake sequence. This is prevented by touching various files in the configure
7265 stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
7266 NO in the package Makefile.
7268 19.4. Programming languages
7270 19.4.1. C, C++, and Fortran
7272 Compilers for the C, C++, and Fortran languages comes with the NetBSD base
7273 system. By default, pkgsrc assumes that a package is written in C and will hide
7274 all other compilers (via the wrapper framework, see Chapter 14, Buildlink
7275 methodology).
7277 To declare which language's compiler a package needs, set the USE_LANGUAGES
7278 variable. Allowed values currently are "c", "c++", and "fortran" (and any
7279 combination). The default is "c". Packages using GNU configure scripts, even if
7280 written in C++, usually need a C compiler for the configure phase.
7282 19.4.2. Java
7284 If a program is written in Java, use the Java framework in pkgsrc. The package
7285 must include ../../mk/java-vm.mk. This Makefile fragment provides the following
7286 variables:
7288   * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is
7289     set to "run", then there is only a runtime dependency on the JDK. The
7290     default is "yes", which also adds a build dependency on the JDK.
7292   * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The
7293     supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2
7294     implementation, "1.4" insists on versions 1.4 or above, and "1.5" only
7295     accepts versions 1.5 or above. This variable is not set by default.
7297   * PKG_JAVA_HOME is automatically set to the runtime location of the used Java
7298     implementation dependency. It may be used to set JAVA_HOME to a good value
7299     if the program needs this variable to be defined.
7301 19.4.3. Packages containing perl scripts
7303 If your package contains interpreted perl scripts, add "perl" to the USE_TOOLS
7304 variable and set REPLACE_PERL to ensure that the proper interpreter path is
7305 set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that
7306 you want adjusted. Every occurrence of */bin/perl will be replaced with the
7307 full path to the perl executable.
7309 If a particular version of perl is needed, set the PERL5_REQD variable to the
7310 version number. The default is "5.0".
7312 See Section 19.6.6, "Packages installing perl modules" for information about
7313 handling perl modules.
7315 19.4.4. Packages containing shell scripts
7317 REPLACE_SH, REPLACE_BASH, REPLACE_CSH, and REPLACE_KSH can be used to replace
7318 shell hash bangs in files. Please use the appropriate one, prefering REPLACE_SH
7319 in case this shell is sufficient. When using REPLACE_BASH, don't forget to add
7320 bash to USE_TOOLS.
7322 19.4.5. Other programming languages
7324 Currently, there is no special handling for other languages in pkgsrc. If a
7325 compiler package provides a buildlink3.mk file, include that, otherwise just
7326 add a (build) dependency on the appropriate compiler package.
7328 19.5. Fixing problems in the build phase
7330 The most common failures when building a package are that some platforms do not
7331 provide certain header files, functions or libraries, or they provide the
7332 functions in a library that the original package author didn't know. To work
7333 around this, you can rewrite the source code in most cases so that it does not
7334 use the missing functions or provides a replacement function.
7336 19.5.1. Compiling C and C++ code conditionally
7338 If a package already comes with a GNU configure script, the preferred way to
7339 fix the build failure is to change the configure script, not the code. In the
7340 other cases, you can utilize the C preprocessor, which defines certain macros
7341 depending on the operating system and hardware architecture it compiles for.
7342 These macros can be queried using for example #if defined(__i386). Almost every
7343 operating system, hardware architecture and compiler has its own macro. For
7344 example, if the macros __GNUC__, __i386__ and __NetBSD__ are all defined, you
7345 know that you are using NetBSD on an i386 compatible CPU, and your compiler is
7346 GCC.
7348 The list of the following macros for hardware and operating system depends on
7349 the compiler that is used. For example, if you want to conditionally compile
7350 code on Solaris, don't use __sun__, as the SunPro compiler does not define it.
7351 Use __sun instead.
7353 19.5.1.1. C preprocessor macros to identify the operating system
7355 To distinguish between 4.4 BSD-derived systems and the rest of the world, you
7356 should use the following code.
7358 #include <sys/param.h>
7359 #if (defined(BSD) && BSD >= 199306)
7360 /* BSD-specific code goes here */
7361 #else
7362 /* non-BSD-specific code goes here */
7363 #endif
7365 If this distinction is not fine enough, you can also test for the following
7366 macros.
7368 Cygwin      __CYGWIN__
7369 DragonFly   __DragonFly__
7370 FreeBSD     __FreeBSD__
7371 Haiku       __HAIKU__
7372 Interix     __INTERIX
7373 IRIX        __sgi (TODO: get a definite source for this)
7374 Linux       linux, __linux, __linux__
7375 MirBSD      __MirBSD__ (__OpenBSD__ is also defined)
7376 Minix3      __minix
7377 NetBSD      __NetBSD__
7378 OpenBSD     __OpenBSD__
7379 Solaris     sun, __sun
7381 19.5.1.2. C preprocessor macros to identify the hardware architecture
7383 i386        i386, __i386, __i386__
7384 MIPS        __mips
7385 SPARC       sparc, __sparc
7387 19.5.1.3. C preprocessor macros to identify the compiler
7389 GCC         __GNUC__ (major version), __GNUC_MINOR__
7390 MIPSpro     _COMPILER_VERSION (0x741 for MIPSpro 7.41)
7391 SunPro      __SUNPRO_C (0x570 for Sun C 5.7)
7392 SunPro C++  __SUNPRO_CC (0x580 for Sun C++ 5.8)
7394 19.5.2. How to handle compiler bugs
7396 Some source files trigger bugs in the compiler, based on combinations of
7397 compiler version and architecture and almost always relation to optimisation
7398 being enabled. Common symptoms are gcc internal errors or never finishing
7399 compiling a file.
7401 Typically, a workaround involves testing the MACHINE_ARCH and compiler version,
7402 disabling optimisation for that combination of file, MACHINE_ARCH and compiler,
7403 and documenting it in pkgsrc/doc/HACKS. See that file for a number of examples.
7405 19.5.3. Undefined reference to "..."
7407 This error message often means that a package did not link to a shared library
7408 it needs. The following functions are known to cause this error message over
7409 and over.
7411 +-----------------------------------------------------+
7412 |        Function         |Library |Affected platforms|
7413 |-------------------------+--------+------------------|
7414 |accept, bind, connect    |-lsocket|Solaris           |
7415 |-------------------------+--------+------------------|
7416 |crypt                    |-lcrypt |DragonFly, NetBSD |
7417 |-------------------------+--------+------------------|
7418 |dlopen, dlsym            |-ldl    |Linux             |
7419 |-------------------------+--------+------------------|
7420 |gethost*                 |-lnsl   |Solaris           |
7421 |-------------------------+--------+------------------|
7422 |inet_aton                |-lresolv|Solaris           |
7423 |-------------------------+--------+------------------|
7424 |nanosleep, sem_*, timer_*|-lrt    |Solaris           |
7425 |-------------------------+--------+------------------|
7426 |openpty                  |-lutil  |Linux             |
7427 +-----------------------------------------------------+
7429 To fix these linker errors, it is often sufficient to say LIBS.OperatingSystem+
7430 = -lfoo to the package Makefile and then say bmake clean; bmake.
7432 19.5.3.1. Special issue: The SunPro compiler
7434 When you are using the SunPro compiler, there is another possibility. That
7435 compiler cannot handle the following code:
7437 extern int extern_func(int);
7439 static inline int
7440 inline_func(int x)
7442         return extern_func(x);
7445 int main(void)
7447         return 0;
7450 It generates the code for inline_func even if that function is never used. This
7451 code then refers to extern_func, which can usually not be resolved. To solve
7452 this problem you can try to tell the package to disable inlining of functions.
7454 19.5.4. Running out of memory
7456 Sometimes packages fail to build because the compiler runs into an operating
7457 system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be
7458 told to unlimit the resources. Currently, the allowed values are "datasize" and
7459 "stacksize" (or both). Setting this variable is similar to running the shell
7460 builtin ulimit command to raise the maximum data segment size or maximum stack
7461 size of a process, respectively, to their hard limits.
7463 19.6. Fixing problems in the install phase
7465 19.6.1. Creating needed directories
7467 The BSD-compatible install supplied with some operating systems cannot create
7468 more than one directory at a time. As such, you should call ${INSTALL_*_DIR}
7469 like this:
7471 ${INSTALL_DATA_DIR} ${PREFIX}/dir1
7472 ${INSTALL_DATA_DIR} ${PREFIX}/dir2
7475 You can also just append "dir1 dir2" to the INSTALLATION_DIRS variable, which
7476 will automatically do the right thing.
7478 19.6.2. Where to install documentation
7480 In general, documentation should be installed into ${PREFIX}/share/doc/$
7481 {PKGBASE} or ${PREFIX}/share/doc/${PKGNAME} (the latter includes the version
7482 number of the package).
7484 Many modern packages using GNU autoconf allow to set the directory where HTML
7485 documentation is installed with the "--with-html-dir" option. Sometimes using
7486 this flag is needed because otherwise the documentation ends up in ${PREFIX}/
7487 share/doc/html or other places.
7489 An exception to the above is that library API documentation generated with the
7490 textproc/gtk-doc tools, for use by special browsers (devhelp) should be left at
7491 their default location, which is ${PREFIX}/share/gtk-doc. Such documentation
7492 can be recognized from files ending in .devhelp or .devhelp2. (It is also
7493 acceptable to install such files in ${PREFIX}/share/doc/${PKGBASE} or ${PREFIX}
7494 /share/doc/${PKGNAME}; the .devhelp* file must be directly in that directory
7495 then, no additional subdirectory level is allowed in this case. This is usually
7496 achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/
7497 gtk-doc is preferred though.)
7499 19.6.3. Installing highscore files
7501 Certain packages, most of them in the games category, install a score file that
7502 allows all users on the system to record their highscores. In order for this to
7503 work, the binaries need to be installed setgid and the score files owned by the
7504 appropriate group and/or owner (traditionally the "games" user/group). Set
7505 USE_GAMESGROUP to yes to support this. The following variables, documented in
7506 more detail in mk/defaults/mk.conf, control this behaviour: GAMEDATAMODE,
7507 GAMEDIRMODE, GAMES_GROUP, GAMEMODE, GAME_USER.
7509 A package should therefore never hard code file ownership or access permissions
7510 but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly.
7512 19.6.4. Adding DESTDIR support to packages
7514 DESTDIR support means that a package installs into a staging directory, not the
7515 final location of the files. Then a binary package is created which can be used
7516 for installation as usual. There are two ways: Either the package must install
7517 as root ("destdir") or the package can install as non-root user ("user-destdir"
7520   * PKG_DESTDIR_SUPPORT has to be set to "none", "destdir", or "user-destdir".
7521     By default PKG_DESTDIR_SUPPORT is set to "user-destdir" to help catching
7522     more potential packaging problems. If bsd.prefs.mk is included in the
7523     Makefile, PKG_DESTDIR_SUPPORT needs to be set before the inclusion.
7525   * All installation operations have to be prefixed with ${DESTDIR}.
7527   * automake gets this DESTDIR mostly right automatically. Many manual rules
7528     and pre/post-install often are incorrect; fix them.
7530   * If files are installed with special owner/group use SPECIAL_PERMS.
7532   * In general, packages should support UNPRIVILEGED to be able to use DESTDIR.
7534 19.6.5. Packages with hardcoded paths to other interpreters
7536 Your package may also contain scripts with hardcoded paths to other
7537 interpreters besides (or as well as) perl. To correct the full pathname to the
7538 script interpreter, you need to set the following definitions in your Makefile
7539 (we shall use tclsh in this example):
7541 REPLACE_INTERPRETER+=   tcl
7542 REPLACE.tcl.old=        .*/bin/tclsh
7543 REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
7544 REPLACE_FILES.tcl=      # list of tcl scripts which need to be fixed,
7545 # relative to ${WRKSRC}, just as in REPLACE_PERL
7548 Note
7550 Before March 2006, these variables were called _REPLACE.* and _REPLACE_FILES.*.
7552 19.6.6. Packages installing perl modules
7554 Makefiles of packages providing perl5 modules should include the Makefile
7555 fragment ../../lang/perl5/module.mk. It provides a do-configure target for the
7556 standard perl configuration for such modules as well as various hooks to tune
7557 this configuration. See comments in this file for details.
7559 Perl5 modules will install into different places depending on the version of
7560 perl used during the build process. To address this, pkgsrc will append lines
7561 to the PLIST corresponding to the files listed in the installed .packlist file
7562 generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to
7563 a space-separated list of packlist files relative to PERL5_PACKLIST_DIR
7564 (PERL5_INSTALLVENDORARCH by default), e.g.:
7566 PERL5_PACKLIST= auto/Pg/.packlist
7569 The perl5 config variables installarchlib, installscript, installvendorbin,
7570 installvendorscript, installvendorarch, installvendorlib, installvendorman1dir,
7571 and installvendorman3dir represent those locations in which components of perl5
7572 modules may be installed, provided as variable with uppercase and prefixed with
7573 PERL5_, e.g. PERL5_INSTALLARCHLIB and may be used by perl5 packages that don't
7574 have a packlist. These variables are also substituted for in the PLIST as
7575 uppercase prefixed with PERL5_SUB_.
7577 19.6.7. Packages installing info files
7579 Some packages install info files or use the "makeinfo" or "install-info"
7580 commands. INFO_FILES should be defined in the package Makefile so that INSTALL
7581 and DEINSTALL scripts will be generated to handle registration of the info
7582 files in the Info directory file. The "install-info" command used for the info
7583 files registration is either provided by the system, or by a special purpose
7584 package automatically added as dependency if needed.
7586 PKGINFODIR is the directory under ${PREFIX} where info files are primarily
7587 located. PKGINFODIR defaults to "info" and can be overridden by the user.
7589 The info files for the package should be listed in the package PLIST; however
7590 any split info files need not be listed.
7592 A package which needs the "makeinfo" command at build time must add "makeinfo"
7593 to USE_TOOLS in its Makefile. If a minimum version of the "makeinfo" command is
7594 needed it should be noted with the TEXINFO_REQD variable in the package
7595 Makefile. By default, a minimum version of 3.12 is required. If the system does
7596 not provide a makeinfo command or if it does not match the required minimum, a
7597 build dependency on the devel/gtexinfo package will be added automatically.
7599 The build and installation process of the software provided by the package
7600 should not use the install-info command as the registration of info files is
7601 the task of the package INSTALL script, and it must use the appropriate 
7602 makeinfo command.
7604 To achieve this goal, the pkgsrc infrastructure creates overriding scripts for
7605 the install-info and makeinfo commands in a directory listed early in PATH.
7607 The script overriding install-info has no effect except the logging of a
7608 message. The script overriding makeinfo logs a message and according to the
7609 value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on
7610 error.
7612 19.6.8. Packages installing man pages
7614 All packages that install manual pages should install them into the same
7615 directory, so that there is one common place to look for them. In pkgsrc, this
7616 place is ${PREFIX}/${PKGMANDIR}, and this expression should be used in
7617 packages. The default for PKGMANDIR is "man". Another often-used value is "
7618 share/man".
7620 Note
7622 The support for a custom PKGMANDIR is far from complete.
7624 The PLIST files can just use man/ as the top level directory for the man page
7625 file entries, and the pkgsrc framework will convert as needed. In all other
7626 places, the correct PKGMANDIR must be used.
7628 Packages that are configured with GNU_CONFIGURE set as "yes", by default will
7629 use the ./configure --mandir switch to set where the man pages should be
7630 installed. The path is GNU_CONFIGURE_MANDIR which defaults to ${PREFIX}/$
7631 {PKGMANDIR}.
7633 Packages that use GNU_CONFIGURE but do not use --mandir, can set
7634 CONFIGURE_HAS_MANDIR to "no". Or if the ./configure script uses a non-standard
7635 use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed.
7637 See Section 13.5, "Man page compression" for information on installation of
7638 compressed manual pages.
7640 19.6.9. Packages installing GConf data files
7642 If a package installs .schemas or .entries files, used by GConf, you need to
7643 take some extra steps to make sure they get registered in the database:
7645  1. Include ../../devel/GConf/schemas.mk instead of its buildlink3.mk file.
7646     This takes care of rebuilding the GConf database at installation and
7647     deinstallation time, and tells the package where to install GConf data
7648     files using some standard configure arguments. It also disallows any access
7649     to the database directly from the package.
7651  2. Ensure that the package installs its .schemas files under ${PREFIX}/share/
7652     gconf/schemas. If they get installed under ${PREFIX}/etc, you will need to
7653     manually patch the package.
7655  3. Check the PLIST and remove any entries under the etc/gconf directory, as
7656     they will be handled automatically. See Section 9.13, "How do I change the
7657     location of configuration files?" for more information.
7659  4. Define the GCONF_SCHEMAS variable in your Makefile with a list of all
7660     .schemas files installed by the package, if any. Names must not contain any
7661     directories in them.
7663  5. Define the GCONF_ENTRIES variable in your Makefile with a list of all
7664     .entries files installed by the package, if any. Names must not contain any
7665     directories in them.
7667 19.6.10. Packages installing scrollkeeper/rarian data files
7669 If a package installs .omf files, used by scrollkeeper/rarian, you need to take
7670 some extra steps to make sure they get registered in the database:
7672  1. Include ../../mk/omf-scrollkeeper.mk instead of rarian's buildlink3.mk
7673     file. This takes care of rebuilding the scrollkeeper database at
7674     installation and deinstallation time, and disallows any access to it
7675     directly from the package.
7677  2. Check the PLIST and remove any entries under the libdata/scrollkeeper
7678     directory, as they will be handled automatically.
7680  3. Remove the share/omf directory from the PLIST. It will be handled by
7681     rarian. (make print-PLIST does this automatically.)
7683 19.6.11. Packages installing X11 fonts
7685 If a package installs font files, you will need to rebuild the fonts database
7686 in the directory where they get installed at installation and deinstallation
7687 time. This can be automatically done by using the pkginstall framework.
7689 You can list the directories where fonts are installed in the FONTS_DIRS.type
7690 variables, where type can be one of "ttf", "type1" or "x11". Also make sure
7691 that the database file fonts.dir is not listed in the PLIST.
7693 Note that you should not create new directories for fonts; instead use the
7694 standard ones to avoid that the user needs to manually configure his X server
7695 to find them.
7697 19.6.12. Packages installing GTK2 modules
7699 If a package installs GTK2 immodules or loaders, you need to take some extra
7700 steps to get them registered in the GTK2 database properly:
7702  1. Include ../../x11/gtk2/modules.mk instead of its buildlink3.mk file. This
7703     takes care of rebuilding the database at installation and deinstallation
7704     time.
7706  2. Set GTK2_IMMODULES=YES if your package installs GTK2 immodules.
7708  3. Set GTK2_LOADERS=YES if your package installs GTK2 loaders.
7710  4. Patch the package to not touch any of the GTK2 databases directly. These
7711     are:
7713       + libdata/gtk-2.0/gdk-pixbuf.loaders
7715       + libdata/gtk-2.0/gtk.immodules
7717  5. Check the PLIST and remove any entries under the libdata/gtk-2.0 directory,
7718     as they will be handled automatically.
7720 19.6.13. Packages installing SGML or XML data
7722 If a package installs SGML or XML data files that need to be registered in
7723 system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
7724 extra steps:
7726  1. Include ../../textproc/xmlcatmgr/catalogs.mk in your Makefile, which takes
7727     care of registering those files in system-wide catalogs at installation and
7728     deinstallation time.
7730  2. Set SGML_CATALOGS to the full path of any SGML catalogs installed by the
7731     package.
7733  3. Set XML_CATALOGS to the full path of any XML catalogs installed by the
7734     package.
7736  4. Set SGML_ENTRIES to individual entries to be added to the SGML catalog.
7737     These come in groups of three strings; see xmlcatmgr(1) for more
7738     information (specifically, arguments recognized by the 'add' action). Note
7739     that you will normally not use this variable.
7741  5. Set XML_ENTRIES to individual entries to be added to the XML catalog. These
7742     come in groups of three strings; see xmlcatmgr(1) for more information
7743     (specifically, arguments recognized by the 'add' action). Note that you
7744     will normally not use this variable.
7746 19.6.14. Packages installing extensions to the MIME database
7748 If a package provides extensions to the MIME database by installing .xml files
7749 inside ${PREFIX}/share/mime/packages, you need to take some extra steps to
7750 ensure that the database is kept consistent with respect to these new files:
7752  1. Include ../../databases/shared-mime-info/mimedb.mk (avoid using the
7753     buildlink3.mk file from this same directory, which is reserved for
7754     inclusion from other buildlink3.mk files). It takes care of rebuilding the
7755     MIME database at installation and deinstallation time, and disallows any
7756     access to it directly from the package.
7758  2. Check the PLIST and remove any entries under the share/mime directory, 
7759     except for files saved under share/mime/packages. The former are handled
7760     automatically by the update-mime-database program, but the latter are
7761     package-dependent and must be removed by the package that installed them in
7762     the first place.
7764  3. Remove any share/mime/* directories from the PLIST. They will be handled by
7765     the shared-mime-info package.
7767 19.6.15. Packages using intltool
7769 If a package uses intltool during its build, add intltool to the USE_TOOLS,
7770 which forces it to use the intltool package provided by pkgsrc, instead of the
7771 one bundled with the distribution file.
7773 This tracks intltool's build-time dependencies and uses the latest available
7774 version; this way, the package benefits of any bug fixes that may have appeared
7775 since it was released.
7777 19.6.16. Packages installing startup scripts
7779 If a package contains a rc.d script, it won't be copied into the startup
7780 directory by default, but you can enable it, by adding the option
7781 PKG_RCD_SCRIPTS=YES in mk.conf. This option will copy the scripts into /etc/
7782 rc.d when a package is installed, and it will automatically remove the scripts
7783 when the package is deinstalled.
7785 19.6.17. Packages installing TeX modules
7787 If a package installs TeX packages into the texmf tree, the ls-R database of
7788 the tree needs to be updated.
7790 Note
7792 Except the main TeX packages such as kpathsea, packages should install files
7793 into ${PREFIX}/share/texmf-dist, not ${PREFIX}/share/texmf.
7795  1. Include ../../print/kpathsea/texmf.mk. This takes care of rebuilding the
7796     ls-R database at installation and deinstallation time.
7798  2. If your package installs files into a texmf tree other than the one at $
7799     {PREFIX}/share/texmf-dist, set TEX_TEXMF_DIRS to the list of all texmf
7800     trees that need database update.
7802     If your package also installs font map files that need to be registered
7803     using updmap, include ../../print/tex-tetex/map.mk and set TEX_MAP_FILES
7804     and/or TEX_MIXEDMAP_FILES to the list of all such font map files. Then 
7805     updmap will be run automatically at installation/deinstallation to enable/
7806     disable font map files for TeX output drivers.
7808  3. Make sure that none of ls-R databases are included in PLIST, as they will
7809     be removed only by the kpathsea package.
7811 19.6.18. Packages supporting running binaries in emulation
7813 There are some packages that provide libraries and executables for running
7814 binaries from a one operating system on a different one (if the latter supports
7815 it). One example is running Linux binaries on NetBSD.
7817 The pkgtools/rpm2pkg helps in extracting and packaging Linux rpm packages.
7819 The CHECK_SHLIBS can be set to no to avoid the check-shlibs target, which tests
7820 if all libraries for each installed executable can be found by the dynamic
7821 linker. Since the standard dynamic linker is run, this fails for emulation
7822 packages, because the libraries used by the emulation are not in the standard
7823 directories.
7825 19.6.19. Packages installing hicolor theme icons
7827 If a package installs images under the share/icons/hicolor and/or updates the
7828 share/icons/hicolor/icon-theme.cache database, you need to take some extra
7829 steps to make sure that the shared theme directory is handled appropriately and
7830 that the cache database is rebuilt:
7832  1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk.
7834  2. Check the PLIST and remove the entry that refers to the theme cache.
7836  3. Ensure that the PLIST does not remove the shared icon directories from the
7837     share/icons/hicolor hierarchy because they will be handled automatically.
7839 The best way to verify that the PLIST is correct with respect to the last two
7840 points is to regenerate it using make print-PLIST.
7842 19.6.20. Packages installing desktop files
7844 If a package installs .desktop files under share/applications and these include
7845 MIME information (MimeType key), you need to take extra steps to ensure that
7846 they are registered into the MIME database:
7848  1. Include ../../sysutils/desktop-file-utils/desktopdb.mk.
7850  2. Check the PLIST and remove the entry that refers to the share/applications/
7851     mimeinfo.cache file. It will be handled automatically.
7853 The best way to verify that the PLIST is correct with respect to the last point
7854 is to regenerate it using make print-PLIST.
7856 19.7. Marking packages as having problems
7858 In some cases one does not have the time to solve a problem immediately. In
7859 this case, one can plainly mark a package as broken. For this, one just sets
7860 the variable BROKEN to the reason why the package is broken (similar to the
7861 RESTRICTED variable). A user trying to build the package will immediately be
7862 shown this message, and the build will not be even tried.
7864 BROKEN packages are removed from pkgsrc in irregular intervals.
7866 Chapter 20. Debugging
7868 To check out all the gotchas when building a package, here are the steps that I
7869 do in order to get a package working. Please note this is basically the same as
7870 what was explained in the previous sections, only with some debugging aids.
7872   * Be sure to set PKG_DEVELOPER=yes in mk.conf.
7874   * Install pkgtools/url2pkg, create a directory for a new package, change into
7875     it, then run url2pkg:
7877     % mkdir /usr/pkgsrc/category/examplepkg
7878     % cd /usr/pkgsrc/category/examplepkg
7879     % url2pkg http://www.example.com/path/to/distfile.tar.gz
7881   * Edit the Makefile as requested.
7883   * Fill in the DESCR file
7885   * Run make configure
7887   * Add any dependencies glimpsed from documentation and the configure step to
7888     the package's Makefile.
7890   * Make the package compile, doing multiple rounds of
7892     % make
7893     % pkgvi ${WRKSRC}/some/file/that/does/not/compile
7894     % mkpatches
7895     % patchdiff
7896     % mv ${WRKDIR}/.newpatches/* patches
7897     % make mps
7898     % make clean
7900     Doing this step as non-root user will ensure that no files are modified
7901     that shouldn't be, especially during the build phase. mkpatches, patchdiff
7902     and pkgvi are from the pkgtools/pkgdiff package.
7904   * Look at the Makefile, fix if necessary; see Section 11.1, "Makefile".
7906   * Generate a PLIST:
7908     # make install
7909     # make print-PLIST >PLIST
7910     # make deinstall
7911     # make install
7912     # make deinstall
7914     You usually need to be root to do this. Look if there are any files left:
7916     # make print-PLIST
7918     If this reveals any files that are missing in PLIST, add them.
7920   * Now that the PLIST is OK, install the package again and make a binary
7921     package:
7923     # make reinstall
7924     # make package
7926   * Delete the installed package:
7928     # pkg_delete examplepkg
7930   * Repeat the above make print-PLIST command, which shouldn't find anything
7931     now:
7933     # make print-PLIST
7935   * Reinstall the binary package:
7937     # pkg_add .../examplepkg.tgz
7939   * Play with it. Make sure everything works.
7941   * Run pkglint from pkgtools/pkglint, and fix the problems it reports:
7943     # pkglint
7945   * Submit (or commit, if you have cvs access); see Chapter 21, Submitting and
7946     Committing.
7948 Chapter 21. Submitting and Committing
7950 Table of Contents
7952 21.1. Submitting binary packages
7953 21.2. Submitting source packages (for non-NetBSD-developers)
7954 21.3. General notes when adding, updating, or removing packages
7955 21.4. Committing: Adding a package to CVS
7956 21.5. Updating a package to a newer version
7957 21.6. Renaming a package in pkgsrc
7958 21.7. Moving a package in pkgsrc
7960 21.1. Submitting binary packages
7962 Our policy is that we accept binaries only from pkgsrc developers to guarantee
7963 that the packages don't contain any trojan horses etc. This is not to annoy
7964 anyone but rather to protect our users! You're still free to put up your
7965 home-made binary packages and tell the world where to get them. NetBSD
7966 developers doing bulk builds and wanting to upload them please see
7967 Section 7.3.8, "Uploading results of a bulk build".
7969 21.2. Submitting source packages (for non-NetBSD-developers)
7971 First, check that your package is complete, compiles and runs well; see
7972 Chapter 20, Debugging and the rest of this document. Next, generate an
7973 uuencoded gzipped tar(1) archive that contains all files that make up the
7974 package. Finally, send this package to the pkgsrc bug tracking system, either
7975 with the send-pr(1) command, or if you don't have that, go to the web page
7976 http://www.NetBSD.org/support/send-pr.html, which contains some instructions
7977 and a link to a form where you can submit packages. The sysutils/gtk-send-pr
7978 package is also available as a substitute for either of the above two tools.
7980 In the form of the problem report, the category should be "pkg", the synopsis
7981 should include the package name and version number, and the description field
7982 should contain a short description of your package (contents of the COMMENT
7983 variable or DESCR file are OK). The uuencoded package data should go into the "
7984 fix" field.
7986 If you want to submit several packages, please send a separate PR for each one,
7987 it's easier for us to track things that way.
7989 Alternatively, you can also import new packages into pkgsrc-wip ("pkgsrc
7990 work-in-progress"); see the homepage at http://pkgsrc-wip.sourceforge.net/ for
7991 details.
7993 21.3. General notes when adding, updating, or removing packages
7995 Please note all package additions, updates, moves, and removals in pkgsrc/doc/
7996 CHANGES-YYYY. It's very important to keep this file up to date and conforming
7997 to the existing format, because it will be used by scripts to automatically
7998 update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/
7999 doc/TODO file and remove the entry for the package you updated or removed, in
8000 case it was mentioned there.
8002 When the PKGREVISION of a package is bumped, the change should appear in pkgsrc
8003 /doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps
8004 that result from a dependency being updated should not be mentioned. In all
8005 other cases it's the developer's decision.
8007 There is a make target that helps in creating proper CHANGES-YYYY entries: make
8008 changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The
8009 general usage is to first make sure that your CHANGES-YYYY file is up-to-date
8010 (to avoid having to resolve conflicts later-on) and then to cd to the package
8011 directory. For package updates, make changes-entry is enough. For new packages,
8012 or package moves or removals, set the CTYPE variable on the command line to
8013 "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if
8014 your local login name is not the same as your NetBSD login name. The target
8015 also automatically removes possibly existing entries for the package in the
8016 TODO file. Don't forget to commit the changes, e.g. by using make
8017 changes-entry-commit! If you are not using a checkout directly from
8018 cvs.NetBSD.org, but e.g. a local copy of the repository, you can set
8019 USE_NETBSD_REPO=yes. This makes the cvs commands use the main repository.
8021 21.4. Committing: Adding a package to CVS
8023 This section is only of interest for pkgsrc developers with write access to the
8024 pkgsrc repository.
8026 When the package is finished, "cvs add" the files. Start by adding the
8027 directory and then files in the directory. Don't forget to add the new package
8028 to the category's Makefile. Make sure you don't forget any files; you can check
8029 by running "cvs status". An example:
8031 $ cd .../pkgsrc/category
8032 $ cvs add pkgname
8033 $ cd pkgname
8034 $ cvs add DESCR Makefile PLIST distinfo buildlink3.mk patches
8035 $ cvs add patches/p*
8036 $ cvs status | less
8037 $ cvs commit
8038 $ cd ..
8039 $ vi Makefile # add SUBDIRS+=pkgname line
8040 $ cvs commit Makefile
8042 The commit message of the initial import should include part of the DESCR file,
8043 so people reading the mailing lists know what the package is/does.
8045 Also mention the new package in pkgsrc/doc/CHANGES-20xx.
8047 Previously, "cvs import" was suggested, but it was much easier to get wrong
8048 than "cvs add".
8050 21.5. Updating a package to a newer version
8052 Please always put a concise, appropriate and relevant summary of the changes
8053 between old and new versions into the commit log when updating a package. There
8054 are various reasons for this:
8056   * A URL is volatile, and can change over time. It may go away completely or
8057     its information may be overwritten by newer information.
8059   * Having the change information between old and new versions in our CVS
8060     repository is very useful for people who use either cvs or anoncvs.
8062   * Having the change information between old and new versions in our CVS
8063     repository is very useful for people who read the pkgsrc-changes mailing
8064     list, so that they can make tactical decisions about when to upgrade the
8065     package.
8067 Please also recognize that, just because a new version of a package has been
8068 released, it should not automatically be upgraded in the CVS repository. We
8069 prefer to be conservative in the packages that are included in pkgsrc -
8070 development or beta packages are not really the best thing for most places in
8071 which pkgsrc is used. Please use your judgement about what should go into
8072 pkgsrc, and bear in mind that stability is to be preferred above new and
8073 possibly untested features.
8075 21.6. Renaming a package in pkgsrc
8077 Renaming packages is not recommended.
8079 When renaming packages, be sure to fix any references to old name in other
8080 Makefiles, options, buildlink files, etc.
8082 Also When renaming a package, please define SUPERSEDES to the package name and
8083 dewey version pattern(s) of the previous package name. This may be repeated for
8084 multiple renames. The new package would be an exact replacement.
8086 Note that "successor" in the CHANGES-YYYY file doesn't necessarily mean that it
8087 supersedes, as that successor may not be an exact replacement but is a
8088 suggestion for the replaced functionality.
8090 21.7. Moving a package in pkgsrc
8092 It is preferred that packages are not renamed or moved, but if needed please
8093 follow these steps.
8095  1. Make a copy of the directory somewhere else.
8097  2. Remove all CVS dirs.
8099     Alternatively to the first two steps you can also do:
8101     % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
8103     and use that for further work.
8105  3. Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of 
8106     "../../category/package".
8108  4. In the modified package's Makefile, consider setting PREV_PKGPATH to the
8109     previous category/package pathname. The PREV_PKGPATH can be used by tools
8110     for doing an update using pkgsrc building; for example, it can search the
8111     pkg_summary(5) database for PREV_PKGPATH (if no SUPERSEDES) and then use
8112     the corresponding new PKGPATH for that moved package. Note that it may have
8113     multiple matches, so the tool should also check on the PKGBASE too. The
8114     PREV_PKGPATH probably has no value unless SUPERSEDES is not set, i.e.
8115     PKGBASE stays the same.
8117  5. cvs import the modified package in the new place.
8119  6. Check if any package depends on it:
8121     % cd /usr/pkgsrc
8122     % grep /package */*/Makefile* */*/buildlink*
8124  7. Fix paths in packages from step 5 to point to new location.
8126  8. cvs rm (-f) the package at the old location.
8128  9. Remove from oldcategory/Makefile.
8130 10. Add to newcategory/Makefile.
8132 11. Commit the changed and removed files:
8134     % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
8136     (and any packages from step 5, of course).
8138 Chapter 22. Frequently Asked Questions
8140 This section contains the answers to questions that may arise when you are
8141 writing a package. If you don't find your question answered here, first have a
8142 look in the other chapters, and if you still don't have the answer, ask on the
8143 pkgsrc-users mailing list.
8145 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
8146 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
8147 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
8148 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
8149     BUILDLINK_LIBS?
8150 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
8151 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
8152     the := inside it.
8153 22.7. Which mailing lists are there for package developers?
8154 22.8. Where is the pkgsrc documentation?
8155 22.9. I have a little time to kill. What shall I do?
8157 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
8159       MAKEFLAGS are the flags passed to the pkgsrc-internal invocations of make
8160       (1), while MAKE_FLAGS are the flags that are passed to the MAKE_PROGRAM
8161       when building the package. [FIXME: What is .MAKEFLAGS for?]
8163 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
8165       MAKE is the path to the make(1) program that is used in the pkgsrc
8166       infrastructure. GMAKE is the path to GNU Make, but you need to say
8167       USE_TOOLS+=gmake to use that. MAKE_PROGRAM is the path to the Make
8168       program that is used for building the package.
8170 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
8172       CC is the path to the real C compiler, which can be configured by the
8173       pkgsrc user. PKG_CC is the path to the compiler wrapper. PKGSRC_COMPILER
8174       is not a path to a compiler, but the type of compiler that should be
8175       used. See mk/compiler.mk for more information about the latter variable.
8177 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
8178       BUILDLINK_LIBS?
8180       [FIXME]
8182 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
8184       For optimization reasons, some variables are only available in the "
8185       wrapper" phase and later. To "simulate" the wrapper phase, append 
8186       PKG_PHASE=wrapper to the above command.
8188 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
8189       the := inside it.
8191       The := is not really an assignment operator, like you might expect at
8192       first sight. Instead, it is a degenerate form of ${LIST:old_string=
8193       new_string}, which is documented in the make(1) man page and which you
8194       may have seen as in ${SRCS:.c=.o}. In the case of MASTER_SITE_*,
8195       old_string is the empty string and new_string is package/. That's where
8196       the : and the = fall together.
8198 22.7. Which mailing lists are there for package developers?
8200       tech-pkg
8202           This is a list for technical discussions related to pkgsrc
8203           development, e.g. soliciting feedback for changes to pkgsrc
8204           infrastructure, proposed new features, questions related to porting
8205           pkgsrc to a new platform, advice for maintaining a package, patches
8206           that affect many packages, help requests moved from pkgsrc-users when
8207           an infrastructure bug is found, etc.
8209       pkgsrc-bugs
8211           All bug reports in category "pkg" sent with send-pr(1) appear here.
8212           Please do not report your bugs here directly; use one of the other
8213           mailing lists.
8215 22.8. Where is the pkgsrc documentation?
8217       There are many places where you can find documentation about pkgsrc:
8219         * The pkgsrc guide (this document) is a collection of chapters that
8220           explain large parts of pkgsrc, but some chapters tend to be outdated.
8221           Which ones they are is hard to say.
8223         * On the mailing list archives (see http://mail-index.NetBSD.org/), you
8224           can find discussions about certain features, announcements of new
8225           parts of the pkgsrc infrastructure and sometimes even announcements
8226           that a certain feature has been marked as obsolete. The benefit here
8227           is that each message has a date appended to it.
8229         * Many of the files in the mk/ directory start with a comment that
8230           describes the purpose of the file and how it can be used by the
8231           pkgsrc user and package authors. An easy way to find this
8232           documentation is to run bmake help.
8234         * The CVS log messages are a rich source of information, but they tend
8235           to be highly abbreviated, especially for actions that occur often.
8236           Some contain a detailed description of what has changed, but they are
8237           geared towards the other pkgsrc developers, not towards an average
8238           pkgsrc user. They also only document changes, so if you don't know
8239           what has been before, these messages may not be worth too much to
8240           you.
8242         * Some parts of pkgsrc are only "implicitly documented", that is the
8243           documentation exists only in the mind of the developer who wrote the
8244           code. To get this information, use the cvs annotate command to see
8245           who has written it and ask on the tech-pkg mailing list, so that
8246           others can find your questions later (see above). To be sure that the
8247           developer in charge reads the mail, you may CC him or her.
8249 22.9. I have a little time to kill. What shall I do?
8251       This is not really an FAQ yet, but here's the answer anyway.
8253         * Run pkg_chk -N (from the pkgtools/pkg_chk package). It will tell you
8254           about newer versions of installed packages that are available, but
8255           not yet updated in pkgsrc.
8257         * Browse pkgsrc/doc/TODO ? it contains a list of suggested new packages
8258           and a list of cleanups and enhancements for pkgsrc that would be nice
8259           to have.
8261         * Review packages for which review was requested on the pkgsrc-wip
8262           review mailing list.
8264 Chapter 23. GNOME packaging and porting
8266 Table of Contents
8268 23.1. Meta packages
8269 23.2. Packaging a GNOME application
8270 23.3. Updating GNOME to a newer version
8271 23.4. Patching guidelines
8273 Quoting GNOME's web site:
8275     The GNOME project provides two things: The GNOME desktop environment, an
8276     intuitive and attractive desktop for users, and the GNOME development
8277     platform, an extensive framework for building applications that integrate
8278     into the rest of the desktop.
8280 pkgsrc provides a seamless way to automatically build and install a complete
8281 GNOME environment under many different platforms. We can say with confidence
8282 that pkgsrc is one of the most advanced build and packaging systems for GNOME
8283 due to its included technologies buildlink3, the wrappers and tools framework
8284 and automatic configuration file management. Lots of efforts are put into
8285 achieving a completely clean deinstallation of installed software components.
8287 Given that pkgsrc is NetBSD's official packaging system, the above also means
8288 that great efforts are put into making GNOME work under this operating system.
8289 Recently, DragonFly BSD also adopted pkgsrc as its preferred packaging system,
8290 contributing lots of portability fixes to make GNOME build and install under
8293 This chapter is aimed at pkgsrc developers and other people interested in
8294 helping our GNOME porting and packaging efforts. It provides instructions on
8295 how to manage the existing packages and some important information regarding
8296 their internals.
8298 We need your help!
8300 Should you have some spare cycles to devote to NetBSD, pkgsrc and GNOME and are
8301 willing to learn new exciting stuff, please jump straight to the pending work
8302 list! There is still a long way to go to get a fully-functional GNOME desktop
8303 under NetBSD and we need your help to achieve it!
8305 23.1. Meta packages
8307 pkgsrc includes three GNOME-related meta packages:
8309   * meta-pkgs/gnome-base: Provides the core GNOME desktop environment. It only
8310     includes the necessary bits to get it to boot correctly, although it may
8311     lack important functionality for daily operation. The idea behind this
8312     package is to let end users build their own configurations on top of this
8313     one, first installing this meta package to achieve a functional setup and
8314     then adding individual applications.
8316   * meta-pkgs/gnome: Provides a complete installation of the GNOME platform and
8317     desktop as defined by the GNOME project; this is based on the components
8318     distributed in the platform/x.y/x.y.z/sources and desktop/x.y/x.y.z/sources
8319     directories of the official FTP server. Developer-only tools found in those
8320     directories are not installed unless required by some other component to
8321     work properly. Similarly, packages from the bindings set (bindings/x.y/
8322     x.y.z/sources) are not pulled in unless required as a dependency for an
8323     end-user component. This package "extends" meta-pkgs/gnome-base.
8325   * meta-pkgs/gnome-devel: Installs all the tools required to build a GNOME
8326     component when fetched from the CVS repository. These are required to let
8327     the autogen.sh scripts work appropriately.
8329 In all these packages, the DEPENDS lines are sorted in a way that eases
8330 updates: a package may depend on other packages listed before it but not on any
8331 listed after it. It is very important to keep this order to ease updates so... 
8332 do not change it to alphabetical sorting!
8334 23.2. Packaging a GNOME application
8336 Almost all GNOME applications are written in C and use a common set of tools as
8337 their build system. Things get different with the new bindings to other
8338 languages (such as Python), but the following will give you a general idea on
8339 the minimum required tools:
8341   * Almost all GNOME applications use the GNU Autotools as their build system.
8342     As a general rule you will need to tell this to your package:
8344     GNU_CONFIGURE=yes
8345     USE_LIBTOOL=yes
8346     USE_TOOLS+=gmake
8348   * If the package uses pkg-config to detect dependencies, add this tool to the
8349     list of required utilities:
8351     USE_TOOLS+=pkg-config
8353     Also use pkgtools/verifypc at the end of the build process to ensure that
8354     you did not miss to specify any dependency in your package and that the
8355     version requirements are all correct.
8357   * If the package uses intltool, be sure to add intltool to the USE_TOOLS to
8358     handle dependencies and to force the package to use the latest available
8359     version.
8361   * If the package uses gtk-doc (a documentation generation utility), do not
8362     add a dependency on it. The tool is rather big and the distfile should come
8363     with pregenerated documentation anyway; if it does not, it is a bug that
8364     you ought to report. For such packages you should disable gtk-doc (unless
8365     it is the default):
8367     CONFIGURE_ARGS+=--disable-gtk-doc
8369     The default location of installed HTML files (share/gtk-doc/<package-name>)
8370     is correct and should not be changed unless the package insists on
8371     installing them somewhere else. Otherwise programs as devhelp will not be
8372     able to open them. You can do that with an entry similar to:
8374     CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
8376 GNOME uses multiple shared directories and files under the installation prefix
8377 to maintain databases. In this context, shared means that those exact same
8378 directories and files are used among several different packages, leading to
8379 conflicts in the PLIST. pkgsrc currently includes functionality to handle the
8380 most common cases, so you have to forget about using @unexec ${RMDIR} lines in
8381 your file lists and omitting shared files from them. If you find yourself doing
8382 those, your package is most likely incorrect.
8384 The following table lists the common situations that result in using shared
8385 directories or files. For each of them, the appropriate solution is given.
8386 After applying the solution be sure to regenerate the package's file list with 
8387 make print-PLIST and ensure it is correct.
8389 Table 23.1. PLIST handling for GNOME packages
8391 +-----------------------------------------------------------------------------+
8392 |             If the package...             |             Then...             |
8393 |-------------------------------------------+---------------------------------|
8394 |                                           |See Section 19.6.10, "Packages   |
8395 |Installs OMF files under share/omf.        |installing scrollkeeper/rarian   |
8396 |                                           |data files".                     |
8397 |-------------------------------------------+---------------------------------|
8398 |Installs icons under the share/icons/      |See Section 19.6.19, "Packages   |
8399 |hicolor hierarchy or updates share/icons/  |installing hicolor theme icons". |
8400 |hicolor/icon-theme.cache.                  |                                 |
8401 |-------------------------------------------+---------------------------------|
8402 |                                           |See Section 19.6.14, "Packages   |
8403 |Installs files under share/mime/packages.  |installing extensions to the MIME|
8404 |                                           |database".                       |
8405 |-------------------------------------------+---------------------------------|
8406 |Installs .desktop files under share/       |See Section 19.6.20, "Packages   |
8407 |applications and these include MIME        |installing desktop files".       |
8408 |information.                               |                                 |
8409 +-----------------------------------------------------------------------------+
8412 23.3. Updating GNOME to a newer version
8414 When seeing GNOME as a whole, there are two kinds of updates:
8416 Major update
8418     Given that there is still a very long way for GNOME 3 (if it ever appears),
8419     we consider a major update one that goes from a 2.X version to a 2.Y one,
8420     where Y is even and greater than X. These are hard to achieve because they
8421     introduce lots of changes in the components' code and almost all GNOME
8422     distfiles are updated to newer versions. Some of them can even break API
8423     and ABI compatibility with the previous major version series. As a result,
8424     the update needs to be done all at once to minimize breakage.
8426     A major update typically consists of around 80 package updates and the
8427     addition of some new ones.
8429 Minor update
8431     We consider a minor update one that goes from a 2.A.X version to a 2.A.Y
8432     one where Y is greater than X. These are easy to achieve because they do
8433     not update all GNOME components, can be done in an incremental way and do
8434     not break API nor ABI compatibility.
8436     A minor update typically consists of around 50 package updates, although
8437     the numbers here may vary a lot.
8439 In order to update the GNOME components in pkgsrc to a new stable release
8440 (either major or minor), the following steps should be followed:
8442  1. Get a list of all the tarballs that form the new release by using the
8443     following commands. These will leave the full list of the components'
8444     distfiles into the list.txt file:
8446     % echo ls "*.tar.bz2" | \
8447         ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
8448         awk '{ print $9 }' >list.txt
8449     % echo ls "*.tar.bz2" | \
8450         ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
8451         awk '{ print $9 }' >>list.txt
8453  2. Open each meta package's Makefile and bump their version to the release you
8454     are updating them to. The three meta packages should be always consistent
8455     with versioning. Obviously remove any PKGREVISIONs that might be in them.
8457  3. For each meta package, update all its DEPENDS lines to match the latest
8458     versions as shown by the above commands. Do not list any newer version
8459     (even if found in the FTP) because the meta packages are supposed to list
8460     the exact versions that form a specific GNOME release. Exceptions are
8461     permitted here if a newer version solves a serious issue in the overall
8462     desktop experience; these typically come in the form of a revision bump in
8463     pkgsrc, not in newer versions from the developers.
8465     Packages not listed in the list.txt file should be updated to the latest
8466     version available (if found in pkgsrc). This is the case, for example, of
8467     the dependencies on the GNU Autotools in the meta-pkgs/gnome-devel meta
8468     package.
8470  4. Generate a patch from the modified meta packages and extract the list of
8471     "new" lines. This will provide you an outline on what packages need to be
8472     updated in pkgsrc and in what order:
8474     % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt
8476  5. For major desktop updates it is recommended to zap all your installed
8477     packages and start over from scratch at this point.
8479  6. Now comes the longest step by far: iterate over the contents of todo.txt
8480     and update the packages listed in it in order. For major desktop updates
8481     none of these should be committed until the entire set is completed because
8482     there are chances of breaking not-yet-updated packages.
8484  7. Once the packages are up to date and working, commit them to the tree one
8485     by one with appropriate log messages. At the end, commit the three meta
8486     package updates and all the corresponding changes to the doc/CHANGES-<YEAR>
8487     and pkgsrc/doc/TODO files.
8489 23.4. Patching guidelines
8491 GNOME is a very big component in pkgsrc which approaches 100 packages. Please,
8492 it is very important that you always, always, always feed back any portability
8493 fixes you do to a GNOME package to the mainstream developers (see
8494 Section 11.3.5, "Feedback to the author"). This is the only way to get their
8495 attention on portability issues and to ensure that future versions can be built
8496 out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further
8497 updates are. Those developers in charge of issuing major GNOME updates will be
8498 grateful if you do that.
8500 The most common places to report bugs are the GNOME's Bugzilla and the
8501 freedesktop.org's Bugzilla. Not all components use these to track bugs, but
8502 most of them do. Do not be short on your reports: always provide detailed
8503 explanations of the current failure, how it can be improved to achieve maximum
8504 portability and, if at all possible, provide a patch against CVS head. The more
8505 verbose you are, the higher chances of your patch being accepted.
8507 Also, please avoid using preprocessor magic to fix portability issues. While
8508 the FreeBSD GNOME people are doing a great job in porting GNOME to their
8509 operating system, the official GNOME sources are now plagued by conditionals
8510 that check for __FreeBSD__ and similar macros. This hurts portability. Please
8511 see our patching guidelines (Section 11.3.4, "Patching guidelines") for more
8512 details.
8514 Part III. The pkgsrc infrastructure internals
8516 This part of the guide deals with everything from the infrastructure that is
8517 behind the interfaces described in the developer's guide. A casual package
8518 maintainer should not need anything from this part.
8520 Table of Contents
8522 24. Design of the pkgsrc infrastructure
8524     24.1. The meaning of variable definitions
8525     24.2. Avoiding problems before they arise
8526     24.3. Variable evaluation
8528         24.3.1. At load time
8529         24.3.2. At runtime
8531     24.4. How can variables be specified?
8532     24.5. Designing interfaces for Makefile fragments
8534         24.5.1. Procedures with parameters
8535         24.5.2. Actions taken on behalf of parameters
8537     24.6. The order in which files are loaded
8539         24.6.1. The order in bsd.prefs.mk
8540         24.6.2. The order in bsd.pkg.mk
8542 25. Regression tests
8544     25.1. The regression tests framework
8545     25.2. Running the regression tests
8546     25.3. Adding a new regression test
8548         25.3.1. Overridable functions
8549         25.3.2. Helper functions
8551 26. Porting pkgsrc
8553     26.1. Porting pkgsrc to a new operating system
8554     26.2. Adding support for a new compiler
8556 Chapter 24. Design of the pkgsrc infrastructure
8558 Table of Contents
8560 24.1. The meaning of variable definitions
8561 24.2. Avoiding problems before they arise
8562 24.3. Variable evaluation
8564     24.3.1. At load time
8565     24.3.2. At runtime
8567 24.4. How can variables be specified?
8568 24.5. Designing interfaces for Makefile fragments
8570     24.5.1. Procedures with parameters
8571     24.5.2. Actions taken on behalf of parameters
8573 24.6. The order in which files are loaded
8575     24.6.1. The order in bsd.prefs.mk
8576     24.6.2. The order in bsd.pkg.mk
8578 The pkgsrc infrastructure consists of many small Makefile fragments. Each such
8579 fragment needs a properly specified interface. This chapter explains how such
8580 an interface looks like.
8582 24.1. The meaning of variable definitions
8584 Whenever a variable is defined in the pkgsrc infrastructure, the location and
8585 the way of definition provide much information about the intended use of that
8586 variable. Additionally, more documentation may be found in a header comment or
8587 in this pkgsrc guide.
8589 A special file is mk/defaults/mk.conf, which lists all variables that are
8590 intended to be user-defined. They are either defined using the ?= operator or
8591 they are left undefined because defining them to anything would effectively
8592 mean "yes". All these variables may be overridden by the pkgsrc user in the
8593 MAKECONF file.
8595 Outside this file, the following conventions apply: Variables that are defined
8596 using the ?= operator may be overridden by a package.
8598 Variables that are defined using the = operator may be used read-only at
8599 run-time.
8601 Variables whose name starts with an underscore must not be accessed outside the
8602 pkgsrc infrastructure at all. They may change without further notice.
8604 Note
8606 These conventions are currently not applied consistently to the complete pkgsrc
8607 infrastructure.
8609 24.2. Avoiding problems before they arise
8611 All variables that contain lists of things should default to being empty. Two
8612 examples that do not follow this rule are USE_LANGUAGES and DISTFILES. These
8613 variables cannot simply be modified using the += operator in package Makefiles
8614 (or other files included by them), since there is no guarantee whether the
8615 variable is already set or not, and what its value is. In the case of
8616 DISTFILES, the packages "know" the default value and just define it as in the
8617 following example.
8619 DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
8621 Because of the selection of this default value, the same value appears in many
8622 package Makefiles. Similarly for USE_LANGUAGES, but in this case the default
8623 value ("c") is so short that it doesn't stand out. Nevertheless it is mentioned
8624 in many files.
8626 24.3. Variable evaluation
8628 24.3.1. At load time
8630 Variable evaluation takes place either at load time or at runtime, depending on
8631 the context in which they occur. The contexts where variables are evaluated at
8632 load time are:
8634   * The right hand side of the := and != operators,
8636   * Make directives like .if or .for,
8638   * Dependency lines.
8640 A special exception are references to the iteration variables of .for loops,
8641 which are expanded inline, no matter in which context they appear.
8643 As the values of variables may change during load time, care must be taken not
8644 to evaluate them by accident. Typical examples for variables that should not be
8645 evaluated at load time are DEPENDS and CONFIGURE_ARGS. To make the effect more
8646 clear, here is an example:
8648 CONFIGURE_ARGS=         # none
8649 CFLAGS=                 -O
8650 CONFIGURE_ARGS+=        CFLAGS=${CFLAGS:Q}
8652 CONFIGURE_ARGS:=        ${CONFIGURE_ARGS}
8654 CFLAGS+=                -Wall
8657 This code shows how the use of the := operator can quickly lead to unexpected
8658 results. The first paragraph is fairly common code. The second paragraph
8659 evaluates the CONFIGURE_ARGS variable, which results in CFLAGS=-O. In the third
8660 paragraph, the -Wall is appended to the CFLAGS, but this addition will not
8661 appear in CONFIGURE_ARGS. In actual code, the three paragraphs from above
8662 typically occur in completely unrelated files.
8664 24.3.2. At runtime
8666 After all the files have been loaded, the values of the variables cannot be
8667 changed anymore. Variables that are used in the shell commands are expanded at
8668 this point.
8670 24.4. How can variables be specified?
8672 There are many ways in which the definition and use of a variable can be
8673 restricted in order to detect bugs and violations of the (mostly unwritten)
8674 policies. See the pkglint developer's documentation for further details.
8676 24.5. Designing interfaces for Makefile fragments
8678 Most of the .mk files fall into one of the following classes. Cases where a
8679 file falls into more than one class should be avoided as it often leads to
8680 subtle bugs.
8682 24.5.1. Procedures with parameters
8684 In a traditional imperative programming language some of the .mk files could be
8685 described as procedures. They take some input parameters and?after
8686 inclusion?provide a result in output parameters. Since all variables in
8687 Makefiles have global scope care must be taken not to use parameter names that
8688 have already another meaning. For example, PKGNAME is a bad choice for a
8689 parameter name.
8691 Procedures are completely evaluated at preprocessing time. That is, when
8692 calling a procedure all input parameters must be completely resolvable. For
8693 example, CONFIGURE_ARGS should never be an input parameter since it is very
8694 likely that further text will be added after calling the procedure, which would
8695 effectively apply the procedure to only a part of the variable. Also,
8696 references to other variables wit will be modified after calling the procedure.
8698 A procedure can declare its output parameters either as suitable for use in
8699 preprocessing directives or as only available at runtime. The latter
8700 alternative is for variables that contain references to other runtime
8701 variables.
8703 Procedures shall be written such that it is possible to call the procedure more
8704 than once. That is, the file must not contain multiple-inclusion guards.
8706 Examples for procedures are mk/bsd.options.mk and mk/buildlink3/bsd.builtin.mk.
8707 To express that the parameters are evaluated at load time, they should be
8708 assigned using the := operator, which should be used only for this purpose.
8710 24.5.2. Actions taken on behalf of parameters
8712 Action files take some input parameters and may define runtime variables. They
8713 shall not define loadtime variables. There are action files that are included
8714 implicitly by the pkgsrc infrastructure, while other must be included
8715 explicitly.
8717 An example for action files is mk/subst.mk.
8719 24.6. The order in which files are loaded
8721 Package Makefiles usually consist of a set of variable definitions, and include
8722 the file ../../mk/bsd.pkg.mk in the very last line. Before that, they may also
8723 include various other *.mk files if they need to query the availability of
8724 certain features like the type of compiler or the X11 implementation. Due to
8725 the heavy use of preprocessor directives like .if and .for, the order in which
8726 the files are loaded matters.
8728 This section describes at which point the various files are loaded and gives
8729 reasons for that order.
8731 24.6.1. The order in bsd.prefs.mk
8733 The very first action in bsd.prefs.mk is to define some essential variables
8734 like OPSYS, OS_VERSION and MACHINE_ARCH.
8736 Then, the user settings are loaded from the file specified in MAKECONF, which
8737 is usually mk.conf. After that, those variables that have not been overridden
8738 by the user are loaded from mk/defaults/mk.conf.
8740 After the user settings, the system settings and platform settings are loaded,
8741 which may override the user settings.
8743 Then, the tool definitions are loaded. The tool wrappers are not yet in effect.
8744 This only happens when building a package, so the proper variables must be used
8745 instead of the direct tool names.
8747 As the last steps, some essential variables from the wrapper and the package
8748 system flavor are loaded, as well as the variables that have been cached in
8749 earlier phases of a package build.
8751 24.6.2. The order in bsd.pkg.mk
8753 First, bsd.prefs.mk is loaded.
8755 Then, the various *-vars.mk files are loaded, which fill default values for
8756 those variables that have not been defined by the package. These variables may
8757 later be used even in unrelated files.
8759 Then, the file bsd.pkg.error.mk provides the target error-check that is added
8760 as a special dependency to all other targets that use DELAYED_ERROR_MSG or
8761 DELAYED_WARNING_MSG.
8763 Then, the package-specific hacks from hacks.mk are included.
8765 Then, various other files follow. Most of them don't have any dependencies on
8766 what they need to have included before or after them, though some do.
8768 The code to check PKG_FAIL_REASON and PKG_SKIP_REASON is then executed, which
8769 restricts the use of these variables to all the files that have been included
8770 before. Appearances in later files will be silently ignored.
8772 Then, the files for the main targets are included, in the order of later
8773 execution, though the actual order should not matter.
8775 At last, some more files are included that don't set any interesting variables
8776 but rather just define make targets to be executed.
8778 Chapter 25. Regression tests
8780 Table of Contents
8782 25.1. The regression tests framework
8783 25.2. Running the regression tests
8784 25.3. Adding a new regression test
8786     25.3.1. Overridable functions
8787     25.3.2. Helper functions
8789 The pkgsrc infrastructure consists of a large codebase, and there are many
8790 corners where every little bit of a file is well thought out, making pkgsrc
8791 likely to fail as soon as anything is changed near those parts. To prevent most
8792 changes from breaking anything, a suite of regression tests should go along
8793 with every important part of the pkgsrc infrastructure. This chapter describes
8794 how regression tests work in pkgsrc and how you can add new tests.
8796 25.1. The regression tests framework
8798 25.2. Running the regression tests
8800 You first need to install the pkgtools/pkg_regress package, which provides the 
8801 pkg_regress command. Then you can simply run that command, which will run all
8802 tests in the regress category.
8804 25.3. Adding a new regression test
8806 Every directory in the regress category that contains a file called spec is
8807 considered a regression test. This file is a shell program that is included by
8808 the pkg_regress command. The following functions can be overridden to suit your
8809 needs.
8811 25.3.1. Overridable functions
8813 These functions do not take any parameters. They are all called in "set -e"
8814 mode, so you should be careful to check the exitcodes of any commands you run
8815 in the test.
8817 do_setup()
8819     This function prepares the environment for the test. By default it does
8820     nothing.
8822 do_test()
8824     This function runs the actual test. By default, it calls TEST_MAKE with the
8825     arguments MAKEARGS_TEST and writes its output including error messages into
8826     the file TEST_OUTFILE.
8828 check_result()
8830     This function is run after the test and is typically used to compare the
8831     actual output from the one that is expected. It can make use of the various
8832     helper functions from the next section.
8834 do_cleanup()
8836     This function cleans everything up after the test has been run. By default
8837     it does nothing.
8839 25.3.2. Helper functions
8841 exit_status(expected)
8843     This function compares the exitcode of the do_test() function with its
8844     first parameter. If they differ, the test will fail.
8846 output_require(regex...)
8848     This function checks for each of its parameters if the output from do_test
8849     () matches the extended regular expression. If it does not, the test will
8850     fail.
8852 output_prohibit(regex...)
8854     This function checks for each of its parameters if the output from do_test
8855     () does not match the extended regular expression. If any of the regular
8856     expressions matches, the test will fail.
8858 Chapter 26. Porting pkgsrc
8860 Table of Contents
8862 26.1. Porting pkgsrc to a new operating system
8863 26.2. Adding support for a new compiler
8865 The pkgsrc system has already been ported to many operating systems, hardware
8866 architectures and compilers. This chapter explains the necessary steps to make
8867 pkgsrc even more portable.
8869 26.1. Porting pkgsrc to a new operating system
8871 To port pkgsrc to a new operating system (called MyOS in this example), you
8872 need to touch the following files:
8874 pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk
8876     This file contains some basic definitions, for example the name of the C
8877     compiler.
8879 mk/bsd.prefs.mk
8881     Insert code that defines the variables OPSYS, OS_VERSION, LOWER_OS_VERSION,
8882     LOWER_VENDOR, MACHINE_ARCH, OBJECT_FMT, APPEND_ELF, and the other variables
8883     that appear in this file.
8885 mk/platform/MyOS.mk
8887     This file contains the platform-specific definitions that are used by
8888     pkgsrc. Start by copying one of the other files and edit it to your needs.
8890 mk/platform/MyOS.pkg.dist
8892     This file contains a list of directories, together with their permission
8893     bits and ownership. These directories will be created automatically with
8894     every package that explicitly sets USE_MTREE. This feature will be removed.
8896 mk/platform/MyOS.x11.dist
8898     Just copy one of the pre-existing x11.dist files to your MyOS.x11.dist.
8900 mk/tools/bootstrap.mk
8902     On some operating systems, the tools that are provided with the base system
8903     are not good enough for pkgsrc. For example, there are many versions of sed
8904     (1) that have a narrow limit on the line length they can process. Therefore
8905     pkgsrc brings its own tools, which can be enabled here.
8907 mk/tools/tools.MyOS.mk
8909     This file defines the paths to all the tools that are needed by one or the
8910     other package in pkgsrc, as well as by pkgsrc itself. Find out where these
8911     tools are on your platform and add them.
8913 Now, you should be able to build some basic packages, like lang/perl5, shells/
8914 bash.
8916 26.2. Adding support for a new compiler
8918 TODO
8920 Appendix A. A simple example package: bison
8922 Table of Contents
8924 A.1. files
8926     A.1.1. Makefile
8927     A.1.2. DESCR
8928     A.1.3. PLIST
8929     A.1.4. Checking a package with pkglint
8931 A.2. Steps for building, installing, packaging
8933 We checked to find a piece of software that wasn't in the packages collection,
8934 and picked GNU bison. Quite why someone would want to have bison when Berkeley 
8935 yacc is already present in the tree is beyond us, but it's useful for the
8936 purposes of this exercise.
8938 A.1. files
8940 A.1.1. Makefile
8942 # $NetBSD$
8945 DISTNAME=       bison-1.25
8946 CATEGORIES=     devel
8947 MASTER_SITES=   ${MASTER_SITE_GNU}
8949 MAINTAINER=     pkgsrc-users@NetBSD.org
8950 HOMEPAGE=       http://www.gnu.org/software/bison/bison.html
8951 COMMENT=        GNU yacc clone
8953 GNU_CONFIGURE=  yes
8954 INFO_FILES=     yes
8956 .include "../../mk/bsd.pkg.mk"
8958 A.1.2. DESCR
8960 GNU version of yacc.  Can make re-entrant parsers, and numerous other
8961 improvements.  Why you would want this when Berkeley yacc(1) is part
8962 of the NetBSD source tree is beyond me.
8964 A.1.3. PLIST
8966 @comment $NetBSD$
8967 bin/bison
8968 man/man1/bison.1.gz
8969 share/bison.simple
8970 share/bison.hairy
8972 A.1.4. Checking a package with pkglint
8974 The NetBSD package system comes with pkgtools/pkglint which helps to check the
8975 contents of these files. After installation it is quite easy to use, just
8976 change to the directory of the package you wish to examine and execute pkglint:
8978 $ pkglint
8979 looks fine.
8981 Depending on the supplied command line arguments (see pkglint(1)), more checks
8982 will be performed. Use e.g. pkglint -Call -Wall for a very thorough check.
8984 A.2. Steps for building, installing, packaging
8986 Create the directory where the package lives, plus any auxiliary directories:
8988 # cd /usr/pkgsrc/lang
8989 # mkdir bison
8990 # cd bison
8991 # mkdir patches
8993 Create Makefile, DESCR and PLIST (see Chapter 11, Package components - files,
8994 directories and contents) then continue with fetching the distfile:
8996 # make fetch
8997 >> bison-1.25.tar.gz doesn't seem to exist on this system.
8998 >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
8999 Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
9000 ftp: Error retrieving file: 500 Internal error
9002 >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
9003 Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
9004 ftp: Error retrieving file: 500 Internal error
9006 >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
9007 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
9008 Successfully retrieved file.
9010 Generate the checksum of the distfile into distinfo:
9012 # make makedistinfo
9014 Now compile:
9016 # make
9017 >> Checksum OK for bison-1.25.tar.gz.
9018 ===>  Extracting for bison-1.25
9019 ===>  Patching for bison-1.25
9020 ===>   Ignoring empty patch directory
9021 ===>  Configuring for bison-1.25
9022 creating cache ./config.cache
9023 checking for gcc... cc
9024 checking whether we are using GNU C... yes
9025 checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
9026 checking how to run the C preprocessor... cc -E
9027 checking for minix/config.h... no
9028 checking for POSIXized ISC... no
9029 checking whether cross-compiling... no
9030 checking for ANSI C header files... yes
9031 checking for string.h... yes
9032 checking for stdlib.h... yes
9033 checking for memory.h... yes
9034 checking for working const... yes
9035 checking for working alloca.h... no
9036 checking for alloca... yes
9037 checking for strerror... yes
9038 updating cache ./config.cache
9039 creating ./config.status
9040 creating Makefile
9041 ===>  Building for bison-1.25
9042 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
9043 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
9044 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
9045 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
9046 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
9047 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
9048 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
9049 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
9050 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
9051 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
9052 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
9053 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
9054 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
9055 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
9056 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
9057 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
9058 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
9059 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
9060 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
9061 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
9062 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
9063 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
9064 ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
9065 rm -f bison.s1
9066 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
9068 Everything seems OK, so install the files:
9070 # make install
9071 >> Checksum OK for bison-1.25.tar.gz.
9072 ===>  Installing for bison-1.25
9073 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
9074 rm -f /usr/pkg/bin/bison
9075 cd /usr/pkg/share; rm -f bison.simple bison.hairy
9076 rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
9077 install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
9078 /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
9079 /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
9080 cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
9081 /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
9082 ===>  Registering installation for bison-1.25
9084 You can now use bison, and also - if you decide so - remove it with pkg_delete
9085 bison. Should you decide that you want a binary package, do this now:
9087 # make package
9088 >> Checksum OK for bison-1.25.tar.gz.
9089 ===>  Building package for bison-1.25
9090 Creating package bison-1.25.tgz
9091 Registering depends:.
9092 Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
9094 Now that you don't need the source and object files any more, clean up:
9096 # make clean
9097 ===>  Cleaning for bison-1.25
9099 Appendix B. Build logs
9101 Table of Contents
9103 B.1. Building figlet
9104 B.2. Packaging figlet
9106 B.1. Building figlet
9108 # make
9109 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9110 => figlet221.tar.gz doesn't seem to exist on this system.
9111 => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
9112 => [172219 bytes]
9113 Connected to ftp.plig.net.
9114 220 ftp.plig.org NcFTPd Server (licensed copy) ready.
9115 331 Guest login ok, send your complete e-mail address as password.
9116 230-You are user #5 of 500 simultaneous users allowed.
9117 230-
9118 230-  ___ _             _ _
9119 230- |  _| |_ ___   ___| |_|___   ___ ___ ___
9120 230- |  _|  _| . |_| . | | | . |_| . |  _| . |
9121 230- |_| |_| |  _|_|  _|_|_|_  |_|___|_| |_  |
9122 230-         |_|   |_|     |___|         |___|
9123 230-
9124 230-** Welcome to ftp.plig.org **
9125 230-
9126 230-Please note that all transfers from this FTP site are logged. If you
9127 230-do not like this, please disconnect now.
9128 230-
9129 230-This archive is available via
9130 230-
9131 230-HTTP:  http://ftp.plig.org/
9132 230-FTP:   ftp://ftp.plig.org/     (max 500 connections)
9133 230-RSYNC: rsync://ftp.plig.org/   (max  30 connections)
9134 230-
9135 230-Please email comments, bug reports and requests for packages to be
9136 230-mirrored to ftp-admin@plig.org.
9137 230-
9138 230-
9139 230 Logged in anonymously.
9140 Remote system type is UNIX.
9141 Using binary mode to transfer files.
9142 200 Type okay.
9143 250 "/pub" is new cwd.
9144 250-"/pub/figlet" is new cwd.
9145 250-
9146 250-Welcome to the figlet archive at ftp.figlet.org
9147 250-
9148 250-    ftp://ftp.figlet.org/pub/figlet/
9149 250-
9150 250-The official FIGlet web page is:
9151 250-    http://www.figlet.org/
9152 250-
9153 250-If you have questions, please mailto:info@figlet.org. If you want to
9154 250-contribute a font or something else, you can email us.
9156 250 "/pub/figlet/program" is new cwd.
9157 250 "/pub/figlet/program/unix" is new cwd.
9158 local: figlet221.tar.gz remote: figlet221.tar.gz
9159 502 Unimplemented command.
9160 227 Entering Passive Mode (195,40,6,41,246,104)
9161 150 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
9162 38% |**************                       | 65800      64.16 KB/s    00:01 ETA
9163 226 Transfer completed.
9164 172219 bytes received in 00:02 (75.99 KB/s)
9165 221 Goodbye.
9166 => Checksum OK for figlet221.tar.gz.
9167 ===> Extracting for figlet-2.2.1nb2
9168 ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found
9169 ===> Patching for figlet-2.2.1nb2
9170 ===> Applying pkgsrc patches for figlet-2.2.1nb2
9171 ===> Overriding tools for figlet-2.2.1nb2
9172 ===> Creating toolchain wrappers for figlet-2.2.1nb2
9173 ===> Configuring for figlet-2.2.1nb2
9174 ===> Building for figlet-2.2.1nb2
9175 gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\"  -DDEFAULTFONTFILE=\"standard.flf\"  figlet.c zipio.c crc.c inflate.c -o figlet
9176 chmod a+x figlet
9177 gcc -O2 -o chkfont chkfont.c
9178 => Unwrapping files-to-be-installed.
9180 # make install
9181 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9182 ===> Installing for figlet-2.2.1nb2
9183 install -d -o root -g wheel -m 755 /usr/pkg/bin
9184 install -d -o root -g wheel -m 755 /usr/pkg/man/man6
9185 mkdir -p /usr/pkg/share/figlet
9186 cp figlet /usr/pkg/bin
9187 cp chkfont /usr/pkg/bin
9188 chmod 555 figlist showfigfonts
9189 cp figlist /usr/pkg/bin
9190 cp showfigfonts /usr/pkg/bin
9191 cp fonts/*.flf /usr/pkg/share/figlet
9192 cp fonts/*.flc /usr/pkg/share/figlet
9193 cp figlet.6 /usr/pkg/man/man6
9194 ===> Registering installation for figlet-2.2.1nb2
9197 B.2. Packaging figlet
9199 # make package
9200 ===> Checking for vulnerabilities in figlet-2.2.1nb2
9201 ===> Packaging figlet-2.2.1nb2
9202 ===> Building binary package for figlet-2.2.1nb2
9203 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
9204 Using SrcDir value of /usr/pkg
9205 Registering depends:.
9208 Appendix C. Directory layout of the pkgsrc FTP server
9210 Table of Contents
9212 C.1. distfiles: The distributed source files
9213 C.2. misc: Miscellaneous things
9214 C.3. packages: Binary packages
9215 C.4. reports: Bulk build reports
9216 C.5. current, pkgsrc-20xxQy: source packages
9218 As in other big projects, the directory layout of pkgsrc is quite complex for
9219 newbies. This chapter explains where you find things on the FTP server. The
9220 base directory on ftp.NetBSD.org is /pub/pkgsrc/. On other servers it may be
9221 different, but inside this directory, everything should look the same, no
9222 matter on which server you are. This directory contains some subdirectories,
9223 which are explained below.
9225 C.1. distfiles: The distributed source files
9227 The directory distfiles contains lots of archive files from all pkgsrc
9228 packages, which are mirrored here. The subdirectories are called after their
9229 package names and are used when the distributed files have names that don't
9230 explicitly contain a version number or are otherwise too generic (for example
9231 release.tar.gz).
9233 C.2. misc: Miscellaneous things
9235 This directory contains things that individual pkgsrc developers find worth
9236 publishing.
9238 C.3. packages: Binary packages
9240 This directory contains binary packages for the various platforms that are
9241 supported by pkgsrc. Each subdirectory is of the form OPSYS/ARCH/OSVERSION_TAG.
9242 The meaning of these variables is:
9244   * OPSYS is the name of the operating system for which the packages have been
9245     built. The name is taken from the output of the uname command, so it may
9246     differ from the one you are used to hear.
9248   * ARCH is the hardware architecture of the platform for which the packages
9249     have been built. It also includes the ABI (Application Binary Interface)
9250     for platforms that have several of them.
9252   * OSVERSION is the version of the operating system. For version numbers that
9253     change often (for example NetBSD-current), the often-changing part should
9254     be replaced with an x, for example 4.99.x.
9256   * TAG is either 20xxQy for a stable branch, or head for packages built from
9257     the HEAD branch. The latter should only be used when the packages are
9258     updated on a regular basis. Otherwise the date from checking out pkgsrc
9259     should be appended, for example head_20071015.
9261 The rationale for exactly this scheme is that the pkgsrc users looking for
9262 binary packages can quickly click through the directories on the server and
9263 find the best binary packages for their machines. Since they usually know the
9264 operating system and the hardware architecture, OPSYS and ARCH are placed
9265 first. After these choices, they can select the best combination of OSVERSION
9266 and TAG together, since it is usually the case that packages stay compatible
9267 between different version of the operating system.
9269 In each of these directories, there is a whole binary packages collection for a
9270 specific platform. It has a directory called All which contains all binary
9271 packages. Besides that, there are various category directories that contain
9272 symbolic links to the real binary packages.
9274 C.4. reports: Bulk build reports
9276 Here are the reports from bulk builds, for those who want to fix packages that
9277 didn't build on some of the platforms. The structure of subdirectories should
9278 look like the one in Section C.3, "packages: Binary packages".
9280 C.5. current, pkgsrc-20xxQy: source packages
9282 These directories contain the "real" pkgsrc, that is the files that define how
9283 to create binary packages from source archives.
9285 The directory pkgsrc contains a snapshot of the CVS repository, which is
9286 updated regularly. The file pkgsrc.tar.gz contains the same as the directory,
9287 ready to be downloaded as a whole.
9289 In the directories for the quarterly branches, there is an additional file
9290 called pkgsrc-20xxQy.tar.gz, which contains the state of pkgsrc when it was
9291 branched.
9293 Appendix D. Editing guidelines for the pkgsrc guide
9295 Table of Contents
9297 D.1. Make targets
9298 D.2. Procedure
9300 This section contains information on editing the pkgsrc guide itself.
9302 D.1. Make targets
9304 The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several
9305 files are created from it:
9307   * pkgsrc/doc/pkgsrc.txt
9309   * pkgsrc/doc/pkgsrc.html
9311   * http://www.NetBSD.org/docs/pkgsrc/
9313   * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.pdf: The PDF version of the pkgsrc
9314     guide.
9316   * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps: PostScript version of the
9317     pkgsrc guide.
9319 D.2. Procedure
9321 The procedure to edit the pkgsrc guide is:
9323  1. Make sure you have the packages needed to regenerate the pkgsrc guide (and
9324     other XML-based NetBSD documentation) installed. These are automatically
9325     installed when you install the meta-pkgs/pkgsrc-guide-tools package.
9327  2. Run cd doc/guide to get to the right directory. All further steps will take
9328     place here.
9330  3. Edit the XML file(s) in files/.
9332  4. Run bmake to check the pkgsrc guide for valid XML and to build the final
9333     output files. If you get any errors at this stage, you can just edit the
9334     files, as there are only symbolic links in the working directory, pointing
9335     to the files in files/.
9337  5. (cd files && cvs commit)
9339  6. Run bmake clean && bmake to regenerate the output files with the proper RCS
9340     Ids.
9342  7. Run bmake regen to install and commit the files in both pkgsrc/doc and
9343     htdocs.
9345     Note
9347     If you have added, removed or renamed some chapters, you need to
9348     synchronize them using cvs add or cvs delete in the htdocs directory.