[BACK]Return to pkgsrc.txt CVS log [TXT][DIR] Up to [cvs.NetBSD.org] / pkgsrc / doc

Annotation of pkgsrc/doc/pkgsrc.txt, Revision 1.131

1.1       grant       1: The pkgsrc guide
                      2:
1.2       hubertf     3: Documentation on the NetBSD packages system
1.1       grant       4:
                      5: Alistair Crooks
                      6:
                      7: <agc@NetBSD.org>
                      8:
                      9: Hubert Feyrer
                     10:
                     11: <hubertf@NetBSD.org>
                     12:
1.3       hubertf    13: The pkgsrc Developers
1.2       hubertf    14:
1.105     rillig     15: Copyright   1994-2007 The NetBSD Foundation, Inc
1.1       grant      16:
1.107     rillig     17: $NetBSD: pkgsrc.xml,v 1.26 2007/09/18 08:17:21 rillig Exp $
1.1       grant      18:
                     19: Abstract
                     20:
1.74      rillig     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.
1.1       grant      25:
                     26: -------------------------------------------------------------------------------
                     27:
                     28: Table of Contents
                     29:
1.51      rillig     30: 1. What is pkgsrc?
1.20      ben        31:
1.1       grant      32:     1.1. Introduction
1.82      rillig     33:
                     34:         1.1.1. Why pkgsrc?
                     35:         1.1.2. Supported platforms
                     36:
1.1       grant      37:     1.2. Overview
                     38:     1.3. Terminology
1.74      rillig     39:
1.88      wiz        40:         1.3.1. Roles involved in pkgsrc
1.74      rillig     41:
1.1       grant      42:     1.4. Typography
1.20      ben        43:
1.46      gdt        44: I. The pkgsrc user's guide
1.20      ben        45:
1.59      rillig     46:     2. Where to get pkgsrc and how to keep it up-to-date
1.20      ben        47:
1.75      rillig     48:         2.1. Getting pkgsrc for the first time
                     49:
                     50:             2.1.1. As tar file
1.130     wiz        51:             2.1.2. Via anonymous CVS
1.75      rillig     52:
                     53:         2.2. Keeping pkgsrc up-to-date
                     54:
                     55:             2.2.1. Via tar files
                     56:             2.2.2. Via CVS
1.20      ben        57:
1.1       grant      58:     3. Using pkgsrc on systems other than NetBSD
1.20      ben        59:
1.82      rillig     60:         3.1. Binary distribution
                     61:         3.2. Bootstrapping pkgsrc
                     62:         3.3. Platform-specific notes
                     63:
                     64:             3.3.1. Darwin (Mac OS X)
                     65:             3.3.2. FreeBSD
                     66:             3.3.3. Interix
                     67:             3.3.4. IRIX
                     68:             3.3.5. Linux
                     69:             3.3.6. OpenBSD
                     70:             3.3.7. Solaris
1.20      ben        71:
1.1       grant      72:     4. Using pkgsrc
1.20      ben        73:
1.70      rillig     74:         4.1. Using binary packages
1.20      ben        75:
1.70      rillig     76:             4.1.1. Finding binary packages
                     77:             4.1.2. Installing binary packages
1.82      rillig     78:             4.1.3. Deinstalling packages
                     79:             4.1.4. Getting information about installed packages
                     80:             4.1.5. Checking for security vulnerabilities in installed packages
                     81:             4.1.6. Finding if newer versions of your installed packages are in
                     82:                 pkgsrc
                     83:             4.1.7. Other administrative functions
                     84:             4.1.8. A word of warning
1.20      ben        85:
1.1       grant      86:         4.2. Building packages from source
1.20      ben        87:
1.1       grant      88:             4.2.1. Requirements
                     89:             4.2.2. Fetching distfiles
                     90:             4.2.3. How to build and install
1.20      ben        91:
1.38      dillo      92:     5. Configuring pkgsrc
1.20      ben        93:
1.45      wiz        94:         5.1. General configuration
                     95:         5.2. Variables affecting the build process
1.110     rillig     96:         5.3. Variables affecting the installation process
1.104     wiz        97:         5.4. Selecting and configuring the compiler
1.78      rillig     98:
1.104     wiz        99:             5.4.1. Selecting the compiler
                    100:             5.4.2. Additional flags to the compiler (CFLAGS)
                    101:             5.4.3. Additional flags to the linker (LDFLAGS)
1.78      rillig    102:
1.104     wiz       103:         5.5. Developer/advanced settings
                    104:         5.6. Selecting Build Options
1.38      dillo     105:
                    106:     6. Creating binary packages
                    107:
                    108:         6.1. Building a single binary package
                    109:         6.2. Settings for creation of binary packages
                    110:
1.107     rillig    111:     7. Creating binary packages for everything in pkgsrc (bulk builds)
                    112:
                    113:         7.1. Think first, build later
                    114:         7.2. Requirements of a bulk build
                    115:         7.3. Running an old-style bulk build
                    116:
                    117:             7.3.1. Configuration
                    118:             7.3.2. Other environmental considerations
                    119:             7.3.3. Operation
                    120:             7.3.4. What it does
                    121:             7.3.5. Disk space requirements
                    122:             7.3.6. Setting up a sandbox for chrooted builds
                    123:             7.3.7. Building a partial set of packages
                    124:             7.3.8. Uploading results of a bulk build
                    125:
                    126:         7.4. Running a pbulk-style bulk build
                    127:
1.117     rillig    128:             7.4.1. Preparation
                    129:             7.4.2. Configuration
1.107     rillig    130:
                    131:         7.5. Creating a multiple CD-ROM packages collection
                    132:
                    133:             7.5.1. Example of cdpack
                    134:
                    135:     8. Directory layout of the installed files
                    136:
                    137:         8.1. File system layout in ${LOCALBASE}
                    138:         8.2. File system layout in ${VARBASE}
                    139:
                    140:     9. Frequently Asked Questions
                    141:
                    142:         9.1. Are there any mailing lists for pkg-related discussion?
                    143:         9.2. Where's the pkgviews documentation?
                    144:         9.3. Utilities for package management (pkgtools)
                    145:         9.4. How to use pkgsrc as non-root
                    146:         9.5. How to resume transfers when fetching distfiles?
                    147:         9.6. How can I install/use modular X.org from pkgsrc?
                    148:         9.7. How to fetch files from behind a firewall
                    149:         9.8. How do I tell make fetch to do passive FTP?
                    150:         9.9. How to fetch all distfiles at once
1.130     wiz       151:         9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc"
                    152:             mean?
                    153:         9.11. What does "Could not find bsd.own.mk" mean?
1.107     rillig    154:         9.12. Using 'sudo' with pkgsrc
                    155:         9.13. How do I change the location of configuration files?
                    156:         9.14. Automated security checks
                    157:         9.15. Why do some packages ignore my CFLAGS?
                    158:         9.16. A package does not build. What shall I do?
1.130     wiz       159:         9.17. What does "Makefile appears to contain unresolved cvs/rcs/???
                    160:             merge conflicts" mean?
1.20      ben       161:
1.46      gdt       162: II. The pkgsrc developer's guide
1.20      ben       163:
1.107     rillig    164:     10. Creating a new pkgsrc package from scratch
1.91      rillig    165:
1.107     rillig    166:         10.1. Common types of packages
1.91      rillig    167:
1.107     rillig    168:             10.1.1. Perl modules
                    169:             10.1.2. KDE applications
1.119     imil      170:             10.1.3. Python modules and programs
1.91      rillig    171:
1.107     rillig    172:         10.2. Examples
1.91      rillig    173:
1.107     rillig    174:             10.2.1. How the www/nvu package came into pkgsrc
1.91      rillig    175:
1.107     rillig    176:     11. Package components - files, directories and contents
1.20      ben       177:
1.107     rillig    178:         11.1. Makefile
                    179:         11.2. distinfo
                    180:         11.3. patches/*
1.85      jmmv      181:
1.107     rillig    182:             11.3.1. Structure of a single patch file
                    183:             11.3.2. Creating patch files
                    184:             11.3.3. Sources where the patch files come from
                    185:             11.3.4. Patching guidelines
                    186:             11.3.5. Feedback to the author
1.85      jmmv      187:
1.107     rillig    188:         11.4. Other mandatory files
                    189:         11.5. Optional files
1.78      rillig    190:
1.107     rillig    191:             11.5.1. Files affecting the binary package
                    192:             11.5.2. Files affecting the build process
                    193:             11.5.3. Files affecting nothing at all
1.78      rillig    194:
1.107     rillig    195:         11.6. work*
                    196:         11.7. files/*
1.20      ben       197:
1.107     rillig    198:     12. Programming in Makefiles
1.27      rillig    199:
1.107     rillig    200:         12.1. Caveats
                    201:         12.2. Makefile variables
1.27      rillig    202:
1.107     rillig    203:             12.2.1. Naming conventions
1.27      rillig    204:
1.107     rillig    205:         12.3. Code snippets
1.27      rillig    206:
1.107     rillig    207:             12.3.1. Adding things to a list
                    208:             12.3.2. Converting an internal list into an external list
                    209:             12.3.3. Passing variables to a shell command
                    210:             12.3.4. Quoting guideline
                    211:             12.3.5. Workaround for a bug in BSD Make
1.20      ben       212:
1.107     rillig    213:     13. PLIST issues
1.20      ben       214:
1.107     rillig    215:         13.1. RCS ID
                    216:         13.2. Semi-automatic PLIST generation
                    217:         13.3. Tweaking output of make print-PLIST
                    218:         13.4. Variable substitution in PLIST
                    219:         13.5. Man page compression
                    220:         13.6. Changing PLIST source with PLIST_SRC
                    221:         13.7. Platform-specific and differing PLISTs
                    222:         13.8. Sharing directories between packages
1.20      ben       223:
1.107     rillig    224:     14. Buildlink methodology
1.20      ben       225:
1.107     rillig    226:         14.1. Converting packages to use buildlink3
                    227:         14.2. Writing buildlink3.mk files
1.20      ben       228:
1.107     rillig    229:             14.2.1. Anatomy of a buildlink3.mk file
                    230:             14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
1.20      ben       231:
1.107     rillig    232:         14.3. Writing builtin.mk files
1.20      ben       233:
1.107     rillig    234:             14.3.1. Anatomy of a builtin.mk file
                    235:             14.3.2. Global preferences for native or pkgsrc software
1.20      ben       236:
1.107     rillig    237:     15. The pkginstall framework
1.20      ben       238:
1.107     rillig    239:         15.1. Files and directories outside the installation prefix
1.20      ben       240:
1.107     rillig    241:             15.1.1. Directory manipulation
                    242:             15.1.2. File manipulation
1.20      ben       243:
1.107     rillig    244:         15.2. Configuration files
1.35      jmmv      245:
1.107     rillig    246:             15.2.1. How PKG_SYSCONFDIR is set
                    247:             15.2.2. Telling the software where configuration files are
                    248:             15.2.3. Patching installations
                    249:             15.2.4. Disabling handling of configuration files
1.35      jmmv      250:
1.107     rillig    251:         15.3. System startup scripts
1.35      jmmv      252:
1.107     rillig    253:             15.3.1. Disabling handling of system startup scripts
1.35      jmmv      254:
1.107     rillig    255:         15.4. System users and groups
                    256:         15.5. System shells
1.35      jmmv      257:
1.107     rillig    258:             15.5.1. Disabling shell registration
1.65      hubertf   259:
1.107     rillig    260:         15.6. Fonts
1.65      hubertf   261:
1.107     rillig    262:             15.6.1. Disabling automatic update of the fonts databases
1.35      jmmv      263:
1.107     rillig    264:     16. Options handling
1.35      jmmv      265:
1.107     rillig    266:         16.1. Global default options
                    267:         16.2. Converting packages to use bsd.options.mk
                    268:         16.3. Option Names
1.108     rillig    269:         16.4. Determining the options of dependencies
1.35      jmmv      270:
1.107     rillig    271:     17. The build process
1.35      jmmv      272:
1.107     rillig    273:         17.1. Introduction
                    274:         17.2. Program location
                    275:         17.3. Directories used during the build process
                    276:         17.4. Running a phase
                    277:         17.5. The fetch phase
1.81      rillig    278:
1.107     rillig    279:             17.5.1. What to fetch and where to get it from
                    280:             17.5.2. How are the files fetched?
1.81      rillig    281:
1.107     rillig    282:         17.6. The checksum phase
                    283:         17.7. The extract phase
                    284:         17.8. The patch phase
                    285:         17.9. The tools phase
                    286:         17.10. The wrapper phase
                    287:         17.11. The configure phase
                    288:         17.12. The build phase
                    289:         17.13. The test phase
                    290:         17.14. The install phase
                    291:         17.15. The package phase
                    292:         17.16. Cleaning up
                    293:         17.17. Other helpful targets
1.35      jmmv      294:
1.107     rillig    295:     18. Tools needed for building or running
1.35      jmmv      296:
1.107     rillig    297:         18.1. Tools for pkgsrc builds
                    298:         18.2. Tools needed by packages
                    299:         18.3. Tools provided by platforms
                    300:         18.4. Questions regarding the tools
1.68      rillig    301:
1.107     rillig    302:     19. Making your package work
1.68      rillig    303:
1.107     rillig    304:         19.1. General operation
1.68      rillig    305:
1.107     rillig    306:             19.1.1. Portability of packages
1.130     wiz       307:             19.1.2. How to pull in user-settable variables from mk.conf
1.107     rillig    308:             19.1.3. User interaction
                    309:             19.1.4. Handling licenses
                    310:             19.1.5. Restricted packages
                    311:             19.1.6. Handling dependencies
                    312:             19.1.7. Handling conflicts with other packages
                    313:             19.1.8. Packages that cannot or should not be built
                    314:             19.1.9. Packages which should not be deleted, once installed
                    315:             19.1.10. Handling packages with security problems
                    316:             19.1.11. How to handle incrementing versions when fixing an
1.31      wiz       317:                 existing package
1.107     rillig    318:             19.1.12. Substituting variable text in the package files (the SUBST
1.79      rillig    319:                 framework)
1.20      ben       320:
1.107     rillig    321:         19.2. Fixing problems in the fetch phase
1.20      ben       322:
1.107     rillig    323:             19.2.1. Packages whose distfiles aren't available for plain
1.1       grant     324:                 downloading
1.107     rillig    325:             19.2.2. How to handle modified distfiles with the 'old' name
1.20      ben       326:
1.107     rillig    327:         19.3. Fixing problems in the configure phase
1.20      ben       328:
1.107     rillig    329:             19.3.1. Shared libraries - libtool
                    330:             19.3.2. Using libtool on GNU packages that already support libtool
                    331:             19.3.3. GNU Autoconf/Automake
                    332:
                    333:         19.4. Programming languages
                    334:
                    335:             19.4.1. C, C++, and Fortran
                    336:             19.4.2. Java
                    337:             19.4.3. Packages containing perl scripts
                    338:             19.4.4. Other programming languages
                    339:
                    340:         19.5. Fixing problems in the build phase
                    341:
                    342:             19.5.1. Compiling C and C++ code conditionally
                    343:             19.5.2. How to handle compiler bugs
1.130     wiz       344:             19.5.3. Undefined reference to "..."
1.107     rillig    345:             19.5.4. Running out of memory
                    346:
                    347:         19.6. Fixing problems in the install phase
                    348:
                    349:             19.6.1. Creating needed directories
                    350:             19.6.2. Where to install documentation
                    351:             19.6.3. Installing highscore files
                    352:             19.6.4. Adding DESTDIR support to packages
                    353:             19.6.5. Packages with hardcoded paths to other interpreters
                    354:             19.6.6. Packages installing perl modules
                    355:             19.6.7. Packages installing info files
                    356:             19.6.8. Packages installing man pages
1.108     rillig    357:             19.6.9. Packages installing GConf data files
1.120     mishka    358:             19.6.10. Packages installing scrollkeeper/rarian data files
1.107     rillig    359:             19.6.11. Packages installing X11 fonts
                    360:             19.6.12. Packages installing GTK2 modules
                    361:             19.6.13. Packages installing SGML or XML data
                    362:             19.6.14. Packages installing extensions to the MIME database
                    363:             19.6.15. Packages using intltool
                    364:             19.6.16. Packages installing startup scripts
                    365:             19.6.17. Packages installing TeX modules
                    366:             19.6.18. Packages supporting running binaries in emulation
                    367:             19.6.19. Packages installing hicolor theme icons
                    368:             19.6.20. Packages installing desktop files
                    369:
                    370:         19.7. Marking packages as having problems
                    371:
                    372:     20. Debugging
                    373:     21. Submitting and Committing
                    374:
                    375:         21.1. Submitting binary packages
                    376:         21.2. Submitting source packages (for non-NetBSD-developers)
                    377:         21.3. General notes when adding, updating, or removing packages
                    378:         21.4. Committing: Importing a package into CVS
                    379:         21.5. Updating a package to a newer version
1.123     reed      380:         21.6. Renaming a package in pkgsrc
                    381:         21.7. Moving a package in pkgsrc
1.107     rillig    382:
                    383:     22. Frequently Asked Questions
                    384:     23. GNOME packaging and porting
                    385:
                    386:         23.1. Meta packages
                    387:         23.2. Packaging a GNOME application
                    388:         23.3. Updating GNOME to a newer version
                    389:         23.4. Patching guidelines
1.69      rillig    390:
1.73      rillig    391: III. The pkgsrc infrastructure internals
1.72      rillig    392:
1.107     rillig    393:     24. Design of the pkgsrc infrastructure
1.72      rillig    394:
1.107     rillig    395:         24.1. The meaning of variable definitions
                    396:         24.2. Avoiding problems before they arise
                    397:         24.3. Variable evaluation
1.81      rillig    398:
1.107     rillig    399:             24.3.1. At load time
                    400:             24.3.2. At runtime
1.81      rillig    401:
1.107     rillig    402:         24.4. How can variables be specified?
                    403:         24.5. Designing interfaces for Makefile fragments
1.72      rillig    404:
1.107     rillig    405:             24.5.1. Procedures with parameters
                    406:             24.5.2. Actions taken on behalf of parameters
1.72      rillig    407:
1.107     rillig    408:         24.6. The order in which files are loaded
1.72      rillig    409:
1.107     rillig    410:             24.6.1. The order in bsd.prefs.mk
                    411:             24.6.2. The order in bsd.pkg.mk
1.73      rillig    412:
1.107     rillig    413:     25. Regression tests
1.73      rillig    414:
1.107     rillig    415:         25.1. The regression tests framework
                    416:         25.2. Running the regression tests
                    417:         25.3. Adding a new regression test
1.73      rillig    418:
1.107     rillig    419:             25.3.1. Overridable functions
                    420:             25.3.2. Helper functions
1.73      rillig    421:
1.107     rillig    422:     26. Porting pkgsrc
1.73      rillig    423:
1.107     rillig    424:         26.1. Porting pkgsrc to a new operating system
                    425:         26.2. Adding support for a new compiler
1.69      rillig    426:
1.46      gdt       427: A. A simple example package: bison
1.20      ben       428:
1.46      gdt       429:     A.1. files
1.20      ben       430:
1.46      gdt       431:         A.1.1. Makefile
                    432:         A.1.2. DESCR
                    433:         A.1.3. PLIST
                    434:         A.1.4. Checking a package with pkglint
1.20      ben       435:
1.46      gdt       436:     A.2. Steps for building, installing, packaging
1.20      ben       437:
1.46      gdt       438: B. Build logs
1.20      ben       439:
1.46      gdt       440:     B.1. Building figlet
                    441:     B.2. Packaging figlet
1.20      ben       442:
1.76      rillig    443: C. Directory layout of the pkgsrc FTP server
                    444:
1.128     jakllsch  445:     C.1. distfiles: The distributed source files
                    446:     C.2. misc: Miscellaneous things
                    447:     C.3. packages: Binary packages
                    448:     C.4. reports: Bulk build reports
                    449:     C.5. current, pkgsrc-20xxQy: source packages
1.76      rillig    450:
1.46      gdt       451: D. Editing guidelines for the pkgsrc guide
1.20      ben       452:
1.79      rillig    453:     D.1. Make targets
1.46      gdt       454:     D.2. Procedure
1.20      ben       455:
1.82      rillig    456: List of Tables
                    457:
                    458: 1.1. Platforms supported by pkgsrc
1.107     rillig    459: 11.1. Patching examples
                    460: 23.1. PLIST handling for GNOME packages
1.82      rillig    461:
1.51      rillig    462: Chapter 1. What is pkgsrc?
1.1       grant     463:
                    464: Table of Contents
                    465:
                    466: 1.1. Introduction
1.82      rillig    467:
                    468:     1.1.1. Why pkgsrc?
                    469:     1.1.2. Supported platforms
                    470:
1.1       grant     471: 1.2. Overview
                    472: 1.3. Terminology
1.74      rillig    473:
1.88      wiz       474:     1.3.1. Roles involved in pkgsrc
1.74      rillig    475:
1.1       grant     476: 1.4. Typography
                    477:
                    478: 1.1. Introduction
                    479:
1.82      rillig    480: There is a lot of software freely available for Unix-based systems, which is
                    481: usually available in form of the source code. Before such software can be used,
                    482: it needs to be configured to the local system, compiled and installed, and this
                    483: is exactly what The NetBSD Packages Collection (pkgsrc) does. pkgsrc also has
                    484: some basic commands to handle binary packages, so that not every user has to
                    485: build the packages for himself, which is a time-costly task.
1.1       grant     486:
                    487: pkgsrc currently contains several thousand packages, including:
                    488:
                    489:   * www/apache - The Apache web server
1.20      ben       490:
1.83      wiz       491:   * www/firefox - The Firefox web browser
1.20      ben       492:
1.1       grant     493:   * meta-pkgs/gnome - The GNOME Desktop Environment
1.20      ben       494:
1.1       grant     495:   * meta-pkgs/kde3 - The K Desktop Environment
1.20      ben       496:
1.1       grant     497: ...just to name a few.
                    498:
                    499: pkgsrc has built-in support for handling varying dependencies, such as pthreads
                    500: and X11, and extended features such as IPv6 support on a range of platforms.
                    501:
1.82      rillig    502: 1.1.1. Why pkgsrc?
                    503:
                    504: pkgsrc provides the following key features:
                    505:
                    506:   * Easy building of software from source as well as the creation and
                    507:     installation of binary packages. The source and latest patches are
                    508:     retrieved from a master or mirror download site, checksum verified, then
                    509:     built on your system. Support for binary-only distributions is available
                    510:     for both native platforms and NetBSD emulated platforms.
                    511:
                    512:   * All packages are installed in a consistent directory tree, including
                    513:     binaries, libraries, man pages and other documentation.
                    514:
                    515:   * Package dependencies, including when performing package updates, are
                    516:     handled automatically. The configuration files of various packages are
                    517:     handled automatically during updates, so local changes are preserved.
                    518:
                    519:   * Like NetBSD, pkgsrc is designed with portability in mind and consists of
                    520:     highly portable code. This allows the greatest speed of development when
                    521:     porting to new a platform. This portability also ensures that pkgsrc is
                    522:     consistent across all platforms.
                    523:
                    524:   * The installation prefix, acceptable software licenses, international
                    525:     encryption requirements and build-time options for a large number of
                    526:     packages are all set in a simple, central configuration file.
                    527:
                    528:   * The entire source (not including the distribution files) is freely
                    529:     available under a BSD license, so you may extend and adapt pkgsrc to your
                    530:     needs. Support for local packages and patches is available right out of the
                    531:     box, so you can configure it specifically for your environment.
                    532:
1.91      rillig    533: The following principles are basic to pkgsrc:
                    534:
                    535:   * "It should only work if it's right." ? That means, if a package contains
                    536:     bugs, it's better to find them and to complain about them rather than to
                    537:     just install the package and hope that it works. There are numerous checks
                    538:     in pkgsrc that try to find such bugs: Static analysis tools (pkgtools/
                    539:     pkglint), build-time checks (portability of shell scripts), and
                    540:     post-installation checks (installed files, references to shared libraries,
                    541:     script interpreters).
                    542:
                    543:   * "If it works, it should work everywhere" ? Like NetBSD has been ported to
                    544:     many hardware architectures, pkgsrc has been ported to many operating
                    545:     systems. Care is taken that packages behave the same on all platforms.
                    546:
1.82      rillig    547: 1.1.2. Supported platforms
                    548:
                    549: pkgsrc consists of both a source distribution and a binary distribution for
                    550: these operating systems. After retrieving the required source or binaries, you
                    551: can be up and running with pkgsrc in just minutes!
                    552:
1.1       grant     553: pkgsrc was derived from FreeBSD's ports system, and initially developed for
                    554: NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
                    555: platforms:
                    556:
1.82      rillig    557: Table 1.1. Platforms supported by pkgsrc
1.20      ben       558:
1.82      rillig    559: +----------------------------------------------------------------+
                    560: |                  Platform                   |Date Support Added|
                    561: |---------------------------------------------+------------------|
                    562: |NetBSD                                       |     Aug 1997     |
                    563: |---------------------------------------------+------------------|
                    564: |Solaris                                      |     Mar 1999     |
                    565: |---------------------------------------------+------------------|
                    566: |Linux                                        |     Jun 1999     |
                    567: |---------------------------------------------+------------------|
                    568: |Darwin (Mac OS X)                            |     Oct 2001     |
                    569: |---------------------------------------------+------------------|
                    570: |FreeBSD                                      |     Nov 2002     |
                    571: |---------------------------------------------+------------------|
                    572: |OpenBSD                                      |     Nov 2002     |
                    573: |---------------------------------------------+------------------|
                    574: |IRIX                                         |     Dec 2002     |
                    575: |---------------------------------------------+------------------|
                    576: |BSD/OS                                       |     Dec 2003     |
                    577: |---------------------------------------------+------------------|
                    578: |AIX                                          |     Dec 2003     |
                    579: |---------------------------------------------+------------------|
                    580: |Interix (Microsoft Windows Services for Unix)|     Mar 2004     |
                    581: |---------------------------------------------+------------------|
                    582: |DragonFlyBSD                                 |     Oct 2004     |
                    583: |---------------------------------------------+------------------|
                    584: |OSF/1                                        |     Nov 2004     |
1.99      wiz       585: |---------------------------------------------+------------------|
                    586: |HP-UX                                        |     Apr 2007     |
1.130     wiz       587: |---------------------------------------------+------------------|
                    588: |Haiku                                        |     Sep 2010     |
1.82      rillig    589: +----------------------------------------------------------------+
1.20      ben       590:
1.91      rillig    591:
1.1       grant     592: 1.2. Overview
                    593:
1.73      rillig    594: This document is divided into three parts. The first, The pkgsrc user's guide,
1.1       grant     595: describes how one can use one of the packages in the Package Collection, either
                    596: by installing a precompiled binary package, or by building one's own copy using
1.2       hubertf   597: the NetBSD package system. The second part, The pkgsrc developer's guide,
                    598: explains how to prepare a package so it can be easily built by other NetBSD
1.73      rillig    599: users without knowing about the package's building details. The third part, The
                    600: pkgsrc infrastructure internals is intended for those who want to understand
                    601: how pkgsrc is implemented.
1.20      ben       602:
1.73      rillig    603: This document is available in various formats: HTML, PDF, PS, TXT.
1.20      ben       604:
1.1       grant     605: 1.3. Terminology
                    606:
                    607: There has been a lot of talk about "ports", "packages", etc. so far. Here is a
                    608: description of all the terminology used within this document.
                    609:
                    610: Package
1.20      ben       611:
1.1       grant     612:     A set of files and building instructions that describe what's necessary to
                    613:     build a certain piece of software using pkgsrc. Packages are traditionally
                    614:     stored under /usr/pkgsrc.
1.20      ben       615:
1.1       grant     616: The NetBSD package system
1.20      ben       617:
1.1       grant     618:     This is the former name of "pkgsrc". It is part of the NetBSD operating
1.27      rillig    619:     system and can be bootstrapped to run on non-NetBSD operating systems as
                    620:     well. It handles building (compiling), installing, and removing of
                    621:     packages.
1.20      ben       622:
1.1       grant     623: Distfile
1.20      ben       624:
1.1       grant     625:     This term describes the file or files that are provided by the author of
                    626:     the piece of software to distribute his work. All the changes necessary to
                    627:     build on NetBSD are reflected in the corresponding package. Usually the
                    628:     distfile is in the form of a compressed tar-archive, but other types are
                    629:     possible, too. Distfiles are usually stored below /usr/pkgsrc/distfiles.
1.20      ben       630:
1.1       grant     631: Port
1.20      ben       632:
1.1       grant     633:     This is the term used by FreeBSD and OpenBSD people for what we call a
                    634:     package. In NetBSD terminology, "port" refers to a different architecture.
1.20      ben       635:
1.1       grant     636: Precompiled/binary package
1.20      ben       637:
1.1       grant     638:     A set of binaries built with pkgsrc from a distfile and stuffed together in
                    639:     a single .tgz file so it can be installed on machines of the same machine
                    640:     architecture without the need to recompile. Packages are usually generated
                    641:     in /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.
1.20      ben       642:
1.1       grant     643:     Sometimes, this is referred to by the term "package" too, especially in the
                    644:     context of precompiled packages.
1.20      ben       645:
1.1       grant     646: Program
1.20      ben       647:
1.1       grant     648:     The piece of software to be installed which will be constructed from all
1.47      reed      649:     the files in the distfile by the actions defined in the corresponding
1.1       grant     650:     package.
1.20      ben       651:
1.88      wiz       652: 1.3.1. Roles involved in pkgsrc
1.74      rillig    653:
                    654: pkgsrc users
                    655:
                    656:     The pkgsrc users are people who use the packages provided by pkgsrc.
                    657:     Typically they are system administrators. The people using the software
                    658:     that is inside the packages (maybe called "end users") are not covered by
                    659:     the pkgsrc guide.
                    660:
                    661:     There are two kinds of pkgsrc users: Some only want to install pre-built
                    662:     binary packages. Others build the pkgsrc packages from source, either for
                    663:     installing them directly or for building binary packages themselves. For
                    664:     pkgsrc users Part I, "The pkgsrc user's guide" should provide all necessary
                    665:     documentation.
                    666:
                    667: package maintainers
                    668:
                    669:     A package maintainer creates packages as described in Part II, "The pkgsrc
                    670:     developer's guide".
                    671:
                    672: infrastructure developers
                    673:
                    674:     These people are involved in all those files that live in the mk/ directory
                    675:     and below. Only these people should need to read through Part III, "The
                    676:     pkgsrc infrastructure internals", though others might be curious, too.
                    677:
1.1       grant     678: 1.4. Typography
                    679:
                    680: When giving examples for commands, shell prompts are used to show if the
                    681: command should/can be issued as root, or if "normal" user privileges are
1.27      rillig    682: sufficient. We use a # for root's shell prompt, and a % for users' shell
1.1       grant     683: prompt, assuming they use the C-shell or tcsh.
                    684:
1.48      dillo     685: Part I. The pkgsrc user's guide
1.1       grant     686:
                    687: Table of Contents
                    688:
1.59      rillig    689: 2. Where to get pkgsrc and how to keep it up-to-date
1.20      ben       690:
1.75      rillig    691:     2.1. Getting pkgsrc for the first time
                    692:
                    693:         2.1.1. As tar file
1.130     wiz       694:         2.1.2. Via anonymous CVS
1.75      rillig    695:
                    696:     2.2. Keeping pkgsrc up-to-date
                    697:
                    698:         2.2.1. Via tar files
                    699:         2.2.2. Via CVS
1.20      ben       700:
1.1       grant     701: 3. Using pkgsrc on systems other than NetBSD
1.20      ben       702:
1.82      rillig    703:     3.1. Binary distribution
                    704:     3.2. Bootstrapping pkgsrc
                    705:     3.3. Platform-specific notes
                    706:
                    707:         3.3.1. Darwin (Mac OS X)
                    708:         3.3.2. FreeBSD
                    709:         3.3.3. Interix
                    710:         3.3.4. IRIX
                    711:         3.3.5. Linux
                    712:         3.3.6. OpenBSD
                    713:         3.3.7. Solaris
1.20      ben       714:
1.1       grant     715: 4. Using pkgsrc
1.20      ben       716:
1.70      rillig    717:     4.1. Using binary packages
1.20      ben       718:
1.70      rillig    719:         4.1.1. Finding binary packages
                    720:         4.1.2. Installing binary packages
1.82      rillig    721:         4.1.3. Deinstalling packages
                    722:         4.1.4. Getting information about installed packages
                    723:         4.1.5. Checking for security vulnerabilities in installed packages
                    724:         4.1.6. Finding if newer versions of your installed packages are in
                    725:             pkgsrc
                    726:         4.1.7. Other administrative functions
                    727:         4.1.8. A word of warning
1.20      ben       728:
1.1       grant     729:     4.2. Building packages from source
1.20      ben       730:
1.1       grant     731:         4.2.1. Requirements
                    732:         4.2.2. Fetching distfiles
                    733:         4.2.3. How to build and install
1.20      ben       734:
1.38      dillo     735: 5. Configuring pkgsrc
                    736:
1.45      wiz       737:     5.1. General configuration
                    738:     5.2. Variables affecting the build process
1.110     rillig    739:     5.3. Variables affecting the installation process
1.104     wiz       740:     5.4. Selecting and configuring the compiler
1.78      rillig    741:
1.104     wiz       742:         5.4.1. Selecting the compiler
                    743:         5.4.2. Additional flags to the compiler (CFLAGS)
                    744:         5.4.3. Additional flags to the linker (LDFLAGS)
1.78      rillig    745:
1.104     wiz       746:     5.5. Developer/advanced settings
                    747:     5.6. Selecting Build Options
1.20      ben       748:
1.38      dillo     749: 6. Creating binary packages
                    750:
                    751:     6.1. Building a single binary package
                    752:     6.2. Settings for creation of binary packages
                    753:
1.107     rillig    754: 7. Creating binary packages for everything in pkgsrc (bulk builds)
                    755:
                    756:     7.1. Think first, build later
                    757:     7.2. Requirements of a bulk build
                    758:     7.3. Running an old-style bulk build
                    759:
                    760:         7.3.1. Configuration
                    761:         7.3.2. Other environmental considerations
                    762:         7.3.3. Operation
                    763:         7.3.4. What it does
                    764:         7.3.5. Disk space requirements
                    765:         7.3.6. Setting up a sandbox for chrooted builds
                    766:         7.3.7. Building a partial set of packages
                    767:         7.3.8. Uploading results of a bulk build
                    768:
                    769:     7.4. Running a pbulk-style bulk build
                    770:
1.117     rillig    771:         7.4.1. Preparation
                    772:         7.4.2. Configuration
1.107     rillig    773:
                    774:     7.5. Creating a multiple CD-ROM packages collection
                    775:
                    776:         7.5.1. Example of cdpack
                    777:
                    778: 8. Directory layout of the installed files
                    779:
                    780:     8.1. File system layout in ${LOCALBASE}
                    781:     8.2. File system layout in ${VARBASE}
                    782:
                    783: 9. Frequently Asked Questions
                    784:
                    785:     9.1. Are there any mailing lists for pkg-related discussion?
                    786:     9.2. Where's the pkgviews documentation?
                    787:     9.3. Utilities for package management (pkgtools)
                    788:     9.4. How to use pkgsrc as non-root
                    789:     9.5. How to resume transfers when fetching distfiles?
                    790:     9.6. How can I install/use modular X.org from pkgsrc?
                    791:     9.7. How to fetch files from behind a firewall
                    792:     9.8. How do I tell make fetch to do passive FTP?
                    793:     9.9. How to fetch all distfiles at once
1.130     wiz       794:     9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
                    795:     9.11. What does "Could not find bsd.own.mk" mean?
1.107     rillig    796:     9.12. Using 'sudo' with pkgsrc
                    797:     9.13. How do I change the location of configuration files?
                    798:     9.14. Automated security checks
                    799:     9.15. Why do some packages ignore my CFLAGS?
                    800:     9.16. A package does not build. What shall I do?
1.130     wiz       801:     9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
                    802:         conflicts" mean?
1.20      ben       803:
1.59      rillig    804: Chapter 2. Where to get pkgsrc and how to keep it up-to-date
1.1       grant     805:
                    806: Table of Contents
                    807:
1.75      rillig    808: 2.1. Getting pkgsrc for the first time
                    809:
                    810:     2.1.1. As tar file
1.130     wiz       811:     2.1.2. Via anonymous CVS
1.75      rillig    812:
                    813: 2.2. Keeping pkgsrc up-to-date
                    814:
                    815:     2.2.1. Via tar files
                    816:     2.2.2. Via CVS
                    817:
1.91      rillig    818: Before you download and extract the files, you need to decide where you want to
                    819: extract them. When using pkgsrc as root user, pkgsrc is usually installed in /
                    820: usr/pkgsrc. You are though free to install the sources and binary packages
                    821: wherever you want in your filesystem, provided that the pathname does not
                    822: contain white-space or other characters that are interpreted specially by the
                    823: shell and some other programs. A safe bet is to use only letters, digits,
                    824: underscores and dashes.
1.75      rillig    825:
                    826: 2.1. Getting pkgsrc for the first time
                    827:
                    828: Before you download any pkgsrc files, you should decide whether you want the
                    829: current branch or the stable branch. The latter is forked on a quarterly basis
                    830: from the current branch and only gets modified for security updates. The names
                    831: of the stable branches are built from the year and the quarter, for example
1.125     snj       832: 2009Q1.
1.1       grant     833:
1.75      rillig    834: The second step is to decide how you want to download pkgsrc. You can get it as
1.130     wiz       835: a tar file or via CVS. Both ways are described here.
1.1       grant     836:
1.75      rillig    837: 2.1.1. As tar file
1.1       grant     838:
1.75      rillig    839: The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/
                    840: pkgsrc/. There are a number of subdirectories for different purposes, which are
1.76      rillig    841: described in detail in Appendix C, Directory layout of the pkgsrc FTP server.
1.1       grant     842:
1.75      rillig    843: The tar file for the current branch is in the directory current and is called
                    844: pkgsrc.tar.gz. It is autogenerated daily.
                    845:
1.125     snj       846: The tar file for the stable branch 2009Q1 is in the directory pkgsrc-2009Q1 and
                    847: is also called pkgsrc-2009Q1.tar.gz.
1.75      rillig    848:
1.113     weinem    849: To download a pkgsrc stable tarball, run:
                    850:
1.128     jakllsch  851: $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-20xxQy/pkgsrc-20xxQy.tar.gz
1.113     weinem    852:
1.128     jakllsch  853: Where pkgsrc-20xxQy is the stable branch to be downloaded, for example,
1.125     snj       854: "pkgsrc-2009Q1".
1.113     weinem    855:
                    856: Then, extract it with:
                    857:
1.128     jakllsch  858: $ tar -xzf pkgsrc-20xxQy.tar.gz -C /usr
1.113     weinem    859:
                    860: This will create the directory pkgsrc/ in /usr/ and all the package source will
                    861: be stored under /usr/pkgsrc/.
                    862:
                    863: To download pkgsrc-current, run:
                    864:
                    865: $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
1.75      rillig    866:
1.130     wiz       867: 2.1.2. Via anonymous CVS
                    868:
                    869: To fetch a specific pkgsrc stable branch, run:
1.1       grant     870:
1.130     wiz       871: $ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-20xxQy -P pkgsrc
1.1       grant     872:
1.130     wiz       873: Where pkgsrc-20xxQy is the stable branch to be checked out, for example,
                    874: "pkgsrc-2009Q1"
                    875:
                    876: This will create the directory pkgsrc/ in your /usr/ directory and all the
                    877: package source will be stored under /usr/pkgsrc/.
1.1       grant     878:
1.130     wiz       879: To fetch the pkgsrc current branch, run:
1.114     weinem    880:
1.130     wiz       881: $ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
1.1       grant     882:
1.130     wiz       883: Refer to list of available CVS mirrors to choose faster one.
1.75      rillig    884:
1.130     wiz       885: If you get error messages from rsh, you need to set CVS_RSH variable. E.g.:
1.75      rillig    886:
1.130     wiz       887: $ cd /usr && env CVS_RSH=ssh cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
1.75      rillig    888:
1.130     wiz       889: Refer to documentation on your command shell how to set CVS_RSH=ssh
                    890: permanently. For Bourne shells, you can set it in your .profile or better
                    891: globally in /etc/profile:
1.1       grant     892:
1.130     wiz       893: # set CVS remote shell command
                    894: CVS_RSH=ssh
                    895: export CVS_RSH
1.113     weinem    896:
1.114     weinem    897: By default, CVS doesn't do things like most people would expect it to do. But
                    898: there is a way to convince CVS, by creating a file called .cvsrc in your home
1.113     weinem    899: directory and saving the following lines to it. This file will save you lots of
                    900: headache and some bug reports, so we strongly recommend it. You can find an
                    901: explanation of this file in the CVS documentation.
1.102     rillig    902:
                    903: # recommended CVS configuration file from the pkgsrc guide
1.130     wiz       904: cvs -q -z3
1.102     rillig    905: checkout -P
1.104     wiz       906: update -dP
                    907: diff -upN
1.102     rillig    908: rdiff -u
1.130     wiz       909: release -d
1.1       grant     910:
1.75      rillig    911: 2.2. Keeping pkgsrc up-to-date
                    912:
                    913: The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you
                    914: have first installed it via a tar file). It saves bandwidth and hard disk
                    915: activity, compared to downloading the tar file again.
                    916:
                    917: 2.2.1. Via tar files
                    918:
                    919: Warning
                    920:
1.77      rillig    921: When updating from a tar file, you first need to completely remove the old
                    922: pkgsrc directory. Otherwise those files that have been removed from pkgsrc in
                    923: the mean time will not be removed on your local disk, resulting in
                    924: inconsistencies. When removing the old files, any changes that you have done to
                    925: the pkgsrc files will be lost after updating. Therefore updating via CVS is
                    926: strongly recommended.
1.1       grant     927:
1.82      rillig    928: Note that by default the distfiles and the binary packages are saved in the
                    929: pkgsrc tree, so don't forget to rescue them before updating. You can also
                    930: configure pkgsrc to use other than the default directories by setting the
                    931: DISTDIR and PACKAGES variables. See Chapter 5, Configuring pkgsrc for the
                    932: details.
                    933:
1.75      rillig    934: To update pkgsrc from a tar file, download the tar file as explained above.
                    935: Then, make sure that you have not made any changes to the files in the pkgsrc
                    936: directory. Remove the pkgsrc directory and extract the new tar file. Done.
                    937:
                    938: 2.2.2. Via CVS
                    939:
                    940: To update pkgsrc via CVS, make sure the environment variable CVS_RSH is set as
1.114     weinem    941: above. Then, change to the pkgsrc directory and run cvs:
1.113     weinem    942:
1.114     weinem    943: $ cd /usr/pkgsrc
1.113     weinem    944: $ cvs update -dP
1.75      rillig    945:
                    946: 2.2.2.1. Switching between different pkgsrc branches
                    947:
                    948: When updating pkgsrc, the CVS program keeps track of the branch you selected.
                    949: But if you, for whatever reason, want to switch from the stable branch to the
                    950: current one, you can do it by adding the option "-A" after the "update"
                    951: keyword. To switch from the current branch back to the stable branch, add the
1.128     jakllsch  952: "-rpkgsrc-2009Q3" option.
1.75      rillig    953:
                    954: 2.2.2.2. What happens to my changes when updating?
                    955:
                    956: When you update pkgsrc, the CVS program will only touch those files that are
                    957: registered in the CVS repository. That means that any packages that you created
                    958: on your own will stay unmodified. If you change files that are managed by CVS,
                    959: later updates will try to merge your changes with those that have been done by
                    960: others. See the CVS manual, chapter "update" for details.
1.59      rillig    961:
1.1       grant     962: Chapter 3. Using pkgsrc on systems other than NetBSD
                    963:
                    964: Table of Contents
                    965:
1.82      rillig    966: 3.1. Binary distribution
                    967: 3.2. Bootstrapping pkgsrc
                    968: 3.3. Platform-specific notes
                    969:
                    970:     3.3.1. Darwin (Mac OS X)
                    971:     3.3.2. FreeBSD
                    972:     3.3.3. Interix
                    973:     3.3.4. IRIX
                    974:     3.3.5. Linux
                    975:     3.3.6. OpenBSD
                    976:     3.3.7. Solaris
                    977:
                    978: 3.1. Binary distribution
                    979:
1.110     rillig    980: See Section 4.1, "Using binary packages".
1.20      ben       981:
1.82      rillig    982: 3.2. Bootstrapping pkgsrc
1.20      ben       983:
1.82      rillig    984: Installing the bootstrap kit from source should be as simple as:
1.1       grant     985:
                    986: # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
                    987: # cd pkgsrc/bootstrap
                    988: # ./bootstrap
                    989:
1.87      wiz       990:
1.59      rillig    991: See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways
                    992: to get pkgsrc before bootstrapping. The given bootstrap command will use the
                    993: defaults of /usr/pkg for the prefix where programs will be installed in, and /
                    994: var/db/pkg for the package database directory where pkgsrc will do its internal
                    995: bookkeeping. However, these can also be set using command-line arguments.
1.1       grant     996:
1.47      reed      997: Note
                    998:
                    999: The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
                   1000: For examples in this guide, use bmake instead of "make".
                   1001:
1.82      rillig   1002: 3.3. Platform-specific notes
1.1       grant    1003:
                   1004: Here are some platform-specific notes you should be aware of.
                   1005:
1.82      rillig   1006: 3.3.1. Darwin (Mac OS X)
1.1       grant    1007:
1.128     jakllsch 1008: Darwin 5.x and up are supported. Before you start, you will need to download
                   1009: and install the Mac OS X Developer Tools from Apple's Developer Connection. See
                   1010: http://developer.apple.com/macosx/ for details. Also, make sure you install X11
                   1011: (an optional package included with the Developer Tools) if you intend to build
                   1012: packages that use the X11 Window System.
1.1       grant    1013:
1.82      rillig   1014: 3.3.2. FreeBSD
1.1       grant    1015:
                   1016: FreeBSD 4.7 and 5.0 have been tested and are supported, other versions may
                   1017: work.
                   1018:
                   1019: Care should be taken so that the tools that this kit installs do not conflict
                   1020: with the FreeBSD userland tools. There are several steps:
                   1021:
                   1022:  1. FreeBSD stores its ports pkg database in /var/db/pkg. It is therefore
                   1023:     recommended that you choose a different location (e.g. /usr/pkgdb) by using
                   1024:     the --pkgdbdir option to the bootstrap script.
1.20      ben      1025:
1.1       grant    1026:  2. If you do not intend to use the FreeBSD ports tools, it's probably a good
                   1027:     idea to move them out of the way to avoid confusion, e.g.
1.20      ben      1028:
1.1       grant    1029:     # cd /usr/sbin
                   1030:     # mv pkg_add pkg_add.orig
                   1031:     # mv pkg_create pkg_create.orig
                   1032:     # mv pkg_delete pkg_delete.orig
                   1033:     # mv pkg_info pkg_info.orig
1.20      ben      1034:
1.87      wiz      1035:
1.105     rillig   1036:  3. An example mk.conf file will be placed in /etc/mk.conf.example file when
                   1037:     you use the bootstrap script.
1.20      ben      1038:
1.82      rillig   1039: 3.3.3. Interix
1.1       grant    1040:
1.47      reed     1041: Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a
1.1       grant    1042: Unix-like environment with a tighter kernel integration than available with
                   1043: Cygwin. It is part of the Windows Services for Unix package, available for free
1.22      tv       1044: for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU
                   1045: can be downloaded from http://www.microsoft.com/windows/sfu/.
1.1       grant    1046:
1.93      rillig   1047: Services for Unix 3.5 has been tested. 3.0 or 3.1 may work, but are not
                   1048: officially supported. (The main difference in 3.0/3.1 is lack of pthreads, but
                   1049: other parts of libc may also be lacking.)
                   1050:
                   1051: Services for Unix Applications (aka SUA) is an integrated component of Windows
1.130     wiz      1052: Server 2003 R2 (5.2), Windows Vista and Windows Server 2008 (6.0), Windows 7
1.131   ! wiz      1053: and Windows Server 2008 R2 (6.1). As of this writing, the SUA's Interix 6.0
        !          1054: (32bit) and 6.1 (64bit) subsystems have been tested. Other versions may work as
        !          1055: well. The Interix 5.x subsystem has not yet been tested with pkgsrc.
1.1       grant    1056:
1.82      rillig   1057: 3.3.3.1. When installing Interix/SFU
1.1       grant    1058:
                   1059: At an absolute minimum, the following packages must be installed from the
                   1060: Windows Services for Unix 3.5 distribution in order to use pkgsrc:
                   1061:
                   1062:   * Utilities -> Base Utilities
1.20      ben      1063:
1.1       grant    1064:   * Interix GNU Components -> (all)
1.20      ben      1065:
1.1       grant    1066:   * Remote Connectivity
1.20      ben      1067:
1.1       grant    1068:   * Interix SDK
1.20      ben      1069:
1.1       grant    1070: When using pkgsrc on Interix, DO NOT install the Utilities subcomponent "UNIX
                   1071: Perl". That is Perl 5.6 without shared module support, installed to /usr/local,
                   1072: and will only cause confusion. Instead, install Perl 5.8 from pkgsrc (or from a
                   1073: binary package).
                   1074:
                   1075: The Remote Connectivity subcomponent "Windows Remote Shell Service" does not
                   1076: need to be installed, but Remote Connectivity itself should be installed in
                   1077: order to have a working inetd.
                   1078:
1.52      tv       1079: During installation you may be asked whether to enable setuid behavior for
                   1080: Interix programs, and whether to make pathnames default to case-sensitive.
1.1       grant    1081: Setuid should be enabled, and case-sensitivity MUST be enabled. (Without
                   1082: case-sensitivity, a large number of packages including perl will not build.)
                   1083:
1.52      tv       1084: NOTE: Newer Windows service packs change the way binary execution works (via
                   1085: the Data Execution Prevention feature). In order to use pkgsrc and other
                   1086: gcc-compiled binaries reliably, a hotfix containing POSIX.EXE, PSXDLL.DLL,
                   1087: PSXRUN.EXE, and PSXSS.EXE (899522 or newer) must be installed. Hotfixes are
1.115     jmcneill 1088: available from Microsoft through a support contract; however, Debian Interix
                   1089: Port has made most Interix hotfixes available for personal use from http://
                   1090: www.debian-interix.net/hotfixes/.
1.52      tv       1091:
1.93      rillig   1092: In addition to the hotfix noted above, it may be necessary to disable Data
                   1093: Execution Prevention entirely to make Interix functional. This may happen only
                   1094: with certain types of CPUs; the cause is not fully understood at this time. If
                   1095: gcc or other applications still segfault repeatedly after installing one of the
                   1096: hotfixes note above, the following option can be added to the appropriate
                   1097: "boot.ini" line on the Windows boot drive: /NoExecute=AlwaysOff (WARNING, this
                   1098: will disable DEP completely, which may be a security risk if applications are
                   1099: often run as a user in the Administrators group!)
                   1100:
1.82      rillig   1101: 3.3.3.2. What to do if Interix/SFU is already installed
1.1       grant    1102:
                   1103: If SFU is already installed and you wish to alter these settings to work with
                   1104: pkgsrc, note the following things.
                   1105:
                   1106:   * To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft Windows
                   1107:     Services for UNIX, then click Change. In the installer, choose Add or
                   1108:     Remove, then uncheck Utilities->UNIX Perl.
1.20      ben      1109:
1.47      reed     1110:   * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change
1.1       grant    1111:     the following registry key:
1.20      ben      1112:
1.1       grant    1113:     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
1.20      ben      1114:
1.1       grant    1115:     Set the DWORD value "obcaseinsensitive" to 0; then reboot.
1.20      ben      1116:
1.1       grant    1117:   * To enable setuid binaries (optional), run REGEDIT.EXE, and change the
                   1118:     following registry key:
1.20      ben      1119:
1.1       grant    1120:     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX
1.20      ben      1121:
1.1       grant    1122:     Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.
1.20      ben      1123:
1.82      rillig   1124: 3.3.3.3. Important notes for using pkgsrc
1.1       grant    1125:
1.52      tv       1126: The package manager (either the pkgsrc "su" user, or the user running
1.1       grant    1127: "pkg_add") must be a member of the local Administrators group. Such a user must
                   1128: also be used to run the bootstrap. This is slightly relaxed from the normal
                   1129: pkgsrc requirement of "root".
                   1130:
                   1131: The package manager should use a umask of 002. "make install" will
                   1132: automatically complain if this is not the case. This ensures that directories
                   1133: written in /var/db/pkg are Administrators-group writeable.
                   1134:
                   1135: The popular Interix binary packages from http://www.interopsystems.com/ use an
                   1136: older version of pkgsrc's pkg_* tools. Ideally, these should NOT be used in
                   1137: conjunction with pkgsrc. If you choose to use them at the same time as the
                   1138: pkgsrc packages, ensure that you use the proper pkg_* tools for each type of
                   1139: binary package.
                   1140:
1.22      tv       1141: The TERM setting used for DOS-type console windows (including those invoked by
                   1142: the csh and ksh startup shortcuts) is "interix". Most systems don't have a
                   1143: termcap/terminfo entry for it, but the following .termcap entry provides
                   1144: adequate emulation in most cases:
                   1145:
1.101     rillig   1146: interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
1.87      wiz      1147:
1.22      tv       1148:
1.82      rillig   1149: 3.3.3.4. Limitations of the Interix platform
1.52      tv       1150:
                   1151: Though Interix suffices as a familiar and flexible substitute for a full
                   1152: Unix-like platform, it has some drawbacks that should be noted for those
                   1153: desiring to make the most of Interix.
                   1154:
1.57      minskim  1155:   * X11:
1.52      tv       1156:
                   1157:     Interix comes with the standard set of X11R6 client libraries, and can run
1.57      minskim  1158:     X11 based applications, but it does not come with an X server. Some options
                   1159:     are StarNet X-Win32, Hummingbird Exceed (available in a trimmed version for
                   1160:     Interix from Interop Systems as the Interop X Server), and the free X11
1.52      tv       1161:     server included with Cygwin.
                   1162:
1.57      minskim  1163:   * X11 acceleration:
1.52      tv       1164:
                   1165:     Because Interix runs in a completely different NT subsystem from Win32
                   1166:     applications, it does not currently support various X11 protocol extensions
                   1167:     for acceleration (such as MIT-SHM or DGA). Most interactive applications to
                   1168:     a local X server will run reasonably fast, but full motion video and other
                   1169:     graphics intensive applications may require a faster-than-expected CPU.
                   1170:
                   1171:   * Audio:
                   1172:
1.53      tv       1173:     Interix has no native support for audio output. For audio support, pkgsrc
                   1174:     uses the esound client/server audio system on Interix. Unlike on most
                   1175:     platforms, the audio/esound package does not contain the esd server
                   1176:     component. To output audio via an Interix host, the emulators/cygwin_esound
                   1177:     package must also be installed.
1.52      tv       1178:
                   1179:   * CD/DVDs, USB, and SCSI:
                   1180:
                   1181:     Direct device access is not currently supported in Interix, so it is not
                   1182:     currently possible to access CD/DVD drives, USB devices, or SCSI devices
                   1183:     through non-filesystem means. Among other things, this makes it impossible
                   1184:     to use Interix directly for CD/DVD burning.
                   1185:
                   1186:   * Tape drives:
                   1187:
                   1188:     Due to the same limitations as for CD-ROMs and SCSI devices, tape drives
                   1189:     are also not directly accessible in Interix. However, support is in work to
                   1190:     make tape drive access possible by using Cygwin as a bridge (similarly to
                   1191:     audio bridged via Cygwin's esound server).
                   1192:
1.82      rillig   1193: 3.3.3.5. Known issues for pkgsrc on Interix
1.52      tv       1194:
                   1195: It is not necessary, in general, to have a "root" user on the Windows system;
                   1196: any member of the local Administrators group will suffice. However, some
                   1197: packages currently assume that the user named "root" is the privileged user. To
                   1198: accommodate these, you may create such a user; make sure it is in the local
                   1199: group Administrators (or your language equivalent).
                   1200:
1.87      wiz      1201: pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time
                   1202: being, install packages as the local Administrator (or your language
1.52      tv       1203: equivalent), or run the following command after installing a package to work
                   1204: around the issue:
                   1205:
                   1206: # chmod -R g+w $PKG_DBDIR
                   1207:
1.87      wiz      1208:
1.82      rillig   1209: 3.3.4. IRIX
1.1       grant    1210:
                   1211: You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro
                   1212: compiler (cc/c89). Please set the CC environment variable according to your
                   1213: preference. If you do not have a license for the MIPSpro compiler suite, you
                   1214: can download a gcc tardist file from http://freeware.sgi.com/.
                   1215:
                   1216: Please note that you will need IRIX 6.5.17 or higher, as this is the earliest
                   1217: version of IRIX providing support for if_indextoname(3), if_nametoindex(3),
                   1218: etc.
                   1219:
1.87      wiz      1220: At this point in time, pkgsrc only supports one ABI at a time. That is, you
                   1221: cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit
                   1222: ABI. If you start out using "abi=n32", that's what all your packages will be
                   1223: built with.
1.1       grant    1224:
                   1225: Therefore, please make sure that you have no conflicting CFLAGS in your
1.105     rillig   1226: environment or the mk.conf. Particularly, make sure that you do not try to link
                   1227: n32 object files with lib64 or vice versa. Check your /etc/compiler.defaults!
1.1       grant    1228:
                   1229: If you have the actual pkgsrc tree mounted via NFS from a different host,
                   1230: please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX
1.47      reed     1231: linker occasionally runs into issues when trying to link over a network-mounted
                   1232: file system.
1.1       grant    1233:
                   1234: The bootstrapping process should set all the right options for programs such as
                   1235: imake(1), but you may want to set some options depending on your local setup.
1.27      rillig   1236: Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages
1.11      ben      1237: for details.
1.1       grant    1238:
1.22      tv       1239: If you are using SGI's MIPSPro compiler, please set
                   1240:
1.101     rillig   1241: PKGSRC_COMPILER=        mipspro
1.87      wiz      1242:
1.22      tv       1243:
1.105     rillig   1244: in mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up
1.22      tv       1245: passing invalid flags to the compiler. Note that bootstrap should create an
                   1246: appropriate mk.conf.example by default.
                   1247:
                   1248: If you have both the MIPSPro compiler chain installed as well as gcc, but want
1.93      rillig   1249: to make sure that MIPSPro is used, please set your PATH to not include the
1.22      tv       1250: location of gcc (often /usr/freeware/bin), and (important) pass the
                   1251: '--preserve-path' flag.
                   1252:
1.82      rillig   1253: 3.3.5. Linux
1.22      tv       1254:
                   1255: Some versions of Linux (for example Debian GNU/Linux) need either libtermcap or
                   1256: libcurses (libncurses). Installing the distributions libncurses-dev package (or
                   1257: equivalent) should fix the problem.
                   1258:
                   1259: pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++
                   1260: Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested.
                   1261:
                   1262: To bootstrap using icc, assuming the default icc installation directory:
                   1263:
1.101     rillig   1264: env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \
                   1265: ac_cv___attribute__=yes ./bootstrap
1.87      wiz      1266:
1.22      tv       1267:
                   1268: Note
                   1269:
                   1270: icc 8.1 needs the `-i-static' argument instead of -static-libcxa.
                   1271:
                   1272: icc supports __attribute__, but the GNU configure test uses a nested function,
                   1273: which icc does not support. #undef'ing __attribute__ has the unfortunate
                   1274: side-effect of breaking many of the Linux header files, which cannot be
                   1275: compiled properly without __attribute__. The test must be overridden so that
                   1276: __attribute__ is assumed supported by the compiler.
                   1277:
1.105     rillig   1278: After bootstrapping, you should set PKGSRC_COMPILER in mk.conf:
1.22      tv       1279:
1.101     rillig   1280: PKGSRC_COMPILER=        icc
1.87      wiz      1281:
1.22      tv       1282:
                   1283: The default installation directory for icc is /opt/intel_cc_80, which is also
                   1284: the pkgsrc default. If you have installed it into a different directory, set
1.105     rillig   1285: ICCBASE in mk.conf:
1.22      tv       1286:
1.101     rillig   1287: ICCBASE=                /opt/icc
1.87      wiz      1288:
1.22      tv       1289:
                   1290: pkgsrc uses the static linking method of the runtime libraries provided by icc,
                   1291: so binaries can be run on other systems which do not have the shared libraries
                   1292: installed.
                   1293:
                   1294: Libtool, however, extracts a list of libraries from the ld(1) command run when
                   1295: linking a C++ shared library and records it, throwing away the -Bstatic and
                   1296: -Bdynamic options interspersed between the libraries. This means that
                   1297: libtool-linked C++ shared libraries will have a runtime dependency on the icc
                   1298: libraries until this is fixed in libtool.
                   1299:
1.82      rillig   1300: 3.3.6. OpenBSD
1.1       grant    1301:
                   1302: OpenBSD 3.0 and 3.2 are tested and supported.
                   1303:
                   1304: Care should be taken so that the tools that this kit installs do not conflict
                   1305: with the OpenBSD userland tools. There are several steps:
                   1306:
                   1307:  1. OpenBSD stores its ports pkg database in /var/db/pkg. It is therefore
                   1308:     recommended that you choose a different location (e.g. /usr/pkgdb) by using
                   1309:     the --pkgdbdir option to the bootstrap script.
1.20      ben      1310:
1.1       grant    1311:  2. If you do not intend to use the OpenBSD ports tools, it's probably a good
                   1312:     idea to move them out of the way to avoid confusion, e.g.
1.20      ben      1313:
1.1       grant    1314:     # cd /usr/sbin
                   1315:     # mv pkg_add pkg_add.orig
                   1316:     # mv pkg_create pkg_create.orig
                   1317:     # mv pkg_delete pkg_delete.orig
                   1318:     # mv pkg_info pkg_info.orig
1.20      ben      1319:
1.87      wiz      1320:
1.105     rillig   1321:  3. An example mk.conf file will be placed in /etc/mk.conf.example file when
                   1322:     you use the bootstrap script. OpenBSD's make program uses mk.conf as well.
                   1323:     You can work around this by enclosing all the pkgsrc-specific parts of the
                   1324:     file with:
1.20      ben      1325:
1.101     rillig   1326:     .ifdef BSD_PKG_MK
                   1327:     # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
                   1328:     .else
                   1329:     # OpenBSD stuff
                   1330:     .endif
1.87      wiz      1331:
1.20      ben      1332:
1.82      rillig   1333: 3.3.7. Solaris
1.1       grant    1334:
                   1335: Solaris 2.6 through 9 are supported on both x86 and sparc. You will need a
                   1336: working C compiler. Both gcc 2.95.3 and Sun WorkShop 5 have been tested.
                   1337:
                   1338: The following packages are required on Solaris 8 for the bootstrap process and
                   1339: to build packages.
                   1340:
                   1341:   * SUNWsprot
1.20      ben      1342:
1.1       grant    1343:   * SUNWarc
1.20      ben      1344:
1.1       grant    1345:   * SUNWbtool
1.20      ben      1346:
1.1       grant    1347:   * SUNWtoo
1.20      ben      1348:
1.1       grant    1349:   * SUNWlibm
1.20      ben      1350:
1.78      rillig   1351: Please note that the use of GNU binutils on Solaris is not supported, as of
                   1352: June 2006.
1.1       grant    1353:
1.70      rillig   1354: Whichever compiler you use, please ensure the compiler tools and your $prefix
                   1355: are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/
                   1356: {bin,sbin}.
                   1357:
1.82      rillig   1358: 3.3.7.1. If you are using gcc
1.1       grant    1359:
                   1360: It makes life much simpler if you only use the same gcc consistently for
                   1361: building all packages.
                   1362:
                   1363: It is recommended that an external gcc be used only for bootstrapping, then
                   1364: either build gcc from lang/gcc or install a binary gcc package, then remove gcc
                   1365: used during bootstrapping.
                   1366:
1.93      rillig   1367: Binary packages of gcc can be found through http://www.sunfreeware.com/.
1.1       grant    1368:
1.82      rillig   1369: 3.3.7.2. If you are using Sun WorkShop
1.1       grant    1370:
                   1371: You will need at least the following packages installed (from WorkShop 5.0)
                   1372:
                   1373:   * SPROcc - Sun WorkShop Compiler C 5.0
1.20      ben      1374:
1.1       grant    1375:   * SPROcpl - Sun WorkShop Compiler C++ 5.0
1.20      ben      1376:
1.1       grant    1377:   * SPROild - Sun WorkShop Incremental Linker
1.20      ben      1378:
1.1       grant    1379:   * SPROlang - Sun WorkShop Compilers common components
1.20      ben      1380:
1.96      rillig   1381: You should set the following variables in your mk.conf file:
1.1       grant    1382:
1.101     rillig   1383: CC=     cc
                   1384: CXX=    CC
                   1385: CPP=    cc -E
                   1386: CXXCPP= CC -E
1.87      wiz      1387:
1.96      rillig   1388: Note
                   1389:
                   1390: The CPP setting might break some packages that use the C preprocessor for
                   1391: processing things other than C source code.
1.1       grant    1392:
1.93      rillig   1393: 3.3.7.3. Building 64-bit binaries with SunPro
1.1       grant    1394:
1.96      rillig   1395: To build 64-bit packages, you just need to have the following lines in your
                   1396: mk.conf file:
1.70      rillig   1397:
1.101     rillig   1398: PKGSRC_COMPILER=        sunpro
                   1399: ABI=                    64
1.87      wiz      1400:
1.96      rillig   1401: Note
1.70      rillig   1402:
1.96      rillig   1403: This setting has been tested for the SPARC architecture. Intel and AMD machines
                   1404: need some more work.
1.1       grant    1405:
1.82      rillig   1406: 3.3.7.4. Common problems
1.68      rillig   1407:
                   1408: Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The
                   1409: workaround is to use another shell for the configure scripts, for example by
1.69      rillig   1410: installing shells/bash and adding the following lines to your mk.conf:
1.68      rillig   1411:
1.101     rillig   1412: CONFIG_SHELL=   ${LOCALBASE}/bin/bash
                   1413: WRAPPER_SHELL=  ${LOCALBASE}/bin/bash
1.87      wiz      1414:
1.68      rillig   1415:
1.71      wiz      1416: Then, rebuild the devel/libtool-base package.
                   1417:
1.1       grant    1418: Chapter 4. Using pkgsrc
                   1419:
                   1420: Table of Contents
                   1421:
1.70      rillig   1422: 4.1. Using binary packages
1.20      ben      1423:
1.70      rillig   1424:     4.1.1. Finding binary packages
                   1425:     4.1.2. Installing binary packages
1.82      rillig   1426:     4.1.3. Deinstalling packages
                   1427:     4.1.4. Getting information about installed packages
                   1428:     4.1.5. Checking for security vulnerabilities in installed packages
                   1429:     4.1.6. Finding if newer versions of your installed packages are in pkgsrc
                   1430:     4.1.7. Other administrative functions
                   1431:     4.1.8. A word of warning
1.20      ben      1432:
1.1       grant    1433: 4.2. Building packages from source
1.20      ben      1434:
1.1       grant    1435:     4.2.1. Requirements
                   1436:     4.2.2. Fetching distfiles
                   1437:     4.2.3. How to build and install
1.20      ben      1438:
1.70      rillig   1439: Basically, there are two ways of using pkgsrc. The first is to only install the
                   1440: package tools and to use binary packages that someone else has prepared. This
                   1441: is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
                   1442: Then you are able to build your own packages, and you can still use binary
                   1443: packages from someone else.
                   1444:
                   1445: 4.1. Using binary packages
                   1446:
1.110     rillig   1447: On the ftp.NetBSD.org server and its mirrors, there are collections of binary
                   1448: packages, ready to be installed. These binary packages have been built using
                   1449: the default settings for the directories, that is:
                   1450:
                   1451:   * /usr/pkg for LOCALBASE, where most of the files are installed,
                   1452:
                   1453:   * /usr/pkg/etc for configuration files,
                   1454:
                   1455:   * /var for VARBASE, where those files are installed that may change after
                   1456:     installation.
                   1457:
                   1458: If you cannot use these directories for whatever reasons (maybe because you're
                   1459: not root), you cannot use these binary packages, but have to build the packages
                   1460: yourself, which is explained in Section 3.2, "Bootstrapping pkgsrc".
1.70      rillig   1461:
                   1462: 4.1.1. Finding binary packages
                   1463:
1.106     weinem   1464: To install binary packages, you first need to know from where to get them. The
                   1465: first place where you should look is on the main pkgsrc FTP server in the
                   1466: directory /pub/pkgsrc/packages.
                   1467:
                   1468: This directory contains binary packages for multiple platforms. First, select
                   1469: your operating system. (Ignore the directories with version numbers attached to
                   1470: it, they just exist for legacy reasons.) Then, select your hardware
                   1471: architecture, and in the third step, the OS version and the "version" of
1.110     rillig   1472: pkgsrc.
                   1473:
                   1474: In this directory, you often find a file called bootstrap.tar.gz which contains
                   1475: the package management tools. If the file is missing, it is likely that your
                   1476: operating system already provides those tools. Download the file and extract it
                   1477: in the / directory. It will create the directories /usr/pkg (containing the
                   1478: tools for managing binary packages) and /var/db/pkg (the database of installed
                   1479: packages).
1.1       grant    1480:
1.70      rillig   1481: 4.1.2. Installing binary packages
1.1       grant    1482:
1.110     rillig   1483: In the directory from the last section, there is a subdirectory called All,
                   1484: which contains all the binary packages that are available for the platform,
                   1485: excluding those that may not be distributed via FTP or CDROM (depending on
1.130     wiz      1486: which medium you are using).
1.110     rillig   1487:
                   1488: To install packages directly from an FTP or HTTP server, run the following
                   1489: commands in a Bourne-compatible shell (be sure to su to root first):
                   1490:
                   1491: # PATH="/usr/pkg/sbin:$PATH"
                   1492: # PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All"
                   1493: # export PATH PKG_PATH
                   1494:
                   1495: Instead of URLs, you can also use local paths, for example if you are
                   1496: installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want
                   1497: to install packages from multiple sources, you can separate them by a semicolon
                   1498: in PKG_PATH.
                   1499:
                   1500: After these preparations, installing a package is very easy:
                   1501:
                   1502: # pkg_add openoffice2
                   1503: # pkg_add kde-3.5.7
                   1504: # pkg_add ap2-php5-*
1.1       grant    1505:
1.27      rillig   1506: Note that any prerequisite packages needed to run the package in question will
                   1507: be installed, too, assuming they are present where you install from.
1.1       grant    1508:
1.130     wiz      1509: Adding packages might install vulnerable packages. Thus you should run
                   1510: pkg_admin audit regularly, especially after installing new packages, and verify
                   1511: that the vulnerabilities are acceptable for your configuration.
                   1512:
1.27      rillig   1513: After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
                   1514: in your PATH so you can actually start the just installed program.
1.1       grant    1515:
1.82      rillig   1516: 4.1.3. Deinstalling packages
                   1517:
                   1518: To deinstall a package, it does not matter whether it was installed from source
                   1519: code or from a binary package. The pkg_delete command does not know it anyway.
                   1520: To delete a package, you can just run pkg_delete package-name. The package name
                   1521: can be given with or without version number. Wildcards can also be used to
                   1522: deinstall a set of packages, for example *emacs*. Be sure to include them in
                   1523: quotes, so that the shell does not expand them before pkg_delete sees them.
                   1524:
                   1525: The -r option is very powerful: it removes all the packages that require the
                   1526: package in question and then removes the package itself. For example:
                   1527:
1.88      wiz      1528: # pkg_delete -r jpeg
                   1529:
1.82      rillig   1530:
                   1531: will remove jpeg and all the packages that used it; this allows upgrading the
                   1532: jpeg package.
                   1533:
                   1534: 4.1.4. Getting information about installed packages
                   1535:
                   1536: The pkg_info shows information about installed packages or binary package
                   1537: files.
                   1538:
                   1539: 4.1.5. Checking for security vulnerabilities in installed packages
                   1540:
                   1541: The NetBSD Security-Officer and Packages Groups maintain a list of known
                   1542: security vulnerabilities to packages which are (or have been) included in
                   1543: pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/
                   1544: pub/pkgsrc/distfiles/vulnerabilities.
                   1545:
1.126     wiz      1546: Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded
                   1547: automatically, and a security audit of all packages installed on a system can
                   1548: take place.
                   1549:
                   1550: There are two components to auditing. The first step, pkg_admin
                   1551: fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
                   1552: the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of
                   1553: your installed packages are vulnerable. If a package is vulnerable, you will
                   1554: see output similar to the following:
1.82      rillig   1555:
                   1556: Package samba-2.0.9 has a local-root-shell vulnerability, see
1.88      wiz      1557:     http://www.samba.org/samba/whatsnew/macroexploit.html
1.82      rillig   1558:
1.126     wiz      1559: You may wish to have the vulnerabilities file downloaded daily so that it
                   1560: remains current. This may be done by adding an appropriate entry to the root
                   1561: users crontab(5) entry. For example the entry
                   1562:
                   1563: # download vulnerabilities file
                   1564: 0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
                   1565:
                   1566:
                   1567: will update the vulnerability list every day at 3AM. You may wish to do this
                   1568: more often than once a day. In addition, you may wish to run the package audit
                   1569: from the daily security script. This may be accomplished by adding the
                   1570: following line to /etc/security.local:
                   1571:
                   1572: /usr/sbin/pkg_admin audit
                   1573:
1.82      rillig   1574:
                   1575: 4.1.6. Finding if newer versions of your installed packages are in pkgsrc
                   1576:
1.113     weinem   1577: Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
                   1578: if your packages are up-to-date, e.g.
1.82      rillig   1579:
                   1580: % lintpkgsrc -i
                   1581: ...
                   1582: Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
                   1583:
1.88      wiz      1584:
1.82      rillig   1585: You can then use make update to update the package on your system and rebuild
                   1586: any dependencies.
                   1587:
                   1588: 4.1.7. Other administrative functions
                   1589:
                   1590: The pkg_admin executes various administrative functions on the package system.
                   1591:
                   1592: 4.1.8. A word of warning
1.1       grant    1593:
                   1594: Please pay very careful attention to the warnings expressed in the pkg_add(1)
                   1595: manual page about the inherent dangers of installing binary packages which you
                   1596: did not create yourself, and the security holes that can be introduced onto
                   1597: your system by indiscriminate adding of such files.
                   1598:
1.66      rillig   1599: The same warning of course applies to every package you install from source
                   1600: when you haven't completely read and understood the source code of the package,
                   1601: the compiler that is used to build the package and all the other tools that are
                   1602: involved.
                   1603:
1.1       grant    1604: 4.2. Building packages from source
                   1605:
1.82      rillig   1606: After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
                   1607: organized into categories. You can browse the online index of packages, or run
                   1608: make readme from the pkgsrc directory to build local README.html files for all
1.83      wiz      1609: packages, viewable with any web browser such as www/lynx or www/firefox.
1.82      rillig   1610:
                   1611: The default prefix for installed packages is /usr/pkg. If you wish to change
                   1612: this, you should do so by setting LOCALBASE in mk.conf. You should not try to
                   1613: use multiple different LOCALBASE definitions on the same system (inside a
                   1614: chroot is an exception).
                   1615:
                   1616: The rest of this chapter assumes that the package is already in pkgsrc. If it
                   1617: is not, see Part II, "The pkgsrc developer's guide" for instructions how to
                   1618: create your own packages.
1.1       grant    1619:
                   1620: 4.2.1. Requirements
                   1621:
1.82      rillig   1622: To build packages from source, you need a working C compiler. On NetBSD, you
                   1623: need to install the "comp" and the "text" distribution sets. If you want to
                   1624: build X11-related packages, the "xbase" and "xcomp" distribution sets are
                   1625: required, too.
1.1       grant    1626:
                   1627: 4.2.2. Fetching distfiles
                   1628:
1.27      rillig   1629: The first step for building a package is downloading the distfiles (i.e. the
                   1630: unmodified source). If they have not yet been downloaded, pkgsrc will fetch
                   1631: them automatically.
1.1       grant    1632:
1.82      rillig   1633: If you have all files that you need in the distfiles directory, you don't need
                   1634: to connect. If the distfiles are on CD-ROM, you can mount the CD-ROM on /cdrom
                   1635: and add:
                   1636:
                   1637: DISTDIR=/cdrom/pkgsrc/distfiles
                   1638:
                   1639: to your mk.conf.
                   1640:
1.91      rillig   1641: By default a list of distribution sites will be randomly intermixed to prevent
                   1642: huge load on servers which holding popular packages (for example,
                   1643: SourceForge.net mirrors). Thus, every time when you need to fetch yet another
                   1644: distfile all the mirrors will be tried in new (random) order. You can turn this
                   1645: feature off by setting MASTER_SORT_RANDOM=NO (for PKG_DEVELOPERs it's already
                   1646: disabled).
                   1647:
1.1       grant    1648: You can overwrite some of the major distribution sites to fit to sites that are
1.88      wiz      1649: close to your own. By setting one or two variables you can modify the order in
                   1650: which the master sites are accessed. MASTER_SORT contains a whitespace
                   1651: delimited list of domain suffixes. MASTER_SORT_REGEX is even more flexible, it
                   1652: contains a whitespace delimited list of regular expressions. It has higher
                   1653: priority than MASTER_SORT. Have a look at pkgsrc/mk/defaults/mk.conf to find
                   1654: some examples. This may save some of your bandwidth and time.
1.1       grant    1655:
                   1656: You can change these settings either in your shell's environment, or, if you
1.105     rillig   1657: want to keep the settings, by editing the mk.conf file, and adding the
1.1       grant    1658: definitions there.
                   1659:
1.82      rillig   1660: If a package depends on many other packages (such as meta-pkgs/kde3), the build
                   1661: process may alternate between periods of downloading source, and compiling. To
                   1662: ensure you have all the source downloaded initially you can run the command:
                   1663:
                   1664: % make fetch-list | sh
                   1665:
                   1666: which will output and run a set of shell commands to fetch the necessary files
                   1667: into the distfiles directory. You can also choose to download the files
                   1668: manually.
1.1       grant    1669:
                   1670: 4.2.3. How to build and install
                   1671:
1.82      rillig   1672: Once the software has downloaded, any patches will be applied, then it will be
                   1673: compiled for you. This may take some time depending on your computer, and how
                   1674: many other packages the software depends on and their compile time.
1.47      reed     1675:
                   1676: Note
                   1677:
                   1678: If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
                   1679: command instead of "make" in the examples in this guide.
                   1680:
                   1681: For example, type
1.1       grant    1682:
                   1683: % cd misc/figlet
                   1684: % make
                   1685:
1.88      wiz      1686:
1.82      rillig   1687: at the shell prompt to build the various components of the package.
                   1688:
                   1689: The next stage is to actually install the newly compiled program onto your
                   1690: system. Do this by entering:
                   1691:
1.88      wiz      1692: % make install
                   1693:
1.82      rillig   1694:
                   1695: while you are still in the directory for whatever package you are installing.
1.1       grant    1696:
1.82      rillig   1697: Installing the package on your system may require you to be root. However,
                   1698: pkgsrc has a just-in-time-su feature, which allows you to only become root for
                   1699: the actual installation step.
                   1700:
                   1701: That's it, the software should now be installed and setup for use. You can now
                   1702: enter:
                   1703:
1.88      wiz      1704: % make clean
                   1705:
1.82      rillig   1706:
                   1707: to remove the compiled files in the work directory, as you shouldn't need them
                   1708: any more. If other packages were also added to your system (dependencies) to
                   1709: allow your program to compile, you can tidy these up also with the command:
1.1       grant    1710:
1.88      wiz      1711: % make clean-depends
                   1712:
1.1       grant    1713:
                   1714: Taking the figlet utility as an example, we can install it on our system by
1.46      gdt      1715: building as shown in Appendix B, Build logs.
1.1       grant    1716:
                   1717: The program is installed under the default root of the packages tree - /usr/
                   1718: pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
                   1719: environment, and it will use that value as the root of your packages tree. So,
                   1720: to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
                   1721: that you should use a directory which is dedicated to packages and not shared
1.47      reed     1722: with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
1.1       grant    1723: not try to add any of your own files or directories (such as src/, obj/, or
                   1724: pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
                   1725: between programs and other files installed by the package system and whatever
                   1726: else may have been installed there.
                   1727:
1.105     rillig   1728: Some packages look in mk.conf to alter some configuration options at build
1.11      ben      1729: time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will
                   1730: be set there by default. Environment variables such as LOCALBASE can be set in
1.105     rillig   1731: mk.conf to save having to remember to set them each time you want to use
1.11      ben      1732: pkgsrc.
1.1       grant    1733:
                   1734: Occasionally, people want to "look under the covers" to see what is going on
                   1735: when a package is building or being installed. This may be for debugging
                   1736: purposes, or out of simple curiosity. A number of utility values have been
                   1737: added to help with this.
                   1738:
                   1739:  1. If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a huge
                   1740:     amount of information will be displayed. For example,
1.20      ben      1741:
1.1       grant    1742:     make patch PKG_DEBUG_LEVEL=2
1.20      ben      1743:
1.1       grant    1744:     will show all the commands that are invoked, up to and including the
                   1745:     "patch" stage.
1.20      ben      1746:
1.1       grant    1747:  2. If you want to know the value of a certain make(1) definition, then the
                   1748:     VARNAME definition should be used, in conjunction with the show-var target.
1.22      tv       1749:     e.g. to show the expansion of the make(1) variable LOCALBASE:
1.20      ben      1750:
1.1       grant    1751:     % make show-var VARNAME=LOCALBASE
                   1752:     /usr/pkg
                   1753:     %
1.20      ben      1754:
                   1755:
1.1       grant    1756: If you want to install a binary package that you've either created yourself
                   1757: (see next section), that you put into pkgsrc/packages manually or that is
1.8       wiz      1758: located on a remote FTP server, you can use the "bin-install" target. This
1.1       grant    1759: target will install a binary package - if available - via pkg_add(1), else do a
                   1760: make package. The list of remote FTP sites searched is kept in the variable
1.11      ben      1761: BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
                   1762: to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
                   1763: for more details.
1.1       grant    1764:
1.47      reed     1765: A final word of warning: If you set up a system that has a non-standard setting
1.1       grant    1766: for LOCALBASE, be sure to set that before any packages are installed, as you
1.86      schwarz  1767: cannot use several directories for the same purpose. Doing so will result in
1.1       grant    1768: pkgsrc not being able to properly detect your installed packages, and fail
                   1769: miserably. Note also that precompiled binary packages are usually built with
                   1770: the default LOCALBASE of /usr/pkg, and that you should not install any if you
                   1771: use a non-standard LOCALBASE.
                   1772:
1.38      dillo    1773: Chapter 5. Configuring pkgsrc
                   1774:
                   1775: Table of Contents
                   1776:
1.45      wiz      1777: 5.1. General configuration
                   1778: 5.2. Variables affecting the build process
1.110     rillig   1779: 5.3. Variables affecting the installation process
1.104     wiz      1780: 5.4. Selecting and configuring the compiler
1.78      rillig   1781:
1.104     wiz      1782:     5.4.1. Selecting the compiler
                   1783:     5.4.2. Additional flags to the compiler (CFLAGS)
                   1784:     5.4.3. Additional flags to the linker (LDFLAGS)
1.78      rillig   1785:
1.104     wiz      1786: 5.5. Developer/advanced settings
                   1787: 5.6. Selecting Build Options
1.38      dillo    1788:
1.89      rillig   1789: The whole pkgsrc system is configured in a single file, usually called mk.conf.
                   1790: In which directory pkgsrc looks for that file depends on the installation. On
                   1791: NetBSD, when you use make(1) from the base system, it is in the directory /etc
                   1792: /. In all other cases the default location is ${PREFIX}/etc/, depending on
                   1793: where you told the bootstrap program to install the binary packages.
                   1794:
                   1795: During the bootstrap, an example configuration file is created. To use that,
                   1796: you have to create the directory ${PREFIX}/etc and copy the example file there.
                   1797:
                   1798: The format of the configuration file is that of the usual BSD-style Makefiles.
                   1799: The whole pkgsrc configuration is done by setting variables in this file. Note
                   1800: that you can define all kinds of variables, and no special error checking (for
                   1801: example for spelling mistakes) takes place, so you have to try it out to see if
                   1802: it works.
                   1803:
1.45      wiz      1804: 5.1. General configuration
                   1805:
1.47      reed     1806: In this section, you can find some variables that apply to all pkgsrc packages.
1.89      rillig   1807: A complete list of the variables that can be configured by the user is
                   1808: available in mk/defaults/mk.conf, together with some comments that describe
                   1809: each variable's intent.
1.45      wiz      1810:
                   1811:   * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
                   1812:     not mix binary packages with different LOCALBASEs!
                   1813:
                   1814:   * CROSSBASE: Where "cross" category packages will be installed. The default
                   1815:     is ${LOCALBASE}/cross.
                   1816:
                   1817:   * X11BASE: Where X11 is installed on the system. The default is /usr/X11R6.
                   1818:
                   1819:   * DISTDIR: Where to store the downloaded copies of the original source
                   1820:     distributions used for building pkgsrc packages. The default is $
                   1821:     {PKGSRCDIR}/distfiles.
                   1822:
1.97      wiz      1823:   * PKG_DBDIR: Where the database about installed packages is stored. The
1.98      rillig   1824:     default is /var/db/pkg.
1.97      wiz      1825:
1.45      wiz      1826:   * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
                   1827:     value.
                   1828:
                   1829:   * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
                   1830:     files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
                   1831:     respectively. The defaults are ftp://ftp.NetBSD.org/pub/NetBSD/packages/
                   1832:     distfiles/${DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$
                   1833:     {DIST_SUBDIR}/.
                   1834:
1.93      rillig   1835:   * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
                   1836:     with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
1.45      wiz      1837:
1.126     wiz      1838:   * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
                   1839:     case-sensitive. Whenever you try to build a package whose license is not in
                   1840:     this list, you will get an error message. If the license condition is
                   1841:     simple enough, the error message will include specific instructions on how
                   1842:     to change this variable.
1.82      rillig   1843:
1.45      wiz      1844: 5.2. Variables affecting the build process
                   1845:
                   1846: XXX
                   1847:
                   1848:   * PACKAGES: The top level directory for the binary packages. The default is $
                   1849:     {PKGSRCDIR}/packages.
                   1850:
                   1851:   * WRKOBJDIR: The top level directory where, if defined, the separate working
                   1852:     directories will get created, and symbolically linked to from ${WRKDIR}
                   1853:     (see below). This is useful for building packages on several architectures,
                   1854:     then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
                   1855:     architecture. (It should be noted that PKGSRCDIR should not be set by the
                   1856:     user ? it is an internal definition which refers to the root of the pkgsrc
                   1857:     tree. It is possible to have many pkgsrc tree instances.)
                   1858:
                   1859:   * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
1.107     rillig   1860:     Section 11.3, "patches/*" for more information.
1.45      wiz      1861:
                   1862:   * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
                   1863:     Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
                   1864:     up settings used by builds in /usr/src.
                   1865:
1.82      rillig   1866:   * DEPENDS_TARGET: By default, dependencies are only installed, and no binary
                   1867:     package is created for them. You can set this variable to package to
                   1868:     automatically create binary packages after installing dependencies.
                   1869:
1.110     rillig   1870: 5.3. Variables affecting the installation process
1.78      rillig   1871:
1.104     wiz      1872: A growing number of packages support installation into a subdirectory of
                   1873: WRKDIR. This allows a package to be built, before the actual filesystem is
                   1874: touched. DESTDIR support exists in two variations:
                   1875:
                   1876:   * Basic DESTDIR support means that the package installation and packaging is
                   1877:     still run as root.
                   1878:
                   1879:   * Full DESTDIR support can run the complete build, installation and packaging
                   1880:     as normal user. Root privileges are only needed to add packages.
                   1881:
1.124     snj      1882: To use the DESTDIR support, set USE_DESTDIR=yes to get the full support for
                   1883: packages that support it and with fallback to basic support.
1.104     wiz      1884:
                   1885: DESTDIR support changes the behaviour of various targets slightly. To install a
                   1886: package after building it, use package-install. package and install don't do
                   1887: that any longer. package-install can be used as DEPENDS_TARGET. bin-install
                   1888: will ask for the root password to install the package and fail, package-install
                   1889: will ask again.
                   1890:
                   1891: With basic DESTDIR support, make clean needs to be run as root.
                   1892:
1.119     imil     1893: Considering the foo/bar package, DESTDIR full support can be tested using the
                   1894: following commands
                   1895:
                   1896: $ id
                   1897: uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
                   1898: $ mkdir $HOME/packages
                   1899: $ cd $PKGSRCDIR/foo/bar
                   1900:
                   1901: Verify DESTDIR full support, no root privileges should be needed
                   1902:
1.124     snj      1903: $ make USE_DESTDIR=yes install
1.119     imil     1904:
                   1905: Create a package without root privileges
                   1906:
1.124     snj      1907: $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package
1.119     imil     1908:
                   1909: For the following command, you must be able to gain root privileges using su(1)
                   1910:
1.124     snj      1911: $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install
1.119     imil     1912:
                   1913: Then, as a simple user
                   1914:
                   1915: $ make clean
                   1916:
1.104     wiz      1917: 5.4. Selecting and configuring the compiler
                   1918:
                   1919: 5.4.1. Selecting the compiler
1.89      rillig   1920:
                   1921: By default, pkgsrc will use GCC to build packages. This may be overridden by
                   1922: setting the following variables in /etc/mk.conf:
                   1923:
                   1924: PKGSRC_COMPILER:
                   1925:
                   1926:     This is a list of values specifying the chain of compilers to invoke when
                   1927:     building packages. Valid values are:
                   1928:
                   1929:       * distcc: distributed C/C++ (chainable)
                   1930:
                   1931:       * ccache: compiler cache (chainable)
                   1932:
                   1933:       * gcc: GNU C/C++ Compiler
                   1934:
                   1935:       * mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)
                   1936:
                   1937:       * mipspro: Silicon Graphics, Inc. MIPSpro (o32)
                   1938:
                   1939:       * sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio
                   1940:
                   1941:     The default is "gcc". You can use ccache and/or distcc with an appropriate
                   1942:     PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
1.94      dmcmahil 1943:     terminated with a value for a real compiler. Note that only one real
                   1944:     compiler should be listed (e.g. "sunpro gcc" is not allowed).
1.89      rillig   1945:
                   1946: GCC_REQD:
                   1947:
                   1948:     This specifies the minimum version of GCC to use when building packages. If
                   1949:     the system GCC doesn't satisfy this requirement, then pkgsrc will build and
                   1950:     install one of the GCC packages to use instead.
                   1951:
1.104     wiz      1952: 5.4.2. Additional flags to the compiler (CFLAGS)
1.78      rillig   1953:
                   1954: If you wish to set the CFLAGS variable, please make sure to use the += operator
                   1955: instead of the = operator:
                   1956:
1.101     rillig   1957: CFLAGS+=        -your -flags
1.78      rillig   1958:
                   1959: Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
1.118     jnemeth  1960: need to add their own flags. You may want to take a look at the devel/cpuflags
1.130     wiz      1961: package if you're interested in optimization specifically for the current CPU.
1.78      rillig   1962:
1.104     wiz      1963: 5.4.3. Additional flags to the linker (LDFLAGS)
1.88      wiz      1964:
                   1965: If you want to pass flags to the linker, both in the configure step and the
                   1966: build step, you can do this in two ways. Either set LDFLAGS or LIBS. The
                   1967: difference between the two is that LIBS will be appended to the command line,
                   1968: while LDFLAGS come earlier. LDFLAGS is pre-loaded with rpath settings for ELF
                   1969: machines depending on the setting of USE_IMAKE or the inclusion of mk/
                   1970: x11.buildlink3.mk. As with CFLAGS, if you do not wish to override these
                   1971: settings, use the += operator:
                   1972:
1.101     rillig   1973: LDFLAGS+=        -your -linkerflags
1.88      wiz      1974:
1.104     wiz      1975: 5.5. Developer/advanced settings
1.45      wiz      1976:
                   1977: XXX
                   1978:
                   1979:   * PKG_DEVELOPER: Run some sanity checks that package developers want:
                   1980:
                   1981:       o make sure patches apply with zero fuzz
                   1982:
                   1983:       o run check-shlibs to see that all binaries will find their shared libs.
                   1984:
                   1985:   * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst
                   1986:     making and installing the package. The default value for this is 0, which
                   1987:     will not display the commands as they are executed (normal, default, quiet
                   1988:     operation); the value 1 will display all shell commands before their
                   1989:     invocation, and the value 2 will display both the shell commands before
                   1990:     their invocation, and their actual execution progress with set -x will be
                   1991:     displayed.
                   1992:
1.104     wiz      1993: 5.6. Selecting Build Options
1.38      dillo    1994:
                   1995: Some packages have build time options, usually to select between different
                   1996: dependencies, enable optional support for big dependencies or enable
                   1997: experimental features.
                   1998:
                   1999: To see which options, if any, a package supports, and which options are
                   2000: mutually exclusive, run make show-options, for example:
                   2001:
1.51      rillig   2002:     The following options are supported by this package:
1.70      rillig   2003:         ssl      Enable SSL support.
1.51      rillig   2004:     Exactly one of the following gecko options is required:
1.70      rillig   2005:         firefox  Use firefox as gecko rendering engine.
                   2006:         mozilla  Use mozilla as gecko rendering engine.
1.51      rillig   2007:     At most one of the following database options may be selected:
1.70      rillig   2008:         mysql    Enable support for MySQL database.
                   2009:         pgsql    Enable support for PostgreSQL database.
1.38      dillo    2010:
1.51      rillig   2011:     These options are enabled by default: firefox
                   2012:     These options are currently enabled: mozilla ssl
1.38      dillo    2013:
1.105     rillig   2014: The following variables can be defined in mk.conf to select which options to
                   2015: enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
1.38      dillo    2016: disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
                   2017: which can be used to select or disable options specifically for package pkgbase
                   2018: . Options listed in these variables are selected, options preceded by "-" are
1.67      hubertf  2019: disabled. A few examples:
                   2020:
1.105     rillig   2021: $ grep "PKG.*OPTION" mk.conf
1.67      hubertf  2022: PKG_DEFAULT_OPTIONS=    -arts -dvdread -esound
                   2023: PKG_OPTIONS.kdebase=    debug -sasl
                   2024: PKG_OPTIONS.apache=     suexec
1.38      dillo    2025:
1.112     rillig   2026: It is important to note that options that were specifically suggested by the
1.121     snj      2027: package maintainer must be explicitly removed if you do not wish to include the
                   2028: option. If you are unsure you can view the current state with make show-options
                   2029: .
1.112     rillig   2030:
1.39      dillo    2031: The following settings are consulted in the order given, and the last setting
                   2032: that selects or disables an option is used:
1.38      dillo    2033:
                   2034:  1. the default options as suggested by the package maintainer
                   2035:
                   2036:  2. the options implied by the settings of legacy variables (see below)
                   2037:
                   2038:  3. PKG_DEFAULT_OPTIONS
                   2039:
                   2040:  4. PKG_OPTIONS.pkgbase
                   2041:
                   2042: For groups of mutually exclusive options, the last option selected is used, all
                   2043: others are automatically disabled. If an option of the group is explicitly
                   2044: disabled, the previously selected option, if any, is used. It is an error if no
                   2045: option from a required group of options is selected, and building the package
                   2046: will fail.
                   2047:
                   2048: Before the options framework was introduced, build options were selected by
1.105     rillig   2049: setting a variable (often named USE_FOO) in mk.conf for each option. To ease
                   2050: transition to the options framework for the user, these legacy variables are
                   2051: converted to the appropriate options setting (PKG_OPTIONS.pkgbase)
                   2052: automatically. A warning is issued to prompt the user to update mk.conf to use
                   2053: the options framework directly. Support for the legacy variables will be
1.65      hubertf  2054: removed eventually.
1.38      dillo    2055:
                   2056: Chapter 6. Creating binary packages
1.1       grant    2057:
                   2058: Table of Contents
                   2059:
1.38      dillo    2060: 6.1. Building a single binary package
                   2061: 6.2. Settings for creation of binary packages
1.20      ben      2062:
1.38      dillo    2063: 6.1. Building a single binary package
1.1       grant    2064:
                   2065: Once you have built and installed a package, you can create a binary package
1.47      reed     2066: which can be installed on another system with pkg_add(1). This saves having to
1.1       grant    2067: build the same package on a group of hosts and wasting CPU time. It also
                   2068: provides a simple means for others to install your package, should you
                   2069: distribute it.
                   2070:
                   2071: To create a binary package, change into the appropriate directory in pkgsrc,
                   2072: and run make package:
                   2073:
                   2074: # cd misc/figlet
                   2075: # make package
                   2076:
1.87      wiz      2077:
1.1       grant    2078: This will build and install your package (if not already done), and then build
                   2079: a binary package from what was installed. You can then use the pkg_* tools to
                   2080: manipulate it. Binary packages are created by default in /usr/pkgsrc/packages,
1.46      gdt      2081: in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a
1.1       grant    2082: continuation of the above misc/figlet example.
                   2083:
1.107     rillig   2084: See Chapter 21, Submitting and Committing for information on how to submit such
1.1       grant    2085: a binary package.
                   2086:
1.38      dillo    2087: 6.2. Settings for creation of binary packages
1.1       grant    2088:
1.107     rillig   2089: See Section 17.17, "Other helpful targets".
                   2090:
                   2091: Chapter 7. Creating binary packages for everything in pkgsrc (bulk builds)
                   2092:
                   2093: Table of Contents
                   2094:
                   2095: 7.1. Think first, build later
                   2096: 7.2. Requirements of a bulk build
                   2097: 7.3. Running an old-style bulk build
                   2098:
                   2099:     7.3.1. Configuration
                   2100:     7.3.2. Other environmental considerations
                   2101:     7.3.3. Operation
                   2102:     7.3.4. What it does
                   2103:     7.3.5. Disk space requirements
                   2104:     7.3.6. Setting up a sandbox for chrooted builds
                   2105:     7.3.7. Building a partial set of packages
                   2106:     7.3.8. Uploading results of a bulk build
                   2107:
                   2108: 7.4. Running a pbulk-style bulk build
                   2109:
1.117     rillig   2110:     7.4.1. Preparation
                   2111:     7.4.2. Configuration
1.107     rillig   2112:
                   2113: 7.5. Creating a multiple CD-ROM packages collection
                   2114:
                   2115:     7.5.1. Example of cdpack
                   2116:
                   2117: When you have multiple machines that should run the same packages, it is wasted
                   2118: time if they all build their packages themselves from source. There are two
                   2119: ways of getting a set of binary packages: The old bulk build system, or the new
                   2120: (as of 2007) parallel bulk build (pbulk) system. This chapter describes how to
                   2121: set them up so that the packages are most likely to be usable later.
                   2122:
                   2123: 7.1. Think first, build later
                   2124:
                   2125: Since a bulk build takes several days or even weeks to finish, you should think
                   2126: about the setup before you start everything. Pay attention to at least the
                   2127: following points:
1.1       grant    2128:
1.107     rillig   2129:   * If you want to upload the binary packages to ftp.NetBSD.org, make sure the
                   2130:     setup complies to the requirements for binary packages:
1.1       grant    2131:
1.107     rillig   2132:       o To end up on ftp.NetBSD.org, the packages must be built by a NetBSD
                   2133:         developer on a trusted machine (that is, where you and only you have
                   2134:         root access).
1.63      dillo    2135:
1.107     rillig   2136:       o Packages on ftp.NetBSD.org should only be created from the stable
1.125     snj      2137:         branches (like 2009Q1), so that users browsing the available
1.107     rillig   2138:         collections can see at a glance how old the packages are.
1.1       grant    2139:
1.107     rillig   2140:       o The packages must be built as root, since some packages require set-uid
                   2141:         binaries at runtime, and creating those packages as unprivileged user
                   2142:         doesn't work well at the moment.
1.1       grant    2143:
1.107     rillig   2144:   * Make sure that the bulk build cannot break anything in your system. Most
                   2145:     bulk builds run as root, so they should be run at least in a chroot
                   2146:     environment or something even more restrictive, depending on what the
                   2147:     operating system provides. There have been numerous cases where certain
                   2148:     packages tried to install files outside the LOCALBASE or wanted to edit
                   2149:     some files in /etc. Furthermore, the bulk builds install and deinstall
                   2150:     packages in /usr/pkg (or whatever LOCALBASE is) during their operation, so
                   2151:     be sure that you don't need any package during the build.
                   2152:
                   2153: 7.2. Requirements of a bulk build
                   2154:
                   2155: A complete bulk build requires lots of disk space. Some of the disk space can
                   2156: be read-only, some other must be writable. Some can be on remote filesystems
                   2157: (such as NFS) and some should be local. Some can be temporary filesystems,
                   2158: others must survive a sudden reboot.
                   2159:
                   2160:   * 10 GB for the distfiles (read-write, remote, temporary)
                   2161:
                   2162:   * 10 GB for the binary packages (read-write, remote, permanent)
                   2163:
                   2164:   * 400 MB for the pkgsrc tree (read-only, remote, permanent)
                   2165:
                   2166:   * 5 GB for LOCALBASE (read-write, local, temporary for pbulk, permanent for
                   2167:     old-bulk)
                   2168:
                   2169:   * 5 GB for the log files (read-write, remote, permanent)
                   2170:
                   2171:   * 5 GB for temporary files (read-write, local, temporary)
                   2172:
                   2173: 7.3. Running an old-style bulk build
                   2174:
1.117     rillig   2175: Note
1.107     rillig   2176:
1.117     rillig   2177: There are two ways of doing a bulk build. The old-style one and the new-style
                   2178: "pbulk". The latter is the recommended way.
1.107     rillig   2179:
                   2180: 7.3.1. Configuration
                   2181:
                   2182: 7.3.1.1. build.conf
1.63      dillo    2183:
                   2184: The build.conf file is the main configuration file for bulk builds. You can
                   2185: configure how your copy of pkgsrc is kept up to date, how the distfiles are
                   2186: downloaded, how the packages are built and how the report is generated. You can
                   2187: find an annotated example file in pkgsrc/mk/bulk/build.conf-example. To use it,
                   2188: copy build.conf-example to build.conf and edit it, following the comments in
                   2189: that file.
                   2190:
1.107     rillig   2191: 7.3.1.2. mk.conf
1.1       grant    2192:
1.105     rillig   2193: You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf
                   2194: for details of the default settings. You will want to ensure that
1.11      ben      2195: ACCEPTABLE_LICENSES meet your local policy. As used in this example,
1.126     wiz      2196: SKIP_LICENSE_CHECK=yes completely bypasses the license check.
1.1       grant    2197:
1.101     rillig   2198: PACKAGES?=      ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
                   2199: WRKOBJDIR?=     /usr/tmp/pkgsrc   # build here instead of in pkgsrc
                   2200: BSDSRCDIR=      /usr/src
                   2201: BSDXSRCDIR=     /usr/xsrc         # for x11/xservers
                   2202: OBJHOSTNAME?=   yes               # use work.`hostname`
                   2203: FAILOVER_FETCH= yes               # insist on the correct checksum
                   2204: PKG_DEVELOPER?= yes
1.126     wiz      2205: SKIP_LICENSE_CHECK=    yes
1.1       grant    2206:
1.63      dillo    2207: Some options that are especially useful for bulk builds can be found at the top
                   2208: lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are
                   2209: briefly described here.
                   2210:
                   2211:   * If you are on a slow machine, you may want to set USE_BULK_BROKEN_CHECK to
                   2212:     "no".
                   2213:
                   2214:   * If you are doing bulk builds from a read-only copy of pkgsrc, you have to
                   2215:     set BULKFILESDIR to the directory where all log files are created.
                   2216:     Otherwise the log files are created in the pkgsrc directory.
1.1       grant    2217:
1.63      dillo    2218:   * Another important variable is BULK_PREREQ, which is a list of packages that
                   2219:     should be always available while building other packages.
1.1       grant    2220:
1.68      rillig   2221: Some other options are scattered in the pkgsrc infrastructure:
                   2222:
1.69      rillig   2223:   * ALLOW_VULNERABLE_PACKAGES should be set to yes. The purpose of the bulk
                   2224:     builds is creating binary packages, no matter if they are vulnerable or
1.130     wiz      2225:     not. Leaving this variable unset would prevent the bulk build system from
                   2226:     even trying to build them, so possible building errors would not show up.
1.69      rillig   2227:
1.93      rillig   2228:   * CHECK_FILES (pkgsrc/mk/check/check-files.mk) can be set to "yes" to check
                   2229:     that the installed set of files matches the PLIST.
1.68      rillig   2230:
1.93      rillig   2231:   * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to
                   2232:     "yes" to check that the installed "#!"-scripts will find their interpreter.
1.68      rillig   2233:
1.91      rillig   2234:   * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before
                   2235:     installing it. Note that some packages make heavy use of "good" random
                   2236:     numbers, so you need to assure that the machine on which you are doing the
                   2237:     bulk builds is not completely idle. Otherwise some test programs will seem
                   2238:     to hang, while they are just waiting for new random data to be available.
                   2239:
1.107     rillig   2240: 7.3.1.3. pre-build.local
1.1       grant    2241:
1.47      reed     2242: It is possible to configure the bulk build to perform certain site-specific
1.1       grant    2243: tasks at the end of the pre-build stage. If the file pre-build.local exists in
1.23      wiz      2244: /usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the
1.1       grant    2245: usual pre-build stage. An example use of pre-build.local is to have the line:
                   2246:
1.71      wiz      2247: echo "I do not have enough disk space to build this pig." \
1.87      wiz      2248:         > misc/openoffice/$BROKENF
1.1       grant    2249:
                   2250: to prevent the system from trying to build a particular package which requires
                   2251: nearly 3 GB of disk space.
                   2252:
1.107     rillig   2253: 7.3.2. Other environmental considerations
1.1       grant    2254:
                   2255: As /usr/pkg will be completely deleted at the start of bulk builds, make sure
                   2256: your login shell is placed somewhere else. Either drop it into /usr/local/bin
1.20      ben      2257: (and adjust your login shell in the passwd file), or (re-)install it via
1.1       grant    2258: pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that
                   2259: your current process won't die if the package is removed, you just can't start
                   2260: any new instances of the shell any more). Also, if you use NetBSD earlier than
                   2261: 1.5, or you still want to use the pkgsrc version of ssh for some reason, be
                   2262: sure to install ssh before starting it from rc.local:
                   2263:
1.101     rillig   2264: (cd /usr/pkgsrc/security/ssh && make bulk-install)
                   2265: if [ -f /usr/pkg/etc/rc.d/sshd ]; then
                   2266:   /usr/pkg/etc/rc.d/sshd
                   2267: fi
1.1       grant    2268:
                   2269: Not doing so will result in you being not able to log in via ssh after the bulk
                   2270: build is finished or if the machine gets rebooted or crashes. You have been
                   2271: warned! :)
                   2272:
1.107     rillig   2273: 7.3.3. Operation
1.1       grant    2274:
                   2275: Make sure you don't need any of the packages still installed.
                   2276:
                   2277: Warning
                   2278:
1.100     rillig   2279: During the bulk build, all packages, their configuration files and some more
1.101     rillig   2280: files from /var, /home and possibly other locations will be removed! So don't
                   2281: run a bulk build with privileges that might harm your system.
1.1       grant    2282:
                   2283: Be sure to remove all other things that might interfere with builds, like some
                   2284: libs installed in /usr/local, etc. then become root and type:
                   2285:
                   2286: # cd /usr/pkgsrc
                   2287: # sh mk/bulk/build
                   2288:
1.87      wiz      2289:
1.1       grant    2290: If for some reason your last build didn't complete (power failure, system
                   2291: panic, ...), you can continue it by running:
                   2292:
                   2293: # sh mk/bulk/build restart
                   2294:
                   2295: At the end of the bulk build, you will get a summary via mail, and find build
                   2296: logs in the directory specified by FTP in the build.conf file.
                   2297:
1.107     rillig   2298: 7.3.4. What it does
1.1       grant    2299:
                   2300: The bulk builds consist of three steps:
                   2301:
                   2302: 1. pre-build
1.20      ben      2303:
1.1       grant    2304:     The script updates your pkgsrc tree via (anon)cvs, then cleans out any
                   2305:     broken distfiles, and removes all packages installed.
1.20      ben      2306:
1.1       grant    2307: 2. the bulk build
1.20      ben      2308:
1.1       grant    2309:     This is basically "make bulk-package" with an optimised order in which
                   2310:     packages will be built. Packages that don't require other packages will be
                   2311:     built first, and packages with many dependencies will be built later.
1.20      ben      2312:
1.1       grant    2313: 3. post-build
1.20      ben      2314:
1.1       grant    2315:     Generates a report that's placed in the directory specified in the
                   2316:     build.conf file named broken.html, a short version of that report will also
                   2317:     be mailed to the build's admin.
1.20      ben      2318:
1.1       grant    2319: During the build, a list of broken packages will be compiled in /usr/pkgsrc
                   2320: /.broken (or .../.broken.${MACHINE} if OBJMACHINE is set), individual build
                   2321: logs of broken builds can be found in the package's directory. These files are
                   2322: used by the bulk-targets to mark broken builds to not waste time trying to
                   2323: rebuild them, and they can be used to debug these broken package builds later.
                   2324:
1.107     rillig   2325: 7.3.5. Disk space requirements
1.1       grant    2326:
                   2327: Currently, roughly the following requirements are valid for NetBSD 2.0/i386:
                   2328:
                   2329:   * 10 GB - distfiles (NFS ok)
1.20      ben      2330:
1.1       grant    2331:   * 8 GB - full set of all binaries (NFS ok)
1.20      ben      2332:
1.1       grant    2333:   * 5 GB - temp space for compiling (local disk recommended)
1.20      ben      2334:
1.1       grant    2335: Note that all pkgs will be de-installed as soon as they are turned into a
                   2336: binary package, and that sources are removed, so there is no excessively huge
                   2337: demand to disk space. Afterwards, if the package is needed again, it will be
                   2338: installed via pkg_add(1) instead of building again, so there are no cycles
                   2339: wasted by recompiling.
                   2340:
1.107     rillig   2341: 7.3.6. Setting up a sandbox for chrooted builds
1.1       grant    2342:
1.12      agc      2343: If you don't want all the packages nuked from a machine (rendering it useless
1.23      wiz      2344: for anything but pkg compiling), there is the possibility of doing the package
                   2345: bulk build inside a chroot environment.
1.1       grant    2346:
1.12      agc      2347: The first step is to set up a chroot sandbox, e.g. /usr/sandbox. This can be
                   2348: done by using null mounts, or manually.
                   2349:
                   2350: There is a shell script called pkgsrc/mk/bulk/mksandbox which will set up the
                   2351: sandbox environment using null mounts. It will also create a script called
                   2352: sandbox in the root of the sandbox environment, which will allow the null
                   2353: mounts to be activated using the sandbox mount command and deactivated using
                   2354: the sandbox umount command.
                   2355:
                   2356: To set up a sandbox environment by hand, after extracting all the sets from a
                   2357: NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in /usr/
                   2358: src/etc, be sure the following items are present and properly configured:
1.1       grant    2359:
                   2360:  1. Kernel
1.20      ben      2361:
1.1       grant    2362:     # cp /netbsd /usr/sandbox
1.20      ben      2363:
1.1       grant    2364:  2. /dev/*
1.20      ben      2365:
1.1       grant    2366:     # cd /usr/sandbox/dev ; sh MAKEDEV all
1.20      ben      2367:
1.1       grant    2368:  3. /etc/resolv.conf (for security/smtpd and mail):
1.20      ben      2369:
1.1       grant    2370:     # cp /etc/resolv.conf /usr/sandbox/etc
1.20      ben      2371:
1.1       grant    2372:  4. Working(!) mail config (hostname, sendmail.cf):
1.20      ben      2373:
1.1       grant    2374:     # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
1.20      ben      2375:
1.1       grant    2376:  5. /etc/localtime (for security/smtpd):
1.20      ben      2377:
1.1       grant    2378:     # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
1.20      ben      2379:
1.71      wiz      2380:  6. /usr/src (system sources, e. g. for sysutils/aperture):
1.20      ben      2381:
1.1       grant    2382:     # ln -s ../disk1/cvs .
1.87      wiz      2383:               # ln -s cvs/src-2.0 src
1.20      ben      2384:
1.1       grant    2385:  7. Create /var/db/pkg (not part of default install):
1.20      ben      2386:
1.1       grant    2387:     # mkdir /usr/sandbox/var/db/pkg
1.20      ben      2388:
1.1       grant    2389:  8. Create /usr/pkg (not part of default install):
1.20      ben      2390:
1.1       grant    2391:     # mkdir /usr/sandbox/usr/pkg
1.20      ben      2392:
1.1       grant    2393:  9. Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:
1.20      ben      2394:
1.1       grant    2395:     # cd /usr/sandbox/usr
                   2396:     # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
1.20      ben      2397:
1.87      wiz      2398:
1.1       grant    2399:     Do not mount/link this to the copy of your pkgsrc tree you do development
                   2400:     in, as this will likely cause problems!
1.20      ben      2401:
1.1       grant    2402: 10. Make /usr/sandbox/usr/pkgsrc/packages and .../distfiles point somewhere
                   2403:     appropriate. NFS- and/or nullfs-mounts may come in handy!
1.20      ben      2404:
1.130     wiz      2405: 11. Edit mk.conf, see Section 7.3.1.2, "mk.conf".
1.20      ben      2406:
1.1       grant    2407: 12. Adjust mk/bulk/build.conf to suit your needs.
1.20      ben      2408:
1.47      reed     2409: When the chroot sandbox is set up, you can start the build with the following
1.1       grant    2410: steps:
                   2411:
                   2412: # cd /usr/sandbox/usr/pkgsrc
                   2413: # sh mk/bulk/do-sandbox-build
                   2414:
1.87      wiz      2415:
1.1       grant    2416: This will just jump inside the sandbox and start building. At the end of the
                   2417: build, mail will be sent with the results of the build. Created binary pkgs
                   2418: will be in /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/
                   2419: from).
                   2420:
1.107     rillig   2421: 7.3.7. Building a partial set of packages
1.1       grant    2422:
                   2423: In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk
                   2424: /bulk/build script may be used to build a subset of the packages contained in
1.105     rillig   2425: pkgsrc. By setting SPECIFIC_PKGS in mk.conf, the variables
1.1       grant    2426:
                   2427:   * SITE_SPECIFIC_PKGS
1.20      ben      2428:
1.1       grant    2429:   * HOST_SPECIFIC_PKGS
1.20      ben      2430:
1.1       grant    2431:   * GROUP_SPECIFIC_PKGS
1.20      ben      2432:
1.1       grant    2433:   * USER_SPECIFIC_PKGS
1.20      ben      2434:
1.1       grant    2435: will define the set of packages which should be built. The bulk build code will
                   2436: also include any packages which are needed as dependencies for the explicitly
                   2437: listed packages.
                   2438:
                   2439: One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
                   2440: periodically to have a complete set of the binary packages needed for your site
                   2441: available without the overhead of building extra packages that are not needed.
                   2442:
1.107     rillig   2443: 7.3.8. Uploading results of a bulk build
1.13      hubertf  2444:
                   2445: This section describes how pkgsrc developers can upload binary pkgs built by
                   2446: bulk builds to ftp.NetBSD.org.
                   2447:
1.17      sketch   2448: If you would like to automatically create checksum files for the binary
                   2449: packages you intend to upload, remember to set MKSUMS=yes in your mk/bulk/
                   2450: build.conf.
                   2451:
                   2452: If you would like to PGP sign the checksum files (highly recommended!),
                   2453: remember to set SIGN_AS=username@NetBSD.org in your mk/bulk/build.conf. This
1.23      wiz      2454: will prompt you for your GPG password to sign the files before uploading
1.17      sketch   2455: everything.
                   2456:
                   2457: Then, make sure that you have RSYNC_DST set properly in your mk/bulk/build.conf
                   2458: file, i.e. adjust it to something like one of the following:
1.13      hubertf  2459:
1.128     jakllsch 2460: RSYNC_DST=ftp.NetBSD.org:/pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch/upload
1.13      hubertf  2461:
1.128     jakllsch 2462: Please use appropriate values for "packages-20xxQy", "NetBSD-a.b.c" and "arch"
1.68      rillig   2463: here. If your login on ftp.NetBSD.org is different from your local login, write
                   2464: your login directly into the variable, e.g. my local account is "feyrer", but
                   2465: for my login "hubertf", I use:
1.13      hubertf  2466:
1.128     jakllsch 2467: RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch/upload
1.13      hubertf  2468:
                   2469: A separate upload directory is used here to allow "closing" the directory
                   2470: during upload. To do so, run the following command on ftp.NetBSD.org next:
                   2471:
1.128     jakllsch 2472: nbftp% mkdir -p -m 750 /pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch/upload
1.13      hubertf  2473:
                   2474: Please note that /pub/NetBSD/packages is only appropriate for packages for the
                   2475: NetBSD operating system. Binary packages for other operating systems should go
                   2476: into /pub/pkgsrc.
                   2477:
1.23      wiz      2478: Before uploading the binary pkgs, ssh authentication needs to be set up. This
1.47      reed     2479: example shows how to set up temporary keys for the root account inside the
1.13      hubertf  2480: sandbox (assuming that no keys should be present there usually):
                   2481:
1.20      ben      2482: # chroot /usr/sandbox
                   2483: chroot-# rm $HOME/.ssh/id-dsa*
                   2484: chroot-# ssh-keygen -t dsa
                   2485: chroot-# cat $HOME/.ssh/id-dsa.pub
1.13      hubertf  2486:
1.87      wiz      2487:
1.13      hubertf  2488: Now take the output of id-dsa.pub and append it to your ~/.ssh/authorized_keys
1.17      sketch   2489: file on ftp.NetBSD.org. You can remove the key after the upload is done!
1.13      hubertf  2490:
                   2491: Next, test if your ssh connection really works:
                   2492:
1.20      ben      2493: chroot-# ssh ftp.NetBSD.org date
1.13      hubertf  2494:
                   2495: Use "-l yourNetBSDlogin" here as appropriate!
                   2496:
                   2497: Now after all this works, you can exit the sandbox and start the upload:
                   2498:
1.20      ben      2499: chroot-# exit
                   2500: # cd /usr/sandbox/usr/pkgsrc
                   2501: # sh mk/bulk/do-sandbox-upload
1.13      hubertf  2502:
1.87      wiz      2503:
1.24      wiz      2504: The upload process may take quite some time. Use ls(1) or du(1) on the FTP
                   2505: server to monitor progress of the upload. The upload script will take care of
1.129     spz      2506: not uploading restricted packages.
1.13      hubertf  2507:
                   2508: After the upload has ended, first thing is to revoke ssh access:
                   2509:
                   2510: nbftp% vi ~/.ssh/authorized_keys
1.87      wiz      2511:       Gdd:x!
1.13      hubertf  2512:
                   2513: Use whatever is needed to remove the key you've entered before! Last, move the
                   2514: uploaded packages out of the upload directory to have them accessible to
                   2515: everyone:
                   2516:
1.128     jakllsch 2517: nbftp% cd /pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch
1.13      hubertf  2518: nbftp% mv upload/* .
                   2519: nbftp% rmdir upload
1.20      ben      2520: nbftp% chmod 755 .
1.13      hubertf  2521:
1.87      wiz      2522:
1.107     rillig   2523: 7.4. Running a pbulk-style bulk build
                   2524:
1.117     rillig   2525: Running a pbulk-style bulk build works roughly as follows:
                   2526:
                   2527:   * First, build the pbulk infrastructure in a fresh pkgsrc location.
                   2528:
                   2529:   * Then, build each of the packages from a clean installation directory using
                   2530:     the infrastructure.
                   2531:
                   2532: 7.4.1. Preparation
                   2533:
                   2534: First, you need to create a pkgsrc installation for the pbulk infrastructure.
                   2535: No matter on which platform you are (even on NetBSD), you should bootstrap into
1.118     jnemeth  2536: its own directory. Let's take the directory /usr/pbulk or $HOME/pbulk for it.
                   2537: This installation will be bootstrapped and all the tools that are required for
                   2538: the bulk build will be installed there.
1.117     rillig   2539:
                   2540: $ cd /usr/pkgsrc
                   2541: $ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap
                   2542: $ rm -rf /tmp/pbulk-bootstrap
                   2543:
                   2544: Now the basic environment for the pbulk infrastructure is installed. The
                   2545: specific tools are still missing. This is a good time to edit the pkgsrc
                   2546: configuration file /usr/pbulk/etc/mk.conf to fit your needs. Typical things you
                   2547: might set now are:
                   2548:
                   2549:   * PKG_DEVELOPER=yes, to enable many consistency checks,
                   2550:
                   2551:   * WRKOBJDIR=/tmp/pbulk-outer, to keep /usr/pkgsrc free from any
                   2552:     modifications,
                   2553:
                   2554:   * DISTDIR=/distfiles, to have only one directory in which all distfiles (for
                   2555:     the infrastructure and for the actual packages) are downloaded,
                   2556:
                   2557:   * ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual
                   2558:     Free/Open Source licenses that are acceptable to you,
                   2559:
1.126     wiz      2560:   * SKIP_LICENSE_CHECK=yes, to bypass the license checks.
1.117     rillig   2561:
                   2562: Now you are ready to build the rest of the pbulk infrastructure.
                   2563:
                   2564: $ cd pkgtools/pbulk
                   2565: $ /usr/pbulk/bin/bmake install
                   2566: $ rm -rf /tmp/pbulk-outer
                   2567:
                   2568: Now the pbulk infrastructure is built and installed. It still needs to be
                   2569: configured, and after some more preparation, we will be able to start the real
                   2570: bulk build.
                   2571:
                   2572: 7.4.2. Configuration
1.107     rillig   2573:
1.115     jmcneill 2574: TODO; see pkgsrc/doc/HOWTO-pbulk for more information.
1.107     rillig   2575:
1.117     rillig   2576: TODO: continue writing
                   2577:
1.107     rillig   2578: 7.5. Creating a multiple CD-ROM packages collection
1.1       grant    2579:
                   2580: After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
                   2581: of the resulting binary packages to assist in installing packages on other
                   2582: machines. The pkgtools/cdpack package provides a simple tool for creating the
                   2583: ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
1.47      reed     2584: keeps all the dependencies for a given package on the same CD as that package.
1.1       grant    2585:
1.107     rillig   2586: 7.5.1. Example of cdpack
1.1       grant    2587:
1.47      reed     2588: Complete documentation for cdpack is found in the cdpack(1) man page. The
1.1       grant    2589: following short example assumes that the binary packages are left in /usr/
                   2590: pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
                   2591: ISO 9660 images.
                   2592:
                   2593: # mkdir /u2/images
                   2594: # pkg_add /usr/pkgsrc/packages/All/cdpack
                   2595: # cdpack /usr/pkgsrc/packages/All /u2/images
                   2596:
1.87      wiz      2597:
1.1       grant    2598: If you wish to include a common set of files (COPYRIGHT, README, etc.) on each
                   2599: CD in the collection, then you need to create a directory which contains these
                   2600: files. e.g.
                   2601:
                   2602: # mkdir /tmp/common
                   2603: # echo "This is a README" > /tmp/common/README
                   2604: # echo "Another file" > /tmp/common/COPYING
                   2605: # mkdir /tmp/common/bin
                   2606: # echo "#!/bin/sh" > /tmp/common/bin/myscript
                   2607: # echo "echo Hello world" >> /tmp/common/bin/myscript
                   2608: # chmod 755 /tmp/common/bin/myscript
                   2609:
1.87      wiz      2610:
1.1       grant    2611: Now create the images:
                   2612:
                   2613: # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
                   2614:
                   2615: Each image will contain README, COPYING, and bin/myscript in their root
                   2616: directories.
                   2617:
1.107     rillig   2618: Chapter 8. Directory layout of the installed files
1.90      rillig   2619:
                   2620: Table of Contents
                   2621:
1.107     rillig   2622: 8.1. File system layout in ${LOCALBASE}
                   2623: 8.2. File system layout in ${VARBASE}
1.90      rillig   2624:
                   2625: The files that are installed by pkgsrc are organized in a way that is similar
                   2626: to what you find in the /usr directory of the base system. But some details are
                   2627: different. This is because pkgsrc initially came from FreeBSD and had adopted
                   2628: its file system hierarchy. Later it was largely influenced by NetBSD. But no
                   2629: matter which operating system you are using pkgsrc with, you can expect the
                   2630: same layout for pkgsrc.
                   2631:
1.91      rillig   2632: There are mainly four root directories for pkgsrc, which are all configurable
                   2633: in the bootstrap/bootstrap script. When pkgsrc has been installed as root, the
                   2634: default locations are:
                   2635:
1.101     rillig   2636: LOCALBASE=              /usr/pkg
                   2637: PKG_SYSCONFBASE=        /usr/pkg/etc
                   2638: VARBASE=                /var
                   2639: PKG_DBDIR=              /var/db/pkg
1.91      rillig   2640:
                   2641: In unprivileged mode (when pkgsrc has been installed as any other user), the
                   2642: default locations are:
                   2643:
1.101     rillig   2644: LOCALBASE=              ${HOME}/pkg
                   2645: PKG_SYSCONFBASE=        ${HOME}/pkg/etc
                   2646: VARBASE=                ${HOME}/pkg/var
                   2647: PKG_DBDIR=              ${HOME}/pkg/var/db/pkg
1.91      rillig   2648:
                   2649: What these four directories are for, and what they look like is explained
                   2650: below.
1.90      rillig   2651:
                   2652:   * LOCALBASE corresponds to the /usr directory in the base system. It is the
                   2653:     "main" directory where the files are installed and contains the well-known
                   2654:     subdirectories like bin, include, lib, share and sbin.
                   2655:
                   2656:   * VARBASE corresponds to /var in the base system. Some programs (especially
                   2657:     games, network daemons) need write access to it during normal operation.
                   2658:
                   2659:   * PKG_SYSCONFDIR corresponds to /etc in the base system. It contains
                   2660:     configuration files of the packages, as well as pkgsrc's mk.conf itself.
                   2661:
1.107     rillig   2662: 8.1. File system layout in ${LOCALBASE}
1.90      rillig   2663:
1.91      rillig   2664: The following directories exist in a typical pkgsrc installation in $
                   2665: {LOCALBASE}.
1.90      rillig   2666:
                   2667: bin
                   2668:
                   2669:     Contains executable programs that are intended to be directly used by the
                   2670:     end user.
                   2671:
                   2672: emul
                   2673:
                   2674:     Contains files for the emulation layers of various other operating systems,
                   2675:     especially for NetBSD.
                   2676:
                   2677: etc (the usual location of ${PKG_SYSCONFDIR})
                   2678:
                   2679:     Contains the configuration files.
                   2680:
                   2681: include
                   2682:
                   2683:     Contains headers for the C and C++ programming languages.
                   2684:
                   2685: info
                   2686:
                   2687:     Contains GNU info files of various packages.
                   2688:
                   2689: lib
                   2690:
                   2691:     Contains shared and static libraries.
                   2692:
                   2693: libdata
                   2694:
                   2695:     Contains data files that don't change after installation. Other data files
                   2696:     belong into ${VARBASE}.
                   2697:
                   2698: libexec
                   2699:
                   2700:     Contains programs that are not intended to be used by end users, such as
                   2701:     helper programs or network daemons.
                   2702:
                   2703: libexec/cgi-bin
                   2704:
                   2705:     Contains programs that are intended to be executed as CGI scripts by a web
                   2706:     server.
                   2707:
                   2708: man (the usual value of ${PKGMANDIR})
                   2709:
                   2710:     Contains brief documentation in form of manual pages.
                   2711:
                   2712: sbin
                   2713:
                   2714:     Contains programs that are intended to be used only by the super-user.
                   2715:
                   2716: share
                   2717:
                   2718:     Contains platform-independent data files that don't change after
                   2719:     installation.
                   2720:
                   2721: share/doc
                   2722:
                   2723:     Contains documentation files provided by the packages.
                   2724:
                   2725: share/examples
                   2726:
                   2727:     Contains example files provided by the packages. Among others, the original
                   2728:     configuration files are saved here and copied to ${PKG_SYSCONFDIR} during
                   2729:     installation.
                   2730:
                   2731: share/examples/rc.d
                   2732:
                   2733:     Contains the original files for rc.d scripts.
                   2734:
                   2735: var (the usual location of ${VARBASE})
                   2736:
                   2737:     Contains files that may be modified after installation.
                   2738:
1.107     rillig   2739: 8.2. File system layout in ${VARBASE}
1.90      rillig   2740:
                   2741: db/pkg (the usual location of ${PKG_DBDIR})
                   2742:
                   2743:     Contains information about the currently installed packages.
                   2744:
                   2745: games
                   2746:
                   2747:     Contains highscore files.
                   2748:
                   2749: log
                   2750:
                   2751:     Contains log files.
                   2752:
                   2753: run
                   2754:
                   2755:     Contains informational files about daemons that are currently running.
                   2756:
1.107     rillig   2757: Chapter 9. Frequently Asked Questions
1.1       grant    2758:
                   2759: Table of Contents
                   2760:
1.107     rillig   2761: 9.1. Are there any mailing lists for pkg-related discussion?
                   2762: 9.2. Where's the pkgviews documentation?
                   2763: 9.3. Utilities for package management (pkgtools)
                   2764: 9.4. How to use pkgsrc as non-root
                   2765: 9.5. How to resume transfers when fetching distfiles?
                   2766: 9.6. How can I install/use modular X.org from pkgsrc?
                   2767: 9.7. How to fetch files from behind a firewall
                   2768: 9.8. How do I tell make fetch to do passive FTP?
                   2769: 9.9. How to fetch all distfiles at once
1.130     wiz      2770: 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
                   2771: 9.11. What does "Could not find bsd.own.mk" mean?
1.107     rillig   2772: 9.12. Using 'sudo' with pkgsrc
                   2773: 9.13. How do I change the location of configuration files?
                   2774: 9.14. Automated security checks
                   2775: 9.15. Why do some packages ignore my CFLAGS?
                   2776: 9.16. A package does not build. What shall I do?
1.130     wiz      2777: 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
                   2778:     conflicts" mean?
1.1       grant    2779:
                   2780: This section contains hints, tips & tricks on special things in pkgsrc that we
                   2781: didn't find a better place for in the previous chapters, and it contains items
                   2782: for both pkgsrc users and developers.
                   2783:
1.107     rillig   2784: 9.1. Are there any mailing lists for pkg-related discussion?
1.1       grant    2785:
1.18      xtraeme  2786: The following mailing lists may be of interest to pkgsrc users:
1.1       grant    2787:
1.78      rillig   2788:   * pkgsrc-users: This is a general purpose list for most issues regarding
                   2789:     pkgsrc, regardless of platform, e.g. soliciting user help for pkgsrc
                   2790:     configuration, unexpected build failures, using particular packages,
                   2791:     upgrading pkgsrc installations, questions regarding the pkgsrc release
                   2792:     branches, etc. General announcements or proposals for changes that impact
                   2793:     the pkgsrc user community, e.g. major infrastructure changes, new features,
                   2794:     package removals, etc., may also be posted.
1.20      ben      2795:
1.34      wiz      2796:   * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and
                   2797:     discussed.
1.20      ben      2798:
1.71      wiz      2799:   * pkgsrc-changes: This list is for those who are interested in getting a
                   2800:     commit message for every change committed to pkgsrc. It is also available
                   2801:     in digest form, meaning one daily message containing all commit messages
                   2802:     for changes to the package source tree in that 24 hour period.
                   2803:
1.18      xtraeme  2804: To subscribe, do:
                   2805:
1.101     rillig   2806: % echo subscribe listname | mail majordomo@NetBSD.org
1.18      xtraeme  2807:
                   2808: Archives for all these mailing lists are available from http://
                   2809: mail-index.NetBSD.org/.
1.1       grant    2810:
1.107     rillig   2811: 9.2. Where's the pkgviews documentation?
1.1       grant    2812:
                   2813: Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's
                   2814: guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.
                   2815:
1.107     rillig   2816: 9.3. Utilities for package management (pkgtools)
1.1       grant    2817:
1.80      rillig   2818: The directory pkgsrc/pkgtools contains a number of useful utilities for both
                   2819: users and developers of pkgsrc. This section attempts only to make the reader
                   2820: aware of the utilities and when they might be useful, and not to duplicate the
                   2821: documentation that comes with each package.
1.1       grant    2822:
                   2823: Utilities used by pkgsrc (automatically installed when needed):
                   2824:
1.34      wiz      2825:   * pkgtools/x11-links: Symlinks for use by buildlink.
1.20      ben      2826:
1.1       grant    2827: OS tool augmentation (automatically installed when needed):
                   2828:
1.34      wiz      2829:   * pkgtools/digest: Calculates various kinds of checksums (including SHA1).
1.20      ben      2830:
1.34      wiz      2831:   * pkgtools/libnbcompat: Compatibility library for pkgsrc tools.
1.20      ben      2832:
1.34      wiz      2833:   * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree.
1.20      ben      2834:
1.34      wiz      2835:   * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or
                   2836:     for use on operating systems where pkg_install is not present.
1.20      ben      2837:
1.1       grant    2838: Utilities used by pkgsrc (not automatically installed):
                   2839:
1.34      wiz      2840:   * pkgtools/pkg_tarup: Create a binary package from an already-installed
                   2841:     package. Used by make replace to save the old package.
1.20      ben      2842:
1.34      wiz      2843:   * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch
1.5       hubertf  2844:     distfiles from multiple locations. It currently supports the following
                   2845:     methods: multiple CD-ROMs and network FTP/HTTP connections.
1.20      ben      2846:
1.34      wiz      2847:   * pkgtools/xpkgwedge: Put X11 packages someplace else (enabled by default).
1.20      ben      2848:
1.34      wiz      2849:   * devel/cpuflags: Determine the best compiler flags to optimise code for your
1.130     wiz      2850:     current CPU and compiler.
1.20      ben      2851:
1.1       grant    2852: Utilities for keeping track of installed packages, being up to date, etc:
                   2853:
1.34      wiz      2854:   * pkgtools/pkg_chk: Reports on packages whose installed versions do not match
                   2855:     the latest pkgsrc entries.
1.20      ben      2856:
1.34      wiz      2857:   * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a
                   2858:     strategy for updating.
1.20      ben      2859:
1.34      wiz      2860:   * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses
                   2861:     graphviz).
1.20      ben      2862:
1.113     weinem   2863:   * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors.
                   2864:
                   2865:   * pkgtools/lintpkgsrc: The lintpkgsrc(1) program does various checks on the
                   2866:     complete pkgsrc system.
1.20      ben      2867:
1.34      wiz      2868:   * pkgtools/pkgsurvey: Report what packages you have installed.
1.20      ben      2869:
1.1       grant    2870: Utilities for people maintaining or creating individual packages:
                   2871:
1.34      wiz      2872:   * pkgtools/pkgdiff: Automate making and maintaining patches for a package
                   2873:     (includes pkgdiff, pkgvi, mkpatches, etc.).
1.20      ben      2874:
1.34      wiz      2875:   * pkgtools/rpm2pkg, pkgtools/url2pkg: Aids in converting to pkgsrc.
1.20      ben      2876:
1.34      wiz      2877:   * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package.
1.20      ben      2878:
1.47      reed     2879: Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
1.20      ben      2880:
1.34      wiz      2881:   * pkgtools/pkg_comp: Build packages in a chrooted area.
1.20      ben      2882:
1.34      wiz      2883:   * pkgtools/libkver: Spoof kernel version for chrooted cross builds.
1.20      ben      2884:
1.107     rillig   2885: 9.4. How to use pkgsrc as non-root
1.1       grant    2886:
                   2887: If you want to use pkgsrc as non-root user, you can set some variables to make
1.33      jmmv     2888: pkgsrc work under these conditions. At the very least, you need to set
                   2889: UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple
                   2890: related variables to allow installation of packages as non-root.
                   2891:
                   2892: In case the defaults are not enough, you may want to tune some other variables
                   2893: used. For example, if the automatic user/group detection leads to incorrect
                   2894: values (or not the ones you would like to use), you can change them by setting
                   2895: UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively.
                   2896:
                   2897: As regards bootstrapping, please note that the bootstrap script will ease
                   2898: non-root configuration when given the "--ignore-user-check" flag, as it will
                   2899: choose and use multiple default directories under ~/pkg as the installation
1.93      rillig   2900: targets. These directories can be overridden by the "--prefix" flag provided by
1.33      jmmv     2901: the script, as well as some others that allow finer tuning of the tree layout.
1.1       grant    2902:
1.107     rillig   2903: 9.5. How to resume transfers when fetching distfiles?
1.14      xtraeme  2904:
1.47      reed     2905: By default, resuming transfers in pkgsrc is disabled, but you can enable this
1.105     rillig   2906: feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
                   2907: a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.
1.15      xtraeme  2908:
                   2909: You can also use a different program than the default ftp(1) by changing the
1.118     jnemeth  2910: FETCH_USING variable. You can specify the program by using of ftp, fetch, wget
                   2911: or curl. Alternatively, fetching can be disabled by using the value manual. A
                   2912: value of custom disables the system defaults and dependency tracking for the
                   2913: fetch program. In that case you have to provide FETCH_CMD, FETCH_BEFORE_ARGS,
                   2914: FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.
1.14      xtraeme  2915:
1.118     jnemeth  2916: For example, if you want to use wget to download, you'll have to use something
                   2917: like:
1.14      xtraeme  2918:
1.118     jnemeth  2919: FETCH_USING=    wget
1.14      xtraeme  2920:
1.107     rillig   2921: 9.6. How can I install/use modular X.org from pkgsrc?
1.1       grant    2922:
1.104     wiz      2923: If you want to use modular X.org from pkgsrc instead of your system's own X11
1.105     rillig   2924: (/usr/X11R6, /usr/openwin, ...) you will have to add the following line into
                   2925: mk.conf:
1.14      xtraeme  2926:
1.104     wiz      2927: X11_TYPE=modular
1.14      xtraeme  2928:
1.70      rillig   2929: Note
                   2930:
1.104     wiz      2931: The DragonFly operating system defaults to using modular X.org from pkgsrc.
1.70      rillig   2932:
1.107     rillig   2933: 9.7. How to fetch files from behind a firewall
1.1       grant    2934:
                   2935: If you are sitting behind a firewall which does not allow direct connections to
                   2936: Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
1.47      reed     2937: is done using an environment variable in the form of a URL, e.g. in Amdahl, the
1.1       grant    2938: machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
                   2939: the proxy port number. So the proxy environment variables are:
                   2940:
1.101     rillig   2941: ftp_proxy=ftp://orpheus.amdahl.com:80/
                   2942: http_proxy=http://orpheus.amdahl.com:80/
1.1       grant    2943:
1.107     rillig   2944: 9.8. How do I tell make fetch to do passive FTP?
1.1       grant    2945:
                   2946: This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
                   2947: FETCH_CMD is assigned the first available command from the following list:
                   2948:
1.34      wiz      2949:   * ${LOCALBASE}/bin/ftp
                   2950:
                   2951:   * /usr/bin/ftp
1.1       grant    2952:
                   2953: On a default NetBSD installation, this will be /usr/bin/ftp, which
                   2954: automatically tries passive connections first, and falls back to active
                   2955: connections if the server refuses to do passive. For the other tools, add the
1.105     rillig   2956: following to your mk.conf file: PASSIVE_FETCH=1.
1.1       grant    2957:
                   2958: Having that option present will prevent /usr/bin/ftp from falling back to
                   2959: active transfers.
                   2960:
1.107     rillig   2961: 9.9. How to fetch all distfiles at once
1.1       grant    2962:
                   2963: You would like to download all the distfiles in a single batch from work or
                   2964: university, where you can't run a make fetch. There is an archive of distfiles
                   2965: on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
                   2966:
1.47      reed     2967: The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
1.1       grant    2968: subdirectories, carry the resulting list to your machine at work/school and use
1.72      rillig   2969: it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work,
1.1       grant    2970: don't forget to set FETCH_CMD to something that fetches a URL:
                   2971:
                   2972: At home:
                   2973:
                   2974: % cd /usr/pkgsrc
                   2975: % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
                   2976: % scp /tmp/fetch.sh work:/tmp
                   2977:
                   2978: At work:
                   2979:
                   2980: % sh /tmp/fetch.sh
                   2981:
                   2982: then tar up /tmp/distfiles and take it home.
                   2983:
                   2984: If you have a machine running NetBSD, and you want to get all distfiles (even
                   2985: ones that aren't for your machine architecture), you can do so by using the
                   2986: above-mentioned make fetch-list approach, or fetch the distfiles directly by
                   2987: running:
                   2988:
                   2989: % make mirror-distfiles
                   2990:
                   2991: If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can get
                   2992: everything by running:
                   2993:
                   2994: % make fetch NO_SKIP=yes
                   2995:
1.107     rillig   2996: 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
1.1       grant    2997:
                   2998: When compiling the pkgtools/pkg_install package, you get the error from make
                   2999: that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
1.23      wiz      3000: that you don't have installed the "text" set (nroff, ...) from the NetBSD base
1.47      reed     3001: distribution on your machine. It is recommended to do that to format man pages.
1.1       grant    3002:
                   3003: In the case of the pkgtools/pkg_install package, you can get away with setting
1.105     rillig   3004: NOMAN=YES either in the environment or in mk.conf.
1.1       grant    3005:
1.107     rillig   3006: 9.11. What does "Could not find bsd.own.mk" mean?
1.1       grant    3007:
                   3008: You didn't install the compiler set, comp.tgz, when you installed your NetBSD
1.47      reed     3009: machine. Please get and install it, by extracting it in /:
1.1       grant    3010:
                   3011: # cd /
                   3012: # tar --unlink -zxvpf .../comp.tgz
                   3013:
                   3014: comp.tgz is part of every NetBSD release. Get the one that corresponds to your
                   3015: release (determine via uname -r).
                   3016:
1.107     rillig   3017: 9.12. Using 'sudo' with pkgsrc
1.1       grant    3018:
                   3019: When installing packages as non-root user and using the just-in-time su(1)
                   3020: feature of pkgsrc, it can become annoying to type in the root password for each
                   3021: required package installed. To avoid this, the sudo package can be used, which
                   3022: does password caching over a limited time. To use it, install sudo (either as
1.105     rillig   3023: binary package or from security/sudo) and then put the following into your
                   3024: mk.conf, somewhere after the definition of the LOCALBASE variable:
1.1       grant    3025:
1.101     rillig   3026: .if exists(${LOCALBASE}/bin/sudo)
                   3027: SU_CMD=        ${LOCALBASE}/bin/sudo /bin/sh -c
                   3028: .endif
1.14      xtraeme  3029:
1.107     rillig   3030: 9.13. How do I change the location of configuration files?
1.1       grant    3031:
1.35      jmmv     3032: As the system administrator, you can choose where configuration files are
                   3033: installed. The default settings make all these files go into ${PREFIX}/etc or
                   3034: some of its subdirectories; this may be suboptimal depending on your
                   3035: expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine
                   3036: configuration of the provided packages).
                   3037:
                   3038: In order to change the defaults, you can modify the PKG_SYSCONFBASE variable
1.105     rillig   3039: (in mk.conf) to point to your preferred configuration directory; some common
                   3040: examples include /etc or /etc/pkg.
1.35      jmmv     3041:
                   3042: Furthermore, you can change this value on a per-package basis by setting the
                   3043: PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
                   3044: matches the name of the package you would like to modify, that is, the contents
                   3045: of PKGBASE.
1.1       grant    3046:
1.47      reed     3047: Note that after changing these settings, you must rebuild and reinstall any
1.35      jmmv     3048: affected packages.
1.1       grant    3049:
1.107     rillig   3050: 9.14. Automated security checks
1.1       grant    3051:
                   3052: Please be aware that there can often be bugs in third-party software, and some
                   3053: of these bugs can leave a machine vulnerable to exploitation by attackers. In
                   3054: an effort to lessen the exposure, the NetBSD packages team maintains a database
                   3055: of known-exploits to packages which have at one time been included in pkgsrc.
                   3056: The database can be downloaded automatically, and a security audit of all
1.115     jmcneill 3057: packages installed on a system can take place. To do this, refer to the
                   3058: following two tools (installed as part of the pkgtools/pkg_install package):
1.1       grant    3059:
1.123     reed     3060:  1. pkg_admin fetch-pkg-vulnerabilities, an easy way to download a list of the
                   3061:     security vulnerabilities information. This list is kept up to date by the
                   3062:     NetBSD security officer and the NetBSD packages team, and is distributed
                   3063:     from the NetBSD ftp server:
1.20      ben      3064:
1.1       grant    3065:     ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities
1.20      ben      3066:
1.123     reed     3067:  2. pkg_admin audit, an easy way to audit the current machine, checking each
1.130     wiz      3068:     known vulnerability. If a vulnerable package is installed, it will be shown
                   3069:     by output to stdout, including a description of the type of vulnerability,
                   3070:     and a URL containing more information.
1.20      ben      3071:
1.115     jmcneill 3072: Use of these tools is strongly recommended! After "pkg_install" is installed,
                   3073: please read the package's message, which you can get by running pkg_info -D
                   3074: pkg_install.
1.1       grant    3075:
1.58      erh      3076: If this package is installed, pkgsrc builds will use it to perform a security
                   3077: check before building any package. See Section 5.2, "Variables affecting the
1.59      rillig   3078: build process" for ways to control this check.
1.58      erh      3079:
1.107     rillig   3080: 9.15. Why do some packages ignore my CFLAGS?
1.74      rillig   3081:
                   3082: When you add your own preferences to the CFLAGS variable in your mk.conf, these
                   3083: flags are passed in environment variables to the ./configure scripts and to
                   3084: make(1). Some package authors ignore the CFLAGS from the environment variable
                   3085: by overriding them in the Makefiles of their package.
                   3086:
                   3087: Currently there is no solution to this problem. If you really need the package
                   3088: to use your CFLAGS you should run make patch in the package directory and then
                   3089: inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly.
                   3090: Usually you can remove these lines. But be aware that some "smart" programmers
                   3091: write so bad code that it only works for the specific combination of CFLAGS
                   3092: they have chosen.
                   3093:
1.107     rillig   3094: 9.16. A package does not build. What shall I do?
1.80      rillig   3095:
                   3096:  1. Make sure that your copy of pkgsrc is consistent. A case that occurs often
                   3097:     is that people only update pkgsrc in parts, because of performance reasons.
                   3098:     Since pkgsrc is one large system, not a collection of many small systems,
                   3099:     there are sometimes changes that only work when the whole pkgsrc tree is
                   3100:     updated.
                   3101:
                   3102:  2. Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or
                   3103:     ">>>>>>" in all your pkgsrc files.
                   3104:
                   3105:  3. Make sure that you don't have old copies of the packages extracted. Run
                   3106:     make clean clean-depends to verify this.
                   3107:
                   3108:  4. If the problem still exists, write a mail to the pkgsrc-users mailing list.
                   3109:
1.107     rillig   3110: 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
1.89      rillig   3111: conflicts" mean?
                   3112:
                   3113: You have modified a file from pkgsrc, and someone else has modified that same
                   3114: file afterwards in the CVS repository. Both changes are in the same region of
                   3115: the file, so when you updated pkgsrc, the cvs command marked the conflicting
                   3116: changes in the file. Because of these markers, the file is no longer a valid
                   3117: Makefile.
                   3118:
                   3119: Have a look at that file, and if you don't need your local changes anymore, you
                   3120: can remove that file and run cvs -q update -dP in that directory to download
                   3121: the current version.
                   3122:
1.48      dillo    3123: Part II. The pkgsrc developer's guide
1.1       grant    3124:
1.77      rillig   3125: This part of the book deals with creating and modifying packages. It starts
                   3126: with a "HOWTO"-like guide on creating a new package. The remaining chapters are
                   3127: more like a reference manual for pkgsrc.
                   3128:
1.1       grant    3129: Table of Contents
                   3130:
1.107     rillig   3131: 10. Creating a new pkgsrc package from scratch
1.91      rillig   3132:
1.107     rillig   3133:     10.1. Common types of packages
1.91      rillig   3134:
1.107     rillig   3135:         10.1.1. Perl modules
                   3136:         10.1.2. KDE applications
1.119     imil     3137:         10.1.3. Python modules and programs
1.91      rillig   3138:
1.107     rillig   3139:     10.2. Examples
1.91      rillig   3140:
1.107     rillig   3141:         10.2.1. How the www/nvu package came into pkgsrc
1.91      rillig   3142:
1.107     rillig   3143: 11. Package components - files, directories and contents
1.27      rillig   3144:
1.107     rillig   3145:     11.1. Makefile
                   3146:     11.2. distinfo
                   3147:     11.3. patches/*
1.85      jmmv     3148:
1.107     rillig   3149:         11.3.1. Structure of a single patch file
                   3150:         11.3.2. Creating patch files
                   3151:         11.3.3. Sources where the patch files come from
                   3152:         11.3.4. Patching guidelines
                   3153:         11.3.5. Feedback to the author
1.85      jmmv     3154:
1.107     rillig   3155:     11.4. Other mandatory files
                   3156:     11.5. Optional files
1.78      rillig   3157:
1.107     rillig   3158:         11.5.1. Files affecting the binary package
                   3159:         11.5.2. Files affecting the build process
                   3160:         11.5.3. Files affecting nothing at all
1.78      rillig   3161:
1.107     rillig   3162:     11.6. work*
                   3163:     11.7. files/*
1.27      rillig   3164:
1.107     rillig   3165: 12. Programming in Makefiles
1.25      rillig   3166:
1.107     rillig   3167:     12.1. Caveats
                   3168:     12.2. Makefile variables
1.25      rillig   3169:
1.107     rillig   3170:         12.2.1. Naming conventions
1.27      rillig   3171:
1.107     rillig   3172:     12.3. Code snippets
1.27      rillig   3173:
1.107     rillig   3174:         12.3.1. Adding things to a list
                   3175:         12.3.2. Converting an internal list into an external list
                   3176:         12.3.3. Passing variables to a shell command
                   3177:         12.3.4. Quoting guideline
                   3178:         12.3.5. Workaround for a bug in BSD Make
1.20      ben      3179:
1.107     rillig   3180: 13. PLIST issues
1.20      ben      3181:
1.107     rillig   3182:     13.1. RCS ID
                   3183:     13.2. Semi-automatic PLIST generation
                   3184:     13.3. Tweaking output of make print-PLIST
                   3185:     13.4. Variable substitution in PLIST
                   3186:     13.5. Man page compression
                   3187:     13.6. Changing PLIST source with PLIST_SRC
                   3188:     13.7. Platform-specific and differing PLISTs
                   3189:     13.8. Sharing directories between packages
1.20      ben      3190:
1.107     rillig   3191: 14. Buildlink methodology
1.20      ben      3192:
1.107     rillig   3193:     14.1. Converting packages to use buildlink3
                   3194:     14.2. Writing buildlink3.mk files
1.20      ben      3195:
1.107     rillig   3196:         14.2.1. Anatomy of a buildlink3.mk file
                   3197:         14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
1.20      ben      3198:
1.107     rillig   3199:     14.3. Writing builtin.mk files
1.20      ben      3200:
1.107     rillig   3201:         14.3.1. Anatomy of a builtin.mk file
                   3202:         14.3.2. Global preferences for native or pkgsrc software
1.20      ben      3203:
1.107     rillig   3204: 15. The pkginstall framework
1.35      jmmv     3205:
1.107     rillig   3206:     15.1. Files and directories outside the installation prefix
1.20      ben      3207:
1.107     rillig   3208:         15.1.1. Directory manipulation
                   3209:         15.1.2. File manipulation
1.20      ben      3210:
1.107     rillig   3211:     15.2. Configuration files
1.20      ben      3212:
1.107     rillig   3213:         15.2.1. How PKG_SYSCONFDIR is set
                   3214:         15.2.2. Telling the software where configuration files are
                   3215:         15.2.3. Patching installations
                   3216:         15.2.4. Disabling handling of configuration files
1.35      jmmv     3217:
1.107     rillig   3218:     15.3. System startup scripts
1.35      jmmv     3219:
1.107     rillig   3220:         15.3.1. Disabling handling of system startup scripts
1.35      jmmv     3221:
1.107     rillig   3222:     15.4. System users and groups
                   3223:     15.5. System shells
1.35      jmmv     3224:
1.107     rillig   3225:         15.5.1. Disabling shell registration
1.65      hubertf  3226:
1.107     rillig   3227:     15.6. Fonts
1.65      hubertf  3228:
1.107     rillig   3229:         15.6.1. Disabling automatic update of the fonts databases
1.35      jmmv     3230:
1.107     rillig   3231: 16. Options handling
1.35      jmmv     3232:
1.107     rillig   3233:     16.1. Global default options
                   3234:     16.2. Converting packages to use bsd.options.mk
                   3235:     16.3. Option Names
1.108     rillig   3236:     16.4. Determining the options of dependencies
1.35      jmmv     3237:
1.107     rillig   3238: 17. The build process
1.35      jmmv     3239:
1.107     rillig   3240:     17.1. Introduction
                   3241:     17.2. Program location
                   3242:     17.3. Directories used during the build process
                   3243:     17.4. Running a phase
                   3244:     17.5. The fetch phase
1.81      rillig   3245:
1.107     rillig   3246:         17.5.1. What to fetch and where to get it from
                   3247:         17.5.2. How are the files fetched?
1.81      rillig   3248:
1.107     rillig   3249:     17.6. The checksum phase
                   3250:     17.7. The extract phase
                   3251:     17.8. The patch phase
                   3252:     17.9. The tools phase
                   3253:     17.10. The wrapper phase
                   3254:     17.11. The configure phase
                   3255:     17.12. The build phase
                   3256:     17.13. The test phase
                   3257:     17.14. The install phase
                   3258:     17.15. The package phase
                   3259:     17.16. Cleaning up
                   3260:     17.17. Other helpful targets
1.35      jmmv     3261:
1.107     rillig   3262: 18. Tools needed for building or running
1.35      jmmv     3263:
1.107     rillig   3264:     18.1. Tools for pkgsrc builds
                   3265:     18.2. Tools needed by packages
                   3266:     18.3. Tools provided by platforms
                   3267:     18.4. Questions regarding the tools
1.68      rillig   3268:
1.107     rillig   3269: 19. Making your package work
1.68      rillig   3270:
1.107     rillig   3271:     19.1. General operation
1.68      rillig   3272:
1.107     rillig   3273:         19.1.1. Portability of packages
1.130     wiz      3274:         19.1.2. How to pull in user-settable variables from mk.conf
1.107     rillig   3275:         19.1.3. User interaction
                   3276:         19.1.4. Handling licenses
                   3277:         19.1.5. Restricted packages
                   3278:         19.1.6. Handling dependencies
                   3279:         19.1.7. Handling conflicts with other packages
                   3280:         19.1.8. Packages that cannot or should not be built
                   3281:         19.1.9. Packages which should not be deleted, once installed
                   3282:         19.1.10. Handling packages with security problems
                   3283:         19.1.11. How to handle incrementing versions when fixing an existing
1.1       grant    3284:             package
1.107     rillig   3285:         19.1.12. Substituting variable text in the package files (the SUBST
1.79      rillig   3286:             framework)
1.77      rillig   3287:
1.107     rillig   3288:     19.2. Fixing problems in the fetch phase
1.77      rillig   3289:
1.107     rillig   3290:         19.2.1. Packages whose distfiles aren't available for plain downloading
                   3291:         19.2.2. How to handle modified distfiles with the 'old' name
1.77      rillig   3292:
1.107     rillig   3293:     19.3. Fixing problems in the configure phase
1.77      rillig   3294:
1.107     rillig   3295:         19.3.1. Shared libraries - libtool
                   3296:         19.3.2. Using libtool on GNU packages that already support libtool
                   3297:         19.3.3. GNU Autoconf/Automake
                   3298:
                   3299:     19.4. Programming languages
                   3300:
                   3301:         19.4.1. C, C++, and Fortran
                   3302:         19.4.2. Java
                   3303:         19.4.3. Packages containing perl scripts
                   3304:         19.4.4. Other programming languages
                   3305:
                   3306:     19.5. Fixing problems in the build phase
                   3307:
                   3308:         19.5.1. Compiling C and C++ code conditionally
                   3309:         19.5.2. How to handle compiler bugs
1.130     wiz      3310:         19.5.3. Undefined reference to "..."
1.107     rillig   3311:         19.5.4. Running out of memory
                   3312:
                   3313:     19.6. Fixing problems in the install phase
                   3314:
                   3315:         19.6.1. Creating needed directories
                   3316:         19.6.2. Where to install documentation
                   3317:         19.6.3. Installing highscore files
                   3318:         19.6.4. Adding DESTDIR support to packages
                   3319:         19.6.5. Packages with hardcoded paths to other interpreters
                   3320:         19.6.6. Packages installing perl modules
                   3321:         19.6.7. Packages installing info files
                   3322:         19.6.8. Packages installing man pages
1.108     rillig   3323:         19.6.9. Packages installing GConf data files
1.120     mishka   3324:         19.6.10. Packages installing scrollkeeper/rarian data files
1.107     rillig   3325:         19.6.11. Packages installing X11 fonts
                   3326:         19.6.12. Packages installing GTK2 modules
                   3327:         19.6.13. Packages installing SGML or XML data
                   3328:         19.6.14. Packages installing extensions to the MIME database
                   3329:         19.6.15. Packages using intltool
                   3330:         19.6.16. Packages installing startup scripts
                   3331:         19.6.17. Packages installing TeX modules
                   3332:         19.6.18. Packages supporting running binaries in emulation
                   3333:         19.6.19. Packages installing hicolor theme icons
                   3334:         19.6.20. Packages installing desktop files
                   3335:
                   3336:     19.7. Marking packages as having problems
                   3337:
                   3338: 20. Debugging
                   3339: 21. Submitting and Committing
                   3340:
                   3341:     21.1. Submitting binary packages
                   3342:     21.2. Submitting source packages (for non-NetBSD-developers)
                   3343:     21.3. General notes when adding, updating, or removing packages
                   3344:     21.4. Committing: Importing a package into CVS
                   3345:     21.5. Updating a package to a newer version
1.123     reed     3346:     21.6. Renaming a package in pkgsrc
                   3347:     21.7. Moving a package in pkgsrc
1.107     rillig   3348:
                   3349: 22. Frequently Asked Questions
                   3350: 23. GNOME packaging and porting
                   3351:
                   3352:     23.1. Meta packages
                   3353:     23.2. Packaging a GNOME application
                   3354:     23.3. Updating GNOME to a newer version
                   3355:     23.4. Patching guidelines
1.77      rillig   3356:
1.107     rillig   3357: Chapter 10. Creating a new pkgsrc package from scratch
1.77      rillig   3358:
1.91      rillig   3359: Table of Contents
                   3360:
1.107     rillig   3361: 10.1. Common types of packages
1.91      rillig   3362:
1.107     rillig   3363:     10.1.1. Perl modules
                   3364:     10.1.2. KDE applications
1.119     imil     3365:     10.1.3. Python modules and programs
1.91      rillig   3366:
1.107     rillig   3367: 10.2. Examples
1.91      rillig   3368:
1.107     rillig   3369:     10.2.1. How the www/nvu package came into pkgsrc
1.91      rillig   3370:
1.77      rillig   3371: When you find a package that is not yet in pkgsrc, you most likely have a URL
                   3372: from where you can download the source code. Starting with this URL, creating a
                   3373: package involves only a few steps.
                   3374:
                   3375:  1. First, install the packages pkgtools/url2pkg and pkgtools/pkglint.
                   3376:
                   3377:  2. Then, choose one of the top-level directories as the category in which you
                   3378:     want to place your package. You can also create a directory of your own
                   3379:     (maybe called local). In that category directory, create another directory
                   3380:     for your package and change into it.
                   3381:
                   3382:  3. Run the program url2pkg, which will ask you for a URL. Enter the URL of the
                   3383:     distribution file (in most cases a .tar.gz file) and watch how the basic
                   3384:     ingredients of your package are created automatically. The distribution
                   3385:     file is extracted automatically to fill in some details in the Makefile
                   3386:     that would otherwise have to be done manually.
                   3387:
                   3388:  4. Examine the extracted files to determine the dependencies of your package.
                   3389:     Ideally, this is mentioned in some README file, but things may differ. For
                   3390:     each of these dependencies, look where it exists in pkgsrc, and if there is
                   3391:     a file called buildlink3.mk in that directory, add a line to your package
                   3392:     Makefile which includes that file just before the last line. If the
                   3393:     buildlink3.mk file does not exist, add a DEPENDS line to the Makefile,
                   3394:     which specifies the version of the dependency and where it can be found in
                   3395:     pkgsrc. This line should be placed in the third paragraph. If the
                   3396:     dependency is only needed for building the package, but not when using it,
                   3397:     use BUILD_DEPENDS instead of DEPENDS. Your package may then look like this:
                   3398:
1.101     rillig   3399:     [...]
1.77      rillig   3400:
1.101     rillig   3401:     BUILD_DEPENDS+= lua>=5.0:../../lang/lua
                   3402:     DEPENDS+=       screen-[0-9]*:../../misc/screen
                   3403:     DEPENDS+=       screen>=4.0:../../misc/screen
1.77      rillig   3404:
1.101     rillig   3405:     [...]
1.77      rillig   3406:
1.101     rillig   3407:     .include "../../category/package/buildlink3.mk"
                   3408:     .include "../../devel/glib2/buildlink3.mk"
                   3409:     .include "../../mk/bsd.pkg.mk"
1.77      rillig   3410:
                   3411:  5. Run pkglint to see what things still need to be done to make your package a
                   3412:     "good" one. If you don't know what pkglint's warnings want to tell you, try
                   3413:     pkglint --explain or pkglint -e, which outputs additional explanations.
1.25      rillig   3414:
1.91      rillig   3415:  6. In many cases the package is not yet ready to build. You can find
1.107     rillig   3416:     instructions for the most common cases in the next section, Section 10.1,
1.91      rillig   3417:     "Common types of packages". After you have followed the instructions over
                   3418:     there, you can hopefully continue here.
                   3419:
                   3420:  7. Run bmake clean to clean the working directory from the extracted files.
                   3421:     Besides these files, a lot of cache files and other system information has
                   3422:     been saved in the working directory, which may become wrong after you
                   3423:     edited the Makefile.
                   3424:
                   3425:  8. Now, run bmake to build the package. For the various things that can go
1.107     rillig   3426:     wrong in this phase, consult Chapter 19, Making your package work.
1.25      rillig   3427:
1.91      rillig   3428:  9. When the package builds fine, the next step is to install the package. Run
1.77      rillig   3429:     bmake install and hope that everything works.
1.25      rillig   3430:
1.91      rillig   3431: 10. Up to now, the file PLIST, which contains a list of the files that are
1.77      rillig   3432:     installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to
                   3433:     generate a probably correct list. Check the file using your preferred text
                   3434:     editor to see if the list of files looks plausible.
1.25      rillig   3435:
1.91      rillig   3436: 11. Run pkglint again to see if the generated PLIST contains garbage or not.
1.25      rillig   3437:
1.91      rillig   3438: 12. When you ran bmake install, the package has been registered in the database
1.77      rillig   3439:     of installed files, but with an empty list of files. To fix this, run bmake
                   3440:     deinstall and bmake install again. Now the package is registered with the
                   3441:     list of files from PLIST.
1.69      rillig   3442:
1.91      rillig   3443: 13. Run bmake package to create a binary package from the set of installed
1.77      rillig   3444:     files.
                   3445:
1.107     rillig   3446: 10.1. Common types of packages
1.91      rillig   3447:
1.107     rillig   3448: 10.1.1. Perl modules
1.91      rillig   3449:
                   3450: Simple Perl modules are handled automatically by url2pkg, including
                   3451: dependencies.
                   3452:
1.107     rillig   3453: 10.1.2. KDE applications
1.91      rillig   3454:
                   3455: KDE applications should always include meta-pkgs/kde3/kde3.mk, which contains
                   3456: numerous settings that are typical of KDE packages.
                   3457:
1.119     imil     3458: 10.1.3. Python modules and programs
                   3459:
                   3460: Python modules and programs packages are easily created using a set of
                   3461: predefined variables.
                   3462:
                   3463: Most Python packages use either "distutils" or easy-setup ("eggs"). If the
                   3464: software uses "distutils", set the PYDISTUTILSPKG variable to "yes" so pkgsrc
                   3465: will make use of this framework. "distutils" uses a script called setup.py, if
                   3466: the "distutils" driver is not called setup.py, set the PYSETUP variable to the
                   3467: name of the script.
                   3468:
                   3469: If the default Python versions are not supported by the software, set the
                   3470: PYTHON_VERSIONS_ACCEPTED variable to the Python versions the software is known
                   3471: to work with, from the most recent to the older one, e.g.
                   3472:
1.127     wiz      3473: PYTHON_VERSIONS_ACCEPTED=       25 24
1.119     imil     3474:
                   3475: If the packaged software is a Python module, include "../../lang/python/
                   3476: extension.mk". In this case, the package directory should be called
                   3477: "py-software" and PKGNAME should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.
                   3478:
                   3479: DISTNAME=   foopymodule-1.2.10
                   3480: PKGNAME=    ${PYPKGPREFIX}-${DISTNAME}
                   3481:
                   3482: If it is an application, also include "../../lang/python/application.mk" before
                   3483: "extension.mk".
                   3484:
                   3485: If the packaged software, either it is an application or a module, is
                   3486: egg-aware, you only need to include "../../lang/python/egg.mk".
                   3487:
                   3488: In order to correctly set the path to the Python interpreter, use the
                   3489: REPLACE_PYTHON variable and set it to the list of files that must be corrected.
                   3490: For example :
                   3491:
                   3492: REPLACE_PYTHON=   ${WRKSRC}/*.py
                   3493:
1.107     rillig   3494: 10.2. Examples
1.91      rillig   3495:
1.107     rillig   3496: 10.2.1. How the www/nvu package came into pkgsrc
1.91      rillig   3497:
1.107     rillig   3498: 10.2.1.1. The initial package
1.91      rillig   3499:
                   3500: Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet
                   3501: been imported into pkgsrc. As the description says it has to do with the web,
                   3502: the obvious choice for the category is "www".
                   3503:
1.101     rillig   3504: $ mkdir www/nvu
                   3505: $ cd www/nvu
1.91      rillig   3506:
                   3507: The web site says that the sources are available as a tar file, so I fed that
                   3508: URL to the url2pkg program:
                   3509:
1.101     rillig   3510: $ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
1.91      rillig   3511:
                   3512: My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the
                   3513: package name should not have the word "sources" in it. I also filled in the
                   3514: MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like
                   3515: that:
                   3516:
1.101     rillig   3517: # $NetBSD$
                   3518: #
1.91      rillig   3519:
1.101     rillig   3520: DISTNAME=       nvu-1.0-sources
                   3521: PKGNAME=        nvu-1.0
                   3522: CATEGORIES=     www
                   3523: MASTER_SITES=   http://cvs.nvu.com/download/
                   3524: EXTRACT_SUFX=   .tar.bz2
                   3525:
                   3526: MAINTAINER=     rillig@NetBSD.org
                   3527: HOMEPAGE=       http://cvs.nvu.com/
                   3528: COMMENT=        Web Authoring System
1.91      rillig   3529:
1.101     rillig   3530: # url2pkg-marker (please do not remove this line.)
                   3531: .include "../../mk/bsd.pkg.mk"
1.91      rillig   3532:
                   3533: Then, I quit the editor and watched pkgsrc downloading a large source archive:
                   3534:
1.101     rillig   3535: url2pkg> Running "make makesum" ...
                   3536: => Required installed package digest>=20010302: digest-20060826 found
                   3537: => Fetching nvu-1.0-sources.tar.bz2
                   3538: Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
                   3539: 100% |*************************************| 28992 KB  150.77 KB/s00:00 ETA
                   3540: 29687976 bytes retrieved in 03:12 (150.77 KB/s)
                   3541: url2pkg> Running "make extract" ...
                   3542: => Required installed package digest>=20010302: digest-20060826 found
                   3543: => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
                   3544: => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
                   3545: work.bacc -> /tmp/roland/pkgsrc/www/nvu/work.bacc
                   3546: ===> Installing dependencies for nvu-1.0
                   3547: ===> Overriding tools for nvu-1.0
                   3548: ===> Extracting for nvu-1.0
                   3549: url2pkg> Adjusting the Makefile.
1.91      rillig   3550:
1.101     rillig   3551: Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done!
1.91      rillig   3552:
1.101     rillig   3553: Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)
1.91      rillig   3554:
1.107     rillig   3555: 10.2.1.2. Fixing all kinds of problems to make the package work
1.91      rillig   3556:
                   3557: Now that the package has been extracted, let's see what's inside it. The
                   3558: package has a README.txt, but that only says something about mozilla, so it's
                   3559: probably useless for seeing what dependencies this package has. But since there
                   3560: is a GNU configure script in the package, let's hope that it will complain
                   3561: about everything it needs.
                   3562:
1.101     rillig   3563: $ bmake
                   3564: => Required installed package digest>=20010302: digest-20060826 found
                   3565: => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
                   3566: => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
                   3567: ===> Patching for nvu-1.0
                   3568: ===> Creating toolchain wrappers for nvu-1.0
                   3569: ===> Configuring for nvu-1.0
                   3570: [...]
                   3571: configure: error: Perl 5.004 or higher is required.
                   3572: [...]
                   3573: WARNING: Please add USE_TOOLS+=perl to the package Makefile.
                   3574: [...]
1.91      rillig   3575:
                   3576: That worked quite well. So I opened the package Makefile in my editor, and
                   3577: since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
                   3578: dependencies of the package have changed now, and since a perl wrapper is
                   3579: automatically installed in the "tools" phase, I need to build the package from
                   3580: scratch.
                   3581:
1.101     rillig   3582: $ bmake clean
                   3583: ===> Cleaning for nvu-1.0
                   3584: $ bmake
                   3585: [...]
                   3586: *** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \
                   3587: GNU Make.  You will not be able to build Mozilla without GNU Make.
                   3588: [...]
1.91      rillig   3589:
                   3590: So I added "gmake" to the USE_TOOLS line and tried again (from scratch).
                   3591:
1.101     rillig   3592: [...]
                   3593: checking for GTK - version >= 1.2.0... no
                   3594: *** Could not run GTK test program, checking why...
                   3595: [...]
1.91      rillig   3596:
                   3597: Now to the other dependencies. The first question is: Where is the GTK package
                   3598: hidden in pkgsrc?
                   3599:
1.101     rillig   3600: $ echo ../../*/gtk*
                   3601: [many packages ...]
                   3602: $ echo ../../*/gtk
                   3603: ../../x11/gtk
                   3604: $ echo ../../*/gtk2
                   3605: ../../x11/gtk2
                   3606: $ echo ../../*/gtk2/bui*
                   3607: ../../x11/gtk2/buildlink3.mk
1.91      rillig   3608:
                   3609: The first try was definitely too broad. The second one had exactly one result,
                   3610: which is very good. But there is one pitfall with GNOME packages. Before GNOME
                   3611: 2 had been released, there were already many GNOME 1 packages in pkgsrc. To be
                   3612: able to continue to use these packages, the GNOME 2 packages were imported as
                   3613: separate packages, and their names usually have a "2" appended. So I checked
                   3614: whether this was the case here, and indeed it was.
                   3615:
                   3616: Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
                   3617: easy. I just inserted an .include line before the last line of the package
                   3618: Makefile, so that it now looks like this:
                   3619:
1.101     rillig   3620: [...]
                   3621: .include "../../x11/gtk2/buildlink3.mk"
                   3622: .include "../../mk/bsd.pkg.mk
1.91      rillig   3623:
                   3624: After another bmake clean && bmake, the answer was:
                   3625:
1.101     rillig   3626: [...]
                   3627: checking for gtk-config... /home/roland/pkg/bin/gtk-config
                   3628: checking for GTK - version >= 1.2.0... no
                   3629: *** Could not run GTK test program, checking why...
                   3630: *** The test program failed to compile or link. See the file config.log for the
                   3631: *** exact error that occured. This usually means GTK was incorrectly installed
                   3632: *** or that you have moved GTK since it was installed. In the latter case, you
                   3633: *** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config
                   3634: configure: error: Test for GTK failed.
                   3635: [...]
1.91      rillig   3636:
                   3637: In this particular case, the assumption that "every package prefers GNOME 2"
                   3638: had been wrong. The first of the lines above told me that this package really
                   3639: wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
                   3640: it would have looked for pkg-config instead of gtk-config. So I changed the x11
                   3641: /gtk2 to x11/gtk in the package Makefile, and tried again.
                   3642:
1.101     rillig   3643: [...]
                   3644: 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
                   3645: In file included from xpidl.c:42:
                   3646: xpidl.h:53:24: libIDL/IDL.h: No such file or directory
                   3647: In file included from xpidl.c:42:
                   3648: xpidl.h:132: error: parse error before "IDL_ns"
                   3649: [...]
1.91      rillig   3650:
                   3651: The package still does not find all of its dependencies. Now the question is:
                   3652: Which package provides the libIDL/IDL.h header file?
                   3653:
1.101     rillig   3654: $ echo ../../*/*idl*
                   3655: ../../devel/py-idle ../../wip/idled ../../x11/acidlaunch
                   3656: $ echo ../../*/*IDL*
                   3657: ../../net/libIDL
1.91      rillig   3658:
                   3659: Let's take the one from the second try. So I included the ../../net/libIDL/
                   3660: buildlink3.mk file and tried again. But the error didn't change. After digging
                   3661: through some of the code, I concluded that the build process of the package was
                   3662: broken and couldn't have ever worked, but since the Mozilla source tree is
                   3663: quite large, I didn't want to fix it. So I added the following to the package
                   3664: Makefile and tried again:
                   3665:
1.101     rillig   3666: CPPFLAGS+=              -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0
                   3667: BUILDLINK_TRANSFORM+=   -l:IDL:IDL-2
1.91      rillig   3668:
                   3669: The latter line is needed because the package expects the library libIDL.so,
                   3670: but only libIDL-2.so is available. So I told the compiler wrapper to rewrite
                   3671: that on the fly.
                   3672:
                   3673: The next problem was related to a recent change of the FreeType interface. I
                   3674: looked up in www/seamonkey which patch files were relevant for this issue and
                   3675: copied them to the patches directory. Then I retried, fixed the patches so that
                   3676: they applied cleanly and retried again. This time, everything worked.
                   3677:
1.107     rillig   3678: 10.2.1.3. Installing the package
1.91      rillig   3679:
1.101     rillig   3680: $ bmake CHECK_FILES=no install
                   3681: [...]
                   3682: $ bmake print-PLIST >PLIST
                   3683: $ bmake deinstall
                   3684: $ bmake install
1.91      rillig   3685:
1.107     rillig   3686: Chapter 11. Package components - files, directories and contents
1.1       grant    3687:
                   3688: Table of Contents
                   3689:
1.107     rillig   3690: 11.1. Makefile
                   3691: 11.2. distinfo
                   3692: 11.3. patches/*
                   3693:
                   3694:     11.3.1. Structure of a single patch file
                   3695:     11.3.2. Creating patch files
                   3696:     11.3.3. Sources where the patch files come from
                   3697:     11.3.4. Patching guidelines
                   3698:     11.3.5. Feedback to the author
                   3699:
                   3700: 11.4. Other mandatory files
                   3701: 11.5. Optional files
                   3702:
                   3703:     11.5.1. Files affecting the binary package
                   3704:     11.5.2. Files affecting the build process
                   3705:     11.5.3. Files affecting nothing at all
1.78      rillig   3706:
1.107     rillig   3707: 11.6. work*
                   3708: 11.7. files/*
1.1       grant    3709:
                   3710: Whenever you're preparing a package, there are a number of files involved which
                   3711: are described in the following sections.
                   3712:
1.107     rillig   3713: 11.1. Makefile
1.1       grant    3714:
                   3715: Building, installation and creation of a binary package are all controlled by
1.23      wiz      3716: the package's Makefile. The Makefile describes various things about a package,
                   3717: for example from where to get it, how to configure, build, and install it.
                   3718:
                   3719: A package Makefile contains several sections that describe the package.
                   3720:
                   3721: In the first section there are the following variables, which should appear
1.87      wiz      3722: exactly in the order given here. The order and grouping of the variables is
1.81      rillig   3723: mostly historical and has no further meaning.
1.23      wiz      3724:
                   3725:   * DISTNAME is the basename of the distribution file to be downloaded from the
                   3726:     package's website.
                   3727:
                   3728:   * PKGNAME is the name of the package, as used by pkgsrc. You only need to
1.87      wiz      3729:     provide it if DISTNAME (which is the default) is not a good name for the
                   3730:     package in pkgsrc. Usually it is the pkgsrc directory name together with
                   3731:     the version number. It must match the regular expression ^[A-Za-z0-9]
                   3732:     [A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains
                   3733:     only letters, digits, dashes, underscores, dots and plus signs.
                   3734:
                   3735:   * SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't
                   3736:     unique on a SVR4 system. The default is PKGNAME, which may be shortened
                   3737:     when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not
                   3738:     produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME
                   3739:     is limited to 5 characters.
1.23      wiz      3740:
                   3741:   * CATEGORIES is a list of categories which the package fits in. You can
                   3742:     choose any of the top-level directories of pkgsrc for it.
                   3743:
1.45      wiz      3744:     Currently the following values are available for CATEGORIES. If more than
                   3745:     one is used, they need to be separated by spaces:
                   3746:
1.101     rillig   3747:     archivers     cross         geography     meta-pkgs     security
                   3748:     audio         databases     graphics      misc          shells
                   3749:     benchmarks    devel         ham           multimedia    sysutils
                   3750:     biology       editors       inputmethod   net           textproc
                   3751:     cad           emulators     lang          news          time
                   3752:     chat          finance       mail          parallel      wm
                   3753:     comms         fonts         math          pkgtools      www
                   3754:     converters    games         mbone         print         x11
1.45      wiz      3755:
1.81      rillig   3756:   * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
1.107     rillig   3757:     are discussed in detail in Section 17.5, "The fetch phase".
1.45      wiz      3758:
                   3759: The second section contains information about separately downloaded patches, if
                   3760: any.
                   3761:
1.47      reed     3762:   * PATCHFILES: Name(s) of additional files that contain distribution patches.
1.45      wiz      3763:     There is no default. pkgsrc will look for them at PATCH_SITES. They will
                   3764:     automatically be uncompressed before patching if the names end with .gz or
                   3765:     .Z.
                   3766:
                   3767:   * PATCH_SITES: Primary location(s) for distribution patch files (see
                   3768:     PATCHFILES below) if not found locally.
                   3769:
                   3770: The third section contains the following variables.
                   3771:
1.50      rillig   3772:   * MAINTAINER is the email address of the person who feels responsible for
                   3773:     this package, and who is most likely to look at problems or questions
                   3774:     regarding this package which have been reported with send-pr(1). Other
1.115     jmcneill 3775:     developers may contact the MAINTAINER before making changes to the package,
                   3776:     but are not required to do so. When packaging a new program, set MAINTAINER
                   3777:     to yourself. If you really can't maintain the package for future updates,
                   3778:     set it to <pkgsrc-users@NetBSD.org>.
                   3779:
                   3780:   * OWNER should be used instead of MAINTAINER when you do not want other
                   3781:     developers to update or change the package without contacting you first. A
                   3782:     package Makefile should contain one of MAINTAINER or OWNER, but not both.
1.23      wiz      3783:
                   3784:   * HOMEPAGE is a URL where users can find more information about the package.
1.1       grant    3785:
1.45      wiz      3786:   * COMMENT is a one-line description of the package (should not include the
                   3787:     package name).
1.1       grant    3788:
1.45      wiz      3789: Other variables that affect the build:
1.1       grant    3790:
1.50      rillig   3791:   * WRKSRC: The directory where the interesting distribution files of the
                   3792:     package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
                   3793:     most packages.
                   3794:
                   3795:     If a package doesn't create a subdirectory for itself (most GNU software
                   3796:     does, for instance), but extracts itself in the current directory, you
1.87      wiz      3797:     should set WRKSRC=${WRKDIR}.
1.50      rillig   3798:
                   3799:     If a package doesn't create a subdirectory with the name of DISTNAME but
                   3800:     some different name, set WRKSRC to point to the proper name in ${WRKDIR},
1.87      wiz      3801:     for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
1.50      rillig   3802:     other examples.
                   3803:
                   3804:     The name of the working directory created by pkgsrc is taken from the
                   3805:     WRKDIR_BASENAME variable. By default, its value is work. If you want to use
                   3806:     the same pkgsrc tree for building different kinds of binary packages, you
                   3807:     can change the variable according to your needs. Two other variables handle
                   3808:     common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
1.105     rillig   3809:     defined in mk.conf, the first component of the host's name is attached to
                   3810:     the directory name. If OBJMACHINE is defined, the platform name is
1.50      rillig   3811:     attached, which might look like work.i386 or work.sparc.
1.1       grant    3812:
                   3813: Please pay attention to the following gotchas:
                   3814:
1.47      reed     3815:   * Add MANCOMPRESSED if man pages are installed in compressed form by the
1.88      wiz      3816:     package. For packages using BSD-style makefiles which honor MANZ, there is
                   3817:     MANCOMPRESSED_IF_MANZ.
1.20      ben      3818:
1.1       grant    3819:   * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
1.20      ben      3820:
1.107     rillig   3821:   * If the package installs any info files, see Section 19.6.7, "Packages
1.1       grant    3822:     installing info files".
1.20      ben      3823:
1.107     rillig   3824: 11.2. distinfo
1.1       grant    3825:
1.50      rillig   3826: The distinfo file contains the message digest, or checksum, of each distfile
                   3827: needed for the package. This ensures that the distfiles retrieved from the
                   3828: Internet have not been corrupted during transfer or altered by a malign force
                   3829: to introduce a security hole. Due to recent rumor about weaknesses of digest
                   3830: algorithms, all distfiles are protected using both SHA1 and RMD160 message
                   3831: digests, as well as the file size.
1.1       grant    3832:
1.50      rillig   3833: The distinfo file also contains the checksums for all the patches found in the
1.107     rillig   3834: patches directory (see Section 11.3, "patches/*").
1.50      rillig   3835:
                   3836: To regenerate the distinfo file, use the make makedistinfo or make mdi command.
                   3837:
                   3838: Some packages have different sets of distfiles depending on the platform, for
1.130     wiz      3839: example lang/openjdk7. These are kept in the same distinfo file and care should
                   3840: be taken when upgrading such a package to ensure distfile information is not
                   3841: lost.
1.1       grant    3842:
1.107     rillig   3843: 11.3. patches/*
1.1       grant    3844:
1.93      rillig   3845: Many packages still don't work out-of-the box on the various platforms that are
                   3846: supported by pkgsrc. Therefore, a number of custom patch files are needed to
                   3847: make the package work. These patch files are found in the patches/ directory.
                   3848:
                   3849: In the patch phase, these patches are applied to the files in WRKSRC directory
                   3850: after extracting them, in alphabetic order, so patch-aa is applied before
                   3851: patch-ab, etc.
                   3852:
1.107     rillig   3853: 11.3.1. Structure of a single patch file
1.1       grant    3854:
                   3855: The patch-* files should be in diff -bu format, and apply without a fuzz to
                   3856: avoid problems. (To force patches to apply with fuzz you can set
1.94      dmcmahil 3857: PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
1.93      rillig   3858: a single file, and no file should be patched by more than one patch file. This
                   3859: helps to keep future modifications simple.
                   3860:
                   3861: Each patch file is structured as follows: In the first line, there is the RCS
                   3862: Id of the patch itself. The second line should be empty for aesthetic reasons.
                   3863: After that, there should be a comment for each change that the patch does.
                   3864: There are a number of standard cases:
                   3865:
                   3866:   * Patches that replace the == operator for test(1) with = in shell scripts
1.112     rillig   3867:     are so common that they don't need a comment at all.
1.93      rillig   3868:
                   3869:   * Patches for commonly known vulnerabilities should mention the vulnerability
                   3870:     ID (CAN, CVE).
                   3871:
                   3872:   * Patches that change source code should mention the platform and other
                   3873:     environment (for example, the compiler) that the patch is needed for.
                   3874:
                   3875: In all other cases, the patch should be commented so that any developer who
                   3876: knows the code of the application can make some use of the patch. Special care
                   3877: should be taken for the upstream developers, since we generally want that they
                   3878: accept our patches, so we have less work in the future.
                   3879:
1.107     rillig   3880: 11.3.2. Creating patch files
1.1       grant    3881:
                   3882: One important thing to mention is to pay attention that no RCS IDs get stored
                   3883: in the patch files, as these will cause problems when later checked into the
1.93      rillig   3884: NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
                   3885: avoid these problems.
1.1       grant    3886:
                   3887: For even more automation, we recommend using mkpatches from the same package to
                   3888: make a whole set of patches. You just have to backup files before you edit them
1.20      ben      3889: to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using
1.1       grant    3890: pkgvi again from the same package. If you upgrade a package this way, you can
1.20      ben      3891: easily compare the new set of patches with the previously existing one with
1.87      wiz      3892: patchdiff. Copy the patches you want to use or update from the work/.newpatches
                   3893: directory to patches/.
1.1       grant    3894:
                   3895: When you have finished a package, remember to generate the checksums for the
1.107     rillig   3896: patch files by using the make makepatchsum command, see Section 11.2,
1.90      rillig   3897: "distinfo".
1.1       grant    3898:
1.87      wiz      3899: When adding a patch that corrects a problem in the distfile (rather than e.g.
                   3900: enforcing pkgsrc's view of where man pages should go), send the patch as a bug
                   3901: report to the maintainer. This benefits non-pkgsrc users of the package, and
                   3902: usually makes it possible to remove the patch in future version.
                   3903:
1.102     rillig   3904: The file names of the patch files are usually of the form patch-[a-z][a-z].
                   3905:
1.107     rillig   3906: 11.3.3. Sources where the patch files come from
1.93      rillig   3907:
1.87      wiz      3908: If you want to share patches between multiple packages in pkgsrc, e.g. because
                   3909: they use the same distfiles, set PATCHDIR to the path where the patch files can
                   3910: be found, e.g.:
                   3911:
1.101     rillig   3912: PATCHDIR= ${.CURDIR}/../xemacs/patches
1.87      wiz      3913:
1.1       grant    3914: Patch files that are distributed by the author or other maintainers can be
1.87      wiz      3915: listed in PATCHFILES.
1.1       grant    3916:
                   3917: If it is desired to store any patches that should not be committed into pkgsrc,
                   3918: they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
                   3919: directory tree there is expected to have the same "category/package" structure
                   3920: as pkgsrc, and patches are expected to be stored inside these dirs (also known
1.47      reed     3921: as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
                   3922: for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
                   3923: files in the named directory are expected to be patch files, and they are
                   3924: applied after pkgsrc patches are applied.
1.1       grant    3925:
1.107     rillig   3926: 11.3.4. Patching guidelines
1.85      jmmv     3927:
                   3928: When fixing a portability issue in the code do not use preprocessor magic to
                   3929: check for the current operating system nor platform. Doing so hurts portability
                   3930: to other platforms because the OS-specific details are not abstracted
                   3931: appropriately.
                   3932:
                   3933: The general rule to follow is: instead of checking for the operating system the
                   3934: application is being built on, check for the specific features you need. For
                   3935: example, instead of assuming that kqueue is available under NetBSD and using
                   3936: the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
                   3937: kqueue itself ? yes, this generally involves patching the configure script.
                   3938: There is absolutely nothing that prevents some OSes from adopting interfaces
                   3939: from other OSes (e.g. Linux implementing kqueue), something that the above
                   3940: checks cannot take into account.
                   3941:
                   3942: Of course, checking for features generally involves more work on the
1.87      wiz      3943: developer's side, but the resulting changes are cleaner and there are chances
1.85      jmmv     3944: they will work on many other platforms. Not to mention that there are higher
                   3945: chances of being later integrated into the mainstream sources. Remember: It
                   3946: doesn't work unless it is right!
                   3947:
                   3948: Some typical examples:
                   3949:
1.107     rillig   3950: Table 11.1. Patching examples
1.85      jmmv     3951:
1.101     rillig   3952: +-------------------------------------------------------------------------------------------+
                   3953: |  Where  |        Incorrect         |                       Correct                        |
                   3954: |---------+--------------------------+------------------------------------------------------|
                   3955: |         |case ${target_os} in      |                                                      |
                   3956: |configure|netbsd*) have_kvm=yes ;;  |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)|
                   3957: |script   |*)       have_kvm=no  ;;  |                                                      |
                   3958: |         |esac                      |                                                      |
                   3959: |---------+--------------------------+------------------------------------------------------|
1.102     rillig   3960: |C source |#if defined(__NetBSD__)   |#if defined(HAVE_SYS_EVENT_H)                         |
                   3961: |file     |#  include <sys/event.h>  |#  include <sys/event.h>                              |
                   3962: |         |#endif                    |#endif                                                |
1.101     rillig   3963: |---------+--------------------------+------------------------------------------------------|
                   3964: |         |int                       |int                                                   |
                   3965: |         |monitor_file(...)         |monitor_file(...)                                     |
                   3966: |         |{                         |{                                                     |
                   3967: |         |#if defined(__NetBSD__)   |#if defined(HAVE_KQUEUE)                              |
                   3968: |C source |        int fd = kqueue();|        int fd = kqueue();                            |
                   3969: |file     |        ...               |        ...                                           |
                   3970: |         |#else                     |#else                                                 |
                   3971: |         |        ...               |        ...                                           |
                   3972: |         |#endif                    |#endif                                                |
                   3973: |         |}                         |}                                                     |
                   3974: +-------------------------------------------------------------------------------------------+
1.85      jmmv     3975:
1.91      rillig   3976:
1.85      jmmv     3977: For more information, please read the Making packager-friendly software article
                   3978: (part 1, part 2). It summarizes multiple details on how to make software easier
                   3979: to package; all the suggestions in it were collected from our experience in
                   3980: pkgsrc work, so they are possibly helpful when creating patches too.
                   3981:
1.107     rillig   3982: 11.3.5. Feedback to the author
1.85      jmmv     3983:
                   3984: Always, always, always feed back any portability fixes or improvements you do
                   3985: to a package to the mainstream developers. This is the only way to get their
                   3986: attention on portability issues and to ensure that future versions can be built
                   3987: out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will
                   3988: get the fixes straight from the packaged code.
                   3989:
1.93      rillig   3990: This generally involves cleaning up the patches (because sometimes the patches
                   3991: that are added to pkgsrc are quick hacks), filling bug reports in the
                   3992: appropriate trackers for the projects and working with the mainstream authors
                   3993: to accept your changes. It is extremely important that you do it so that the
                   3994: packages in pkgsrc are kept simple and thus further changes can be done without
                   3995: much hassle.
1.85      jmmv     3996:
                   3997: Support the idea of free software!
                   3998:
1.107     rillig   3999: 11.4. Other mandatory files
1.1       grant    4000:
                   4001: DESCR
1.20      ben      4002:
1.1       grant    4003:     A multi-line description of the piece of software. This should include any
                   4004:     credits where they are due. Please bear in mind that others do not share
                   4005:     your sense of humour (or spelling idiosyncrasies), and that others will
                   4006:     read everything that you write here.
1.20      ben      4007:
1.1       grant    4008: PLIST
1.20      ben      4009:
1.1       grant    4010:     This file governs the files that are installed on your system: all the
                   4011:     binaries, manual pages, etc. There are other directives which may be
                   4012:     entered in this file, to control the creation and deletion of directories,
1.107     rillig   4013:     and the location of inserted files. See Chapter 13, PLIST issues for more
1.1       grant    4014:     information.
1.20      ben      4015:
1.107     rillig   4016: 11.5. Optional files
1.1       grant    4017:
1.107     rillig   4018: 11.5.1. Files affecting the binary package
1.78      rillig   4019:
1.1       grant    4020: INSTALL
1.20      ben      4021:
1.1       grant    4022:     This shell script is invoked twice by pkg_add(1). First time after package
                   4023:     extraction and before files are moved in place, the second time after the
                   4024:     files to install are moved in place. This can be used to do any custom
1.20      ben      4025:     procedures not possible with @exec commands in PLIST. See pkg_add(1) and
1.107     rillig   4026:     pkg_create(1) for more information. See also Section 15.1, "Files and
1.87      wiz      4027:     directories outside the installation prefix".
1.20      ben      4028:
1.1       grant    4029: DEINSTALL
1.20      ben      4030:
1.1       grant    4031:     This script is executed before and after any files are removed. It is this
                   4032:     script's responsibility to clean up any additional messy details around the
                   4033:     package's installation, since all pkg_delete knows is how to delete the
1.20      ben      4034:     files created in the original distribution. See pkg_delete(1) and
1.1       grant    4035:     pkg_create(1) for more information.
1.20      ben      4036:
1.1       grant    4037: MESSAGE
1.20      ben      4038:
1.50      rillig   4039:     This file is displayed after installation of the package. Useful for things
                   4040:     like legal notices on almost-free software and hints for updating config
                   4041:     files after installing modules for apache, PHP etc. Please note that you
                   4042:     can modify variables in it easily by using MESSAGE_SUBST in the package's
1.1       grant    4043:     Makefile:
1.20      ben      4044:
1.101     rillig   4045:     MESSAGE_SUBST+=  SOMEVAR="somevalue"
1.20      ben      4046:
1.87      wiz      4047:     replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
                   4048:     is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE,
1.118     jnemeth  4049:     PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.
1.87      wiz      4050:
                   4051:     You can display a different or additional files by setting the MESSAGE_SRC
                   4052:     variable. Its default is MESSAGE, if the file exists.
1.20      ben      4053:
1.78      rillig   4054: ALTERNATIVES
                   4055:
                   4056:     FIXME: There is no documentation on the alternatives framework.
                   4057:
1.107     rillig   4058: 11.5.2. Files affecting the build process
1.78      rillig   4059:
                   4060: Makefile.common
                   4061:
                   4062:     This file contains arbitrary things that could also go into a Makefile, but
                   4063:     its purpose is to be used by more than one package. This file should only
                   4064:     be used when the packages that will use the file are known in advance. For
                   4065:     other purposes it is often better to write a *.mk file and give it a good
                   4066:     name that describes what it does.
                   4067:
                   4068: buildlink3.mk
                   4069:
                   4070:     This file contains the dependency information for the buildlink3 framework
1.107     rillig   4071:     (see Chapter 14, Buildlink methodology).
1.78      rillig   4072:
                   4073: hacks.mk
                   4074:
                   4075:     This file contains workarounds for compiler bugs and similar things. It is
                   4076:     included automatically by the pkgsrc infrastructure, so you don't need an
                   4077:     extra .include line for it.
                   4078:
                   4079: options.mk
                   4080:
                   4081:     This file contains the code for the package-specific options (see
1.107     rillig   4082:     Chapter 16, Options handling) that can be selected by the user. If a
1.78      rillig   4083:     package has only one or two options, it is equally acceptable to put the
                   4084:     code directly into the Makefile.
                   4085:
1.107     rillig   4086: 11.5.3. Files affecting nothing at all
1.78      rillig   4087:
                   4088: README*
                   4089:
                   4090:     These files do not take place in the creation of a package and thus are
                   4091:     purely informative to the package developer.
                   4092:
                   4093: TODO
                   4094:
                   4095:     This file contains things that need to be done to make the package even
                   4096:     better.
                   4097:
1.107     rillig   4098: 11.6. work*
1.1       grant    4099:
1.47      reed     4100: When you type make, the distribution files are unpacked into the directory
1.45      wiz      4101: denoted by WRKDIR. It can be removed by running make clean. Besides the
                   4102: sources, this directory is also used to keep various timestamp files. The
                   4103: directory gets removed completely on clean. The default is ${.CURDIR}/work or $
                   4104: {.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
1.1       grant    4105:
1.107     rillig   4106: 11.7. files/*
1.1       grant    4107:
                   4108: If you have any files that you wish to be placed in the package prior to
1.87      wiz      4109: configuration or building, you could place these files here and use a ${CP}
1.1       grant    4110: command in the "pre-configure" target to achieve this. Alternatively, you could
                   4111: simply diff the file against /dev/null and use the patch mechanism to manage
                   4112: the creation of this file.
                   4113:
1.87      wiz      4114: If you want to share files in this way with other packages, set the FILESDIR
                   4115: variable to point to the other package's files directory, e.g.:
                   4116:
1.101     rillig   4117: FILESDIR=${.CURDIR}/../xemacs/files
1.87      wiz      4118:
1.107     rillig   4119: Chapter 12. Programming in Makefiles
1.27      rillig   4120:
                   4121: Table of Contents
                   4122:
1.107     rillig   4123: 12.1. Caveats
                   4124: 12.2. Makefile variables
1.27      rillig   4125:
1.107     rillig   4126:     12.2.1. Naming conventions
1.27      rillig   4127:
1.107     rillig   4128: 12.3. Code snippets
1.27      rillig   4129:
1.107     rillig   4130:     12.3.1. Adding things to a list
                   4131:     12.3.2. Converting an internal list into an external list
                   4132:     12.3.3. Passing variables to a shell command
                   4133:     12.3.4. Quoting guideline
                   4134:     12.3.5. Workaround for a bug in BSD Make
1.27      rillig   4135:
                   4136: Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
                   4137: part of the pkgsrc system. Using the make(1) system as a programming language
                   4138: for a big system like pkgsrc requires some discipline to keep the code correct
                   4139: and understandable.
                   4140:
                   4141: The basic ingredients for Makefile programming are variables (which are
                   4142: actually macros) and shell commands. Among these shell commands may even be
                   4143: more complex ones like awk(1) programs. To make sure that every shell command
                   4144: runs as intended it is necessary to quote all variables correctly when they are
                   4145: used.
                   4146:
                   4147: This chapter describes some patterns, that appear quite often in Makefiles,
                   4148: including the pitfalls that come along with them.
                   4149:
1.107     rillig   4150: 12.1. Caveats
1.98      rillig   4151:
                   4152:   * When you are creating a file as a target of a rule, always write the data
                   4153:     to a temporary file first and finally rename that file. Otherwise there
                   4154:     might occur an error in the middle of generating the file, and when the
                   4155:     user runs make(1) for the second time, the file exists and will not be
                   4156:     regenerated properly. Example:
                   4157:
1.101     rillig   4158:     wrong:
                   4159:             @echo "line 1" > ${.TARGET}
                   4160:             @echo "line 2" >> ${.TARGET}
                   4161:             @false
                   4162:
                   4163:     correct:
                   4164:             @echo "line 1" > ${.TARGET}.tmp
                   4165:             @echo "line 2" >> ${.TARGET}.tmp
                   4166:             @false
                   4167:             @mv ${.TARGET}.tmp ${.TARGET}
1.98      rillig   4168:
                   4169:     When you run make wrong twice, the file wrong will exist, although there
                   4170:     was an error message in the first run. On the other hand, running make
                   4171:     correct gives an error message twice, as expected.
                   4172:
                   4173:     You might remember that make(1) sometimes removes ${.TARGET} in case of
                   4174:     error, but this only happens when it is interrupted, for example by
                   4175:     pressing ^C. This does not happen when one of the commands fails (like
                   4176:     false(1) above).
                   4177:
1.107     rillig   4178: 12.2. Makefile variables
1.27      rillig   4179:
                   4180: Makefile variables contain strings that can be processed using the five
                   4181: operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
                   4182: make(1) man page.
                   4183:
                   4184: When a variable's value is parsed from a Makefile, the hash character ``#'' and
                   4185: the backslash character ``\'' are handled specially. If a backslash is followed
                   4186: by a newline, any whitespace immediately in front of the backslash, the
                   4187: backslash, the newline, and any whitespace immediately behind the newline are
1.74      rillig   4188: replaced with a single space. A backslash character and an immediately
1.47      reed     4189: following hash character are replaced with a single hash character. Otherwise,
1.27      rillig   4190: the backslash is passed as is. In a variable assignment, any hash character
                   4191: that is not preceded by a backslash starts a comment that continues upto the
                   4192: end of the logical line.
                   4193:
                   4194: Note: Because of this parsing algorithm the only way to create a variable
                   4195: consisting of a single backslash is using the ``!='' operator, for example:
                   4196: BACKSLASH!=echo "\\".
                   4197:
                   4198: So far for defining variables. The other thing you can do with variables is
                   4199: evaluating them. A variable is evaluated when it is part of the right side of
                   4200: the ``:='' or the ``!='' operator, or directly before executing a shell command
1.47      reed     4201: which the variable is part of. In all other cases, make(1) performs lazy
1.27      rillig   4202: evaluation, that is, variables are not evaluated until there's no other way.
                   4203: The ``modifiers'' mentioned in the man page also evaluate the variable.
                   4204:
                   4205: Some of the modifiers split the string into words and then operate on the
1.47      reed     4206: words, others operate on the string as a whole. When a string is split into
                   4207: words, it is split as you would expect it from sh(1).
1.27      rillig   4208:
                   4209: No rule without exception?the .for loop does not follow the shell quoting rules
                   4210: but splits at sequences of whitespace.
                   4211:
                   4212: There are several types of variables that should be handled differently.
                   4213: Strings and two types of lists.
                   4214:
1.47      reed     4215:   * Strings can contain arbitrary characters. Nevertheless, you should restrict
1.27      rillig   4216:     yourself to only using printable characters. Examples are PREFIX and
                   4217:     COMMENT.
                   4218:
                   4219:   * Internal lists are lists that are never exported to any shell command.
1.47      reed     4220:     Their elements are separated by whitespace. Therefore, the elements
1.27      rillig   4221:     themselves cannot have embedded whitespace. Any other characters are
                   4222:     allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
                   4223:     BUILD_DEPENDS.
                   4224:
                   4225:   * External lists are lists that may be exported to a shell command. Their
                   4226:     elements can contain any characters, including whitespace. That's why they
                   4227:     cannot be used in .for loops. Examples are DISTFILES and MASTER_SITES.
                   4228:
1.107     rillig   4229: 12.2.1. Naming conventions
1.27      rillig   4230:
                   4231:   * All variable names starting with an underscore are reserved for use by the
                   4232:     pkgsrc infrastructure. They shall not be used by package Makefiles.
                   4233:
                   4234:   * In .for loops you should use lowercase variable names for the iteration
                   4235:     variables.
                   4236:
                   4237:   * All list variables should have a ``plural'' name, e.g. PKG_OPTIONS or
                   4238:     DISTFILES.
                   4239:
1.107     rillig   4240: 12.3. Code snippets
1.27      rillig   4241:
                   4242: This section presents you with some code snippets you should use in your own
                   4243: code. If you don't find anything appropriate here, you should test your code
                   4244: and add it here.
                   4245:
1.107     rillig   4246: 12.3.1. Adding things to a list
1.27      rillig   4247:
1.101     rillig   4248: STRING=                 foo * bar `date`
                   4249: INT_LIST=               # empty
                   4250: ANOTHER_INT_LIST=       apache-[0-9]*:../../www/apache
                   4251: EXT_LIST=               # empty
                   4252: ANOTHER_EXT_LIST=       a=b c=d
                   4253:
                   4254: INT_LIST+=              ${STRING}               # 1
                   4255: INT_LIST+=              ${ANOTHER_INT_LIST}     # 2
                   4256: EXT_LIST+=              ${STRING:Q}             # 3
                   4257: EXT_LIST+=              ${ANOTHER_EXT_LIST}     # 4
1.27      rillig   4258:
                   4259: When you add a string to an external list (example 3), it must be quoted. In
                   4260: all other cases, you must not add a quoting level. You must not merge internal
                   4261: and external lists, unless you are sure that all entries are correctly
                   4262: interpreted in both lists.
                   4263:
1.107     rillig   4264: 12.3.2. Converting an internal list into an external list
1.27      rillig   4265:
1.101     rillig   4266: EXT_LIST=       # empty
                   4267: .for i in ${INT_LIST}
                   4268: EXT_LIST+=      ${i:Q}""
                   4269: .endfor
1.27      rillig   4270:
                   4271: This code converts the internal list INT_LIST into the external list EXT_LIST.
                   4272: As the elements of an internal list are unquoted they must be quoted here. The
                   4273: reason for appending "" is explained below.
                   4274:
1.107     rillig   4275: 12.3.3. Passing variables to a shell command
1.27      rillig   4276:
1.79      rillig   4277: Sometimes you may want to print an arbitrary string. There are many ways to get
                   4278: it wrong and only few that can handle every nastiness.
                   4279:
1.101     rillig   4280: STRING=         foo bar <    > * `date` $$HOME ' "
                   4281: EXT_LIST=       string=${STRING:Q} x=second\ item
1.27      rillig   4282:
1.101     rillig   4283: all:
                   4284:         echo ${STRING}                  # 1
                   4285:         echo "${STRING}"                # 2
                   4286:         echo "${STRING:Q}"              # 3
                   4287:         echo ${STRING:Q}                # 4
                   4288:         echo x${STRING:Q} | sed 1s,.,,  # 5
                   4289:         printf "%s\\n" ${STRING:Q}""    # 6
                   4290:         env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
1.27      rillig   4291:
                   4292: Example 1 leads to a syntax error in the shell, as the characters are just
                   4293: copied.
                   4294:
                   4295: Example 2 leads to a syntax error too, and if you leave out the last "
                   4296: character from ${STRING}, date(1) will be executed. The $HOME shell variable
                   4297: would be evaluated, too.
                   4298:
                   4299: Example 3 outputs each space character preceded by a backslash (or not),
                   4300: depending on the implementation of the echo(1) command.
                   4301:
                   4302: Example 4 handles correctly every string that does not start with a dash. In
                   4303: that case, the result depends on the implementation of the echo(1) command. As
1.47      reed     4304: long as you can guarantee that your input does not start with a dash, this form
1.27      rillig   4305: is appropriate.
                   4306:
                   4307: Example 5 handles even the case of a leading dash correctly.
                   4308:
1.79      rillig   4309: Example 6 also works with every string and is the light-weight solution, since
                   4310: it does not involve a pipe, which has its own problems.
                   4311:
1.47      reed     4312: The EXT_LIST does not need to be quoted because the quoting has already been
                   4313: done when adding elements to the list.
1.27      rillig   4314:
                   4315: As internal lists shall not be passed to the shell, there is no example for it.
                   4316:
1.107     rillig   4317: 12.3.4. Quoting guideline
1.27      rillig   4318:
                   4319: There are many possible sources of wrongly quoted variables. This section lists
                   4320: some of the commonly known ones.
                   4321:
                   4322:   * Whenever you use the value of a list, think about what happens to leading
1.47      reed     4323:     or trailing whitespace. If the list is a well-formed shell expression, you
1.27      rillig   4324:     can apply the :M* modifier to strip leading and trailing whitespace from
                   4325:     each word. The :M operator first splits its argument according to the rules
                   4326:     of the shell, and then creates a new list consisting of all words that
                   4327:     match the shell glob expression *, that is: all. One class of situations
                   4328:     where this is needed is when adding a variable like CPPFLAGS to
1.47      reed     4329:     CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
1.27      rillig   4330:     strips the leading and trailing whitespace from the variable and then
                   4331:     passes it to the other configure scripts. But these configure scripts
                   4332:     expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
                   4333:     That's why we better pass the CPPFLAGS value properly trimmed. And here is
                   4334:     how we do it:
                   4335:
1.101     rillig   4336:     CPPFLAGS=               # empty
                   4337:     CPPFLAGS+=              -Wundef -DPREFIX=\"${PREFIX:Q}\"
                   4338:     CPPFLAGS+=              ${MY_CPPFLAGS}
                   4339:
                   4340:     CONFIGURE_ARGS+=        CPPFLAGS=${CPPFLAGS:M*:Q}
                   4341:
                   4342:     all:
                   4343:             echo x${CPPFLAGS:Q}x            # leading and trailing whitespace
                   4344:             echo x${CONFIGURE_ARGS}x        # properly trimmed
1.27      rillig   4345:
                   4346:   * The example above contains one bug: The ${PREFIX} is a properly quoted
                   4347:     shell expression, but there is the C compiler after it, which also expects
                   4348:     a properly quoted string (this time in C syntax). The version above is
                   4349:     therefore only correct if ${PREFIX} does not have embedded backslashes or
                   4350:     double quotes. If you want to allow these, you have to add another layer of
                   4351:     quoting to each variable that is used as a C string literal. You cannot use
                   4352:     the :Q operator for it, as this operator only works for the shell.
                   4353:
1.47      reed     4354:   * Whenever a variable can be empty, the :Q operator can have surprising
1.27      rillig   4355:     results. Here are two completely different cases which can be solved with
                   4356:     the same trick.
                   4357:
1.101     rillig   4358:     EMPTY=                  # empty
                   4359:     empty_test:
                   4360:             for i in a ${EMPTY:Q} c; do \
                   4361:                 echo "$$i"; \
                   4362:             done
                   4363:
                   4364:     for_test:
                   4365:     .for i in a:\ a:\test.txt
                   4366:             echo ${i:Q}
                   4367:             echo "foo"
                   4368:     .endfor
1.27      rillig   4369:
                   4370:     The first example will only print two of the three lines we might have
                   4371:     expected. This is because ${EMPTY:Q} expands to the empty string, which the
                   4372:     shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
                   4373:     be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
                   4374:     these are wrong).
                   4375:
                   4376:     The second example will only print three lines instead of four. The first
                   4377:     line looks like a:\ echo foo. This is because the backslash of the value a:
                   4378:     \ is interpreted as a line-continuation by make(1), which makes the second
                   4379:     line the arguments of the echo(1) command from the first line. To avoid
                   4380:     this, write ${i:Q}"".
                   4381:
1.107     rillig   4382: 12.3.5. Workaround for a bug in BSD Make
1.27      rillig   4383:
                   4384: The pkgsrc bmake program does not handle the following assignment correctly. In
                   4385: case _othervar_ contains a ``-'' character, one of the closing braces is
                   4386: included in ${VAR} after this code executes.
                   4387:
1.101     rillig   4388: VAR:=   ${VAR:N${_othervar_:C/-//}}
1.27      rillig   4389:
                   4390: For a more complex code snippet and a workaround, see the package regress/
                   4391: make-quoting, testcase bug1.
                   4392:
1.107     rillig   4393: Chapter 13. PLIST issues
1.1       grant    4394:
                   4395: Table of Contents
                   4396:
1.107     rillig   4397: 13.1. RCS ID
                   4398: 13.2. Semi-automatic PLIST generation
                   4399: 13.3. Tweaking output of make print-PLIST
                   4400: 13.4. Variable substitution in PLIST
                   4401: 13.5. Man page compression
                   4402: 13.6. Changing PLIST source with PLIST_SRC
                   4403: 13.7. Platform-specific and differing PLISTs
                   4404: 13.8. Sharing directories between packages
1.1       grant    4405:
                   4406: The PLIST file contains a package's "packing list", i.e. a list of files that
                   4407: belong to the package (relative to the ${PREFIX} directory it's been installed
1.47      reed     4408: in) plus some additional statements - see the pkg_create(1) man page for a full
1.1       grant    4409: list. This chapter addresses some issues that need attention when dealing with
                   4410: the PLIST file (or files, see below!).
                   4411:
1.107     rillig   4412: 13.1. RCS ID
1.1       grant    4413:
                   4414: Be sure to add a RCS ID line as the first thing in any PLIST file you write:
                   4415:
1.101     rillig   4416: @comment $NetBSD$
1.87      wiz      4417:
1.1       grant    4418:
1.107     rillig   4419: 13.2. Semi-automatic PLIST generation
1.1       grant    4420:
                   4421: You can use the make print-PLIST command to output a PLIST that matches any new
1.107     rillig   4422: files since the package was extracted. See Section 17.17, "Other helpful
1.1       grant    4423: targets" for more information on this target.
                   4424:
1.107     rillig   4425: 13.3. Tweaking output of make print-PLIST
1.1       grant    4426:
1.107     rillig   4427: If you have used any of the *-dirs packages, as explained in Section 13.8,
1.1       grant    4428: "Sharing directories between packages", you may have noticed that make
                   4429: print-PLIST outputs a set of @comments instead of real @dirrm lines. You can
                   4430: also do this for specific directories and files, so that the results of that
                   4431: command are very close to reality. This helps a lot during the update of
                   4432: packages.
                   4433:
                   4434: The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
                   4435: used to filter the output of print-PLIST. You can append any chunk of AWK
                   4436: scripting you like to it, but be careful with quoting.
                   4437:
                   4438: For example, to get all files inside the libdata/foo directory removed from the
                   4439: resulting PLIST:
                   4440:
1.101     rillig   4441: PRINT_PLIST_AWK+=       /^libdata\/foo/ { next; }
1.87      wiz      4442:
1.1       grant    4443:
                   4444: And to get all the @dirrm lines referring to a specific (shared) directory
                   4445: converted to @comments:
                   4446:
1.101     rillig   4447: PRINT_PLIST_AWK+=       /^@dirrm share\/specific/ { print "@comment " $$0; next; }
1.87      wiz      4448:
1.1       grant    4449:
1.107     rillig   4450: 13.4. Variable substitution in PLIST
1.1       grant    4451:
                   4452: A number of variables are substituted automatically in PLISTs when a package is
                   4453: installed on a system. This includes the following variables:
                   4454:
                   4455: ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
1.20      ben      4456:
1.1       grant    4457:     Some packages like emacs and perl embed information about which
                   4458:     architecture they were built on into the pathnames where they install their
1.47      reed     4459:     files. To handle this case, PLIST will be preprocessed before actually
                   4460:     used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
                   4461:     gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
                   4462:     PLIST somewhere - use this on packages that have GNU autoconf-created
                   4463:     configure scripts.
1.20      ben      4464:
1.1       grant    4465:     Legacy note
1.20      ben      4466:
1.1       grant    4467:     There used to be a symbol "$ARCH" that was replaced by the output of uname
                   4468:     -m, but that's no longer supported and has been removed.
1.20      ben      4469:
1.1       grant    4470: ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
1.20      ben      4471:
1.1       grant    4472:     Some packages want to embed the OS name and version into some paths. To do
                   4473:     this, use these variables in the PLIST:
1.20      ben      4474:
1.1       grant    4475:       * ${OPSYS} - output of "uname -s"
1.20      ben      4476:
1.1       grant    4477:       * ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
1.20      ben      4478:
1.1       grant    4479:       * ${OS_VERSION} - "uname -r"
1.20      ben      4480:
1.1       grant    4481: For a complete list of values which are replaced by default, please look in
                   4482: bsd.pkg.mk (and search for PLIST_SUBST).
                   4483:
                   4484: If you want to change other variables not listed above, you can add variables
                   4485: and their expansions to this variable in the following way, similar to
1.107     rillig   4486: MESSAGE_SUBST (see Section 11.5, "Optional files"):
1.1       grant    4487:
1.101     rillig   4488: PLIST_SUBST+=   SOMEVAR="somevalue"
1.87      wiz      4489:
1.1       grant    4490:
                   4491: This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".
                   4492:
1.121     snj      4493: The PLIST_VARS variable can be used to simplify the common case of
                   4494: conditionally including some PLIST entries. It can be done by adding
                   4495: PLIST_VARS+=foo and setting the corresponding PLIST.foo variable to yes if the
                   4496: entry should be included. This will substitute "${PLIST.foo}" in the PLIST with
                   4497: either """" or ""@comment "". For example, in Makefile:
1.120     mishka   4498:
                   4499: PLIST_VARS+=    foo
                   4500: .if condition
                   4501: PLIST.foo=      yes
                   4502: .else
                   4503:
                   4504:
                   4505: And then in PLIST:
                   4506:
                   4507: @comment $NetBSD$
                   4508: bin/bar
                   4509: man/man1/bar.1
                   4510: ${PLIST.foo}bin/foo
                   4511: ${PLIST.foo}man/man1/foo.1
                   4512: ${PLIST.foo}share/bar/foo.data
                   4513: ${PLIST.foo}@dirrm share/bar
                   4514:
                   4515:
1.107     rillig   4516: 13.5. Man page compression
1.1       grant    4517:
1.47      reed     4518: Man pages should be installed in compressed form if MANZ is set (in
                   4519: bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
                   4520: suffix ".gz" is appended/removed automatically for man pages according to MANZ
                   4521: and MANCOMPRESSED being set or not, see above for details. This modification of
                   4522: the PLIST file is done on a copy of it, not PLIST itself.
1.1       grant    4523:
1.107     rillig   4524: 13.6. Changing PLIST source with PLIST_SRC
1.1       grant    4525:
                   4526: To use one or more files as source for the PLIST used in generating the binary
                   4527: package, set the variable PLIST_SRC to the names of that file(s). The files are
1.87      wiz      4528: later concatenated using cat(1), and the order of things is important. The
                   4529: default for PLIST_SRC is ${PKGDIR}/PLIST.
1.1       grant    4530:
1.107     rillig   4531: 13.7. Platform-specific and differing PLISTs
1.1       grant    4532:
                   4533: Some packages decide to install a different set of files based on the operating
                   4534: system being used. These differences can be automatically handled by using the
                   4535: following files:
                   4536:
                   4537:   * PLIST.common
1.20      ben      4538:
1.1       grant    4539:   * PLIST.${OPSYS}
1.20      ben      4540:
1.21      ben      4541:   * PLIST.${MACHINE_ARCH}
                   4542:
                   4543:   * PLIST.${OPSYS}-${MACHINE_ARCH}
                   4544:
1.1       grant    4545:   * PLIST.common_end
                   4546:
1.107     rillig   4547: 13.8. Sharing directories between packages
1.1       grant    4548:
                   4549: A "shared directory" is a directory where multiple (and unrelated) packages
1.126     wiz      4550: install files. These directories were problematic because you had to add
1.1       grant    4551: special tricks in the PLIST to conditionally remove them, or have some
                   4552: centralized package handle them.
                   4553:
1.126     wiz      4554: In pkgsrc, it is now easy: Each package should create directories and install
                   4555: files as needed; pkg_delete will remove any directories left empty after
                   4556: uninstalling a package.
1.20      ben      4557:
1.126     wiz      4558: If a package needs an empty directory to work, create the directory during
                   4559: installation as usual, and also add an entry to the PLIST:
1.20      ben      4560:
1.126     wiz      4561: @pkgdir path/to/empty/directory
1.1       grant    4562:
                   4563:
1.107     rillig   4564: Chapter 14. Buildlink methodology
1.1       grant    4565:
                   4566: Table of Contents
                   4567:
1.107     rillig   4568: 14.1. Converting packages to use buildlink3
                   4569: 14.2. Writing buildlink3.mk files
1.20      ben      4570:
1.107     rillig   4571:     14.2.1. Anatomy of a buildlink3.mk file
                   4572:     14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
1.20      ben      4573:
1.107     rillig   4574: 14.3. Writing builtin.mk files
1.20      ben      4575:
1.107     rillig   4576:     14.3.1. Anatomy of a builtin.mk file
                   4577:     14.3.2. Global preferences for native or pkgsrc software
1.20      ben      4578:
1.1       grant    4579: Buildlink is a framework in pkgsrc that controls what headers and libraries are
                   4580: seen by a package's configure and build processes. This is implemented in a two
                   4581: step process:
                   4582:
                   4583:  1. Symlink headers and libraries for dependencies into BUILDLINK_DIR, which by
                   4584:     default is a subdirectory of WRKDIR.
1.20      ben      4585:
1.1       grant    4586:  2. Create wrapper scripts that are used in place of the normal compiler tools
                   4587:     that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib into
                   4588:     references to BUILDLINK_DIR. The wrapper scripts also make native compiler
                   4589:     on some operating systems look like GCC, so that packages that expect GCC
                   4590:     won't require modifications to build with those native compilers.
1.20      ben      4591:
1.1       grant    4592: This normalizes the environment in which a package is built so that the package
                   4593: may be built consistently despite what other software may be installed. Please
                   4594: note that the normal system header and library paths, e.g. /usr/include, /usr/
                   4595: lib, etc., are always searched -- buildlink3 is designed to insulate the
                   4596: package build from non-system-supplied software.
                   4597:
1.107     rillig   4598: 14.1. Converting packages to use buildlink3
1.1       grant    4599:
                   4600: The process of converting packages to use the buildlink3 framework
                   4601: ("bl3ifying") is fairly straightforward. The things to keep in mind are:
                   4602:
1.22      tv       4603:  1. Ensure that the build always calls the wrapper scripts instead of the
1.1       grant    4604:     actual toolchain. Some packages are tricky, and the only way to know for
                   4605:     sure is the check ${WRKDIR}/.work.log to see if the wrappers are being
                   4606:     invoked.
1.20      ben      4607:
1.22      tv       4608:  2. Don't override PREFIX from within the package Makefile, e.g. Java VMs,
1.1       grant    4609:     standalone shells, etc., because the code to symlink files into $
                   4610:     {BUILDLINK_DIR} looks for files relative to "pkg_info -qp pkgname".
1.20      ben      4611:
1.22      tv       4612:  3. Remember that only the buildlink3.mk files that you list in a package's
1.1       grant    4613:     Makefile are added as dependencies for that package.
1.20      ben      4614:
1.1       grant    4615: If a dependency on a particular package is required for its libraries and
                   4616: headers, then we replace:
                   4617:
1.101     rillig   4618: DEPENDS+=       foo>=1.1.0:../../category/foo
1.1       grant    4619:
                   4620: with
                   4621:
1.101     rillig   4622: .include "../../category/foo/buildlink3.mk"
1.1       grant    4623:
1.47      reed     4624: The buildlink3.mk files usually define the required dependencies. If you need a
                   4625: newer version of the dependency when using buildlink3.mk files, then you can
                   4626: define it in your Makefile; for example:
                   4627:
1.101     rillig   4628: BUILDLINK_API_DEPENDS.foo+=   foo>=1.1.0
                   4629: .include "../../category/foo/buildlink3.mk"
1.47      reed     4630:
1.1       grant    4631: There are several buildlink3.mk files in pkgsrc/mk that handle special package
                   4632: issues:
                   4633:
                   4634:   * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
                   4635:     implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.
1.20      ben      4636:
1.47      reed     4637:   * curses.buildlink3.mk: If the system comes with neither Curses nor NCurses,
1.1       grant    4638:     this will take care to install the devel/ncurses package.
1.20      ben      4639:
1.1       grant    4640:   * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding
                   4641:     a dependency on Heimdal or MIT-krb5 for packages that require a Kerberos 5
                   4642:     implementation.
1.20      ben      4643:
1.1       grant    4644:   * motif.buildlink3.mk checks for a system-provided Motif installation or adds
1.88      wiz      4645:     a dependency on x11/lesstif or x11/openmotif. The user can set MOTIF_TYPE
                   4646:     to "dt", "lesstif", or "openmotif" to choose which Motif version will be
                   4647:     used.
1.20      ben      4648:
1.71      wiz      4649:   * oss.buildlink3.mk defines several variables that may be used by packages
                   4650:     that use the Open Sound System (OSS) API.
1.20      ben      4651:
1.93      rillig   4652:   * pgsql.buildlink3.mk will accept either Postgres 8.0, 8.1, or 8.2, whichever
1.91      rillig   4653:     is found installed. See the file for more information.
1.20      ben      4654:
1.1       grant    4655:   * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native
1.47      reed     4656:     pthreads or adds a dependency on devel/pth as needed.
1.20      ben      4657:
1.1       grant    4658:   * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena
                   4659:     widgets library.
1.20      ben      4660:
1.1       grant    4661: The comments in those buildlink3.mk files provide a more complete description
                   4662: of how to use them properly.
                   4663:
1.107     rillig   4664: 14.2. Writing buildlink3.mk files
1.1       grant    4665:
                   4666: A package's buildlink3.mk file is included by Makefiles to indicate the need to
                   4667: compile and link against header files and libraries provided by the package. A
                   4668: buildlink3.mk file should always provide enough information to add the correct
                   4669: type of dependency relationship and include any other buildlink3.mk files that
                   4670: it needs to find headers and libraries that it needs in turn.
                   4671:
1.20      ben      4672: To generate an initial buildlink3.mk file for further editing, Rene Hexel's
1.1       grant    4673: pkgtools/createbuildlink package is highly recommended. For most packages, the
                   4674: following command will generate a good starting point for buildlink3.mk files:
                   4675:
                   4676: % cd pkgsrc/category/pkgdir
1.49      rillig   4677: % createbuildlink >buildlink3.mk
1.1       grant    4678:
1.87      wiz      4679:
1.107     rillig   4680: 14.2.1. Anatomy of a buildlink3.mk file
1.1       grant    4681:
                   4682: The following real-life example buildlink3.mk is taken from pkgsrc/graphics/
                   4683: tiff:
                   4684:
1.121     snj      4685: # $NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp $
1.1       grant    4686:
1.121     snj      4687: BUILDLINK_TREE+=        tiff
1.1       grant    4688:
1.121     snj      4689: .if !defined(TIFF_BUILDLINK3_MK)
                   4690: TIFF_BUILDLINK3_MK:=
1.1       grant    4691:
1.121     snj      4692: BUILDLINK_API_DEPENDS.tiff+=    tiff>=3.6.1
                   4693: BUILDLINK_ABI_DEPENDS.tiff+=    tiff>=3.7.2nb1
1.101     rillig   4694: BUILDLINK_PKGSRCDIR.tiff?=      ../../graphics/tiff
1.1       grant    4695:
1.101     rillig   4696: .include "../../devel/zlib/buildlink3.mk"
                   4697: .include "../../graphics/jpeg/buildlink3.mk"
1.121     snj      4698: .endif # TIFF_BUILDLINK3_MK
1.1       grant    4699:
1.121     snj      4700: BUILDLINK_TREE+=        -tiff
1.1       grant    4701:
1.121     snj      4702: The header and footer manipulate BUILDLINK_TREE, which is common across all
                   4703: buildlink3.mk files and is used to track the dependency tree.
1.1       grant    4704:
1.121     snj      4705: The main section is protected from multiple inclusion and controls how the
1.1       grant    4706: dependency on pkg is added. Several important variables are set in the section:
                   4707:
1.72      rillig   4708:   * BUILDLINK_API_DEPENDS.pkg is the actual dependency recorded in the
                   4709:     installed package; this should always be set using += to ensure that we're
                   4710:     appending to any pre-existing list of values. This variable should be set
                   4711:     to the first version of the package that had an API change.
1.20      ben      4712:
1.47      reed     4713:   * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory.
1.20      ben      4714:
1.1       grant    4715:   * BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
                   4716:     BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
                   4717:     is selected by setting BUILDLINK_DEPMETHOD.pkg to "build". By default, the
                   4718:     full dependency is used.
1.20      ben      4719:
1.67      hubertf  4720:   * BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS.pkg (not shown above) are lists
                   4721:     of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and
1.1       grant    4722:     library search paths. These default to "include" and "lib" respectively.
1.20      ben      4723:
1.1       grant    4724:   * BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags
                   4725:     to add to CPPFLAGS, which are passed on to the configure and build phases.
                   4726:     The "-I" option should be avoided and instead be handled using
                   4727:     BUILDLINK_INCDIRS.pkg as above.
1.20      ben      4728:
1.1       grant    4729: The following variables are all optionally defined within this second section
                   4730: (protected against multiple inclusion) and control which package files are
                   4731: symlinked into ${BUILDLINK_DIR} and how their names are transformed during the
                   4732: symlinking:
                   4733:
                   4734:   * BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to $
                   4735:     {BUILDLINK_PREFIX.pkg} to be symlinked into ${BUILDLINK_DIR}, e.g. include/
                   4736:     *.h.
1.20      ben      4737:
1.1       grant    4738:   * BUILDLINK_FILES_CMD.pkg (not shown above) is a shell pipeline that outputs
                   4739:     to stdout a list of files relative to ${BUILDLINK_PREFIX.pkg}. The
                   4740:     resulting files are to be symlinked into ${BUILDLINK_DIR}. By default, this
                   4741:     takes the +CONTENTS of a pkg and filters it through $
                   4742:     {BUILDLINK_CONTENTS_FILTER.pkg}.
1.20      ben      4743:
1.1       grant    4744:   * BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that
                   4745:     filters +CONTENTS input into a list of files relative to $
                   4746:     {BUILDLINK_PREFIX.pkg} on stdout. By default for overwrite packages,
                   4747:     BUILDLINK_CONTENTS_FILTER.pkg outputs the contents of the include and lib
                   4748:     directories in the package +CONTENTS, and for pkgviews packages, it outputs
                   4749:     any libtool archives in lib directories.
1.20      ben      4750:
1.95      tron     4751:   * BUILDLINK_FNAME_TRANSFORM.pkg (not shown above) is a list of sed arguments
                   4752:     used to transform the name of the source filename into a destination
                   4753:     filename, e.g. -e "s|/curses.h|/ncurses.h|g".
1.20      ben      4754:
1.121     snj      4755: This section can additionally include any buildlink3.mk needed for pkg's
                   4756: library dependencies. Including these buildlink3.mk files means that the
                   4757: headers and libraries for these dependencies are also symlinked into $
                   4758: {BUILDLINK_DIR} whenever the pkg buildlink3.mk file is included. Dependencies
                   4759: are only added for directly include buildlink3.mk files.
1.1       grant    4760:
1.107     rillig   4761: 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
1.20      ben      4762:
1.72      rillig   4763: The situation that requires increasing the dependency listed in
                   4764: BUILDLINK_API_DEPENDS.pkg after a package update is when the API or interface
                   4765: to the header files change.
1.20      ben      4766:
1.72      rillig   4767: In this case, BUILDLINK_API_DEPENDS.pkg should be adjusted to require at least
1.1       grant    4768: the new package version. In some cases, the packages that depend on this new
                   4769: version may need their PKGREVISIONs increased and, if they have buildlink3.mk
1.72      rillig   4770: files, their BUILDLINK_API_DEPENDS.pkg adjusted, too. This is needed so pkgsrc
                   4771: will require the correct package dependency and not settle for an older one
                   4772: when building the source.
                   4773:
                   4774: BUILDLINK_ABI_DEPENDS.pkg should be increased when the binary interface or
                   4775: sonames (major number of the library version) of any installed shared libraries
                   4776: change. This is needed so that binary packages made using it will require the
                   4777: correct package dependency and not settle for an older one which will not
                   4778: contain the necessary shared libraries.
                   4779:
1.107     rillig   4780: See Section 19.1.6, "Handling dependencies" for more information about
1.72      rillig   4781: dependencies on other packages, including the BUILDLINK_ABI_DEPENDS and
                   4782: ABI_DEPENDS definitions.
                   4783:
                   4784: Please take careful consideration before adjusting BUILDLINK_API_DEPENDS.pkg or
                   4785: BUILDLINK_ABI_DEPENDS.pkg as we don't want to cause unneeded package deletions
                   4786: and rebuilds. In many cases, new versions of packages work just fine with older
                   4787: dependencies.
                   4788:
                   4789: Also it is not needed to set BUILDLINK_ABI_DEPENDS.pkg when it is identical to
                   4790: BUILDLINK_API_DEPENDS.pkg.
1.1       grant    4791:
1.107     rillig   4792: 14.3. Writing builtin.mk files
1.1       grant    4793:
                   4794: Some packages in pkgsrc install headers and libraries that coincide with
                   4795: headers and libraries present in the base system. Aside from a buildlink3.mk
                   4796: file, these packages should also include a builtin.mk file that includes the
                   4797: necessary checks to decide whether using the built-in software or the pkgsrc
                   4798: software is appropriate.
                   4799:
                   4800: The only requirements of a builtin.mk file for pkg are:
                   4801:
                   4802:  1. It should set USE_BUILTIN.pkg to either "yes" or "no" after it is included.
1.20      ben      4803:
1.1       grant    4804:  2. It should not override any USE_BUILTIN.pkg which is already set before the
                   4805:     builtin.mk file is included.
1.20      ben      4806:
1.1       grant    4807:  3. It should be written to allow multiple inclusion. This is very important
                   4808:     and takes careful attention to Makefile coding.
1.20      ben      4809:
1.107     rillig   4810: 14.3.1. Anatomy of a builtin.mk file
1.1       grant    4811:
                   4812: The following is the recommended template for builtin.mk files:
                   4813:
1.101     rillig   4814: .if !defined(IS_BUILTIN.foo)
                   4815: #
                   4816: # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
                   4817: # genuinely exists in the system or not.
                   4818: #
                   4819: IS_BUILTIN.foo?=        no
                   4820:
                   4821: # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
                   4822: # version can be determined.
                   4823: #
                   4824: .  if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
                   4825: BUILTIN_PKG.foo?=       foo-1.0
                   4826: .  endif
                   4827: .endif  # IS_BUILTIN.foo
                   4828:
                   4829: .if !defined(USE_BUILTIN.foo)
                   4830: USE_BUILTIN.foo?=       ${IS_BUILTIN.foo}
                   4831: .  if defined(BUILTIN_PKG.foo)
                   4832: .    for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
                   4833: .      if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
                   4834: USE_BUILTIN.foo!=                                                       \
                   4835:         ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}            \
                   4836:         && ${ECHO} "yes" || ${ECHO} "no"
                   4837: .      endif
                   4838: .    endfor
                   4839: .  endif
                   4840: .endif  # USE_BUILTIN.foo
1.51      rillig   4841:
1.101     rillig   4842: CHECK_BUILTIN.foo?=     no
                   4843: .if !empty(CHECK_BUILTIN.foo:M[nN][oO])
                   4844: #
                   4845: # Here we place code that depends on whether USE_BUILTIN.foo is set to
                   4846: # "yes" or "no".
                   4847: #
                   4848: .endif  # CHECK_BUILTIN.foo
1.1       grant    4849:
                   4850: The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the
                   4851: base system. This should not be a base system software with similar
                   4852: functionality to pkg; it should only be "yes" if the actual package is included
                   4853: as part of the base system. This variable is only used internally within the
                   4854: builtin.mk file.
                   4855:
                   4856: The second section sets BUILTIN_PKG.pkg to the version of pkg in the base
                   4857: system if it exists (if IS_BUILTIN.pkg is "yes"). This variable is only used
                   4858: internally within the builtin.mk file.
                   4859:
                   4860: The third section sets USE_BUILTIN.pkg and is required in all builtin.mk files.
                   4861: The code in this section must make the determination whether the built-in
1.72      rillig   4862: software is adequate to satisfy the dependencies listed in
                   4863: BUILDLINK_API_DEPENDS.pkg. This is typically done by comparing BUILTIN_PKG.pkg
                   4864: against each of the dependencies in BUILDLINK_API_DEPENDS.pkg. USE_BUILTIN.pkg
                   4865: must be set to the correct value by the end of the builtin.mk file. Note that
                   4866: USE_BUILTIN.pkg may be "yes" even if IS_BUILTIN.pkg is "no" because we may make
                   4867: the determination that the built-in version of the software is similar enough
                   4868: to be used as a replacement.
1.1       grant    4869:
                   4870: The last section is guarded by CHECK_BUILTIN.pkg, and includes code that uses
                   4871: the value of USE_BUILTIN.pkg set in the previous section. This typically
                   4872: includes, e.g., adding additional dependency restrictions and listing
                   4873: additional files to symlink into ${BUILDLINK_DIR} (via BUILDLINK_FILES.pkg).
                   4874:
1.107     rillig   4875: 14.3.2. Global preferences for native or pkgsrc software
1.1       grant    4876:
                   4877: When building packages, it's possible to choose whether to set a global
                   4878: preference for using either the built-in (native) version or the pkgsrc version
                   4879: of software to satisfy a dependency. This is controlled by setting
                   4880: PREFER_PKGSRC and PREFER_NATIVE. These variables take values of either "yes",
                   4881: "no", or a list of packages. PREFER_PKGSRC tells pkgsrc to use the pkgsrc
                   4882: versions of software, while PREFER_NATIVE tells pkgsrc to use the built-in
                   4883: versions. Preferences are determined by the most specific instance of the
                   4884: package in either PREFER_PKGSRC or PREFER_NATIVE. If a package is specified in
                   4885: neither or in both variables, then PREFER_PKGSRC has precedence over
                   4886: PREFER_NATIVE. For example, to require using pkgsrc versions of software for
                   4887: all but the most basic bits on a NetBSD system, you can set:
                   4888:
1.101     rillig   4889: PREFER_PKGSRC=  yes
                   4890: PREFER_NATIVE=  getopt skey tcp_wrappers
1.1       grant    4891:
                   4892: A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise
                   4893: it is simply ignored in that list.
                   4894:
1.107     rillig   4895: Chapter 15. The pkginstall framework
1.35      jmmv     4896:
                   4897: Table of Contents
                   4898:
1.107     rillig   4899: 15.1. Files and directories outside the installation prefix
1.35      jmmv     4900:
1.107     rillig   4901:     15.1.1. Directory manipulation
                   4902:     15.1.2. File manipulation
1.35      jmmv     4903:
1.107     rillig   4904: 15.2. Configuration files
1.35      jmmv     4905:
1.107     rillig   4906:     15.2.1. How PKG_SYSCONFDIR is set
                   4907:     15.2.2. Telling the software where configuration files are
                   4908:     15.2.3. Patching installations
                   4909:     15.2.4. Disabling handling of configuration files
1.35      jmmv     4910:
1.107     rillig   4911: 15.3. System startup scripts
1.35      jmmv     4912:
1.107     rillig   4913:     15.3.1. Disabling handling of system startup scripts
1.35      jmmv     4914:
1.107     rillig   4915: 15.4. System users and groups
                   4916: 15.5. System shells
1.35      jmmv     4917:
1.107     rillig   4918:     15.5.1. Disabling shell registration
1.65      hubertf  4919:
1.107     rillig   4920: 15.6. Fonts
1.65      hubertf  4921:
1.107     rillig   4922:     15.6.1. Disabling automatic update of the fonts databases
1.35      jmmv     4923:
                   4924: This chapter describes the framework known as pkginstall, whose key features
                   4925: are:
                   4926:
                   4927:   * Generic installation and manipulation of directories and files outside the
                   4928:     pkgsrc-handled tree, LOCALBASE.
                   4929:
                   4930:   * Automatic handling of configuration files during installation, provided
                   4931:     that packages are correctly designed.
                   4932:
                   4933:   * Generation and installation of system startup scripts.
                   4934:
                   4935:   * Registration of system users and groups.
                   4936:
                   4937:   * Registration of system shells.
                   4938:
1.65      hubertf  4939:   * Automatic updating of fonts databases.
1.35      jmmv     4940:
1.65      hubertf  4941: The following sections inspect each of the above points in detail.
1.35      jmmv     4942:
                   4943: You may be thinking that many of the things described here could be easily done
                   4944: with simple code in the package's post-installation target (post-install). This
                   4945: is incorrect, as the code in them is only executed when building from source.
                   4946: Machines using binary packages could not benefit from it at all (as the code
                   4947: itself could be unavailable). Therefore, the only way to achieve any of the
                   4948: items described above is by means of the installation scripts, which are
                   4949: automatically generated by pkginstall.
                   4950:
1.107     rillig   4951: 15.1. Files and directories outside the installation prefix
1.35      jmmv     4952:
                   4953: As you already know, the PLIST file holds a list of files and directories that
                   4954: belong to a package. The names used in it are relative to the installation
                   4955: prefix (${PREFIX}), which means that it cannot register files outside this
                   4956: directory (absolute path names are not allowed). Despite this restriction, some
                   4957: packages need to install files outside this location; e.g., under ${VARBASE} or
1.87      wiz      4958: ${PKG_SYSCONFDIR}. The only way to achieve this is to create such files during
                   4959: installation time by using installation scripts.
1.35      jmmv     4960:
1.87      wiz      4961: The generic installation scripts are shell scripts that can contain arbitrary
                   4962: code. The list of scripts to execute is taken from the INSTALL_FILE variable,
                   4963: which defaults to INSTALL. A similar variable exists for package removal
                   4964: (DEINSTALL_FILE, whose default is DEINSTALL). These scripts can run arbitrary
                   4965: commands, so they have the potential to create and manage files anywhere in the
                   4966: file system.
                   4967:
                   4968: Using these general installation files is not recommended, but may be needed in
                   4969: some special cases. One reason for avoiding them is that the user has to trust
                   4970: the packager that there is no unwanted or simply erroneous code included in the
                   4971: installation script. Also, previously there were many similar scripts for the
                   4972: same functionality, and fixing a common error involved finding and changing all
                   4973: of them.
                   4974:
                   4975: The pkginstall framework offers another, standardized way. It provides generic
                   4976: scripts to abstract the manipulation of such files and directories based on
                   4977: variables set in the package's Makefile. The rest of this section describes
                   4978: these variables.
1.35      jmmv     4979:
1.107     rillig   4980: 15.1.1. Directory manipulation
1.35      jmmv     4981:
                   4982: The following variables can be set to request the creation of directories
1.47      reed     4983: anywhere in the file system:
1.35      jmmv     4984:
                   4985:   * MAKE_DIRS and OWN_DIRS contain a list of directories that should be created
                   4986:     and should attempt to be destroyed by the installation scripts. The
                   4987:     difference between the two is that the latter prompts the administrator to
                   4988:     remove any directories that may be left after deinstallation (because they
                   4989:     were not empty), while the former does not.
                   4990:
                   4991:   * MAKE_DIRS_PERMS and OWN_DIRS_PERMS contain a list of tuples describing
                   4992:     which directories should be created and should attempt to be destroyed by
                   4993:     the installation scripts. Each tuple holds the following values, separated
                   4994:     by spaces: the directory name, its owner, its group and its numerical mode.
                   4995:     For example:
                   4996:
1.101     rillig   4997:     MAKE_DIRS_PERMS+=         ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
1.35      jmmv     4998:
                   4999:     The difference between the two is exactly the same as their non-PERMS
                   5000:     counterparts.
                   5001:
1.107     rillig   5002: 15.1.2. File manipulation
1.35      jmmv     5003:
                   5004: Creating non-empty files outside the installation prefix is tricky because the
                   5005: PLIST forces all files to be inside it. To overcome this problem, the only
                   5006: solution is to extract the file in the known place (i.e., inside the
                   5007: installation prefix) and copy it to the appropriate location during
                   5008: installation (done by the installation scripts generated by pkginstall). We
                   5009: will call the former the master file in the following paragraphs, which
                   5010: describe the variables that can be used to automatically and consistently
                   5011: handle files outside the installation prefix:
                   5012:
                   5013:   * CONF_FILES and SUPPORT_FILES are pairs of master and target files. During
                   5014:     installation time, the master file is copied to the target one if and only
                   5015:     if the latter does not exist. Upon deinstallation, the target file is
                   5016:     removed provided that it was not modified by the installation.
                   5017:
                   5018:     The difference between the two is that the latter prompts the administrator
                   5019:     to remove any files that may be left after deinstallation (because they
                   5020:     were not empty), while the former does not.
                   5021:
                   5022:   * CONF_FILES_PERMS and SUPPORT_FILES_PERMS contain tuples describing master
                   5023:     files as well as their target locations. For each of them, it also
                   5024:     specifies their owner, their group and their numeric permissions, in this
                   5025:     order. For example:
                   5026:
1.101     rillig   5027:     SUPPORT_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
1.35      jmmv     5028:
                   5029:     The difference between the two is exactly the same as their non-PERMS
                   5030:     counterparts.
                   5031:
1.107     rillig   5032: 15.2. Configuration files
1.35      jmmv     5033:
                   5034: Configuration files are special in the sense that they are installed in their
                   5035: own specific directory, PKG_SYSCONFDIR, and need special treatment during
                   5036: installation (most of which is automated by pkginstall). The main concept you
1.36      wiz      5037: must bear in mind is that files marked as configuration files are automatically
1.35      jmmv     5038: copied to the right place (somewhere inside PKG_SYSCONFDIR) during installation
                   5039: if and only if they didn't exist before. Similarly, they will not be removed if
1.36      wiz      5040: they have local modifications. This ensures that administrators never lose any
1.35      jmmv     5041: custom changes they may have made.
                   5042:
1.107     rillig   5043: 15.2.1. How PKG_SYSCONFDIR is set
1.35      jmmv     5044:
                   5045: As said before, the PKG_SYSCONFDIR variable specifies where configuration files
                   5046: shall be installed. Its contents are set based upon the following variables:
                   5047:
                   5048:   * PKG_SYSCONFBASE: The configuration's root directory. Defaults to ${PREFIX}/
1.36      wiz      5049:     etc although it may be overridden by the user to point to his preferred
1.35      jmmv     5050:     location (e.g., /etc, /etc/pkg, etc.). Packages must not use it directly.
                   5051:
                   5052:   * PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the
                   5053:     configuration files for the package being built shall be installed. The
                   5054:     definition of this variable only makes sense in the package's Makefile
1.47      reed     5055:     (i.e., it is not user-customizable).
1.35      jmmv     5056:
                   5057:     As an example, consider the Apache package, www/apache2, which places its
                   5058:     configuration files under the httpd/ subdirectory of PKG_SYSCONFBASE. This
                   5059:     should be set in the package Makefile.
                   5060:
                   5061:   * PKG_SYSCONFVAR: Specifies the name of the variable that holds this
                   5062:     package's configuration directory (if different from PKG_SYSCONFBASE). It
                   5063:     defaults to PKGBASE's value, and is always prefixed with PKG_SYSCONFDIR.
                   5064:
                   5065:   * PKG_SYSCONFDIR.${PKG_SYSCONFVAR}: Holds the directory where the
                   5066:     configuration files for the package identified by PKG_SYSCONFVAR's shall be
                   5067:     placed.
                   5068:
                   5069: Based on the above variables, pkginstall determines the value of
                   5070: PKG_SYSCONFDIR, which is the only variable that can be used within a package to
                   5071: refer to its configuration directory. The algorithm used to set its value is
                   5072: basically the following:
                   5073:
                   5074:  1. If PKG_SYSCONFDIR.${PKG_SYSCONFVAR} is set, its value is used.
                   5075:
                   5076:  2. If the previous variable is not defined but PKG_SYSCONFSUBDIR is set in the
                   5077:     package's Makefile, the resulting value is ${PKG_SYSCONFBASE}/$
                   5078:     {PKG_SYSCONFSUBDIR}.
                   5079:
                   5080:  3. Otherwise, it is set to ${PKG_SYSCONFBASE}.
                   5081:
                   5082: It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
1.118     jnemeth  5083: OWN_DIRS. See Section 15.1.1, "Directory manipulation" what this means. This
                   5084: does not apply to subdirectories of ${PKG_SYSCONFDIR}, they still have to be
                   5085: created with OWN_DIRS or MAKE_DIRS.
1.35      jmmv     5086:
1.107     rillig   5087: 15.2.2. Telling the software where configuration files are
1.35      jmmv     5088:
                   5089: Given that pkgsrc (and users!) expect configuration files to be in a known
1.36      wiz      5090: place, you need to teach each package where it shall install its files. In some
1.35      jmmv     5091: cases you will have to patch the package Makefiles to achieve it. If you are
                   5092: lucky, though, it may be as easy as passing an extra flag to the configuration
1.47      reed     5093: script; this is the case of GNU Autoconf- generated files:
1.35      jmmv     5094:
1.101     rillig   5095: CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
1.35      jmmv     5096:
                   5097: Note that this specifies where the package has to look for its configuration
                   5098: files, not where they will be originally installed (although the difference is
                   5099: never explicit, unfortunately).
                   5100:
1.107     rillig   5101: 15.2.3. Patching installations
1.35      jmmv     5102:
                   5103: As said before, pkginstall automatically handles configuration files. This
                   5104: means that the packages themselves must not touch the contents of $
1.36      wiz      5105: {PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts
                   5106: will, out of the box, mess with the contents of that directory. So what is the
                   5107: correct procedure to fix this issue?
1.35      jmmv     5108:
                   5109: You must teach the package (usually by manually patching it) to install any
                   5110: configuration files under the examples hierarchy, share/examples/${PKGBASE}/.
                   5111: This way, the PLIST registers them and the administrator always has the
                   5112: original copies available.
                   5113:
                   5114: Once the required configuration files are in place (i.e., under the examples
                   5115: hierarchy), the pkginstall framework can use them as master copies during the
                   5116: package installation to update what is in ${PKG_SYSCONFDIR}. To achieve this,
1.63      dillo    5117: the variables CONF_FILES and CONF_FILES_PERMS are used. Check out
1.107     rillig   5118: Section 15.1.2, "File manipulation" for information about their syntax and
1.63      dillo    5119: their purpose. Here is an example, taken from the mail/mutt package:
1.35      jmmv     5120:
1.101     rillig   5121: EGDIR=        ${PREFIX}/share/doc/mutt/samples
                   5122: CONF_FILES=   ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
1.35      jmmv     5123:
                   5124: Note that the EGDIR variable is specific to that package and has no meaning
                   5125: outside it.
                   5126:
1.107     rillig   5127: 15.2.4. Disabling handling of configuration files
1.35      jmmv     5128:
                   5129: The automatic copying of config files can be toggled by setting the environment
                   5130: variable PKG_CONFIG prior to package installation.
                   5131:
1.107     rillig   5132: 15.3. System startup scripts
1.35      jmmv     5133:
                   5134: System startup scripts are special files because they must be installed in a
                   5135: place known by the underlying OS, usually outside the installation prefix.
1.107     rillig   5136: Therefore, the same rules described in Section 15.1, "Files and directories
1.35      jmmv     5137: outside the installation prefix" apply, and the same solutions can be used.
1.36      wiz      5138: However, pkginstall provides a special mechanism to handle these files.
1.35      jmmv     5139:
                   5140: In order to provide system startup scripts, the package has to:
                   5141:
                   5142:  1. Store the script inside ${FILESDIR}, with the .sh suffix appended.
1.36      wiz      5143:     Considering the print/cups package as an example, it has a cupsd.sh in its
                   5144:     files directory.
1.35      jmmv     5145:
                   5146:  2. Tell pkginstall to handle it, appending the name of the script, without its
                   5147:     extension, to the RCD_SCRIPTS variable. Continuing the previous example:
                   5148:
1.101     rillig   5149:     RCD_SCRIPTS+=   cupsd
1.35      jmmv     5150:
                   5151: Once this is done, pkginstall will do the following steps for each script in an
                   5152: automated fashion:
                   5153:
                   5154:  1. Process the file found in the files directory applying all the
                   5155:     substitutions described in the FILES_SUBST variable.
                   5156:
                   5157:  2. Copy the script from the files directory to the examples hierarchy, $
1.36      wiz      5158:     {PREFIX}/share/examples/rc.d/. Note that this master file must be
                   5159:     explicitly registered in the PLIST.
1.35      jmmv     5160:
                   5161:  3. Add code to the installation scripts to copy the startup script from the
                   5162:     examples hierarchy into the system-wide startup scripts directory.
                   5163:
1.107     rillig   5164: 15.3.1. Disabling handling of system startup scripts
1.35      jmmv     5165:
                   5166: The automatic copying of config files can be toggled by setting the environment
                   5167: variable PKG_RCD_SCRIPTS prior to package installation. Note that the scripts
                   5168: will be always copied inside the examples hierarchy, ${PREFIX}/share/examples/
                   5169: rc.d/, no matter what the value of this variable is.
                   5170:
1.107     rillig   5171: 15.4. System users and groups
1.35      jmmv     5172:
                   5173: If a package needs to create special users and/or groups during installation,
                   5174: it can do so by using the pkginstall framework.
                   5175:
                   5176: Users can be created by adding entries to the PKG_USERS variable. Each entry
1.72      rillig   5177: has the following syntax:
1.35      jmmv     5178:
1.101     rillig   5179: user:group
1.35      jmmv     5180:
1.72      rillig   5181: Further specification of user details may be done by setting per-user
                   5182: variables. PKG_UID.user is the numeric UID for the user. PKG_GECOS.user is the
                   5183: user's description or comment. PKG_HOME.user is the user's home directory, and
                   5184: defaults to /nonexistent if not specified. PKG_SHELL.user is the user's shell,
1.94      dmcmahil 5185: and defaults to /sbin/nologin if not specified.
1.35      jmmv     5186:
1.72      rillig   5187: Similarly, groups can be created by adding entries to the PKG_GROUPS variable,
                   5188: whose syntax is:
1.35      jmmv     5189:
1.101     rillig   5190: group
1.35      jmmv     5191:
1.72      rillig   5192: The numeric GID of the group may be set by defining PKG_GID.group.
1.35      jmmv     5193:
1.72      rillig   5194: If a package needs to create the users and groups at an earlier stage, then it
                   5195: can set USERGROUP_PHASE to either configure or build to indicate the phase
                   5196: before which the users and groups are created. In this case, the numeric UIDs
                   5197: and GIDs of the created users and groups are automatically hardcoded into the
                   5198: final installation scripts.
1.35      jmmv     5199:
1.107     rillig   5200: 15.5. System shells
1.35      jmmv     5201:
                   5202: Packages that install system shells should register them in the shell database,
                   5203: /etc/shells, to make things easier to the administrator. This must be done from
                   5204: the installation scripts to keep binary packages working on any system.
                   5205: pkginstall provides an easy way to accomplish this task.
                   5206:
                   5207: When a package provides a shell interpreter, it has to set the PKG_SHELL
                   5208: variable to its absolute file name. This will add some hooks to the
                   5209: installation scripts to handle it. Consider the following example, taken from
                   5210: shells/zsh:
                   5211:
1.101     rillig   5212: PKG_SHELL=      ${PREFIX}/bin/zsh
1.35      jmmv     5213:
1.107     rillig   5214: 15.5.1. Disabling shell registration
1.35      jmmv     5215:
                   5216: The automatic registration of shell interpreters can be disabled by the
                   5217: administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.
                   5218:
1.107     rillig   5219: 15.6. Fonts
1.65      hubertf  5220:
                   5221: Packages that install X11 fonts should update the database files that index the
                   5222: fonts within each fonts directory. This can easily be accomplished within the
                   5223: pkginstall framework.
                   5224:
                   5225: When a package installs X11 fonts, it must list the directories in which fonts
                   5226: are installed in the FONTS_DIRS.type variables, where type can be one of "ttf",
                   5227: "type1" or "x11". This will add hooks to the installation scripts to run the
                   5228: appropriate commands to update the fonts database files within each of those
                   5229: directories. For convenience, if the directory path is relative, it is taken to
                   5230: be relative to the package's installation prefix. Consider the following
                   5231: example, taken from fonts/dbz-ttf:
                   5232:
1.101     rillig   5233: FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF
1.65      hubertf  5234:
1.107     rillig   5235: 15.6.1. Disabling automatic update of the fonts databases
1.65      hubertf  5236:
                   5237: The automatic update of fonts databases can be disabled by the administrator by
                   5238: setting the PKG_UPDATE_FONTS_DB environment variable to NO.
                   5239:
1.107     rillig   5240: Chapter 16. Options handling
1.1       grant    5241:
                   5242: Table of Contents
                   5243:
1.107     rillig   5244: 16.1. Global default options
                   5245: 16.2. Converting packages to use bsd.options.mk
                   5246: 16.3. Option Names
1.108     rillig   5247: 16.4. Determining the options of dependencies
1.1       grant    5248:
                   5249: Many packages have the ability to be built to support different sets of
                   5250: features. bsd.options.mk is a framework in pkgsrc that provides generic
                   5251: handling of those options that determine different ways in which the packages
                   5252: can be built. It's possible for the user to specify exactly which sets of
                   5253: options will be built into a package or to allow a set of global default
                   5254: options apply.
                   5255:
1.108     rillig   5256: There are two broad classes of behaviors that one might want to control via
                   5257: options. One is whether some particular feature is enabled in a program that
                   5258: will be built anyway, often by including or not including a dependency on some
                   5259: other package. The other is whether or not an additional program will be built
                   5260: as part of the package. Generally, it is better to make a split package for
                   5261: such additional programs instead of using options, because it enables binary
                   5262: packages to be built which can then be added separately. For example, the foo
                   5263: package might have minimal dependencies (those packages without which foo
                   5264: doesn't make sense), and then the foo-gfoo package might include the GTK
                   5265: frontend program gfoo. This is better than including a gtk option to foo that
                   5266: adds gfoo, because either that option is default, in which case binary users
                   5267: can't get foo without gfoo, or not default, in which case they can't get gfoo.
                   5268: With split packages, they can install foo without having GTK, and later decide
                   5269: to install gfoo (pulling in GTK at that time). This is an advantage to source
                   5270: users too, avoiding the need for rebuilds.
                   5271:
                   5272: Plugins with widely varying dependencies should usually be split instead of
                   5273: options.
                   5274:
                   5275: It is often more work to maintain split packages, especially if the upstream
                   5276: package does not support this. The decision of split vs. option should be made
                   5277: based on the likelihood that users will want or object to the various pieces,
                   5278: the size of the dependencies that are included, and the amount of work.
                   5279:
                   5280: A further consideration is licensing. Non-free parts, or parts that depend on
                   5281: non-free dependencies (especially plugins) should almost always be split if
                   5282: feasible.
                   5283:
1.107     rillig   5284: 16.1. Global default options
1.1       grant    5285:
                   5286: Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of
                   5287: the options that should be built into every package if that option is
1.105     rillig   5288: supported. This variable should be set in mk.conf.
1.1       grant    5289:
1.107     rillig   5290: 16.2. Converting packages to use bsd.options.mk
1.1       grant    5291:
1.27      rillig   5292: The following example shows how bsd.options.mk should be used by the
                   5293: hypothetical ``wibble'' package, either in the package Makefile, or in a file,
                   5294: e.g. options.mk, that is included by the main package Makefile.
1.1       grant    5295:
1.101     rillig   5296: PKG_OPTIONS_VAR=                PKG_OPTIONS.wibble
                   5297: PKG_SUPPORTED_OPTIONS=          wibble-foo ldap
                   5298: PKG_OPTIONS_OPTIONAL_GROUPS=    database
                   5299: PKG_OPTIONS_GROUP.database=     mysql pgsql
                   5300: PKG_SUGGESTED_OPTIONS=          wibble-foo
                   5301: PKG_OPTIONS_LEGACY_VARS+=       WIBBLE_USE_OPENLDAP:ldap
                   5302: PKG_OPTIONS_LEGACY_OPTS+=       foo:wibble-foo
                   5303:
                   5304: .include "../../mk/bsd.prefs.mk"
                   5305:
                   5306: # this package was previously named wibble2
                   5307: .if defined(PKG_OPTIONS.wibble2)
                   5308: PKG_LEGACY_OPTIONS+=            ${PKG_OPTIONS.wibble2}
                   5309: PKG_OPTIONS_DEPRECATED_WARNINGS+= \
                   5310:         "Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR} instead."
                   5311: .endif
1.51      rillig   5312:
1.101     rillig   5313: .include "../../mk/bsd.options.mk"
1.51      rillig   5314:
1.101     rillig   5315: # Package-specific option-handling
1.51      rillig   5316:
1.101     rillig   5317: ###
                   5318: ### FOO support
                   5319: ###
                   5320: .if !empty(PKG_OPTIONS:Mwibble-foo)
                   5321: CONFIGURE_ARGS+=    --enable-foo
                   5322: .endif
1.51      rillig   5323:
1.101     rillig   5324: ###
                   5325: ### LDAP support
                   5326: ###
                   5327: .if !empty(PKG_OPTIONS:Mldap)
                   5328: .  include "../../databases/openldap-client/buildlink3.mk"
                   5329: CONFIGURE_ARGS+=    --enable-ldap=${BUILDLINK_PREFIX.openldap-client}
                   5330: .endif
1.51      rillig   5331:
1.101     rillig   5332: ###
                   5333: ### database support
                   5334: ###
                   5335: .if !empty(PKG_OPTIONS:Mmysql)
                   5336: .  include "../../mk/mysql.buildlink3.mk"
                   5337: .endif
                   5338: .if !empty(PKG_OPTIONS:Mpgsql)
                   5339: .  include "../../mk/pgsql.buildlink3.mk"
                   5340: .endif
1.20      ben      5341:
1.28      rillig   5342: The first section contains the information about which build options are
1.1       grant    5343: supported by the package, and any default options settings if needed.
                   5344:
1.37      dillo    5345:  1. PKG_OPTIONS_VAR is the name of the make(1) variable that the user can set
1.57      minskim  5346:     to override the default options. It should be set to PKG_OPTIONS.pkgbase.
1.78      rillig   5347:     Do not set it to PKG_OPTIONS.${PKGBASE}, since PKGBASE is not defined at
                   5348:     the point where the options are processed.
1.20      ben      5349:
1.1       grant    5350:  2. PKG_SUPPORTED_OPTIONS is a list of build options supported by the package.
1.20      ben      5351:
1.37      dillo    5352:  3. PKG_OPTIONS_OPTIONAL_GROUPS is a list of names of groups of mutually
                   5353:     exclusive options. The options in each group are listed in
                   5354:     PKG_OPTIONS_GROUP.groupname. The most specific setting of any option from
                   5355:     the group takes precedence over all other options in the group. Options
                   5356:     from the groups will be automatically added to PKG_SUPPORTED_OPTIONS.
                   5357:
                   5358:  4. PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, but
                   5359:     building the packages will fail if no option from the group is selected.
                   5360:
1.44      gdt      5361:  5. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of options. At least
                   5362:     one option from each set must be selected. The options in each set are
                   5363:     listed in PKG_OPTIONS_SET.setname. Options from the sets will be
                   5364:     automatically added to PKG_SUPPORTED_OPTIONS. Building the package will
                   5365:     fail if no option from the set is selected.
                   5366:
                   5367:  6. PKG_SUGGESTED_OPTIONS is a list of build options which are enabled by
1.27      rillig   5368:     default.
                   5369:
1.67      hubertf  5370:  7. PKG_OPTIONS_LEGACY_VARS is a list of "USE_VARIABLE:option" pairs that map
1.105     rillig   5371:     legacy mk.conf variables to their option counterparts. Pairs should be
1.37      dillo    5372:     added with "+=" to keep the listing of global legacy variables. A warning
                   5373:     will be issued if the user uses a legacy variable.
                   5374:
1.67      hubertf  5375:  8. PKG_OPTIONS_LEGACY_OPTS is a list of "old-option:new-option" pairs that map
                   5376:     options that have been renamed to their new counterparts. Pairs should be
                   5377:     added with "+=" to keep the listing of global legacy options. A warning
1.37      dillo    5378:     will be issued if the user uses a legacy option.
                   5379:
1.44      gdt      5380:  9. PKG_LEGACY_OPTIONS is a list of options implied by deprecated variables
1.37      dillo    5381:     used. This can be used for cases that neither PKG_OPTIONS_LEGACY_VARS nor
                   5382:     PKG_OPTIONS_LEGACY_OPTS can handle, e. g. when PKG_OPTIONS_VAR is renamed.
                   5383:
1.44      gdt      5384: 10. PKG_OPTIONS_DEPRECATED_WARNINGS is a list of warnings about deprecated
1.37      dillo    5385:     variables or options used, and what to use instead.
                   5386:
                   5387: A package should never modify PKG_DEFAULT_OPTIONS or the variable named in
                   5388: PKG_OPTIONS_VAR. These are strictly user-settable. To suggest a default set of
                   5389: options, use PKG_SUGGESTED_OPTIONS.
                   5390:
1.42      dillo    5391: PKG_OPTIONS_VAR must be defined before including bsd.options.mk. If none of
                   5392: PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, and
1.47      reed     5393: PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform-specific
1.42      dillo    5394: options if none of them is supported on the current platform), PKG_OPTIONS is
                   5395: set to the empty list and the package is otherwise treated as not using the
                   5396: options framework.
1.28      rillig   5397:
                   5398: After the inclusion of bsd.options.mk, the variable PKG_OPTIONS contains the
1.37      dillo    5399: list of selected build options, properly filtered to remove unsupported and
1.28      rillig   5400: duplicate options.
1.20      ben      5401:
1.37      dillo    5402: The remaining sections contain the logic that is specific to each option. The
                   5403: correct way to check for an option is to check whether it is listed in
                   5404: PKG_OPTIONS:
                   5405:
1.101     rillig   5406: .if !empty(PKG_OPTIONS:Moption)
1.37      dillo    5407:
1.107     rillig   5408: 16.3. Option Names
1.48      dillo    5409:
                   5410: Options that enable similar features in different packages (like optional
                   5411: support for a library) should use a common name in all packages that support it
                   5412: (like the name of the library). If another package already has an option with
                   5413: the same meaning, use the same name.
                   5414:
                   5415: Options that enable features specific to one package, where it's unlikely that
                   5416: another (unrelated) package has the same (or a similar) optional feature,
                   5417: should use a name prefixed with pkgname-.
                   5418:
                   5419: If a group of related packages share an optional feature specific to that
                   5420: group, prefix it with the name of the "main" package (e. g.
                   5421: djbware-errno-hack).
                   5422:
                   5423: For new options, add a line to mk/defaults/options.description. Lines have two
                   5424: fields, separated by tab. The first field is the option name, the second its
                   5425: description. The description should be a whole sentence (starting with an
                   5426: uppercase letter and ending with a period) that describes what enabling the
                   5427: option does. E. g. "Enable ispell support." The file is sorted by option names.
1.1       grant    5428:
1.108     rillig   5429: 16.4. Determining the options of dependencies
                   5430:
                   5431: When writing buildlink3.mk files, it is often necessary to list different
                   5432: dependencies based on the options with which the package was built. For
                   5433: querying these options, the file pkgsrc/mk/pkg-build-options.mk should be used.
                   5434: A typical example looks like this:
                   5435:
                   5436: pkgbase := libpurple
                   5437: .include "../../mk/pkg-build-options.mk"
                   5438:
                   5439: .if !empty(PKG_BUILD_OPTIONS.libpurple:Mdbus)
                   5440: ...
                   5441: .endif
                   5442:
                   5443: Including pkg-build-options.mk here will set the variable
                   5444: PKG_BUILD_OPTIONS.libpurple to the build options of the libpurple package,
                   5445: which can then be queried like PKG_OPTIONS in the options.mk file. See the file
                   5446: pkg-build-options.mk for more details.
                   5447:
1.107     rillig   5448: Chapter 17. The build process
1.1       grant    5449:
                   5450: Table of Contents
                   5451:
1.107     rillig   5452: 17.1. Introduction
                   5453: 17.2. Program location
                   5454: 17.3. Directories used during the build process
                   5455: 17.4. Running a phase
                   5456: 17.5. The fetch phase
                   5457:
                   5458:     17.5.1. What to fetch and where to get it from
                   5459:     17.5.2. How are the files fetched?
                   5460:
                   5461: 17.6. The checksum phase
                   5462: 17.7. The extract phase
                   5463: 17.8. The patch phase
                   5464: 17.9. The tools phase
                   5465: 17.10. The wrapper phase
                   5466: 17.11. The configure phase
                   5467: 17.12. The build phase
                   5468: 17.13. The test phase
                   5469: 17.14. The install phase
                   5470: 17.15. The package phase
                   5471: 17.16. Cleaning up
                   5472: 17.17. Other helpful targets
1.56      rillig   5473:
1.107     rillig   5474: 17.1. Introduction
1.56      rillig   5475:
                   5476: This chapter gives a detailed description on how a package is built. Building a
                   5477: package is separated into different phases (for example fetch, build, install),
1.121     snj      5478: all of which are described in the following sections. Each phase is split into
                   5479: so-called stages, which take the name of the containing phase, prefixed by one
                   5480: of pre-, do- or post-. (Examples are pre-configure, post-build.) Most of the
                   5481: actual work is done in the do-* stages.
1.1       grant    5482:
1.97      wiz      5483: Never override the regular targets (like fetch), if you have to, override the
                   5484: do-* ones instead.
                   5485:
1.1       grant    5486: The basic steps for building a program are always the same. First the program's
                   5487: source (distfile) must be brought to the local system and then extracted. After
1.66      rillig   5488: any pkgsrc-specific patches to compile properly are applied, the software can
                   5489: be configured, then built (usually by compiling), and finally the generated
                   5490: binaries, etc. can be put into place on the system.
1.1       grant    5491:
1.97      wiz      5492: To get more details about what is happening at each step, you can set the
                   5493: PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in
                   5494: more details about the patch step.
                   5495:
1.107     rillig   5496: 17.2. Program location
1.1       grant    5497:
                   5498: Before outlining the process performed by the NetBSD package system in the next
                   5499: section, here's a brief discussion on where programs are installed, and which
                   5500: variables influence this.
                   5501:
                   5502: The automatic variable PREFIX indicates where all files of the final program
                   5503: shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
1.88      wiz      5504: pkgs in the cross category. The value of PREFIX needs to be put into the
1.1       grant    5505: various places in the program's source where paths to these files are encoded.
1.107     rillig   5506: See Section 11.3, "patches/*" and Section 19.3.1, "Shared libraries - libtool"
1.1       grant    5507: for more details.
                   5508:
                   5509: When choosing which of these variables to use, follow the following rules:
                   5510:
                   5511:   * PREFIX always points to the location where the current pkg will be
                   5512:     installed. When referring to a pkg's own installation path, use "${PREFIX}
                   5513:     ".
1.20      ben      5514:
1.1       grant    5515:   * LOCALBASE is where all non-X11 pkgs are installed. If you need to construct
                   5516:     a -I or -L argument to the compiler to find includes and libraries
1.78      rillig   5517:     installed by another non-X11 pkg, use "${LOCALBASE}". The name LOCALBASE
                   5518:     stems from FreeBSD, which installed all packages in /usr/local. As pkgsrc
                   5519:     leaves /usr/local for the system administrator, this variable is a
                   5520:     misnomer.
1.20      ben      5521:
1.1       grant    5522:   * X11BASE is where the actual X11 distribution (from xsrc, etc.) is
                   5523:     installed. When looking for standard X11 includes (not those installed by a
1.88      wiz      5524:     package), use "${X11BASE}".
1.20      ben      5525:
1.47      reed     5526:   * X11-based packages are special in that they may be installed in either
                   5527:     X11BASE or LOCALBASE.
1.20      ben      5528:
1.1       grant    5529:     Usually, X11 packages should be installed under LOCALBASE whenever
1.34      wiz      5530:     possible. Note that you will need to include ../../mk/x11.buildlink3.mk in
                   5531:     them to request the presence of X11 and to get the right compilation flags.
1.20      ben      5532:
1.1       grant    5533:     Even though, there are some packages that cannot be installed under
                   5534:     LOCALBASE: those that come with app-defaults files. These packages are
                   5535:     special and they must be placed under X11BASE. To accomplish this, set
                   5536:     either USE_X11BASE or USE_IMAKE in your package.
1.20      ben      5537:
1.34      wiz      5538:     Some notes: If you need to find includes or libraries installed by a pkg
                   5539:     that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in
                   5540:     both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages
                   5541:     in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default.
1.20      ben      5542:
1.1       grant    5543:   * X11PREFIX should be used to refer to the installed location of an X11
                   5544:     package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed,
                   5545:     and to LOCALBASE if xpkgwedge is installed.
1.20      ben      5546:
1.1       grant    5547:   * If xpkgwedge is installed, it is possible to have some packages installed
                   5548:     in X11BASE and some in LOCALBASE. To determine the prefix of an installed
                   5549:     package, the EVAL_PREFIX definition can be used. It takes pairs in the
                   5550:     format "DIRNAME=<package>", and the make(1) variable DIRNAME will be set to
                   5551:     the prefix of the installed package <package>, or "${X11PREFIX}" if the
                   5552:     package is not installed.
1.20      ben      5553:
1.1       grant    5554:     This is best illustrated by example.
1.20      ben      5555:
1.1       grant    5556:     The following lines are taken from pkgsrc/wm/scwm/Makefile:
1.20      ben      5557:
1.101     rillig   5558:     EVAL_PREFIX+=           GTKDIR=gtk+
                   5559:     CONFIGURE_ARGS+=        --with-guile-prefix=${LOCALBASE:Q}
                   5560:     CONFIGURE_ARGS+=        --with-gtk-prefix=${GTKDIR:Q}
                   5561:     CONFIGURE_ARGS+=        --enable-multibyte
1.20      ben      5562:
1.1       grant    5563:     Specific defaults can be defined for the packages evaluated using
                   5564:     EVAL_PREFIX, by using a definition of the form:
1.20      ben      5565:
1.101     rillig   5566:     GTKDIR_DEFAULT= ${LOCALBASE}
1.20      ben      5567:
1.1       grant    5568:     where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair.
1.20      ben      5569:
1.1       grant    5570:   * Within ${PREFIX}, packages should install files according to hier(7), with
                   5571:     the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
                   5572:     man.
1.20      ben      5573:
1.107     rillig   5574: 17.3. Directories used during the build process
1.1       grant    5575:
1.115     jmcneill 5576: When building a package, various directories are used to store source files,
1.56      rillig   5577: temporary files, pkgsrc-internal files, and so on. These directories are
                   5578: explained here.
1.1       grant    5579:
1.56      rillig   5580: Some of the directory variables contain relative pathnames. There are two
                   5581: common base directories for these relative directories: PKGSRCDIR/PKGPATH is
                   5582: used for directories that are pkgsrc-specific. WRKSRC is used for directories
1.66      rillig   5583: inside the package itself.
1.20      ben      5584:
1.66      rillig   5585: PKGSRCDIR
1.1       grant    5586:
1.56      rillig   5587:     This is an absolute pathname that points to the pkgsrc root directory.
                   5588:     Generally, you don't need it.
                   5589:
1.97      wiz      5590: PKGDIR
                   5591:
                   5592:     This is an absolute pathname that points to the current package.
                   5593:
1.66      rillig   5594: PKGPATH
1.56      rillig   5595:
                   5596:     This is a pathname relative to PKGSRCDIR that points to the current
                   5597:     package.
                   5598:
1.66      rillig   5599: WRKDIR
1.56      rillig   5600:
                   5601:     This is an absolute pathname pointing to the directory where all work takes
1.93      rillig   5602:     place. The distfiles are extracted to this directory. It also contains
1.57      minskim  5603:     temporary directories and log files used by the various pkgsrc frameworks,
                   5604:     like buildlink or the wrappers.
1.56      rillig   5605:
1.66      rillig   5606: WRKSRC
1.56      rillig   5607:
                   5608:     This is an absolute pathname pointing to the directory where the distfiles
                   5609:     are extracted. It is usually a direct subdirectory of WRKDIR, and often
1.66      rillig   5610:     it's the only directory entry that isn't hidden. This variable may be
                   5611:     changed by a package Makefile.
1.56      rillig   5612:
1.115     jmcneill 5613: The CREATE_WRKDIR_SYMLINK definition takes either the value yes or no and
1.117     rillig   5614: defaults to no. It indicates whether a symbolic link to the WRKDIR is to be
1.115     jmcneill 5615: created in the pkgsrc entry's directory. If users would like to have their
                   5616: pkgsrc trees behave in a read-only manner, then the value of
                   5617: CREATE_WRKDIR_SYMLINK should be set to no.
                   5618:
1.107     rillig   5619: 17.4. Running a phase
1.56      rillig   5620:
                   5621: You can run a particular phase by typing make phase, where phase is the name of
                   5622: the phase. This will automatically run all phases that are required for this
                   5623: phase. The default phase is build, that is, when you run make without
                   5624: parameters in a package directory, the package will be built, but not
                   5625: installed.
                   5626:
1.107     rillig   5627: 17.5. The fetch phase
1.56      rillig   5628:
1.81      rillig   5629: The first step in building a package is to fetch the distribution files
                   5630: (distfiles) from the sites that are providing them. This is the task of the
                   5631: fetch phase.
                   5632:
1.107     rillig   5633: 17.5.1. What to fetch and where to get it from
1.81      rillig   5634:
                   5635: In simple cases, MASTER_SITES defines all URLs from where the distfile, whose
                   5636: name is derived from the DISTNAME variable, is fetched. The more complicated
                   5637: cases are described below.
                   5638:
                   5639: The variable DISTFILES specifies the list of distfiles that have to be fetched.
                   5640: Its value defaults to ${DISTNAME}${EXTRACT_SUFX}, so that most packages don't
                   5641: need to define it at all. EXTRACT_SUFX is .tar.gz by default, but can be
                   5642: changed freely. Note that if your package requires additional distfiles to the
                   5643: default one, you cannot just append the additional filenames using the +=
                   5644: operator, but you have write for example:
                   5645:
1.101     rillig   5646: DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
1.88      wiz      5647:
                   5648: Each distfile is fetched from a list of sites, usually MASTER_SITES. If the
                   5649: package has multiple DISTFILES or multiple PATCHFILES from different sites, you
                   5650: can set SITES.distfile to the list of URLs where the file distfile (including
                   5651: the suffix) can be found.
                   5652:
1.101     rillig   5653: DISTFILES=      ${DISTNAME}${EXTRACT_SUFX}
                   5654: DISTFILES+=     foo-file.tar.gz
                   5655: SITES.foo-file.tar.gz= \
                   5656: http://www.somewhere.com/somehow/ \
                   5657: http://www.somewhereelse.com/mirror/somehow/
1.81      rillig   5658:
                   5659: When actually fetching the distfiles, each item from MASTER_SITES or SITES.*
                   5660: gets the name of each distfile appended to it, without an intermediate slash.
                   5661: Therefore, all site values have to end with a slash or other separator
                   5662: character. This allows for example to set MASTER_SITES to a URL of a CGI script
                   5663: that gets the name of the distfile as a parameter. In this case, the definition
                   5664: would look like:
                   5665:
1.101     rillig   5666: MASTER_SITES=   http://www.example.com/download.cgi?file=
1.81      rillig   5667:
1.126     wiz      5668: The exception to this rule are URLs starting with a dash. In that case the URL
                   5669: is taken as is, fetched and the result stored under the name of the distfile.
                   5670:
1.81      rillig   5671: There are some predefined values for MASTER_SITES, which can be used in
                   5672: packages. The names of the variables should speak for themselves.
                   5673:
1.101     rillig   5674: ${MASTER_SITE_APACHE}
                   5675: ${MASTER_SITE_BACKUP}
                   5676: ${MASTER_SITE_CYGWIN}
                   5677: ${MASTER_SITE_DEBIAN}
                   5678: ${MASTER_SITE_FREEBSD}
                   5679: ${MASTER_SITE_FREEBSD_LOCAL}
                   5680: ${MASTER_SITE_GENTOO}
                   5681: ${MASTER_SITE_GNOME}
                   5682: ${MASTER_SITE_GNU}
                   5683: ${MASTER_SITE_GNUSTEP}
                   5684: ${MASTER_SITE_IFARCHIVE}
                   5685: ${MASTER_SITE_KDE}
                   5686: ${MASTER_SITE_MOZILLA}
                   5687: ${MASTER_SITE_MYSQL}
                   5688: ${MASTER_SITE_OPENOFFICE}
                   5689: ${MASTER_SITE_PERL_CPAN}
                   5690: ${MASTER_SITE_PGSQL}
                   5691: ${MASTER_SITE_R_CRAN}
                   5692: ${MASTER_SITE_SOURCEFORGE}
                   5693: ${MASTER_SITE_SOURCEFORGE_JP}
                   5694: ${MASTER_SITE_SUNSITE}
                   5695: ${MASTER_SITE_SUSE}
                   5696: ${MASTER_SITE_TEX_CTAN}
                   5697: ${MASTER_SITE_XCONTRIB}
                   5698: ${MASTER_SITE_XEMACS}
1.88      wiz      5699:
                   5700: Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP
1.93      rillig   5701: contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org/
                   5702: pub/NetBSD/packages/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local
                   5703: package source distributions that are maintained in ftp://ftp.NetBSD.org/pub/
1.88      wiz      5704: NetBSD/packages/distfiles/LOCAL_PORTS/.
1.81      rillig   5705:
                   5706: If you choose one of these predefined sites, you may want to specify a
                   5707: subdirectory of that site. Since these macros may expand to more than one
                   5708: actual site, you must use the following construct to specify a subdirectory:
                   5709:
1.101     rillig   5710: MASTER_SITES=   ${MASTER_SITE_GNU:=subdirectory/name/}
                   5711: MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=project_name/}
1.81      rillig   5712:
                   5713: Note the trailing slash after the subdirectory name.
                   5714:
1.107     rillig   5715: 17.5.2. How are the files fetched?
1.81      rillig   5716:
                   5717: The fetch phase makes sure that all the distfiles exist in a local directory
1.93      rillig   5718: (DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they
                   5719: are fetched using commands of the form
1.56      rillig   5720:
1.101     rillig   5721: ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
1.56      rillig   5722:
                   5723: where ${site} varies through several possibilities in turn: first,
1.72      rillig   5724: MASTER_SITE_OVERRIDE is tried, then the sites specified in either SITES.file if
1.56      rillig   5725: defined, else MASTER_SITES or PATCH_SITES, as applies, then finally the value
1.91      rillig   5726: of MASTER_SITE_BACKUP. The order of all except the first and the last can be
                   5727: optionally sorted by the user, via setting either MASTER_SORT_RANDOM, and
                   5728: MASTER_SORT_AWK or MASTER_SORT_REGEX.
1.56      rillig   5729:
1.118     jnemeth  5730: The specific command and arguments used depend on the FETCH_USING parameter.
                   5731: The example above is for FETCH_USING=custom.
                   5732:
1.97      wiz      5733: The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles
                   5734: target to mirror the distfiles, if they are freely distributable. Packages
                   5735: setting NO_SRC_ON_FTP (usually to "${RESTRICTED}") will not have their
                   5736: distfiles mirrored.
                   5737:
1.107     rillig   5738: 17.6. The checksum phase
1.56      rillig   5739:
                   5740: After the distfile(s) are fetched, their checksum is generated and compared
                   5741: with the checksums stored in the distinfo file. If the checksums don't match,
                   5742: the build is aborted. This is to ensure the same distfile is used for building,
                   5743: and that the distfile wasn't changed, e.g. by some malign force, deliberately
                   5744: changed distfiles on the master distribution site or network lossage.
                   5745:
1.107     rillig   5746: 17.7. The extract phase
1.56      rillig   5747:
                   5748: When the distfiles are present on the local system, they need to be extracted,
1.69      rillig   5749: as they usually come in the form of some compressed archive format.
                   5750:
                   5751: By default, all DISTFILES are extracted. If you only need some of them, you can
                   5752: set the EXTRACT_ONLY variable to the list of those files.
                   5753:
1.93      rillig   5754: Extracting the files is usually done by a little program, mk/extract/extract,
1.69      rillig   5755: which already knows how to extract various archive formats, so most likely you
                   5756: will not need to change anything here. But if you need, the following variables
                   5757: may help you:
                   5758:
                   5759: EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}
                   5760:
                   5761:     Use these variables to override the default options for an extract command,
1.93      rillig   5762:     which are defined in mk/extract/extract.
1.56      rillig   5763:
1.69      rillig   5764: EXTRACT_USING
1.56      rillig   5765:
1.115     jmcneill 5766:     This variable can be set to bsdtar, gtar, nbtar (which is the default
                   5767:     value), pax, or an absolute pathname pointing to the command with which tar
                   5768:     archives should be extracted. It is preferred to choose bsdtar over gtar if
                   5769:     NetBSD's pax-as-tar is not good enough.
1.69      rillig   5770:
                   5771: If the extract program doesn't serve your needs, you can also override the
                   5772: EXTRACT_CMD variable, which holds the command used for extracting the files.
                   5773: This command is executed in the ${WRKSRC} directory. During execution of this
                   5774: command, the shell variable extract_file holds the absolute pathname of the
                   5775: file that is going to be extracted.
                   5776:
                   5777: And if that still does not suffice, you can override the do-extract target in
                   5778: the package Makefile.
1.56      rillig   5779:
1.107     rillig   5780: 17.8. The patch phase
1.56      rillig   5781:
                   5782: After extraction, all the patches named by the PATCHFILES, those present in the
                   5783: patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
                   5784: /usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz
                   5785: are uncompressed before they are applied, files ending in .orig or .rej are
                   5786: ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See
1.107     rillig   5787: Section 11.3, "patches/*" for more details.
1.56      rillig   5788:
                   5789: By default patch(1) is given special args to make it fail if the patches apply
                   5790: with some lines of fuzz. Please fix (regen) the patches so that they apply
                   5791: cleanly. The rationale behind this is that patches that don't apply cleanly may
                   5792: end up being applied in the wrong place, and cause severe harm there.
                   5793:
1.107     rillig   5794: 17.9. The tools phase
1.56      rillig   5795:
1.107     rillig   5796: This is covered in Chapter 18, Tools needed for building or running.
1.56      rillig   5797:
1.107     rillig   5798: 17.10. The wrapper phase
1.56      rillig   5799:
1.72      rillig   5800: This phase creates wrapper programs for the compilers and linkers. The
                   5801: following variables can be used to tweak the wrappers.
                   5802:
                   5803: ECHO_WRAPPER_MSG
                   5804:
                   5805:     The command used to print progress messages. Does nothing by default. Set
                   5806:     to ${ECHO} to see the progress messages.
                   5807:
                   5808: WRAPPER_DEBUG
                   5809:
                   5810:     This variable can be set to yes (default) or no, depending on whether you
                   5811:     want additional information in the wrapper log file.
                   5812:
                   5813: WRAPPER_UPDATE_CACHE
                   5814:
                   5815:     This variable can be set to yes or no, depending on whether the wrapper
                   5816:     should use its cache, which will improve the speed. The default value is
                   5817:     yes, but is forced to no if the platform does not support it.
                   5818:
                   5819: WRAPPER_REORDER_CMDS
                   5820:
                   5821:     A list of reordering commands. A reordering command has the form reorder:l:
                   5822:     lib1:lib2. It ensures that that -llib1 occurs before -llib2.
                   5823:
                   5824: WRAPPER_TRANSFORM_CMDS
                   5825:
                   5826:     A list of transformation commands. [TODO: investigate further]
1.56      rillig   5827:
1.107     rillig   5828: 17.11. The configure phase
1.56      rillig   5829:
                   5830: Most pieces of software need information on the header files, system calls, and
                   5831: library routines which are available on the platform they run on. The process
                   5832: of determining this information is known as configuration, and is usually
                   5833: automated. In most cases, a script is supplied with the distfiles, and its
                   5834: invocation results in generation of header files, Makefiles, etc.
                   5835:
                   5836: If the package contains a configure script, this can be invoked by setting
                   5837: HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you
                   5838: should set GNU_CONFIGURE to "yes" instead. What happens in the configure phase
                   5839: is roughly:
                   5840:
1.101     rillig   5841: .for d in ${CONFIGURE_DIRS}
                   5842:         cd ${WRKSRC} \
                   5843:         && cd ${d} \
                   5844:         && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
                   5845: .endfor
1.56      rillig   5846:
                   5847: CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In
                   5848: each of these directories, the configure script is run with the environment
                   5849: CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV,
                   5850: CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed
                   5851: by the package.
                   5852:
                   5853: If the program uses an Imakefile for configuration, the appropriate steps can
                   5854: be invoked by setting USE_IMAKE to "yes". (If you only want the package
                   5855: installed in ${X11PREFIX} but xmkmf not being run, set USE_X11BASE instead.)
1.97      wiz      5856: You can add variables to xmkmf's environment by adding them to the SCRIPTS_ENV
                   5857: variable.
                   5858:
1.112     rillig   5859: If the program uses cmake for configuration, the appropriate steps can be
                   5860: invoked by setting USE_CMAKE to "yes". You can add variables to cmake's
                   5861: environment by adding them to the CONFIGURE_ENV variable and arguments to cmake
                   5862: by adding them to the CMAKE_ARGS variable. The top directory argument is given
                   5863: by the CMAKE_ARG_PATH variable, that defaults to "." (relative to
                   5864: CONFIGURE_DIRS)
                   5865:
1.97      wiz      5866: If there is no configure step at all, set NO_CONFIGURE to "yes".
1.56      rillig   5867:
1.107     rillig   5868: 17.12. The build phase
1.56      rillig   5869:
                   5870: For building a package, a rough equivalent of the following code is executed.
                   5871:
1.101     rillig   5872: .for d in ${BUILD_DIRS}
                   5873:         cd ${WRKSRC} \
                   5874:         && cd ${d} \
                   5875:         && env ${MAKE_ENV} \
                   5876:             ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \
                   5877:                 -f ${MAKE_FILE} \
                   5878:                 ${BUILD_TARGET}
                   5879: .endfor
1.56      rillig   5880:
                   5881: BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of
                   5882: these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and
1.87      wiz      5883: arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE
1.56      rillig   5884: and BUILD_TARGET may all be changed by the package.
                   5885:
                   5886: The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake",
1.87      wiz      5887: "make" otherwise. The default value of MAKE_FILE is "Makefile", and
                   5888: BUILD_TARGET defaults to "all".
1.56      rillig   5889:
1.98      rillig   5890: If there is no build step at all, set NO_BUILD to "yes".
1.97      wiz      5891:
1.107     rillig   5892: 17.13. The test phase
1.56      rillig   5893:
                   5894: [TODO]
                   5895:
1.107     rillig   5896: 17.14. The install phase
1.56      rillig   5897:
                   5898: Once the build stage has completed, the final step is to install the software
1.68      rillig   5899: in public directories, so users can access the programs and files.
                   5900:
                   5901: In the install phase, a rough equivalent of the following code is executed.
                   5902: Additionally, before and after this code, much magic is performed to do
                   5903: consistency checks, registering the package, and so on.
                   5904:
1.101     rillig   5905: .for d in ${INSTALL_DIRS}
                   5906:         cd ${WRKSRC} \
                   5907:         && cd ${d} \
                   5908:         && env ${MAKE_ENV} \
                   5909:             ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \
                   5910:                 -f ${MAKE_FILE} \
                   5911:                 ${INSTALL_TARGET}
                   5912: .endfor
1.68      rillig   5913:
                   5914: The variable's meanings are analogous to the ones in the build phase.
                   5915: INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is "install" by default,
1.88      wiz      5916: plus "install.man" if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
                   5917: defined.
1.68      rillig   5918:
                   5919: In the install phase, the following variables are useful. They are all
                   5920: variations of the install(1) command that have the owner, group and permissions
                   5921: preset. INSTALL is the plain install command. The specialized variants,
                   5922: together with their intended use, are:
                   5923:
                   5924: INSTALL_PROGRAM_DIR
                   5925:
                   5926:     directories that contain binaries
                   5927:
                   5928: INSTALL_SCRIPT_DIR
                   5929:
                   5930:     directories that contain scripts
                   5931:
                   5932: INSTALL_LIB_DIR
                   5933:
                   5934:     directories that contain shared and static libraries
                   5935:
                   5936: INSTALL_DATA_DIR
                   5937:
                   5938:     directories that contain data files
                   5939:
                   5940: INSTALL_MAN_DIR
                   5941:
                   5942:     directories that contain man pages
                   5943:
                   5944: INSTALL_PROGRAM
                   5945:
                   5946:     binaries that can be stripped from debugging symbols
                   5947:
                   5948: INSTALL_SCRIPT
                   5949:
                   5950:     binaries that cannot be stripped
                   5951:
                   5952: INSTALL_GAME
                   5953:
                   5954:     game binaries
                   5955:
                   5956: INSTALL_LIB
                   5957:
                   5958:     shared and static libraries
                   5959:
                   5960: INSTALL_DATA
                   5961:
                   5962:     data files
                   5963:
                   5964: INSTALL_GAME_DATA
                   5965:
                   5966:     data files for games
                   5967:
                   5968: INSTALL_MAN
                   5969:
                   5970:     man pages
                   5971:
                   5972: Some other variables are:
                   5973:
                   5974: INSTALLATION_DIRS
                   5975:
                   5976:     A list of directories relative to PREFIX that are created by pkgsrc at the
1.99      wiz      5977:     beginning of the install phase. The package is supposed to create all
                   5978:     needed directories itself before installing files to it and list all other
                   5979:     directories here.
1.56      rillig   5980:
1.97      wiz      5981: In the rare cases that a package shouldn't install anything, set NO_INSTALL to
                   5982: "yes". This is mostly relevant for packages in the regress category.
                   5983:
1.107     rillig   5984: 17.15. The package phase
1.56      rillig   5985:
1.88      wiz      5986: Once the install stage has completed, a binary package of the installed files
                   5987: can be built. These binary packages can be used for quick installation without
                   5988: previous compilation, e.g. by the make bin-install or by using pkg_add.
                   5989:
                   5990: By default, the binary packages are created in ${PACKAGES}/All and symlinks are
                   5991: created in ${PACKAGES}/category, one for each category in the CATEGORIES
                   5992: variable. PACKAGES defaults to pkgsrc/packages.
                   5993:
1.107     rillig   5994: 17.16. Cleaning up
1.88      wiz      5995:
                   5996: Once you're finished with a package, you can clean the work directory by
                   5997: running make clean. If you want to clean the work directories of all
                   5998: dependencies too, use make clean-depends.
1.56      rillig   5999:
1.107     rillig   6000: 17.17. Other helpful targets
1.1       grant    6001:
                   6002: pre/post-*
1.20      ben      6003:
1.1       grant    6004:     For any of the main targets described in the previous section, two
                   6005:     auxiliary targets exist with "pre-" and "post-" used as a prefix for the
                   6006:     main target's name. These targets are invoked before and after the main
                   6007:     target is called, allowing extra configuration or installation steps be
                   6008:     performed from a package's Makefile, for example, which a program's
                   6009:     configure script or install target omitted.
1.20      ben      6010:
1.1       grant    6011: do-*
1.20      ben      6012:
1.1       grant    6013:     Should one of the main targets do the wrong thing, and should there be no
                   6014:     variable to fix this, you can redefine it with the do-* target. (Note that
                   6015:     redefining the target itself instead of the do-* target is a bad idea, as
                   6016:     the pre-* and post-* targets won't be called anymore, etc.) You will not
                   6017:     usually need to do this.
1.20      ben      6018:
1.1       grant    6019: reinstall
1.20      ben      6020:
1.1       grant    6021:     If you did a make install and you noticed some file was not installed
                   6022:     properly, you can repeat the installation with this target, which will
                   6023:     ignore the "already installed" flag.
1.20      ben      6024:
1.88      wiz      6025:     This is the default value of DEPENDS_TARGET except in the case of make
                   6026:     update and make package, where the defaults are "package" and "update",
                   6027:     respectively.
                   6028:
1.1       grant    6029: deinstall
1.20      ben      6030:
1.1       grant    6031:     This target does a pkg_delete(1) in the current directory, effectively
                   6032:     de-installing the package. The following variables can be used to tune the
                   6033:     behaviour:
1.20      ben      6034:
1.1       grant    6035:     PKG_VERBOSE
1.20      ben      6036:
1.1       grant    6037:         Add a "-v" to the pkg_delete(1) command.
1.20      ben      6038:
1.1       grant    6039:     DEINSTALLDEPENDS
1.20      ben      6040:
1.1       grant    6041:         Remove all packages that require (depend on) the given package. This
                   6042:         can be used to remove any packages that may have been pulled in by a
                   6043:         given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
                   6044:         pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding
                   6045:         "-R" to the pkg_delete(1) command line.
1.20      ben      6046:
1.88      wiz      6047: bin-install
                   6048:
                   6049:     Install a binary package from local disk and via FTP from a list of sites
                   6050:     (see the BINPKG_SITES variable), and do a make package if no binary package
                   6051:     is available anywhere. The arguments given to pkg_add can be set via
                   6052:     BIN_INSTALL_FLAGS e.g., to do verbose operation, etc.
                   6053:
1.1       grant    6054: update
1.20      ben      6055:
1.1       grant    6056:     This target causes the current package to be updated to the latest version.
                   6057:     The package and all depending packages first get de-installed, then current
                   6058:     versions of the corresponding packages get compiled and installed. This is
                   6059:     similar to manually noting which packages are currently installed, then
                   6060:     performing a series of make deinstall and make install (or whatever
                   6061:     UPDATE_TARGET is set to) for these packages.
1.20      ben      6062:
1.1       grant    6063:     You can use the "update" target to resume package updating in case a
                   6064:     previous make update was interrupted for some reason. However, in this
                   6065:     case, make sure you don't call make clean or otherwise remove the list of
1.47      reed     6066:     dependent packages in WRKDIR. Otherwise, you lose the ability to
1.1       grant    6067:     automatically update the current package along with the dependent packages
                   6068:     you have installed.
1.20      ben      6069:
1.1       grant    6070:     Resuming an interrupted make update will only work as long as the package
                   6071:     tree remains unchanged. If the source code for one of the packages to be
                   6072:     updated has been changed, resuming make update will most certainly fail!
1.20      ben      6073:
1.105     rillig   6074:     The following variables can be used either on the command line or in
1.1       grant    6075:     mk.conf to alter the behaviour of make update:
1.20      ben      6076:
1.1       grant    6077:     UPDATE_TARGET
1.20      ben      6078:
1.1       grant    6079:         Install target to recursively use for the updated package and the
                   6080:         dependent packages. Defaults to DEPENDS_TARGET if set, "install"
1.88      wiz      6081:         otherwise for make update. Other good targets are "package" or
                   6082:         "bin-install". Do not set this to "update" or you will get stuck in an
                   6083:         endless loop!
1.20      ben      6084:
1.1       grant    6085:     NOCLEAN
1.20      ben      6086:
1.1       grant    6087:         Don't clean up after updating. Useful if you want to leave the work
                   6088:         sources of the updated packages around for inspection or other
                   6089:         purposes. Be sure you eventually clean up the source tree (see the
                   6090:         "clean-update" target below) or you may run into troubles with old
                   6091:         source code still lying around on your next make or make update.
1.20      ben      6092:
1.1       grant    6093:     REINSTALL
1.20      ben      6094:
1.1       grant    6095:         Deinstall each package before installing (making DEPENDS_TARGET). This
                   6096:         may be necessary if the "clean-update" target (see below) was called
                   6097:         after interrupting a running make update.
1.20      ben      6098:
1.1       grant    6099:     DEPENDS_TARGET
1.20      ben      6100:
1.1       grant    6101:         Allows you to disable recursion and hardcode the target for packages.
                   6102:         The default is "update" for the update target, facilitating a recursive
                   6103:         update of prerequisite packages. Only set DEPENDS_TARGET if you want to
                   6104:         disable recursive updates. Use UPDATE_TARGET instead to just set a
                   6105:         specific target for each package to be installed during make update
                   6106:         (see above).
1.20      ben      6107:
1.1       grant    6108: clean-update
1.20      ben      6109:
1.1       grant    6110:     Clean the source tree for all packages that would get updated if make
                   6111:     update was called from the current directory. This target should not be
                   6112:     used if the current package (or any of its depending packages) have already
                   6113:     been de-installed (e.g., after calling make update) or you may lose some
1.20      ben      6114:     packages you intended to update. As a rule of thumb: only use this target
1.1       grant    6115:     before the first time you run make update and only if you have a dirty
                   6116:     package tree (e.g., if you used NOCLEAN).
1.20      ben      6117:
1.47      reed     6118:     If you are unsure about whether your tree is clean, you can either perform
                   6119:     a make clean at the top of the tree, or use the following sequence of
1.1       grant    6120:     commands from the directory of the package you want to update (before
                   6121:     running make update for the first time, otherwise you lose all the packages
                   6122:     you wanted to update!):
1.20      ben      6123:
1.1       grant    6124:     # make clean-update
                   6125:     # make clean CLEANDEPENDS=YES
                   6126:     # make update
1.20      ben      6127:
1.87      wiz      6128:
1.105     rillig   6129:     The following variables can be used either on the command line or in
1.1       grant    6130:     mk.conf to alter the behaviour of make clean-update:
1.20      ben      6131:
1.1       grant    6132:     CLEAR_DIRLIST
1.20      ben      6133:
1.1       grant    6134:         After make clean, do not reconstruct the list of directories to update
                   6135:         for this package. Only use this if make update successfully installed
                   6136:         all packages you wanted to update. Normally, this is done automatically
                   6137:         on make update, but may have been suppressed by the NOCLEAN variable
                   6138:         (see above).
1.20      ben      6139:
1.88      wiz      6140: replace
                   6141:
                   6142:     Update the installation of the current package. This differs from update in
                   6143:     that it does not replace dependent packages. You will need to install
1.93      rillig   6144:     pkgtools/pkg_tarup for this target to work.
1.88      wiz      6145:
                   6146:     Be careful when using this target! There are no guarantees that dependent
                   6147:     packages will still work, in particular they will most certainly break if
                   6148:     you make replace a library package whose shared library major version
                   6149:     changed between your installed version and the new one. For this reason,
                   6150:     this target is not officially supported and only recommended for advanced
                   6151:     users.
                   6152:
1.1       grant    6153: info
1.20      ben      6154:
1.1       grant    6155:     This target invokes pkg_info(1) for the current package. You can use this
                   6156:     to check which version of a package is installed.
1.20      ben      6157:
1.88      wiz      6158: index
                   6159:
                   6160:     This is a top-level command, i.e. it should be used in the pkgsrc
                   6161:     directory. It creates a database of all packages in the local pkgsrc tree,
                   6162:     including dependencies, comment, maintainer, and some other useful
                   6163:     information. Individual entries are created by running make describe in the
                   6164:     packages' directories. This index file is saved as pkgsrc/INDEX. It can be
                   6165:     displayed in verbose format by running make print-index. You can search in
                   6166:     it with make search key=something. You can extract a list of all packages
                   6167:     that depend on a particular one by running make show-deps PKG=somepackage.
                   6168:
                   6169:     Running this command takes a very long time, some hours even on fast
                   6170:     machines!
                   6171:
1.1       grant    6172: readme
1.20      ben      6173:
1.1       grant    6174:     This target generates a README.html file, which can be viewed using a
1.83      wiz      6175:     browser such as www/firefox or www/links. The generated files contain
1.1       grant    6176:     references to any packages which are in the PACKAGES directory on the local
                   6177:     host. The generated files can be made to refer to URLs based on
                   6178:     FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate
                   6179:     README.html files which pointed to binary packages on the local machine, in
                   6180:     the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
                   6181:     FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
                   6182:     subdirectories will be searched for all the binary packages.
1.20      ben      6183:
1.88      wiz      6184:     The target can be run at the toplevel or in category directories, in which
                   6185:     case it descends recursively.
                   6186:
1.1       grant    6187: readme-all
1.20      ben      6188:
1.88      wiz      6189:     This is a top-level command, run it in pkgsrc. Use this target to create a
                   6190:     file README-all.html which contains a list of all packages currently
                   6191:     available in the NetBSD Packages Collection, together with the category
                   6192:     they belong to and a short description. This file is compiled from the
                   6193:     pkgsrc/*/README.html files, so be sure to run this after a make readme.
1.20      ben      6194:
1.1       grant    6195: cdrom-readme
1.20      ben      6196:
1.1       grant    6197:     This is very much the same as the "readme" target (see above), but is to be
                   6198:     used when generating a pkgsrc tree to be written to a CD-ROM. This target
                   6199:     also produces README.html files, and can be made to refer to URLs based on
                   6200:     CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
1.20      ben      6201:
1.1       grant    6202: show-distfiles
1.20      ben      6203:
1.1       grant    6204:     This target shows which distfiles and patchfiles are needed to build the
1.87      wiz      6205:     package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not
                   6206:     patches/*).
1.20      ben      6207:
1.1       grant    6208: show-downlevel
1.20      ben      6209:
1.1       grant    6210:     This target shows nothing if the package is not installed. If a version of
                   6211:     this package is installed, but is not the version provided in this version
                   6212:     of pkgsrc, then a warning message is displayed. This target can be used to
                   6213:     show which of your installed packages are downlevel, and so the old
                   6214:     versions can be deleted, and the current ones added.
1.20      ben      6215:
1.1       grant    6216: show-pkgsrc-dir
1.20      ben      6217:
1.1       grant    6218:     This target shows the directory in the pkgsrc hierarchy from which the
                   6219:     package can be built and installed. This may not be the same directory as
                   6220:     the one from which the package was installed. This target is intended to be
                   6221:     used by people who may wish to upgrade many packages on a single host, and
                   6222:     can be invoked from the top-level pkgsrc Makefile by using the
                   6223:     "show-host-specific-pkgs" target.
1.20      ben      6224:
1.1       grant    6225: show-installed-depends
1.20      ben      6226:
1.1       grant    6227:     This target shows which installed packages match the current package's
                   6228:     DEPENDS. Useful if out of date dependencies are causing build problems.
1.20      ben      6229:
1.1       grant    6230: check-shlibs
1.20      ben      6231:
1.1       grant    6232:     After a package is installed, check all its binaries and (on ELF platforms)
                   6233:     shared libraries to see if they find the shared libs they need. Run by
1.105     rillig   6234:     default if PKG_DEVELOPER is set in mk.conf.
1.20      ben      6235:
1.1       grant    6236: print-PLIST
1.20      ben      6237:
1.1       grant    6238:     After a "make install" from a new or upgraded pkg, this prints out an
                   6239:     attempt to generate a new PLIST from a find -newer work/.extract_done. An
                   6240:     attempt is made to care for shared libs etc., but it is strongly
                   6241:     recommended to review the result before putting it into PLIST. On upgrades,
                   6242:     it's useful to diff the output of this command against an already existing
                   6243:     PLIST file.
1.20      ben      6244:
1.1       grant    6245:     If the package installs files via tar(1) or other methods that don't update
                   6246:     file access times, be sure to add these files manually to your PLIST, as
                   6247:     the "find -newer" command used by this target won't catch them!
1.20      ben      6248:
1.107     rillig   6249:     See Section 13.3, "Tweaking output of make print-PLIST" for more
1.38      dillo    6250:     information on this target.
1.20      ben      6251:
1.1       grant    6252: bulk-package
1.20      ben      6253:
1.1       grant    6254:     Used to do bulk builds. If an appropriate binary package already exists, no
                   6255:     action is taken. If not, this target will compile, install and package it
1.107     rillig   6256:     (and its depends, if PKG_DEPENDS is set properly. See Section 7.3.1,
1.47      reed     6257:     "Configuration"). After creating the binary package, the sources, the
                   6258:     just-installed package and its required packages are removed, preserving
1.1       grant    6259:     free disk space.
1.20      ben      6260:
1.1       grant    6261:     Beware that this target may deinstall all packages installed on a system!
1.20      ben      6262:
1.1       grant    6263: bulk-install
1.20      ben      6264:
1.47      reed     6265:     Used during bulk-installs to install required packages. If an up-to-date
1.20      ben      6266:     binary package is available, it will be installed via pkg_add(1). If not,
1.47      reed     6267:     make bulk-package will be executed, but the installed binary won't be
1.1       grant    6268:     removed.
1.20      ben      6269:
1.47      reed     6270:     A binary package is considered "up-to-date" to be installed via pkg_add(1)
1.1       grant    6271:     if:
1.20      ben      6272:
1.1       grant    6273:       * None of the package's files (Makefile, ...) were modified since it was
                   6274:         built.
1.20      ben      6275:
1.1       grant    6276:       * None of the package's required (binary) packages were modified since it
                   6277:         was built.
1.20      ben      6278:
1.1       grant    6279:     Beware that this target may deinstall all packages installed on a system!
1.20      ben      6280:
1.107     rillig   6281: Chapter 18. Tools needed for building or running
1.68      rillig   6282:
                   6283: Table of Contents
                   6284:
1.107     rillig   6285: 18.1. Tools for pkgsrc builds
                   6286: 18.2. Tools needed by packages
                   6287: 18.3. Tools provided by platforms
                   6288: 18.4. Questions regarding the tools
1.68      rillig   6289:
                   6290: The USE_TOOLS definition is used both internally by pkgsrc and also for
                   6291: individual packages to define what commands are needed for building a package
                   6292: (like BUILD_DEPENDS) or for later run-time of an installed packaged (such as
                   6293: DEPENDS). If the native system provides an adequate tool, then in many cases, a
                   6294: pkgsrc package will not be used.
                   6295:
                   6296: When building a package, the replacement tools are made available in a
                   6297: directory (as symlinks or wrapper scripts) that is early in the executable
                   6298: search path. Just like the buildlink system, this helps with consistent builds.
                   6299:
                   6300: A tool may be needed to help build a specific package. For example, perl, GNU
                   6301: make (gmake) or yacc may be needed.
                   6302:
                   6303: Also a tool may be needed, for example, because the native system's supplied
                   6304: tool may be inefficient for building a package with pkgsrc. For example, a
                   6305: package may need GNU awk, bison (instead of yacc) or a better sed.
                   6306:
                   6307: The tools used by a package can be listed by running make show-tools.
                   6308:
1.107     rillig   6309: 18.1. Tools for pkgsrc builds
1.68      rillig   6310:
                   6311: The default set of tools used by pkgsrc is defined in bsd.pkg.mk. This includes
                   6312: standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be
                   6313: seen by running: make show-var VARNAME=USE_TOOLS.
                   6314:
                   6315: If a package needs a specific program to build then the USE_TOOLS variable can
                   6316: be used to define the tools needed.
                   6317:
1.107     rillig   6318: 18.2. Tools needed by packages
1.68      rillig   6319:
                   6320: In the following examples, the :pkgsrc means to use the pkgsrc version and not
                   6321: the native version for a build dependency. And the :run means that it is used
                   6322: for a run-time dependencies also (and becomes a DEPENDS). The default is a
                   6323: build dependency which can be set with :build. (So in this example, it is the
                   6324: same as gmake:build and pkg-config:build.)
                   6325:
                   6326: USE_TOOLS+=     mktemp:pkgsrc
                   6327: USE_TOOLS+=     gmake perl:run pkg-config
                   6328:
                   6329: When using the tools framework, a TOOLS_PATH.foo variable is defined which
                   6330: contains the full path to the appropriate tool. For example, TOOLS_PATH.bash
                   6331: could be "/bin/bash" on Linux systems.
                   6332:
                   6333: If you always need a pkgsrc version of the tool at run-time, then just use
                   6334: DEPENDS instead.
                   6335:
1.107     rillig   6336: 18.3. Tools provided by platforms
1.68      rillig   6337:
                   6338: When improving or porting pkgsrc to a new platform, have a look at (or create)
                   6339: the corresponding platform specific make file fragment under pkgsrc/mk/tools/
                   6340: tools.${OPSYS}.mk which defines the name of the common tools. For example:
                   6341:
                   6342: .if exists(/usr/bin/bzcat)
                   6343: TOOLS_PLATFORM.bzcat?=          /usr/bin/bzcat
                   6344: .elif exists(/usr/bin/bzip2)
                   6345: TOOLS_PLATFORM.bzcat?=          /usr/bin/bzip2 -cd
                   6346: .endif
                   6347:
                   6348: TOOLS_PLATFORM.true?=           true                    # shell builtin
                   6349:
1.107     rillig   6350: 18.4. Questions regarding the tools
1.98      rillig   6351:
1.107     rillig   6352: 18.4.1. How do I add a new tool?
                   6353: 18.4.2. How do I get a list of all available tools?
                   6354: 18.4.3. How can I get a list of all the tools that a package is using while
1.98      rillig   6355:     being built? I want to know whether it uses sed or not.
                   6356:
1.107     rillig   6357: 18.4.1. How do I add a new tool?
1.98      rillig   6358:
                   6359:         TODO
                   6360:
1.107     rillig   6361: 18.4.2. How do I get a list of all available tools?
1.98      rillig   6362:
                   6363:         TODO
                   6364:
1.107     rillig   6365: 18.4.3. How can I get a list of all the tools that a package is using while
1.98      rillig   6366:         being built? I want to know whether it uses sed or not.
                   6367:
                   6368:         Currently, you can't. (TODO: But I want to be able to do it.)
                   6369:
1.107     rillig   6370: Chapter 19. Making your package work
1.1       grant    6371:
                   6372: Table of Contents
                   6373:
1.107     rillig   6374: 19.1. General operation
1.20      ben      6375:
1.107     rillig   6376:     19.1.1. Portability of packages
1.130     wiz      6377:     19.1.2. How to pull in user-settable variables from mk.conf
1.107     rillig   6378:     19.1.3. User interaction
                   6379:     19.1.4. Handling licenses
                   6380:     19.1.5. Restricted packages
                   6381:     19.1.6. Handling dependencies
                   6382:     19.1.7. Handling conflicts with other packages
                   6383:     19.1.8. Packages that cannot or should not be built
                   6384:     19.1.9. Packages which should not be deleted, once installed
                   6385:     19.1.10. Handling packages with security problems
                   6386:     19.1.11. How to handle incrementing versions when fixing an existing
1.31      wiz      6387:         package
1.107     rillig   6388:     19.1.12. Substituting variable text in the package files (the SUBST
1.79      rillig   6389:         framework)
1.77      rillig   6390:
1.107     rillig   6391: 19.2. Fixing problems in the fetch phase
1.77      rillig   6392:
1.107     rillig   6393:     19.2.1. Packages whose distfiles aren't available for plain downloading
                   6394:     19.2.2. How to handle modified distfiles with the 'old' name
1.77      rillig   6395:
1.107     rillig   6396: 19.3. Fixing problems in the configure phase
1.77      rillig   6397:
1.107     rillig   6398:     19.3.1. Shared libraries - libtool
                   6399:     19.3.2. Using libtool on GNU packages that already support libtool
                   6400:     19.3.3. GNU Autoconf/Automake
                   6401:
                   6402: 19.4. Programming languages
                   6403:
                   6404:     19.4.1. C, C++, and Fortran
                   6405:     19.4.2. Java
                   6406:     19.4.3. Packages containing perl scripts
                   6407:     19.4.4. Other programming languages
                   6408:
                   6409: 19.5. Fixing problems in the build phase
                   6410:
                   6411:     19.5.1. Compiling C and C++ code conditionally
                   6412:     19.5.2. How to handle compiler bugs
1.130     wiz      6413:     19.5.3. Undefined reference to "..."
1.107     rillig   6414:     19.5.4. Running out of memory
                   6415:
                   6416: 19.6. Fixing problems in the install phase
                   6417:
                   6418:     19.6.1. Creating needed directories
                   6419:     19.6.2. Where to install documentation
                   6420:     19.6.3. Installing highscore files
                   6421:     19.6.4. Adding DESTDIR support to packages
                   6422:     19.6.5. Packages with hardcoded paths to other interpreters
                   6423:     19.6.6. Packages installing perl modules
                   6424:     19.6.7. Packages installing info files
                   6425:     19.6.8. Packages installing man pages
1.108     rillig   6426:     19.6.9. Packages installing GConf data files
1.120     mishka   6427:     19.6.10. Packages installing scrollkeeper/rarian data files
1.107     rillig   6428:     19.6.11. Packages installing X11 fonts
                   6429:     19.6.12. Packages installing GTK2 modules
                   6430:     19.6.13. Packages installing SGML or XML data
                   6431:     19.6.14. Packages installing extensions to the MIME database
                   6432:     19.6.15. Packages using intltool
                   6433:     19.6.16. Packages installing startup scripts
                   6434:     19.6.17. Packages installing TeX modules
                   6435:     19.6.18. Packages supporting running binaries in emulation
                   6436:     19.6.19. Packages installing hicolor theme icons
                   6437:     19.6.20. Packages installing desktop files
1.87      wiz      6438:
1.107     rillig   6439: 19.7. Marking packages as having problems
1.25      rillig   6440:
1.107     rillig   6441: 19.1. General operation
1.78      rillig   6442:
1.107     rillig   6443: 19.1.1. Portability of packages
1.78      rillig   6444:
                   6445: One appealing feature of pkgsrc is that it runs on many different platforms. As
                   6446: a result, it is important to ensure, where possible, that packages in pkgsrc
                   6447: are portable. This chapter mentions some particular details you should pay
                   6448: attention to while working on pkgsrc.
                   6449:
1.107     rillig   6450: 19.1.2. How to pull in user-settable variables from mk.conf
1.78      rillig   6451:
                   6452: The pkgsrc user can configure pkgsrc by overriding several variables in the
1.105     rillig   6453: file pointed to by MAKECONF, which is mk.conf by default. When you want to use
                   6454: those variables in the preprocessor directives of make(1) (for example .if or
                   6455: .for), you need to include the file ../../mk/bsd.prefs.mk before, which in turn
                   6456: loads the user preferences.
1.78      rillig   6457:
                   6458: But note that some variables may not be completely defined after ../../mk/
                   6459: bsd.prefs.mk has been included, as they may contain references to variables
                   6460: that are not yet defined. In shell commands this is no problem, since variables
                   6461: are actually macros, which are only expanded when they are used. But in the
                   6462: preprocessor directives mentioned above and in dependency lines (of the form
                   6463: target: dependencies) the variables are expanded at load time.
                   6464:
                   6465: Note
                   6466:
                   6467: Currently there is no exhaustive list of all variables that tells you whether
                   6468: they can be used at load time or only at run time, but it is in preparation.
                   6469:
1.107     rillig   6470: 19.1.3. User interaction
1.78      rillig   6471:
                   6472: Occasionally, packages require interaction from the user, and this can be in a
                   6473: number of ways:
                   6474:
1.79      rillig   6475:   * When fetching the distfiles, some packages require user interaction such as
                   6476:     entering username/password or accepting a license on a web page.
                   6477:
1.78      rillig   6478:   * When extracting the distfiles, some packages may ask for passwords.
1.20      ben      6479:
1.78      rillig   6480:   * help to configure the package before it is built
                   6481:
                   6482:   * help during the build process
                   6483:
                   6484:   * help during the installation of a package
1.1       grant    6485:
1.78      rillig   6486: The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of
                   6487: an interactive stage which will be needed, and this should be set in the
                   6488: package's Makefile, e.g.:
                   6489:
1.101     rillig   6490: INTERACTIVE_STAGE=      build
1.87      wiz      6491:
1.78      rillig   6492:
                   6493: Multiple interactive stages can be specified:
                   6494:
1.101     rillig   6495: INTERACTIVE_STAGE=      configure install
1.87      wiz      6496:
1.1       grant    6497:
1.88      wiz      6498: The user can then decide to skip this package by setting the BATCH variable.
                   6499:
1.107     rillig   6500: 19.1.4. Handling licenses
1.1       grant    6501:
1.99      wiz      6502: Authors of software can choose the licence under which software can be copied.
                   6503: This is due to copyright law, and reasons for license choices are outside the
                   6504: scope of pkgsrc. The pkgsrc system recognizes that there are a number of
                   6505: licenses which some users may find objectionable or difficult or impossible to
                   6506: comply with. The Free Software Foundation has declared some licenses "Free",
                   6507: and the Open Source Initiative has a definition of "Open Source". The pkgsrc
                   6508: system, as a policy choice, does not label packages which have licenses that
                   6509: are Free or Open Source. However, packages without a license meeting either of
                   6510: those tests are labeled with a license tag denoting the license. Note that a
                   6511: package with no license to copy trivially does not meet either the Free or Open
                   6512: Source test.
                   6513:
                   6514: For packages which are not Free or Open Source, pkgsrc will not build the
                   6515: package unless the user has indicated to pkgsrc that packages with that
                   6516: particular license may be built. Note that this documentation avoids the term
                   6517: "accepted the license". The pkgsrc system is merely providing a mechanism to
1.100     rillig   6518: avoid accidentally building a package with a non-free license; judgement and
1.99      wiz      6519: responsibility remain with the user. (Installation of binary packages are not
                   6520: currently subject to this mechanism; this is a bug.)
                   6521:
                   6522: One might want to only install packages with a BSD license, or the GPL, and not
1.122     jnemeth  6523: the other. The free licenses are added to the default ACCEPTABLE_LICENSES
                   6524: variable. The user can override the default by setting the ACCEPTABLE_LICENSES
                   6525: variable with "=" instead of "+=". The licenses accepted by default are:
                   6526:
                   6527:     public-domain
                   6528:     gnu-gpl-v2 gnu-lgpl-v2
                   6529:     gnu-gpl-v3 gnu-lgpl-v3
                   6530:     original-bsd modified-bsd
                   6531:     x11
                   6532:     apache-2.0
                   6533:     cddl-1.0
                   6534:     open-font-license
                   6535:
1.1       grant    6536:
1.78      rillig   6537: The license tag mechanism is intended to address copyright-related issues
                   6538: surrounding building, installing and using a package, and not to address
1.122     jnemeth  6539: redistribution issues (see RESTRICTED and NO_SRC_ON_FTP, etc.). Packages with
                   6540: redistribution restrictions should set these tags.
1.20      ben      6541:
1.99      wiz      6542: Denoting that a package may be copied according to a particular license is done
                   6543: by placing the license in pkgsrc/licenses and setting the LICENSE variable to a
                   6544: string identifying the license, e.g. in graphics/xv:
1.1       grant    6545:
1.101     rillig   6546: LICENSE=        xv-license
1.87      wiz      6547:
1.1       grant    6548:
1.78      rillig   6549: When trying to build, the user will get a notice that the package is covered by
1.99      wiz      6550: a license which has not been placed in the ACCEPTABLE_LICENSES variable:
1.1       grant    6551:
1.101     rillig   6552: % make
                   6553: ===> xv-3.10anb9 has an unacceptable license: xv-license.
                   6554: ===>     To view the license, enter "/usr/bin/make show-license".
                   6555: ===>     To indicate acceptance, add this line to your /etc/mk.conf:
                   6556: ===>     ACCEPTABLE_LICENSES+=xv-license
                   6557: *** Error code 1
1.87      wiz      6558:
1.78      rillig   6559:
1.99      wiz      6560: The license can be viewed with make show-license, and if the user so chooses,
1.105     rillig   6561: the line printed above can be added to mk.conf to convey to pkgsrc that it
1.99      wiz      6562: should not in the future fail because of that license:
1.78      rillig   6563:
1.101     rillig   6564: ACCEPTABLE_LICENSES+=xv-license
1.87      wiz      6565:
1.1       grant    6566:
1.78      rillig   6567: When adding a package with a new license, the license text should be added to
                   6568: pkgsrc/licenses for displaying. A list of known licenses can be seen in this
1.91      rillig   6569: directory.
1.31      wiz      6570:
1.99      wiz      6571: When the license changes (in a way other than formatting), please make sure
                   6572: that the new license has a different name (e.g., append the version number if
                   6573: it exists, or the date). Just because a user told pkgsrc to build programs
                   6574: under a previous version of a license does not mean that pkgsrc should build
1.100     rillig   6575: programs under the new licenses. The higher-level point is that pkgsrc does not
1.99      wiz      6576: evaluate licenses for reasonableness; the only test is a mechanistic test of
                   6577: whether a particular text has been approved by either of two bodies.
                   6578:
1.78      rillig   6579: The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar language
                   6580: is deprecated because it does not crisply refer to a particular license text.
1.99      wiz      6581: Another problem with such usage is that it does not enable a user to tell
                   6582: pkgsrc to proceed for a single package without also telling pkgsrc to proceed
                   6583: for all packages with that tag.
1.31      wiz      6584:
1.107     rillig   6585: 19.1.5. Restricted packages
1.1       grant    6586:
1.99      wiz      6587: Some licenses restrict how software may be re-distributed. Because a license
                   6588: tag is required unless the package is Free or Open Source, all packages with
                   6589: restrictions should have license tags. By declaring the restrictions, package
                   6590: tools can automatically refrain from e.g. placing binary packages on FTP sites.
                   6591:
                   6592: There are four restrictions that may be encoded, which are the cross product of
                   6593: sources (distfiles) and binaries not being placed on FTP sites and CD-ROMs.
                   6594: Because this is rarely the exact language in any license, and because non-Free
                   6595: licenses tend to be different from each other, pkgsrc adopts a definition of
                   6596: FTP and CD-ROM. Pkgsrc uses "FTP" to mean that the source or binary file should
                   6597: not be made available over the Internet at no charge. Pkgsrc uses "CD-ROM" to
                   6598: mean that the source or binary may not be made available on some kind of media,
                   6599: together with other source and binary packages, and which is sold for a
                   6600: distribution charge.
                   6601:
                   6602: In order to encode these restrictions, the package system defines five make
                   6603: variables that can be set to note these restrictions:
1.1       grant    6604:
                   6605:   * RESTRICTED
1.20      ben      6606:
1.1       grant    6607:     This variable should be set whenever a restriction exists (regardless of
                   6608:     its kind). Set this variable to a string containing the reason for the
1.99      wiz      6609:     restriction. It should be understood that those wanting to understand the
                   6610:     restriction will have to read the license, and perhaps seek advice of
                   6611:     counsel.
1.20      ben      6612:
1.1       grant    6613:   * NO_BIN_ON_CDROM
1.20      ben      6614:
1.99      wiz      6615:     Binaries may not be placed on CD-ROM containing other binary packages, for
                   6616:     which a distribution charge may be made. In this case, set this variable to
                   6617:     ${RESTRICTED}.
1.20      ben      6618:
1.1       grant    6619:   * NO_BIN_ON_FTP
1.20      ben      6620:
1.99      wiz      6621:     Binaries may not made available on the Internet without charge. In this
                   6622:     case, set this variable to ${RESTRICTED}. If this variable is set, binary
                   6623:     packages will not be included on ftp.NetBSD.org.
1.20      ben      6624:
1.1       grant    6625:   * NO_SRC_ON_CDROM
1.20      ben      6626:
1.99      wiz      6627:     Distfiles may not be placed on CD-ROM, together with other distfiles, for
                   6628:     which a fee may be charged. In this case, set this variable to $
                   6629:     {RESTRICTED}.
1.20      ben      6630:
1.1       grant    6631:   * NO_SRC_ON_FTP
1.20      ben      6632:
1.99      wiz      6633:     Distfiles may not made available via FTP at no charge. In this case, set
                   6634:     this variable to ${RESTRICTED}. If this variable is set, the distfile(s)
                   6635:     will not be mirrored on ftp.NetBSD.org.
1.20      ben      6636:
1.107     rillig   6637: 19.1.6. Handling dependencies
1.1       grant    6638:
                   6639: Your package may depend on some other package being present - and there are
                   6640: various ways of expressing this dependency. pkgsrc supports the BUILD_DEPENDS
1.47      reed     6641: and DEPENDS definitions, the USE_TOOLS definition, as well as dependencies via
                   6642: buildlink3.mk, which is the preferred way to handle dependencies, and which
1.107     rillig   6643: uses the variables named above. See Chapter 14, Buildlink methodology for more
1.47      reed     6644: information.
1.1       grant    6645:
                   6646: The basic difference between the two variables is as follows: The DEPENDS
                   6647: definition registers that pre-requisite in the binary package so it will be
                   6648: pulled in when the binary package is later installed, whilst the BUILD_DEPENDS
                   6649: definition does not, marking a dependency that is only needed for building the
                   6650: package.
                   6651:
                   6652: This means that if you only need a package present whilst you are building, it
                   6653: should be noted as a BUILD_DEPENDS.
                   6654:
                   6655: The format for a BUILD_DEPENDS and a DEPENDS definition is:
                   6656:
1.101     rillig   6657: <pre-req-package-name>:../../<category>/<pre-req-package>
1.87      wiz      6658:
1.1       grant    6659:
                   6660: Please note that the "pre-req-package-name" may include any of the wildcard
1.18      xtraeme  6661: version numbers recognized by pkg_info(1).
1.1       grant    6662:
                   6663:  1. If your package needs another package's binaries or libraries to build or
                   6664:     run, and if that package has a buildlink3.mk file available, use it:
1.20      ben      6665:
1.101     rillig   6666:     .include "../../graphics/jpeg/buildlink3.mk"
1.87      wiz      6667:
1.20      ben      6668:
1.1       grant    6669:  2. If your package needs to use another package to build itself and there is
                   6670:     no buildlink3.mk file available, use the BUILD_DEPENDS definition:
1.20      ben      6671:
1.101     rillig   6672:     BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
1.87      wiz      6673:
1.20      ben      6674:
1.1       grant    6675:  3. If your package needs a library with which to link and again there is no
                   6676:     buildlink3.mk file available, this is specified using the DEPENDS
1.71      wiz      6677:     definition. For example:
1.20      ben      6678:
1.101     rillig   6679:     DEPENDS+=       xpm-3.4j:../../graphics/xpm
1.87      wiz      6680:
1.20      ben      6681:
1.110     rillig   6682:     You can also use wildcards in package dependencies:
1.20      ben      6683:
1.101     rillig   6684:     DEPENDS+=       xpm-[0-9]*:../../graphics/xpm
1.87      wiz      6685:
1.20      ben      6686:
1.1       grant    6687:     Note that such wildcard dependencies are retained when creating binary
                   6688:     packages. The dependency is checked when installing the binary package and
                   6689:     any package which matches the pattern will be used. Wildcard dependencies
                   6690:     should be used with care.
1.20      ben      6691:
1.1       grant    6692:     The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
                   6693:     matches such as "tk-postgresql" matching a "tk-*" DEPENDS.
1.20      ben      6694:
1.1       grant    6695:     Wildcards can also be used to specify that a package will only build
                   6696:     against a certain minimum version of a pre-requisite:
1.20      ben      6697:
1.101     rillig   6698:     DEPENDS+=       tiff>=3.5.4:../../graphics/tiff
1.87      wiz      6699:
1.20      ben      6700:
1.1       grant    6701:     This means that the package will build against version 3.5.4 of the tiff
                   6702:     library or newer. Such a dependency may be warranted if, for example, the
                   6703:     API of the library has changed with version 3.5.4 and a package would not
                   6704:     compile against an earlier version of tiff.
1.20      ben      6705:
1.1       grant    6706:     Please note that such dependencies should only be updated if a package
                   6707:     requires a newer pre-requisite, but not to denote recommendations such as
1.72      rillig   6708:     ABI changes that do not prevent a package from building correctly. Such
                   6709:     recommendations can be expressed using ABI_DEPENDS:
1.20      ben      6710:
1.101     rillig   6711:     ABI_DEPENDS+=   tiff>=3.6.1:../../graphics/tiff
1.87      wiz      6712:
1.20      ben      6713:
1.1       grant    6714:     In addition to the above DEPENDS line, this denotes that while a package
                   6715:     will build against tiff>=3.5.4, at least version 3.6.1 is recommended.
1.72      rillig   6716:     ABI_DEPENDS entries will be turned into dependencies unless explicitly
1.36      wiz      6717:     ignored (in which case a warning will be printed).
                   6718:
1.72      rillig   6719:     To ignore these ABI dependency recommendations and just use the required
                   6720:     DEPENDS, set USE_ABI_DEPENDS=NO. This may make it easier and faster to
1.36      wiz      6721:     update packages built using pkgsrc, since older compatible dependencies can
                   6722:     continue to be used. This is useful for people who watch their rebuilds
                   6723:     very carefully; it is not very good as a general-purpose hammer. If you use
                   6724:     it, you need to be mindful of possible ABI changes, including those from
                   6725:     the underlying OS.
                   6726:
                   6727:     Packages that are built with recommendations ignored may not be uploaded to
                   6728:     ftp.NetBSD.org by developers and should not be used across different
                   6729:     systems that may have different versions of binary packages installed.
1.20      ben      6730:
1.72      rillig   6731:     For security fixes, please update the package vulnerabilities file. See
1.107     rillig   6732:     Section 19.1.10, "Handling packages with security problems" for more
1.72      rillig   6733:     information.
1.20      ben      6734:
1.1       grant    6735:  4. If your package needs some executable to be able to run correctly and if
1.17      sketch   6736:     there's no buildlink3.mk file, this is specified using the DEPENDS
1.1       grant    6737:     variable. The print/lyx package needs to be able to execute the latex
                   6738:     binary from the teTeX package when it runs, and that is specified:
1.20      ben      6739:
1.101     rillig   6740:     DEPENDS+=        teTeX-[0-9]*:../../print/teTeX
1.87      wiz      6741:
1.20      ben      6742:
1.1       grant    6743:     The comment about wildcard dependencies from previous paragraph applies
                   6744:     here, too.
1.20      ben      6745:
1.71      wiz      6746: If your package needs files from another package to build, add the relevant
                   6747: distribution files to DISTFILES, so they will be extracted automatically. See
                   6748: the print/ghostscript package for an example. (It relies on the jpeg sources
                   6749: being present in source form during the build.)
1.1       grant    6750:
1.107     rillig   6751: 19.1.7. Handling conflicts with other packages
1.1       grant    6752:
                   6753: Your package may conflict with other packages a user might already have
1.88      wiz      6754: installed on his system, e.g. if your package installs the same set of files as
                   6755: another package in the pkgsrc tree.
1.1       grant    6756:
1.47      reed     6757: In this case you can set CONFLICTS to a space-separated list of packages
1.1       grant    6758: (including version string) your package conflicts with.
                   6759:
1.47      reed     6760: For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus
                   6761: you set in pkgsrc/x11/Xaw3d/Makefile:
1.1       grant    6762:
1.101     rillig   6763: CONFLICTS=      Xaw-Xpm-[0-9]*
1.87      wiz      6764:
1.1       grant    6765:
                   6766: and in pkgsrc/x11/Xaw-Xpm/Makefile:
                   6767:
1.101     rillig   6768: CONFLICTS=      Xaw3d-[0-9]*
1.87      wiz      6769:
1.1       grant    6770:
                   6771: Packages will automatically conflict with other packages with the name prefix
                   6772: and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
                   6773: with the older version "Xaw3d-1.3".
                   6774:
1.107     rillig   6775: 19.1.8. Packages that cannot or should not be built
1.1       grant    6776:
                   6777: There are several reasons why a package might be instructed to not build under
                   6778: certain circumstances. If the package builds and runs on most platforms, the
                   6779: exceptions should be noted with NOT_FOR_PLATFORM. If the package builds and
1.45      wiz      6780: runs on a small handful of platforms, set ONLY_FOR_PLATFORM instead. Both
                   6781: ONLY_FOR_PLATFORM and NOT_FOR_PLATFORM are OS triples (OS-version-platform)
                   6782: that can use glob-style wildcards.
                   6783:
1.88      wiz      6784: Some packages are tightly bound to a specific version of an operating system,
                   6785: e.g. LKMs or sysutils/lsof. Such binary packages are not backwards compatible
                   6786: with other versions of the OS, and should be uploaded to a version specific
                   6787: directory on the FTP server. Mark these packages by setting OSVERSION_SPECIFIC
                   6788: to "yes". This variable is not currently used by any of the package system
                   6789: internals, but may be used in the future.
                   6790:
1.45      wiz      6791: If the package should be skipped (for example, because it provides
                   6792: functionality already provided by the system), set PKG_SKIP_REASON to a
                   6793: descriptive message. If the package should fail because some preconditions are
                   6794: not met, set PKG_FAIL_REASON to a descriptive message.
1.1       grant    6795:
1.107     rillig   6796: 19.1.9. Packages which should not be deleted, once installed
1.1       grant    6797:
                   6798: To ensure that a package may not be deleted, once it has been installed, the
                   6799: PKG_PRESERVE definition should be set in the package Makefile. This will be
                   6800: carried into any binary package that is made from this pkgsrc entry. A
                   6801: "preserved" package will not be deleted using pkg_delete(1) unless the "-f"
                   6802: option is used.
                   6803:
1.107     rillig   6804: 19.1.10. Handling packages with security problems
1.1       grant    6805:
                   6806: When a vulnerability is found, this should be noted in localsrc/security/
1.43      wiz      6807: advisories/pkg-vulnerabilities, and after committing that file, use make upload
                   6808: in the same directory to update the file on ftp.NetBSD.org.
                   6809:
                   6810: After fixing the vulnerability by a patch, its PKGREVISION should be increased
                   6811: (this is of course not necessary if the problem is fixed by using a newer
1.72      rillig   6812: release of the software).
1.1       grant    6813:
                   6814: Also, if the fix should be applied to the stable pkgsrc branch, be sure to
                   6815: submit a pullup request!
                   6816:
1.43      wiz      6817: Binary packages already on ftp.NetBSD.org will be handled semi-automatically by
                   6818: a weekly cron job.
                   6819:
1.107     rillig   6820: 19.1.11. How to handle incrementing versions when fixing an existing package
1.1       grant    6821:
                   6822: When making fixes to an existing package it can be useful to change the version
                   6823: number in PKGNAME. To avoid conflicting with future versions by the original
                   6824: author, a "nb1", "nb2", ... suffix can be used on package versions by setting
1.87      wiz      6825: PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools.
                   6826: e.g.
1.1       grant    6827:
1.101     rillig   6828: DISTNAME=       foo-17.42
                   6829: PKGREVISION=    9
1.1       grant    6830:
1.87      wiz      6831:
                   6832: will result in a PKGNAME of "foo-17.42nb9". If you want to use the original
                   6833: value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use
                   6834: PKGNAME_NOREV.
1.1       grant    6835:
                   6836: When a new release of the package is released, the PKGREVISION should be
1.47      reed     6837: removed, e.g. on a new minor release of the above package, things should be
1.1       grant    6838: like:
                   6839:
1.101     rillig   6840: DISTNAME=       foo-17.43
1.87      wiz      6841:
1.1       grant    6842:
1.78      rillig   6843: PKGREVISION should be incremented for any non-trivial change in the resulting
                   6844: binary package. Without a PKGREVISION bump, someone with the previous version
                   6845: installed has no way of knowing that their package is out of date. Thus,
                   6846: changes without increasing PKGREVISION are essentially labeled "this is so
                   6847: trivial that no reasonable person would want to upgrade", and this is the rough
                   6848: test for when increasing PKGREVISION is appropriate. Examples of changes that
                   6849: do not merit increasing PKGREVISION are:
                   6850:
1.115     jmcneill 6851:   * Changing HOMEPAGE, MAINTAINER, OWNER, or comments in Makefile.
1.101     rillig   6852:
                   6853:   * Changing build variables if the resulting binary package is the same.
1.87      wiz      6854:
1.101     rillig   6855:   * Changing DESCR.
                   6856:
                   6857:   * Adding PKG_OPTIONS if the default options don't change.
1.78      rillig   6858:
                   6859: Examples of changes that do merit an increase to PKGREVISION include:
                   6860:
1.101     rillig   6861:   * Security fixes
                   6862:
                   6863:   * Changes or additions to a patch file
1.87      wiz      6864:
1.101     rillig   6865:   * Changes to the PLIST
1.1       grant    6866:
1.113     weinem   6867:   * A dependency is changed or renamed.
                   6868:
1.78      rillig   6869: PKGREVISION must also be incremented when dependencies have ABI changes.
1.1       grant    6870:
1.107     rillig   6871: 19.1.12. Substituting variable text in the package files (the SUBST framework)
1.79      rillig   6872:
                   6873: When you want to replace the same text in multiple files or when the
                   6874: replacement text varies, patches alone cannot help. This is where the SUBST
                   6875: framework comes in. It provides an easy-to-use interface for replacing text in
                   6876: files. Example:
                   6877:
1.101     rillig   6878: SUBST_CLASSES+=                 fix-paths
                   6879: SUBST_STAGE.fix-paths=          pre-configure
                   6880: SUBST_MESSAGE.fix-paths=        Fixing absolute paths.
                   6881: SUBST_FILES.fix-paths=          src/*.c
                   6882: SUBST_FILES.fix-paths+=         scripts/*.sh
                   6883: SUBST_SED.fix-paths=            -e 's,"/usr/local,"${PREFIX},g'
                   6884: SUBST_SED.fix-paths+=           -e 's,"/var/log,"${VARBASE}/log,g'
1.87      wiz      6885:
1.79      rillig   6886:
                   6887: SUBST_CLASSES is a list of identifiers that are used to identify the different
                   6888: SUBST blocks that are defined. The SUBST framework is heavily used by pkgsrc,
                   6889: so it is important to always use the += operator with this variable. Otherwise
                   6890: some substitutions may be skipped.
                   6891:
                   6892: The remaining variables of each SUBST block are parameterized with the
                   6893: identifier from the first line (fix-paths in this case.) They can be seen as
                   6894: parameters to a function call.
                   6895:
                   6896: SUBST_STAGE.* specifies the stage at which the replacement will take place. All
                   6897: combinations of pre-, do- and post- together with a phase name are possible,
                   6898: though only few are actually used. Most commonly used are post-patch and
                   6899: pre-configure. Of these two, pre-configure should be preferred because then it
                   6900: is possible to run bmake patch and have the state after applying the patches
                   6901: but before making any other changes. This is especially useful when you are
                   6902: debugging a package in order to create new patches for it. Similarly,
                   6903: post-build is preferred over pre-install, because the install phase should
                   6904: generally be kept as simple as possible. When you use post-build, you have the
                   6905: same files in the working directory that will be installed later, so you can
                   6906: check if the substitution has succeeded.
                   6907:
                   6908: SUBST_MESSAGE.* is an optional text that is printed just before the
                   6909: substitution is done.
                   6910:
                   6911: SUBST_FILES.* is the list of shell globbing patterns that specifies the files
                   6912: in which the substitution will take place. The patterns are interpreted
                   6913: relatively to the WRKSRC directory.
                   6914:
                   6915: SUBST_SED.* is a list of arguments to sed(1) that specify the actual
                   6916: substitution. Every sed command should be prefixed with -e, so that all SUBST
                   6917: blocks look uniform.
                   6918:
                   6919: There are some more variables, but they are so seldomly used that they are only
1.80      rillig   6920: documented in the mk/subst.mk file.
1.79      rillig   6921:
1.107     rillig   6922: 19.2. Fixing problems in the fetch phase
1.1       grant    6923:
1.107     rillig   6924: 19.2.1. Packages whose distfiles aren't available for plain downloading
1.1       grant    6925:
                   6926: If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
                   6927: a make fetch will call files/getsite.sh with the name of each file to download
                   6928: as an argument, expecting it to output the URL of the directory from which to
                   6929: download it. graphics/ns-cult3d is an example of this usage.
                   6930:
                   6931: If the download can't be automated, because the user must submit personal
                   6932: information to apply for a password, or must pay for the source, or whatever,
1.74      rillig   6933: you can set FETCH_MESSAGE to a list of lines that are displayed to the user
                   6934: before aborting the build. Example:
                   6935:
1.101     rillig   6936: FETCH_MESSAGE=  "Please download the files"
                   6937: FETCH_MESSAGE+= "    "${DISTFILES:Q}
                   6938: FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
1.87      wiz      6939:
1.1       grant    6940:
1.107     rillig   6941: 19.2.2. How to handle modified distfiles with the 'old' name
1.1       grant    6942:
                   6943: Sometimes authors of a software package make some modifications after the
                   6944: software was released, and they put up a new distfile without changing the
                   6945: package's version number. If a package is already in pkgsrc at that time, the
1.32      wiz      6946: checksum will no longer match. The contents of the new distfile should be
                   6947: compared against the old one before changing anything, to make sure the
1.1       grant    6948: distfile was really updated on purpose, and that no trojan horse or so crept
1.97      wiz      6949: in. Please mention that the distfiles were compared and what was found in your
                   6950: commit message. Then, the correct way to work around this is to set DIST_SUBDIR
                   6951: to a unique directory name, usually based on PKGNAME_NOREV. All DISTFILES and
                   6952: PATCHFILES for this package will be put in that subdirectory of the local
1.107     rillig   6953: distfiles directory. (See Section 19.1.11, "How to handle incrementing versions
1.97      wiz      6954: when fixing an existing package" for more details.) In case this happens more
                   6955: often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can
                   6956: be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget regenerating the
                   6957: distinfo file after that, since it contains the DIST_SUBDIR path in the
                   6958: filenames. Also increase the PKGREVISION if the installed package is different.
                   6959: Furthermore, a mail to the package's authors seems appropriate telling them
                   6960: that changing distfiles after releases without changing the file names is not
                   6961: good practice.
1.1       grant    6962:
1.107     rillig   6963: 19.3. Fixing problems in the configure phase
1.1       grant    6964:
1.107     rillig   6965: 19.3.1. Shared libraries - libtool
1.1       grant    6966:
                   6967: pkgsrc supports many different machines, with different object formats like
                   6968: a.out and ELF, and varying abilities to do shared library and dynamic loading
                   6969: at all. To accompany this, varying commands and options have to be passed to
                   6970: the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
1.20      ben      6971: especially if you don't have all the machines at your hand to test things. The
1.1       grant    6972: devel/libtool pkg can help here, as it just "knows" how to build both static
1.47      reed     6973: and dynamic libraries from a set of source files, thus being
                   6974: platform-independent.
1.1       grant    6975:
1.87      wiz      6976: Here's how to use libtool in a package in seven simple steps:
1.1       grant    6977:
                   6978:  1. Add USE_LIBTOOL=yes to the package Makefile.
1.20      ben      6979:
1.1       grant    6980:  2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
                   6981:     {CC}". You could even add it to the definition of CC, if only libraries are
                   6982:     being built in a given Makefile. This one command will build both PIC and
                   6983:     non-PIC library objects, so you need not have separate shared and
                   6984:     non-shared library rules.
1.20      ben      6985:
1.1       grant    6986:  3. For the linking of the library, remove any "ar", "ranlib", and "ld
                   6987:     -Bshareable" commands, and instead use:
1.20      ben      6988:
1.101     rillig   6989:     ${LIBTOOL} --mode=link \
                   6990:         ${CC} -o ${.TARGET:.a=.la} \
                   6991:             ${OBJS:.o=.lo} \
                   6992:             -rpath ${PREFIX}/lib \
                   6993:             -version-info major:minor
1.87      wiz      6994:
1.20      ben      6995:
1.1       grant    6996:     Note that the library is changed to have a .la extension, and the objects
                   6997:     are changed to have a .lo extension. Change OBJS as necessary. This
                   6998:     automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
                   6999:     necessary) in the build directory. Be sure to include "-version-info",
                   7000:     especially when major and minor are zero, as libtool will otherwise strip
                   7001:     off the shared library version.
1.20      ben      7002:
1.1       grant    7003:     From the libtool manual:
1.20      ben      7004:
1.101     rillig   7005:     So, libtool library versions are described by three integers:
1.87      wiz      7006:
1.101     rillig   7007:     CURRENT
                   7008:     The most recent interface number that this library implements.
1.20      ben      7009:
1.101     rillig   7010:     REVISION
                   7011:     The implementation number of the CURRENT interface.
1.20      ben      7012:
1.101     rillig   7013:     AGE
                   7014:     The difference between the newest and oldest interfaces that
                   7015:     this library implements.  In other words, the library implements
                   7016:     all the interface numbers in the range from number `CURRENT -
                   7017:     AGE' to `CURRENT'.
1.20      ben      7018:
1.101     rillig   7019:     If two libraries have identical CURRENT and AGE numbers, then the
                   7020:     dynamic linker chooses the library with the greater REVISION number.
1.20      ben      7021:
                   7022:
1.1       grant    7023:     The "-release" option will produce different results for a.out and ELF
                   7024:     (excluding symlinks) in only one case. An ELF library of the form
                   7025:     "libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
                   7026:     platform. This is handled automatically.
1.20      ben      7027:
1.1       grant    7028:     The "-rpath argument" is the install directory of the library being built.
1.20      ben      7029:
1.19      hubertf  7030:     In the PLIST, include only the .la file, the other files will be added
                   7031:     automatically.
1.20      ben      7032:
1.1       grant    7033:  4. When linking shared object (.so) files, i.e. files that are loaded via
                   7034:     dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
                   7035:     them getting version tacked on.
1.20      ben      7036:
1.1       grant    7037:     The PLIST file gets the foo.so entry.
1.20      ben      7038:
1.1       grant    7039:  5. When linking programs that depend on these libraries before they are
                   7040:     installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
                   7041:     and it will find the correct libraries (static or shared), but please be
                   7042:     aware that libtool will not allow you to specify a relative path in -L
                   7043:     (such as "-L../somelib"), because it expects you to change that argument to
                   7044:     be the .la file. e.g.
1.20      ben      7045:
1.101     rillig   7046:     ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
1.87      wiz      7047:
1.20      ben      7048:
1.1       grant    7049:     should be changed to:
1.20      ben      7050:
1.101     rillig   7051:     ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
1.87      wiz      7052:
1.20      ben      7053:
1.1       grant    7054:     and it will do the right thing with the libraries.
1.20      ben      7055:
1.1       grant    7056:  6. When installing libraries, preface the install(1) or cp(1) command with "$
                   7057:     {LIBTOOL} --mode=install", and change the library name to .la. e.g.
1.20      ben      7058:
1.128     jakllsch 7059:     ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
1.87      wiz      7060:
1.20      ben      7061:
1.1       grant    7062:     This will install the static .a, shared library, any needed symlinks, and
                   7063:     run ldconfig(8).
1.20      ben      7064:
1.23      wiz      7065:  7. In your PLIST, include only the .la file (this is a change from previous
                   7066:     behaviour).
1.20      ben      7067:
1.107     rillig   7068: 19.3.2. Using libtool on GNU packages that already support libtool
1.1       grant    7069:
                   7070: Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
                   7071: own libtool in most cases. For older libtool using packages, libtool is made by
                   7072: ltconfig script during the do-configure step; you can check the libtool script
                   7073: location by doing make configure; find work*/ -name libtool.
                   7074:
                   7075: LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
                   7076: override. By default, it is set to "libtool */libtool */*/libtool". If this
                   7077: does not match the location of the package's libtool script(s), set it as
                   7078: appropriate.
                   7079:
                   7080: If you do not need *.a static libraries built and installed, then use
                   7081: SHLIBTOOL_OVERRIDE instead.
                   7082:
1.47      reed     7083: If your package makes use of the platform-independent library for loading
1.1       grant    7084: dynamic shared objects, that comes with libtool (libltdl), you should include
1.22      tv       7085: devel/libltdl/buildlink3.mk.
1.1       grant    7086:
                   7087: Some packages use libtool incorrectly so that the package may not work or build
                   7088: in some circumstances. Some of the more common errors are:
                   7089:
                   7090:   * The inclusion of a shared object (-module) as a dependent library in an
                   7091:     executable or library. This in itself isn't a problem if one of two things
                   7092:     has been done:
1.20      ben      7093:
1.1       grant    7094:      1. The shared object is named correctly, i.e. libfoo.la, not foo.la
1.20      ben      7095:
1.1       grant    7096:      2. The -dlopen option is used when linking an executable.
1.20      ben      7097:
1.1       grant    7098:   * The use of libltdl without the correct calls to initialisation routines.
                   7099:     The function lt_dlinit() should be called and the macro
                   7100:     LTDL_SET_PRELOADED_SYMBOLS included in executables.
1.20      ben      7101:
1.107     rillig   7102: 19.3.3. GNU Autoconf/Automake
1.1       grant    7103:
                   7104: If a package needs GNU autoconf or automake to be executed to regenerate the
                   7105: configure script and Makefile.in makefile templates, then they should be
1.35      jmmv     7106: executed in a pre-configure target.
1.1       grant    7107:
                   7108: For packages that need only autoconf:
                   7109:
1.101     rillig   7110: AUTOCONF_REQD=  2.50            # if default version is not good enough
                   7111: USE_TOOLS+=     autoconf        # use "autoconf213" for autoconf-2.13
                   7112: ...
1.87      wiz      7113:
1.101     rillig   7114: pre-configure:
                   7115:         cd ${WRKSRC} && autoconf
1.1       grant    7116:
1.101     rillig   7117: ...
1.1       grant    7118:
                   7119:
                   7120: and for packages that need automake and autoconf:
                   7121:
1.101     rillig   7122: AUTOMAKE_REQD=  1.7.1           # if default version is not good enough
                   7123: USE_TOOLS+=     automake        # use "automake14" for automake-1.4
                   7124: ...
1.87      wiz      7125:
1.101     rillig   7126: pre-configure:
                   7127:         set -e; cd ${WRKSRC}; \
                   7128:         aclocal; autoheader; automake -a --foreign -i; autoconf
                   7129:
                   7130: ...
1.51      rillig   7131:
1.1       grant    7132:
1.35      jmmv     7133: Packages which use GNU Automake will almost certainly require GNU Make.
1.1       grant    7134:
                   7135: There are times when the configure process makes additional changes to the
                   7136: generated files, which then causes the build process to try to re-execute the
                   7137: automake sequence. This is prevented by touching various files in the configure
                   7138: stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
                   7139: NO in the package Makefile.
                   7140:
1.107     rillig   7141: 19.4. Programming languages
1.87      wiz      7142:
1.107     rillig   7143: 19.4.1. C, C++, and Fortran
1.87      wiz      7144:
                   7145: Compilers for the C, C++, and Fortran languages comes with the NetBSD base
                   7146: system. By default, pkgsrc assumes that a package is written in C and will hide
1.107     rillig   7147: all other compilers (via the wrapper framework, see Chapter 14, Buildlink
1.87      wiz      7148: methodology).
                   7149:
                   7150: To declare which language's compiler a package needs, set the USE_LANGUAGES
                   7151: variable. Allowed values currently are "c", "c++", and "fortran" (and any
                   7152: combination). The default is "c". Packages using GNU configure scripts, even if
                   7153: written in C++, usually need a C compiler for the configure phase.
                   7154:
1.107     rillig   7155: 19.4.2. Java
1.87      wiz      7156:
                   7157: If a program is written in Java, use the Java framework in pkgsrc. The package
                   7158: must include ../../mk/java-vm.mk. This Makefile fragment provides the following
                   7159: variables:
                   7160:
                   7161:   * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is
                   7162:     set to "run", then there is only a runtime dependency on the JDK. The
                   7163:     default is "yes", which also adds a build dependency on the JDK.
                   7164:
                   7165:   * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The
                   7166:     supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2
                   7167:     implementation, "1.4" insists on versions 1.4 or above, and "1.5" only
                   7168:     accepts versions 1.5 or above. This variable is not set by default.
                   7169:
1.107     rillig   7170: 19.4.3. Packages containing perl scripts
1.87      wiz      7171:
                   7172: If your package contains interpreted perl scripts, add "perl" to the USE_TOOLS
                   7173: variable and set REPLACE_PERL to ensure that the proper interpreter path is
                   7174: set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that
                   7175: you want adjusted. Every occurrence of */bin/perl will be replaced with the
                   7176: full path to the perl executable.
                   7177:
                   7178: If a particular version of perl is needed, set the PERL5_REQD variable to the
                   7179: version number. The default is "5.0".
                   7180:
1.107     rillig   7181: See Section 19.6.6, "Packages installing perl modules" for information about
1.87      wiz      7182: handling perl modules.
                   7183:
1.107     rillig   7184: 19.4.4. Other programming languages
1.87      wiz      7185:
                   7186: Currently, there is no special handling for other languages in pkgsrc. If a
                   7187: compiler package provides a buildlink3.mk file, include that, otherwise just
                   7188: add a (build) dependency on the appropriate compiler package.
                   7189:
1.107     rillig   7190: 19.5. Fixing problems in the build phase
1.1       grant    7191:
1.77      rillig   7192: The most common failures when building a package are that some platforms do not
                   7193: provide certain header files, functions or libraries, or they provide the
                   7194: functions in a library that the original package author didn't know. To work
                   7195: around this, you can rewrite the source code in most cases so that it does not
                   7196: use the missing functions or provides a replacement function.
                   7197:
1.107     rillig   7198: 19.5.1. Compiling C and C++ code conditionally
1.77      rillig   7199:
                   7200: If a package already comes with a GNU configure script, the preferred way to
                   7201: fix the build failure is to change the configure script, not the code. In the
                   7202: other cases, you can utilize the C preprocessor, which defines certain macros
                   7203: depending on the operating system and hardware architecture it compiles for.
                   7204: These macros can be queried using for example #if defined(__i386). Almost every
                   7205: operating system, hardware architecture and compiler has its own macro. For
                   7206: example, if the macros __GNUC__, __i386__ and __NetBSD__ are all defined, you
                   7207: know that you are using NetBSD on an i386 compatible CPU, and your compiler is
                   7208: GCC.
                   7209:
                   7210: The list of the following macros for hardware and operating system depends on
                   7211: the compiler that is used. For example, if you want to conditionally compile
                   7212: code on Solaris, don't use __sun__, as the SunPro compiler does not define it.
                   7213: Use __sun instead.
1.1       grant    7214:
1.107     rillig   7215: 19.5.1.1. C preprocessor macros to identify the operating system
1.55      rillig   7216:
                   7217: To distinguish between 4.4 BSD-derived systems and the rest of the world, you
                   7218: should use the following code.
1.1       grant    7219:
1.101     rillig   7220: #include <sys/param.h>
                   7221: #if (defined(BSD) && BSD >= 199306)
                   7222: /* BSD-specific code goes here */
                   7223: #else
                   7224: /* non-BSD-specific code goes here */
                   7225: #endif
1.55      rillig   7226:
1.77      rillig   7227: If this distinction is not fine enough, you can also test for the following
                   7228: macros.
1.55      rillig   7229:
1.101     rillig   7230: FreeBSD     __FreeBSD__
                   7231: DragonFly   __DragonFly__
                   7232: Interix     __INTERIX
                   7233: IRIX        __sgi (TODO: get a definite source for this)
                   7234: Linux       linux, __linux, __linux__
                   7235: NetBSD      __NetBSD__
                   7236: OpenBSD     __OpenBSD__
                   7237: Solaris     sun, __sun
1.1       grant    7238:
1.107     rillig   7239: 19.5.1.2. C preprocessor macros to identify the hardware architecture
1.1       grant    7240:
1.101     rillig   7241: i386        i386, __i386, __i386__
                   7242: MIPS        __mips
                   7243: SPARC       sparc, __sparc
1.55      rillig   7244:
1.107     rillig   7245: 19.5.1.3. C preprocessor macros to identify the compiler
1.1       grant    7246:
1.101     rillig   7247: GCC         __GNUC__ (major version), __GNUC_MINOR__
                   7248: MIPSpro     _COMPILER_VERSION (0x741 for MIPSpro 7.41)
                   7249: SunPro      __SUNPRO_C (0x570 for Sun C 5.7)
                   7250: SunPro C++  __SUNPRO_CC (0x580 for Sun C++ 5.8)
1.1       grant    7251:
1.107     rillig   7252: 19.5.2. How to handle compiler bugs
1.61      rillig   7253:
1.78      rillig   7254: Some source files trigger bugs in the compiler, based on combinations of
                   7255: compiler version and architecture and almost always relation to optimisation
                   7256: being enabled. Common symptoms are gcc internal errors or never finishing
                   7257: compiling a file.
1.1       grant    7258:
1.78      rillig   7259: Typically, a workaround involves testing the MACHINE_ARCH and compiler version,
                   7260: disabling optimisation for that combination of file, MACHINE_ARCH and compiler,
                   7261: and documenting it in pkgsrc/doc/HACKS. See that file for a number of examples.
1.1       grant    7262:
1.107     rillig   7263: 19.5.3. Undefined reference to "..."
1.20      ben      7264:
1.92      rillig   7265: This error message often means that a package did not link to a shared library
1.78      rillig   7266: it needs. The following functions are known to cause this error message over
                   7267: and over.
                   7268:
                   7269: +-----------------------------------------------------+
                   7270: |        Function         |Library |Affected platforms|
                   7271: |-------------------------+--------+------------------|
                   7272: |accept, bind, connect    |-lsocket|Solaris           |
                   7273: |-------------------------+--------+------------------|
                   7274: |crypt                    |-lcrypt |DragonFly, NetBSD |
                   7275: |-------------------------+--------+------------------|
                   7276: |dlopen, dlsym            |-ldl    |Linux             |
                   7277: |-------------------------+--------+------------------|
                   7278: |gethost*                 |-lnsl   |Solaris           |
                   7279: |-------------------------+--------+------------------|
                   7280: |inet_aton                |-lresolv|Solaris           |
                   7281: |-------------------------+--------+------------------|
                   7282: |nanosleep, sem_*, timer_*|-lrt    |Solaris           |
                   7283: |-------------------------+--------+------------------|
                   7284: |openpty                  |-lutil  |Linux             |
                   7285: +-----------------------------------------------------+
                   7286:
                   7287: To fix these linker errors, it is often sufficient to say LIBS.OperatingSystem+
                   7288: = -lfoo to the package Makefile and then say bmake clean; bmake.
                   7289:
1.107     rillig   7290: 19.5.3.1. Special issue: The SunPro compiler
1.92      rillig   7291:
                   7292: When you are using the SunPro compiler, there is another possibility. That
                   7293: compiler cannot handle the following code:
                   7294:
1.101     rillig   7295: extern int extern_func(int);
1.92      rillig   7296:
1.101     rillig   7297: static inline int
                   7298: inline_func(int x)
                   7299: {
1.92      rillig   7300:         return extern_func(x);
1.101     rillig   7301: }
1.92      rillig   7302:
1.101     rillig   7303: int main(void)
                   7304: {
1.92      rillig   7305:         return 0;
1.101     rillig   7306: }
1.92      rillig   7307:
                   7308: It generates the code for inline_func even if that function is never used. This
                   7309: code then refers to extern_func, which can usually not be resolved. To solve
                   7310: this problem you can try to tell the package to disable inlining of functions.
                   7311:
1.107     rillig   7312: 19.5.4. Running out of memory
1.87      wiz      7313:
                   7314: Sometimes packages fail to build because the compiler runs into an operating
                   7315: system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be
                   7316: told to unlimit the resources. Currently, the allowed values are "datasize" and
                   7317: "stacksize" (or both). Setting this variable is similar to running the shell
                   7318: builtin ulimit command to raise the maximum data segment size or maximum stack
                   7319: size of a process, respectively, to their hard limits.
1.78      rillig   7320:
1.107     rillig   7321: 19.6. Fixing problems in the install phase
1.87      wiz      7322:
1.107     rillig   7323: 19.6.1. Creating needed directories
1.78      rillig   7324:
                   7325: The BSD-compatible install supplied with some operating systems cannot create
                   7326: more than one directory at a time. As such, you should call ${INSTALL_*_DIR}
                   7327: like this:
1.20      ben      7328:
1.101     rillig   7329: ${INSTALL_DATA_DIR} ${PREFIX}/dir1
                   7330: ${INSTALL_DATA_DIR} ${PREFIX}/dir2
1.87      wiz      7331:
1.20      ben      7332:
1.78      rillig   7333: You can also just append "dir1 dir2" to the INSTALLATION_DIRS variable, which
                   7334: will automatically do the right thing.
1.20      ben      7335:
1.107     rillig   7336: 19.6.2. Where to install documentation
1.1       grant    7337:
1.83      wiz      7338: In general, documentation should be installed into ${PREFIX}/share/doc/$
                   7339: {PKGBASE} or ${PREFIX}/share/doc/${PKGNAME} (the latter includes the version
                   7340: number of the package).
                   7341:
                   7342: Many modern packages using GNU autoconf allow to set the directory where HTML
1.84      wiz      7343: documentation is installed with the "--with-html-dir" option. Sometimes using
                   7344: this flag is needed because otherwise the documentation ends up in ${PREFIX}/
                   7345: share/doc/html or other places.
1.83      wiz      7346:
                   7347: An exception to the above is that library API documentation generated with the
                   7348: textproc/gtk-doc tools, for use by special browsers (devhelp) should be left at
                   7349: their default location, which is ${PREFIX}/share/gtk-doc. Such documentation
                   7350: can be recognized from files ending in .devhelp or .devhelp2. (It is also
1.84      wiz      7351: acceptable to install such files in ${PREFIX}/share/doc/${PKGBASE} or ${PREFIX}
                   7352: /share/doc/${PKGNAME}; the .devhelp* file must be directly in that directory
                   7353: then, no additional subdirectory level is allowed in this case. This is usually
                   7354: achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/
                   7355: gtk-doc is preferred though.)
1.1       grant    7356:
1.107     rillig   7357: 19.6.3. Installing highscore files
1.1       grant    7358:
                   7359: Certain packages, most of them in the games category, install a score file that
                   7360: allows all users on the system to record their highscores. In order for this to
                   7361: work, the binaries need to be installed setgid and the score files owned by the
                   7362: appropriate group and/or owner (traditionally the "games" user/group). The
1.11      ben      7363: following variables, documented in more detail in mk/defaults/mk.conf, control
                   7364: this behaviour: SETGIDGAME, GAMEDATAMODE, GAMEGRP, GAMEMODE, GAMEOWN.
1.1       grant    7365:
                   7366: Note that per default, setgid installation of games is disabled; setting
                   7367: SETGIDGAME=YES will set all the other variables accordingly.
                   7368:
1.115     jmcneill 7369: A package should therefore never hard code file ownership or access permissions
1.1       grant    7370: but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly.
                   7371:
1.107     rillig   7372: 19.6.4. Adding DESTDIR support to packages
1.104     wiz      7373:
1.115     jmcneill 7374: DESTDIR support means that a package installs into a staging directory, not the
                   7375: final location of the files. Then a binary package is created which can be used
                   7376: for installation as usual. There are two ways: Either the package must install
                   7377: as root ("destdir") or the package can install as non-root user
                   7378: ("user-destdir").
                   7379:
                   7380:   * PKG_DESTDIR_SUPPORT has to be set to "destdir" or "user-destdir". If
                   7381:     bsd.prefs.mk is included in the Makefile, PKG_DESTDIR_SUPPORT needs to be
                   7382:     set before the inclusion.
                   7383:
1.104     wiz      7384:   * All installation operations have to be prefixed with ${DESTDIR}.
                   7385:
                   7386:   * automake gets this DESTDIR mostly right automatically. Many manual rules
                   7387:     and pre/post-install often are incorrect; fix them.
                   7388:
1.119     imil     7389:   * If files are installed with special owner/group use SPECIAL_PERMS.
1.104     wiz      7390:
                   7391:   * In general, packages should support UNPRIVILEGED to be able to use DESTDIR.
                   7392:
1.107     rillig   7393: 19.6.5. Packages with hardcoded paths to other interpreters
1.1       grant    7394:
                   7395: Your package may also contain scripts with hardcoded paths to other
                   7396: interpreters besides (or as well as) perl. To correct the full pathname to the
                   7397: script interpreter, you need to set the following definitions in your Makefile
                   7398: (we shall use tclsh in this example):
                   7399:
1.101     rillig   7400: REPLACE_INTERPRETER+=   tcl
                   7401: REPLACE.tcl.old=        .*/bin/tclsh
                   7402: REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
                   7403: REPLACE_FILES.tcl=      # list of tcl scripts which need to be fixed,
                   7404: # relative to ${WRKSRC}, just as in REPLACE_PERL
1.87      wiz      7405:
1.1       grant    7406:
1.71      wiz      7407: Note
                   7408:
                   7409: Before March 2006, these variables were called _REPLACE.* and _REPLACE_FILES.*.
                   7410:
1.107     rillig   7411: 19.6.6. Packages installing perl modules
1.1       grant    7412:
                   7413: Makefiles of packages providing perl5 modules should include the Makefile
                   7414: fragment ../../lang/perl5/module.mk. It provides a do-configure target for the
                   7415: standard perl configuration for such modules as well as various hooks to tune
                   7416: this configuration. See comments in this file for details.
                   7417:
                   7418: Perl5 modules will install into different places depending on the version of
                   7419: perl used during the build process. To address this, pkgsrc will append lines
                   7420: to the PLIST corresponding to the files listed in the installed .packlist file
                   7421: generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to
                   7422: a space-separated list of paths to packlist files, e.g.:
                   7423:
1.101     rillig   7424: PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
1.87      wiz      7425:
1.1       grant    7426:
                   7427: The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent the
                   7428: three locations in which perl5 modules may be installed, and may be used by
                   7429: perl5 packages that don't have a packlist. These three variables are also
                   7430: substituted for in the PLIST.
                   7431:
1.107     rillig   7432: 19.6.7. Packages installing info files
1.1       grant    7433:
                   7434: Some packages install info files or use the "makeinfo" or "install-info"
1.72      rillig   7435: commands. INFO_FILES should be defined in the package Makefile so that INSTALL
                   7436: and DEINSTALL scripts will be generated to handle registration of the info
                   7437: files in the Info directory file. The "install-info" command used for the info
                   7438: files registration is either provided by the system, or by a special purpose
                   7439: package automatically added as dependency if needed.
                   7440:
                   7441: PKGINFODIR is the directory under ${PREFIX} where info files are primarily
                   7442: located. PKGINFODIR defaults to "info" and can be overridden by the user.
                   7443:
                   7444: The info files for the package should be listed in the package PLIST; however
                   7445: any split info files need not be listed.
                   7446:
                   7447: A package which needs the "makeinfo" command at build time must add "makeinfo"
                   7448: to USE_TOOLS in its Makefile. If a minimum version of the "makeinfo" command is
                   7449: needed it should be noted with the TEXINFO_REQD variable in the package
                   7450: Makefile. By default, a minimum version of 3.12 is required. If the system does
                   7451: not provide a makeinfo command or if it does not match the required minimum, a
                   7452: build dependency on the devel/gtexinfo package will be added automatically.
1.1       grant    7453:
                   7454: The build and installation process of the software provided by the package
                   7455: should not use the install-info command as the registration of info files is
1.20      ben      7456: the task of the package INSTALL script, and it must use the appropriate
1.1       grant    7457: makeinfo command.
                   7458:
1.47      reed     7459: To achieve this goal, the pkgsrc infrastructure creates overriding scripts for
1.1       grant    7460: the install-info and makeinfo commands in a directory listed early in PATH.
                   7461:
                   7462: The script overriding install-info has no effect except the logging of a
                   7463: message. The script overriding makeinfo logs a message and according to the
1.72      rillig   7464: value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on
                   7465: error.
1.1       grant    7466:
1.107     rillig   7467: 19.6.8. Packages installing man pages
1.57      minskim  7468:
1.81      rillig   7469: All packages that install manual pages should install them into the same
                   7470: directory, so that there is one common place to look for them. In pkgsrc, this
                   7471: place is ${PREFIX}/${PKGMANDIR}, and this expression should be used in
                   7472: packages. The default for PKGMANDIR is "man". Another often-used value is
                   7473: "share/man".
1.57      minskim  7474:
                   7475: Note
                   7476:
1.81      rillig   7477: The support for a custom PKGMANDIR is far from complete.
1.57      minskim  7478:
                   7479: The PLIST files can just use man/ as the top level directory for the man page
1.81      rillig   7480: file entries, and the pkgsrc framework will convert as needed. In all other
                   7481: places, the correct PKGMANDIR must be used.
1.57      minskim  7482:
                   7483: Packages that are configured with GNU_CONFIGURE set as "yes", by default will
                   7484: use the ./configure --mandir switch to set where the man pages should be
                   7485: installed. The path is GNU_CONFIGURE_MANDIR which defaults to ${PREFIX}/$
                   7486: {PKGMANDIR}.
                   7487:
                   7488: Packages that use GNU_CONFIGURE but do not use --mandir, can set
                   7489: CONFIGURE_HAS_MANDIR to "no". Or if the ./configure script uses a non-standard
                   7490: use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed.
                   7491:
1.107     rillig   7492: See Section 13.5, "Man page compression" for information on installation of
1.57      minskim  7493: compressed manual pages.
                   7494:
1.108     rillig   7495: 19.6.9. Packages installing GConf data files
1.1       grant    7496:
1.108     rillig   7497: If a package installs .schemas or .entries files, used by GConf, you need to
1.1       grant    7498: take some extra steps to make sure they get registered in the database:
                   7499:
1.108     rillig   7500:  1. Include ../../devel/GConf/schemas.mk instead of its buildlink3.mk file.
                   7501:     This takes care of rebuilding the GConf database at installation and
                   7502:     deinstallation time, and tells the package where to install GConf data
1.1       grant    7503:     files using some standard configure arguments. It also disallows any access
                   7504:     to the database directly from the package.
1.20      ben      7505:
1.1       grant    7506:  2. Ensure that the package installs its .schemas files under ${PREFIX}/share/
                   7507:     gconf/schemas. If they get installed under ${PREFIX}/etc, you will need to
                   7508:     manually patch the package.
1.20      ben      7509:
1.1       grant    7510:  3. Check the PLIST and remove any entries under the etc/gconf directory, as
1.107     rillig   7511:     they will be handled automatically. See Section 9.13, "How do I change the
1.35      jmmv     7512:     location of configuration files?" for more information.
1.20      ben      7513:
1.108     rillig   7514:  4. Define the GCONF_SCHEMAS variable in your Makefile with a list of all
1.1       grant    7515:     .schemas files installed by the package, if any. Names must not contain any
                   7516:     directories in them.
1.20      ben      7517:
1.108     rillig   7518:  5. Define the GCONF_ENTRIES variable in your Makefile with a list of all
1.1       grant    7519:     .entries files installed by the package, if any. Names must not contain any
                   7520:     directories in them.
1.20      ben      7521:
1.120     mishka   7522: 19.6.10. Packages installing scrollkeeper/rarian data files
1.1       grant    7523:
1.120     mishka   7524: If a package installs .omf files, used by scrollkeeper/rarian, you need to take
                   7525: some extra steps to make sure they get registered in the database:
1.1       grant    7526:
1.120     mishka   7527:  1. Include ../../mk/omf-scrollkeeper.mk instead of rarian's buildlink3.mk
                   7528:     file. This takes care of rebuilding the scrollkeeper database at
                   7529:     installation and deinstallation time, and disallows any access to it
                   7530:     directly from the package.
1.20      ben      7531:
1.1       grant    7532:  2. Check the PLIST and remove any entries under the libdata/scrollkeeper
                   7533:     directory, as they will be handled automatically.
1.20      ben      7534:
1.1       grant    7535:  3. Remove the share/omf directory from the PLIST. It will be handled by
1.120     mishka   7536:     rarian. (make print-PLIST does this automatically.)
1.20      ben      7537:
1.107     rillig   7538: 19.6.11. Packages installing X11 fonts
1.1       grant    7539:
                   7540: If a package installs font files, you will need to rebuild the fonts database
                   7541: in the directory where they get installed at installation and deinstallation
1.65      hubertf  7542: time. This can be automatically done by using the pkginstall framework.
1.1       grant    7543:
1.65      hubertf  7544: You can list the directories where fonts are installed in the FONTS_DIRS.type
                   7545: variables, where type can be one of "ttf", "type1" or "x11". Also make sure
                   7546: that the database file fonts.dir is not listed in the PLIST.
1.1       grant    7547:
                   7548: Note that you should not create new directories for fonts; instead use the
                   7549: standard ones to avoid that the user needs to manually configure his X server
                   7550: to find them.
                   7551:
1.107     rillig   7552: 19.6.12. Packages installing GTK2 modules
1.1       grant    7553:
1.47      reed     7554: If a package installs GTK2 immodules or loaders, you need to take some extra
1.1       grant    7555: steps to get them registered in the GTK2 database properly:
                   7556:
                   7557:  1. Include ../../x11/gtk2/modules.mk instead of its buildlink3.mk file. This
                   7558:     takes care of rebuilding the database at installation and deinstallation
                   7559:     time.
1.20      ben      7560:
1.1       grant    7561:  2. Set GTK2_IMMODULES=YES if your package installs GTK2 immodules.
1.20      ben      7562:
1.1       grant    7563:  3. Set GTK2_LOADERS=YES if your package installs GTK2 loaders.
1.20      ben      7564:
1.47      reed     7565:  4. Patch the package to not touch any of the GTK2 databases directly. These
1.1       grant    7566:     are:
1.20      ben      7567:
1.1       grant    7568:       * libdata/gtk-2.0/gdk-pixbuf.loaders
1.20      ben      7569:
1.1       grant    7570:       * libdata/gtk-2.0/gtk.immodules
1.20      ben      7571:
1.1       grant    7572:  5. Check the PLIST and remove any entries under the libdata/gtk-2.0 directory,
                   7573:     as they will be handled automatically.
1.20      ben      7574:
1.107     rillig   7575: 19.6.13. Packages installing SGML or XML data
1.1       grant    7576:
                   7577: If a package installs SGML or XML data files that need to be registered in
                   7578: system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
                   7579: extra steps:
                   7580:
                   7581:  1. Include ../../textproc/xmlcatmgr/catalogs.mk in your Makefile, which takes
                   7582:     care of registering those files in system-wide catalogs at installation and
                   7583:     deinstallation time.
1.20      ben      7584:
1.1       grant    7585:  2. Set SGML_CATALOGS to the full path of any SGML catalogs installed by the
                   7586:     package.
1.20      ben      7587:
1.1       grant    7588:  3. Set XML_CATALOGS to the full path of any XML catalogs installed by the
                   7589:     package.
1.20      ben      7590:
1.1       grant    7591:  4. Set SGML_ENTRIES to individual entries to be added to the SGML catalog.
                   7592:     These come in groups of three strings; see xmlcatmgr(1) for more
                   7593:     information (specifically, arguments recognized by the 'add' action). Note
                   7594:     that you will normally not use this variable.
1.20      ben      7595:
1.1       grant    7596:  5. Set XML_ENTRIES to individual entries to be added to the XML catalog. These
                   7597:     come in groups of three strings; see xmlcatmgr(1) for more information
                   7598:     (specifically, arguments recognized by the 'add' action). Note that you
                   7599:     will normally not use this variable.
1.20      ben      7600:
1.107     rillig   7601: 19.6.14. Packages installing extensions to the MIME database
1.1       grant    7602:
                   7603: If a package provides extensions to the MIME database by installing .xml files
                   7604: inside ${PREFIX}/share/mime/packages, you need to take some extra steps to
                   7605: ensure that the database is kept consistent with respect to these new files:
                   7606:
                   7607:  1. Include ../../databases/shared-mime-info/mimedb.mk (avoid using the
                   7608:     buildlink3.mk file from this same directory, which is reserved for
                   7609:     inclusion from other buildlink3.mk files). It takes care of rebuilding the
                   7610:     MIME database at installation and deinstallation time, and disallows any
                   7611:     access to it directly from the package.
1.20      ben      7612:
                   7613:  2. Check the PLIST and remove any entries under the share/mime directory,
1.1       grant    7614:     except for files saved under share/mime/packages. The former are handled
1.47      reed     7615:     automatically by the update-mime-database program, but the latter are
1.1       grant    7616:     package-dependent and must be removed by the package that installed them in
                   7617:     the first place.
1.20      ben      7618:
1.1       grant    7619:  3. Remove any share/mime/* directories from the PLIST. They will be handled by
                   7620:     the shared-mime-info package.
1.20      ben      7621:
1.107     rillig   7622: 19.6.15. Packages using intltool
1.1       grant    7623:
1.93      rillig   7624: If a package uses intltool during its build, add intltool to the USE_TOOLS,
                   7625: which forces it to use the intltool package provided by pkgsrc, instead of the
                   7626: one bundled with the distribution file.
1.1       grant    7627:
                   7628: This tracks intltool's build-time dependencies and uses the latest available
                   7629: version; this way, the package benefits of any bug fixes that may have appeared
                   7630: since it was released.
                   7631:
1.107     rillig   7632: 19.6.16. Packages installing startup scripts
1.18      xtraeme  7633:
                   7634: If a package contains a rc.d script, it won't be copied into the startup
                   7635: directory by default, but you can enable it, by adding the option
1.105     rillig   7636: PKG_RCD_SCRIPTS=YES in mk.conf. This option will copy the scripts into /etc/
                   7637: rc.d when a package is installed, and it will automatically remove the scripts
                   7638: when the package is deinstalled.
1.18      xtraeme  7639:
1.107     rillig   7640: 19.6.17. Packages installing TeX modules
1.57      minskim  7641:
                   7642: If a package installs TeX packages into the texmf tree, the ls-R database of
                   7643: the tree needs to be updated.
                   7644:
                   7645: Note
                   7646:
1.126     wiz      7647: Except the main TeX packages such as kpathsea, packages should install files
                   7648: into ${PREFIX}/share/texmf-dist, not ${PREFIX}/share/texmf.
1.57      minskim  7649:
1.126     wiz      7650:  1. Include ../../print/kpathsea/texmf.mk. This takes care of rebuilding the
                   7651:     ls-R database at installation and deinstallation time.
1.57      minskim  7652:
1.126     wiz      7653:  2. If your package installs files into a texmf tree other than the one at $
                   7654:     {PREFIX}/share/texmf-dist, set TEX_TEXMF_DIRS to the list of all texmf
                   7655:     trees that need database update.
1.57      minskim  7656:
1.64      kim      7657:     If your package also installs font map files that need to be registered
1.126     wiz      7658:     using updmap, include ../../print/texlive-tetex/map.mk and set
                   7659:     TEX_MAP_FILES and/or TEX_MIXEDMAP_FILES to the list of all such font map
                   7660:     files. Then updmap will be run automatically at installation/deinstallation
                   7661:     to enable/disable font map files for TeX output drivers.
1.64      kim      7662:
1.57      minskim  7663:  3. Make sure that none of ls-R databases are included in PLIST, as they will
                   7664:     be removed only by the teTeX-bin package.
                   7665:
1.107     rillig   7666: 19.6.18. Packages supporting running binaries in emulation
1.87      wiz      7667:
                   7668: There are some packages that provide libraries and executables for running
                   7669: binaries from a one operating system on a different one (if the latter supports
                   7670: it). One example is running Linux binaries on NetBSD.
                   7671:
                   7672: The pkgtools/rpm2pkg helps in extracting and packaging Linux rpm packages.
                   7673:
                   7674: The CHECK_SHLIBS can be set to no to avoid the check-shlibs target, which tests
                   7675: if all libraries for each installed executable can be found by the dynamic
                   7676: linker. Since the standard dynamic linker is run, this fails for emulation
                   7677: packages, because the libraries used by the emulation are not in the standard
                   7678: directories.
                   7679:
1.107     rillig   7680: 19.6.19. Packages installing hicolor theme icons
1.85      jmmv     7681:
                   7682: If a package installs images under the share/icons/hicolor and/or updates the
                   7683: share/icons/hicolor/icon-theme.cache database, you need to take some extra
                   7684: steps to make sure that the shared theme directory is handled appropriately and
                   7685: that the cache database is rebuilt:
                   7686:
1.87      wiz      7687:  1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk.
1.85      jmmv     7688:
                   7689:  2. Check the PLIST and remove the entry that refers to the theme cache.
                   7690:
                   7691:  3. Ensure that the PLIST does not remove the shared icon directories from the
                   7692:     share/icons/hicolor hierarchy because they will be handled automatically.
1.1       grant    7693:
1.85      jmmv     7694: The best way to verify that the PLIST is correct with respect to the last two
                   7695: points is to regenerate it using make print-PLIST.
1.1       grant    7696:
1.107     rillig   7697: 19.6.20. Packages installing desktop files
1.85      jmmv     7698:
                   7699: If a package installs .desktop files under share/applications and these include
                   7700: MIME information, you need to take extra steps to ensure that they are
                   7701: registered into the MIME database:
                   7702:
                   7703:  1. Include ../../sysutils/desktop-file-utils/desktopdb.mk.
                   7704:
                   7705:  2. Check the PLIST and remove the entry that refers to the share/applications/
                   7706:     mimeinfo.cache file. It will be handled automatically.
                   7707:
                   7708: The best way to verify that the PLIST is correct with respect to the last point
                   7709: is to regenerate it using make print-PLIST.
1.1       grant    7710:
1.107     rillig   7711: 19.7. Marking packages as having problems
1.87      wiz      7712:
1.126     wiz      7713: In some cases one does not have the time to solve a problem immediately. In
                   7714: this case, one can plainly mark a package as broken. For this, one just sets
                   7715: the variable BROKEN to the reason why the package is broken (similar to the
                   7716: RESTRICTED variable). A user trying to build the package will immediately be
                   7717: shown this message, and the build will not be even tried.
1.87      wiz      7718:
1.126     wiz      7719: BROKEN packages are removed from pkgsrc in irregular intervals.
1.87      wiz      7720:
1.107     rillig   7721: Chapter 20. Debugging
1.1       grant    7722:
                   7723: To check out all the gotchas when building a package, here are the steps that I
                   7724: do in order to get a package working. Please note this is basically the same as
                   7725: what was explained in the previous sections, only with some debugging aids.
                   7726:
1.105     rillig   7727:   * Be sure to set PKG_DEVELOPER=yes in mk.conf.
1.20      ben      7728:
1.1       grant    7729:   * Install pkgtools/url2pkg, create a directory for a new package, change into
                   7730:     it, then run url2pkg:
1.20      ben      7731:
1.1       grant    7732:     % mkdir /usr/pkgsrc/category/examplepkg
                   7733:     % cd /usr/pkgsrc/category/examplepkg
                   7734:     % url2pkg http://www.example.com/path/to/distfile.tar.gz
1.20      ben      7735:
1.1       grant    7736:   * Edit the Makefile as requested.
1.20      ben      7737:
1.1       grant    7738:   * Fill in the DESCR file
1.20      ben      7739:
1.1       grant    7740:   * Run make configure
1.20      ben      7741:
1.1       grant    7742:   * Add any dependencies glimpsed from documentation and the configure step to
                   7743:     the package's Makefile.
1.20      ben      7744:
1.1       grant    7745:   * Make the package compile, doing multiple rounds of
1.20      ben      7746:
1.1       grant    7747:     % make
                   7748:     % pkgvi ${WRKSRC}/some/file/that/does/not/compile
                   7749:     % mkpatches
                   7750:     % patchdiff
                   7751:     % mv ${WRKDIR}/.newpatches/* patches
                   7752:     % make mps
                   7753:     % make clean
1.20      ben      7754:
1.88      wiz      7755:     Doing this step as non-root user will ensure that no files are modified
                   7756:     that shouldn't be, especially during the build phase. mkpatches, patchdiff
                   7757:     and pkgvi are from the pkgtools/pkgdiff package.
1.20      ben      7758:
1.107     rillig   7759:   * Look at the Makefile, fix if necessary; see Section 11.1, "Makefile".
1.20      ben      7760:
1.1       grant    7761:   * Generate a PLIST:
1.20      ben      7762:
1.1       grant    7763:     # make install
                   7764:     # make print-PLIST >PLIST
                   7765:     # make deinstall
                   7766:     # make install
                   7767:     # make deinstall
1.20      ben      7768:
1.1       grant    7769:     You usually need to be root to do this. Look if there are any files left:
1.20      ben      7770:
1.1       grant    7771:     # make print-PLIST
1.20      ben      7772:
1.1       grant    7773:     If this reveals any files that are missing in PLIST, add them.
1.20      ben      7774:
1.1       grant    7775:   * Now that the PLIST is OK, install the package again and make a binary
                   7776:     package:
1.20      ben      7777:
1.1       grant    7778:     # make reinstall
                   7779:     # make package
1.20      ben      7780:
1.1       grant    7781:   * Delete the installed package:
1.20      ben      7782:
1.88      wiz      7783:     # pkg_delete examplepkg
1.20      ben      7784:
1.1       grant    7785:   * Repeat the above make print-PLIST command, which shouldn't find anything
                   7786:     now:
1.20      ben      7787:
1.1       grant    7788:     # make print-PLIST
1.20      ben      7789:
1.1       grant    7790:   * Reinstall the binary package:
1.20      ben      7791:
1.93      rillig   7792:     # pkg_add .../examplepkg.tgz
1.20      ben      7793:
1.1       grant    7794:   * Play with it. Make sure everything works.
1.20      ben      7795:
1.1       grant    7796:   * Run pkglint from pkgtools/pkglint, and fix the problems it reports:
1.20      ben      7797:
1.1       grant    7798:     # pkglint
1.20      ben      7799:
1.107     rillig   7800:   * Submit (or commit, if you have cvs access); see Chapter 21, Submitting and
1.1       grant    7801:     Committing.
1.20      ben      7802:
1.107     rillig   7803: Chapter 21. Submitting and Committing
1.1       grant    7804:
                   7805: Table of Contents
                   7806:
1.107     rillig   7807: 21.1. Submitting binary packages
                   7808: 21.2. Submitting source packages (for non-NetBSD-developers)
                   7809: 21.3. General notes when adding, updating, or removing packages
                   7810: 21.4. Committing: Importing a package into CVS
                   7811: 21.5. Updating a package to a newer version
1.123     reed     7812: 21.6. Renaming a package in pkgsrc
                   7813: 21.7. Moving a package in pkgsrc
1.74      rillig   7814:
1.107     rillig   7815: 21.1. Submitting binary packages
1.74      rillig   7816:
                   7817: Our policy is that we accept binaries only from pkgsrc developers to guarantee
                   7818: that the packages don't contain any trojan horses etc. This is not to annoy
                   7819: anyone but rather to protect our users! You're still free to put up your
                   7820: home-made binary packages and tell the world where to get them. NetBSD
                   7821: developers doing bulk builds and wanting to upload them please see
1.107     rillig   7822: Section 7.3.8, "Uploading results of a bulk build".
1.74      rillig   7823:
1.107     rillig   7824: 21.2. Submitting source packages (for non-NetBSD-developers)
1.74      rillig   7825:
                   7826: First, check that your package is complete, compiles and runs well; see
1.107     rillig   7827: Chapter 20, Debugging and the rest of this document. Next, generate an
1.82      rillig   7828: uuencoded gzipped tar(1) archive that contains all files that make up the
1.87      wiz      7829: package. Finally, send this package to the pkgsrc bug tracking system, either
                   7830: with the send-pr(1) command, or if you don't have that, go to the web page
1.104     wiz      7831: http://www.NetBSD.org/support/send-pr.html, which contains some instructions
1.125     snj      7832: and a link to a form where you can submit packages. The sysutils/gtk-send-pr
                   7833: package is also available as a substitute for either of the above two tools.
1.87      wiz      7834:
                   7835: In the form of the problem report, the category should be "pkg", the synopsis
                   7836: should include the package name and version number, and the description field
                   7837: should contain a short description of your package (contents of the COMMENT
                   7838: variable or DESCR file are OK). The uuencoded package data should go into the
                   7839: "fix" field.
1.74      rillig   7840:
                   7841: If you want to submit several packages, please send a separate PR for each one,
                   7842: it's easier for us to track things that way.
                   7843:
                   7844: Alternatively, you can also import new packages into pkgsrc-wip ("pkgsrc
                   7845: work-in-progress"); see the homepage at http://pkgsrc-wip.sourceforge.net/ for
                   7846: details.
1.20      ben      7847:
1.107     rillig   7848: 21.3. General notes when adding, updating, or removing packages
1.41      wiz      7849:
                   7850: Please note all package additions, updates, moves, and removals in pkgsrc/doc/
1.93      rillig   7851: CHANGES-YYYY. It's very important to keep this file up to date and conforming
                   7852: to the existing format, because it will be used by scripts to automatically
                   7853: update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/
                   7854: doc/TODO file and remove the entry for the package you updated or removed, in
                   7855: case it was mentioned there.
1.41      wiz      7856:
1.71      wiz      7857: When the PKGREVISION of a package is bumped, the change should appear in pkgsrc
1.93      rillig   7858: /doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps
                   7859: that result from a dependency being updated should not be mentioned. In all
                   7860: other cases it's the developer's decision.
1.71      wiz      7861:
1.93      rillig   7862: There is a make target that helps in creating proper CHANGES-YYYY entries: make
1.41      wiz      7863: changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The
1.93      rillig   7864: general usage is to first make sure that your CHANGES-YYYY file is up-to-date
                   7865: (to avoid having to resolve conflicts later-on) and then to cd to the package
1.41      wiz      7866: directory. For package updates, make changes-entry is enough. For new packages,
                   7867: or package moves or removals, set the CTYPE variable on the command line to
1.105     rillig   7868: "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if
1.126     wiz      7869: your local login name is not the same as your NetBSD login name. The target
                   7870: also automatically removes possibly existing entries for the package in the
                   7871: TODO file. Don't forget to commit the changes, e.g. by using make
                   7872: changes-entry-commit! If you are not using a checkout directly from
1.128     jakllsch 7873: cvs.NetBSD.org, but e.g. a local copy of the repository, you can set
1.126     wiz      7874: USE_NETBSD_REPO=yes. This makes the cvs commands use the main repository.
1.41      wiz      7875:
1.107     rillig   7876: 21.4. Committing: Importing a package into CVS
1.1       grant    7877:
                   7878: This section is only of interest for pkgsrc developers with write access to the
                   7879: pkgsrc repository. Please remember that cvs imports files relative to the
                   7880: current working directory, and that the pathname that you give the cvs import
                   7881: command is so that it knows where to place the files in the repository. Newly
                   7882: created packages should be imported with a vendor tag of "TNF" and a release
                   7883: tag of "pkgsrc-base", e.g:
                   7884:
1.101     rillig   7885: $ cd .../pkgsrc/category/pkgname
                   7886: $ cvs import pkgsrc/category/pkgname TNF pkgsrc-base
1.1       grant    7887:
                   7888: Remember to move the directory from which you imported out of the way, or cvs
                   7889: will complain the next time you "cvs update" your source tree. Also don't
                   7890: forget to add the new package to the category's Makefile.
                   7891:
                   7892: The commit message of the initial import should include part of the DESCR file,
                   7893: so people reading the mailing lists know what the package is/does.
                   7894:
                   7895: For new packages, "cvs import" is preferred to "cvs add" because the former
                   7896: gets everything with a single command, and provides a consistent tag.
                   7897:
1.107     rillig   7898: 21.5. Updating a package to a newer version
1.1       grant    7899:
                   7900: Please always put a concise, appropriate and relevant summary of the changes
                   7901: between old and new versions into the commit log when updating a package. There
                   7902: are various reasons for this:
                   7903:
                   7904:   * A URL is volatile, and can change over time. It may go away completely or
                   7905:     its information may be overwritten by newer information.
1.20      ben      7906:
1.1       grant    7907:   * Having the change information between old and new versions in our CVS
                   7908:     repository is very useful for people who use either cvs or anoncvs.
1.20      ben      7909:
1.1       grant    7910:   * Having the change information between old and new versions in our CVS
                   7911:     repository is very useful for people who read the pkgsrc-changes mailing
                   7912:     list, so that they can make tactical decisions about when to upgrade the
                   7913:     package.
1.20      ben      7914:
1.18      xtraeme  7915: Please also recognize that, just because a new version of a package has been
1.1       grant    7916: released, it should not automatically be upgraded in the CVS repository. We
                   7917: prefer to be conservative in the packages that are included in pkgsrc -
                   7918: development or beta packages are not really the best thing for most places in
                   7919: which pkgsrc is used. Please use your judgement about what should go into
                   7920: pkgsrc, and bear in mind that stability is to be preferred above new and
                   7921: possibly untested features.
                   7922:
1.123     reed     7923: 21.6. Renaming a package in pkgsrc
                   7924:
                   7925: Renaming packages is not recommended.
                   7926:
                   7927: When renaming packages, be sure to fix any references to old name in other
                   7928: Makefiles, options, buildlink files, etc.
                   7929:
                   7930: Also When renaming a package, please define SUPERSEDES to the package name and
                   7931: dewey version pattern(s) of the previous package name. This may be repeated for
                   7932: multiple renames. The new package would be an exact replacement.
                   7933:
                   7934: Note that "successor" in the CHANGES-YYYY file doesn't necessarily mean that it
                   7935: supersedes, as that successor may not be an exact replacement but is a
                   7936: suggestion for the replaced functionality.
                   7937:
                   7938: 21.7. Moving a package in pkgsrc
                   7939:
                   7940: It is preferred that packages are not renamed or moved, but if needed please
                   7941: follow these steps.
1.1       grant    7942:
                   7943:  1. Make a copy of the directory somewhere else.
1.20      ben      7944:
1.1       grant    7945:  2. Remove all CVS dirs.
1.20      ben      7946:
1.1       grant    7947:     Alternatively to the first two steps you can also do:
1.20      ben      7948:
1.1       grant    7949:     % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
1.20      ben      7950:
1.1       grant    7951:     and use that for further work.
1.20      ben      7952:
1.1       grant    7953:  3. Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of
                   7954:     "../../category/package".
1.20      ben      7955:
1.123     reed     7956:  4. In the modified package's Makefile, consider setting PREV_PKGPATH to the
                   7957:     previous category/package pathname. The PREV_PKGPATH can be used by tools
                   7958:     for doing an update using pkgsrc building; for example, it can search the
                   7959:     pkg_summary(5) database for PREV_PKGPATH (if no SUPERSEDES) and then use
                   7960:     the corresponding new PKGPATH for that moved package. Note that it may have
                   7961:     multiple matches, so the tool should also check on the PKGBASE too. The
                   7962:     PREV_PKGPATH probably has no value unless SUPERSEDES is not set, i.e.
                   7963:     PKGBASE stays the same.
                   7964:
                   7965:  5. cvs import the modified package in the new place.
1.20      ben      7966:
1.123     reed     7967:  6. Check if any package depends on it:
1.20      ben      7968:
1.1       grant    7969:     % cd /usr/pkgsrc
                   7970:     % grep /package */*/Makefile* */*/buildlink*
1.20      ben      7971:
1.123     reed     7972:  7. Fix paths in packages from step 5 to point to new location.
1.20      ben      7973:
1.123     reed     7974:  8. cvs rm (-f) the package at the old location.
1.20      ben      7975:
1.123     reed     7976:  9. Remove from oldcategory/Makefile.
1.20      ben      7977:
1.123     reed     7978: 10. Add to newcategory/Makefile.
1.20      ben      7979:
1.123     reed     7980: 11. Commit the changed and removed files:
1.20      ben      7981:
1.1       grant    7982:     % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
1.20      ben      7983:
1.1       grant    7984:     (and any packages from step 5, of course).
1.20      ben      7985:
1.107     rillig   7986: Chapter 22. Frequently Asked Questions
1.72      rillig   7987:
                   7988: This section contains the answers to questions that may arise when you are
                   7989: writing a package. If you don't find your question answered here, first have a
                   7990: look in the other chapters, and if you still don't have the answer, ask on the
                   7991: pkgsrc-users mailing list.
                   7992:
1.107     rillig   7993: 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
                   7994: 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
                   7995: 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
                   7996: 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
1.72      rillig   7997:     BUILDLINK_LIBS?
1.107     rillig   7998: 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
                   7999: 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
1.78      rillig   8000:     the := inside it.
1.107     rillig   8001: 22.7. Which mailing lists are there for package developers?
                   8002: 22.8. Where is the pkgsrc documentation?
                   8003: 22.9. I have a little time to kill. What shall I do?
1.72      rillig   8004:
1.107     rillig   8005: 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
1.72      rillig   8006:
                   8007:       MAKEFLAGS are the flags passed to the pkgsrc-internal invocations of make
                   8008:       (1), while MAKE_FLAGS are the flags that are passed to the MAKE_PROGRAM
                   8009:       when building the package. [FIXME: What is .MAKEFLAGS for?]
                   8010:
1.107     rillig   8011: 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
1.72      rillig   8012:
                   8013:       MAKE is the path to the make(1) program that is used in the pkgsrc
                   8014:       infrastructure. GMAKE is the path to GNU Make, but you need to say
                   8015:       USE_TOOLS+=gmake to use that. MAKE_PROGRAM is the path to the Make
                   8016:       program that is used for building the package.
                   8017:
1.107     rillig   8018: 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
1.72      rillig   8019:
                   8020:       CC is the path to the real C compiler, which can be configured by the
                   8021:       pkgsrc user. PKG_CC is the path to the compiler wrapper. PKGSRC_COMPILER
                   8022:       is not a path to a compiler, but the type of compiler that should be
                   8023:       used. See mk/compiler.mk for more information about the latter variable.
                   8024:
1.107     rillig   8025: 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
1.72      rillig   8026:       BUILDLINK_LIBS?
                   8027:
                   8028:       [FIXME]
                   8029:
1.107     rillig   8030: 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
1.72      rillig   8031:
                   8032:       For optimization reasons, some variables are only available in the
                   8033:       "wrapper" phase and later. To "simulate" the wrapper phase, append
                   8034:       PKG_PHASE=wrapper to the above command.
                   8035:
1.107     rillig   8036: 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
1.78      rillig   8037:       the := inside it.
                   8038:
                   8039:       The := is not really an assignment operator, like you might expect at
                   8040:       first sight. Instead, it is a degenerate form of ${LIST:old_string=
                   8041:       new_string}, which is documented in the make(1) man page and which you
                   8042:       may have seen as in ${SRCS:.c=.o}. In the case of MASTER_SITE_*,
                   8043:       old_string is the empty string and new_string is package/. That's where
                   8044:       the : and the = fall together.
                   8045:
1.107     rillig   8046: 22.7. Which mailing lists are there for package developers?
1.78      rillig   8047:
                   8048:       tech-pkg
                   8049:
                   8050:           This is a list for technical discussions related to pkgsrc
                   8051:           development, e.g. soliciting feedback for changes to pkgsrc
                   8052:           infrastructure, proposed new features, questions related to porting
                   8053:           pkgsrc to a new platform, advice for maintaining a package, patches
                   8054:           that affect many packages, help requests moved from pkgsrc-users when
                   8055:           an infrastructure bug is found, etc.
                   8056:
                   8057:       pkgsrc-bugs
                   8058:
                   8059:           All bug reports in category "pkg" sent with send-pr(1) appear here.
                   8060:           Please do not report your bugs here directly; use one of the other
                   8061:           mailing lists.
                   8062:
1.107     rillig   8063: 22.8. Where is the pkgsrc documentation?
1.80      rillig   8064:
                   8065:       There are many places where you can find documentation about pkgsrc:
                   8066:
                   8067:         * The pkgsrc guide (this document) is a collection of chapters that
                   8068:           explain large parts of pkgsrc, but some chapters tend to be outdated.
                   8069:           Which ones they are is hard to say.
                   8070:
                   8071:         * On the mailing list archives (see http://mail-index.NetBSD.org/), you
                   8072:           can find discussions about certain features, announcements of new
                   8073:           parts of the pkgsrc infrastructure and sometimes even announcements
                   8074:           that a certain feature has been marked as obsolete. The benefit here
                   8075:           is that each message has a date appended to it.
                   8076:
                   8077:         * Many of the files in the mk/ directory start with a comment that
                   8078:           describes the purpose of the file and how it can be used by the
1.92      rillig   8079:           pkgsrc user and package authors. An easy way to find this
                   8080:           documentation is to run bmake help.
1.80      rillig   8081:
                   8082:         * The CVS log messages are a rich source of information, but they tend
                   8083:           to be highly abbreviated, especially for actions that occur often.
                   8084:           Some contain a detailed description of what has changed, but they are
                   8085:           geared towards the other pkgsrc developers, not towards an average
                   8086:           pkgsrc user. They also only document changes, so if you don't know
                   8087:           what has been before, these messages may not be worth too much to
                   8088:           you.
                   8089:
                   8090:         * Some parts of pkgsrc are only "implicitly documented", that is the
                   8091:           documentation exists only in the mind of the developer who wrote the
1.93      rillig   8092:           code. To get this information, use the cvs annotate command to see
                   8093:           who has written it and ask on the tech-pkg mailing list, so that
1.80      rillig   8094:           others can find your questions later (see above). To be sure that the
                   8095:           developer in charge reads the mail, you may CC him or her.
                   8096:
1.107     rillig   8097: 22.9. I have a little time to kill. What shall I do?
1.92      rillig   8098:
                   8099:       This is not really an FAQ yet, but here's the answer anyway.
                   8100:
                   8101:         * Run pkg_chk -N (from the pkgtools/pkg_chk package). It will tell you
                   8102:           about newer versions of installed packages that are available, but
                   8103:           not yet updated in pkgsrc.
                   8104:
                   8105:         * Browse pkgsrc/doc/TODO ? it contains a list of suggested new packages
                   8106:           and a list of cleanups and enhancements for pkgsrc that would be nice
                   8107:           to have.
                   8108:
                   8109:         * Review packages for which review was requested on the pkgsrc-wip
                   8110:           review mailing list.
                   8111:
1.107     rillig   8112: Chapter 23. GNOME packaging and porting
1.85      jmmv     8113:
                   8114: Table of Contents
                   8115:
1.107     rillig   8116: 23.1. Meta packages
                   8117: 23.2. Packaging a GNOME application
                   8118: 23.3. Updating GNOME to a newer version
                   8119: 23.4. Patching guidelines
1.85      jmmv     8120:
                   8121: Quoting GNOME's web site:
                   8122:
                   8123:     The GNOME project provides two things: The GNOME desktop environment, an
                   8124:     intuitive and attractive desktop for users, and the GNOME development
                   8125:     platform, an extensive framework for building applications that integrate
                   8126:     into the rest of the desktop.
                   8127:
                   8128: pkgsrc provides a seamless way to automatically build and install a complete
                   8129: GNOME environment under many different platforms. We can say with confidence
                   8130: that pkgsrc is one of the most advanced build and packaging systems for GNOME
                   8131: due to its included technologies buildlink3, the wrappers and tools framework
                   8132: and automatic configuration file management. Lots of efforts are put into
                   8133: achieving a completely clean deinstallation of installed software components.
                   8134:
                   8135: Given that pkgsrc is NetBSD's official packaging system, the above also means
                   8136: that great efforts are put into making GNOME work under this operating system.
                   8137: Recently, DragonFly BSD also adopted pkgsrc as its preferred packaging system,
                   8138: contributing lots of portability fixes to make GNOME build and install under
                   8139: it.
                   8140:
                   8141: This chapter is aimed at pkgsrc developers and other people interested in
                   8142: helping our GNOME porting and packaging efforts. It provides instructions on
                   8143: how to manage the existing packages and some important information regarding
                   8144: their internals.
                   8145:
                   8146: We need your help!
                   8147:
                   8148: Should you have some spare cycles to devote to NetBSD, pkgsrc and GNOME and are
                   8149: willing to learn new exciting stuff, please jump straight to the pending work
                   8150: list! There is still a long way to go to get a fully-functional GNOME desktop
                   8151: under NetBSD and we need your help to achieve it!
                   8152:
1.107     rillig   8153: 23.1. Meta packages
1.85      jmmv     8154:
                   8155: pkgsrc includes three GNOME-related meta packages:
                   8156:
                   8157:   * meta-pkgs/gnome-base: Provides the core GNOME desktop environment. It only
                   8158:     includes the necessary bits to get it to boot correctly, although it may
                   8159:     lack important functionality for daily operation. The idea behind this
                   8160:     package is to let end users build their own configurations on top of this
                   8161:     one, first installing this meta package to achieve a functional setup and
                   8162:     then adding individual applications.
                   8163:
                   8164:   * meta-pkgs/gnome: Provides a complete installation of the GNOME platform and
                   8165:     desktop as defined by the GNOME project; this is based on the components
                   8166:     distributed in the platform/x.y/x.y.z/sources and desktop/x.y/x.y.z/sources
                   8167:     directories of the official FTP server. Developer-only tools found in those
                   8168:     directories are not installed unless required by some other component to
                   8169:     work properly. Similarly, packages from the bindings set (bindings/x.y/
                   8170:     x.y.z/sources) are not pulled in unless required as a dependency for an
                   8171:     end-user component. This package "extends" meta-pkgs/gnome-base.
                   8172:
                   8173:   * meta-pkgs/gnome-devel: Installs all the tools required to build a GNOME
                   8174:     component when fetched from the CVS repository. These are required to let
                   8175:     the autogen.sh scripts work appropriately.
                   8176:
                   8177: In all these packages, the DEPENDS lines are sorted in a way that eases
                   8178: updates: a package may depend on other packages listed before it but not on any
                   8179: listed after it. It is very important to keep this order to ease updates so...
                   8180: do not change it to alphabetical sorting!
                   8181:
1.107     rillig   8182: 23.2. Packaging a GNOME application
1.85      jmmv     8183:
                   8184: Almost all GNOME applications are written in C and use a common set of tools as
                   8185: their build system. Things get different with the new bindings to other
                   8186: languages (such as Python), but the following will give you a general idea on
                   8187: the minimum required tools:
                   8188:
                   8189:   * Almost all GNOME applications use the GNU Autotools as their build system.
                   8190:     As a general rule you will need to tell this to your package:
                   8191:
                   8192:     GNU_CONFIGURE=yes
                   8193:     USE_LIBTOOL=yes
                   8194:     USE_TOOLS+=gmake
                   8195:
                   8196:   * If the package uses pkg-config to detect dependencies, add this tool to the
                   8197:     list of required utilities:
                   8198:
                   8199:     USE_TOOLS+=pkg-config
                   8200:
                   8201:     Also use pkgtools/verifypc at the end of the build process to ensure that
                   8202:     you did not miss to specify any dependency in your package and that the
                   8203:     version requirements are all correct.
                   8204:
1.93      rillig   8205:   * If the package uses intltool, be sure to add intltool to the USE_TOOLS to
                   8206:     handle dependencies and to force the package to use the latest available
                   8207:     version.
1.85      jmmv     8208:
                   8209:   * If the package uses gtk-doc (a documentation generation utility), do not
                   8210:     add a dependency on it. The tool is rather big and the distfile should come
                   8211:     with pregenerated documentation anyway; if it does not, it is a bug that
                   8212:     you ought to report. For such packages you should disable gtk-doc (unless
1.89      rillig   8213:     it is the default):
1.85      jmmv     8214:
                   8215:     CONFIGURE_ARGS+=--disable-gtk-doc
1.89      rillig   8216:
                   8217:     The default location of installed HTML files (share/gtk-doc/<package-name>)
                   8218:     is correct and should not be changed unless the package insists on
                   8219:     installing them somewhere else. Otherwise programs as devhelp will not be
                   8220:     able to open them. You can do that with an entry similar to:
                   8221:
                   8222:     CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
1.85      jmmv     8223:
                   8224: GNOME uses multiple shared directories and files under the installation prefix
                   8225: to maintain databases. In this context, shared means that those exact same
                   8226: directories and files are used among several different packages, leading to
                   8227: conflicts in the PLIST. pkgsrc currently includes functionality to handle the
                   8228: most common cases, so you have to forget about using @unexec ${RMDIR} lines in
                   8229: your file lists and omitting shared files from them. If you find yourself doing
                   8230: those, your package is most likely incorrect.
                   8231:
                   8232: The following table lists the common situations that result in using shared
                   8233: directories or files. For each of them, the appropriate solution is given.
                   8234: After applying the solution be sure to regenerate the package's file list with
                   8235: make print-PLIST and ensure it is correct.
                   8236:
1.107     rillig   8237: Table 23.1. PLIST handling for GNOME packages
1.85      jmmv     8238:
                   8239: +-----------------------------------------------------------------------------+
                   8240: |             If the package...             |             Then...             |
                   8241: |-------------------------------------------+---------------------------------|
1.107     rillig   8242: |                                           |See Section 19.6.10, "Packages   |
1.120     mishka   8243: |Installs OMF files under share/omf.        |installing scrollkeeper/rarian   |
                   8244: |                                           |data files".                     |
1.85      jmmv     8245: |-------------------------------------------+---------------------------------|
1.107     rillig   8246: |Installs icons under the share/icons/      |See Section 19.6.19, "Packages   |
1.85      jmmv     8247: |hicolor hierarchy or updates share/icons/  |installing hicolor theme icons". |
                   8248: |hicolor/icon-theme.cache.                  |                                 |
                   8249: |-------------------------------------------+---------------------------------|
1.107     rillig   8250: |                                           |See Section 19.6.14, "Packages   |
1.85      jmmv     8251: |Installs files under share/mime/packages.  |installing extensions to the MIME|
                   8252: |                                           |database".                       |
                   8253: |-------------------------------------------+---------------------------------|
1.107     rillig   8254: |Installs .desktop files under share/       |See Section 19.6.20, "Packages   |
1.85      jmmv     8255: |applications and these include MIME        |installing desktop files".       |
                   8256: |information.                               |                                 |
                   8257: +-----------------------------------------------------------------------------+
                   8258:
1.91      rillig   8259:
1.107     rillig   8260: 23.3. Updating GNOME to a newer version
1.85      jmmv     8261:
                   8262: When seeing GNOME as a whole, there are two kinds of updates:
                   8263:
                   8264: Major update
                   8265:
                   8266:     Given that there is still a very long way for GNOME 3 (if it ever appears),
                   8267:     we consider a major update one that goes from a 2.X version to a 2.Y one,
                   8268:     where Y is even and greater than X. These are hard to achieve because they
                   8269:     introduce lots of changes in the components' code and almost all GNOME
                   8270:     distfiles are updated to newer versions. Some of them can even break API
                   8271:     and ABI compatibility with the previous major version series. As a result,
                   8272:     the update needs to be done all at once to minimize breakage.
                   8273:
                   8274:     A major update typically consists of around 80 package updates and the
                   8275:     addition of some new ones.
                   8276:
                   8277: Minor update
                   8278:
                   8279:     We consider a minor update one that goes from a 2.A.X version to a 2.A.Y
                   8280:     one where Y is greater than X. These are easy to achieve because they do
                   8281:     not update all GNOME components, can be done in an incremental way and do
                   8282:     not break API nor ABI compatibility.
                   8283:
                   8284:     A minor update typically consists of around 50 package updates, although
                   8285:     the numbers here may vary a lot.
                   8286:
                   8287: In order to update the GNOME components in pkgsrc to a new stable release
                   8288: (either major or minor), the following steps should be followed:
                   8289:
                   8290:  1. Get a list of all the tarballs that form the new release by using the
1.121     snj      8291:     following commands. These will leave the full list of the components'
1.85      jmmv     8292:     distfiles into the list.txt file:
                   8293:
1.88      wiz      8294:     % echo ls "*.tar.bz2" | \
1.85      jmmv     8295:         ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
                   8296:         awk '{ print $9 }' >list.txt
1.88      wiz      8297:     % echo ls "*.tar.bz2" | \
1.85      jmmv     8298:         ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
                   8299:         awk '{ print $9 }' >>list.txt
                   8300:
                   8301:  2. Open each meta package's Makefile and bump their version to the release you
                   8302:     are updating them to. The three meta packages should be always consistent
                   8303:     with versioning. Obviously remove any PKGREVISIONs that might be in them.
                   8304:
                   8305:  3. For each meta package, update all its DEPENDS lines to match the latest
                   8306:     versions as shown by the above commands. Do not list any newer version
                   8307:     (even if found in the FTP) because the meta packages are supposed to list
                   8308:     the exact versions that form a specific GNOME release. Exceptions are
                   8309:     permitted here if a newer version solves a serious issue in the overall
                   8310:     desktop experience; these typically come in the form of a revision bump in
                   8311:     pkgsrc, not in newer versions from the developers.
                   8312:
                   8313:     Packages not listed in the list.txt file should be updated to the latest
                   8314:     version available (if found in pkgsrc). This is the case, for example, of
                   8315:     the dependencies on the GNU Autotools in the meta-pkgs/gnome-devel meta
                   8316:     package.
                   8317:
                   8318:  4. Generate a patch from the modified meta packages and extract the list of
                   8319:     "new" lines. This will provide you an outline on what packages need to be
                   8320:     updated in pkgsrc and in what order:
                   8321:
1.93      rillig   8322:     % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt
1.85      jmmv     8323:
                   8324:  5. For major desktop updates it is recommended to zap all your installed
                   8325:     packages and start over from scratch at this point.
                   8326:
                   8327:  6. Now comes the longest step by far: iterate over the contents of todo.txt
                   8328:     and update the packages listed in it in order. For major desktop updates
1.93      rillig   8329:     none of these should be committed until the entire set is completed because
1.85      jmmv     8330:     there are chances of breaking not-yet-updated packages.
                   8331:
                   8332:  7. Once the packages are up to date and working, commit them to the tree one
                   8333:     by one with appropriate log messages. At the end, commit the three meta
                   8334:     package updates and all the corresponding changes to the doc/CHANGES-<YEAR>
                   8335:     and pkgsrc/doc/TODO files.
                   8336:
1.107     rillig   8337: 23.4. Patching guidelines
1.85      jmmv     8338:
                   8339: GNOME is a very big component in pkgsrc which approaches 100 packages. Please,
                   8340: it is very important that you always, always, always feed back any portability
                   8341: fixes you do to a GNOME package to the mainstream developers (see
1.107     rillig   8342: Section 11.3.5, "Feedback to the author"). This is the only way to get their
1.85      jmmv     8343: attention on portability issues and to ensure that future versions can be built
                   8344: out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further
                   8345: updates are. Those developers in charge of issuing major GNOME updates will be
                   8346: grateful if you do that.
                   8347:
                   8348: The most common places to report bugs are the GNOME's Bugzilla and the
                   8349: freedesktop.org's Bugzilla. Not all components use these to track bugs, but
                   8350: most of them do. Do not be short on your reports: always provide detailed
                   8351: explanations of the current failure, how it can be improved to achieve maximum
                   8352: portability and, if at all possible, provide a patch against CVS head. The more
                   8353: verbose you are, the higher chances of your patch being accepted.
                   8354:
                   8355: Also, please avoid using preprocessor magic to fix portability issues. While
                   8356: the FreeBSD GNOME people are doing a great job in porting GNOME to their
                   8357: operating system, the official GNOME sources are now plagued by conditionals
                   8358: that check for __FreeBSD__ and similar macros. This hurts portability. Please
1.107     rillig   8359: see our patching guidelines (Section 11.3.4, "Patching guidelines") for more
1.85      jmmv     8360: details.
                   8361:
1.73      rillig   8362: Part III. The pkgsrc infrastructure internals
                   8363:
                   8364: This part of the guide deals with everything from the infrastructure that is
                   8365: behind the interfaces described in the developer's guide. A casual package
                   8366: maintainer should not need anything from this part.
1.72      rillig   8367:
                   8368: Table of Contents
                   8369:
1.107     rillig   8370: 24. Design of the pkgsrc infrastructure
1.73      rillig   8371:
1.107     rillig   8372:     24.1. The meaning of variable definitions
                   8373:     24.2. Avoiding problems before they arise
                   8374:     24.3. Variable evaluation
1.81      rillig   8375:
1.107     rillig   8376:         24.3.1. At load time
                   8377:         24.3.2. At runtime
1.73      rillig   8378:
1.107     rillig   8379:     24.4. How can variables be specified?
                   8380:     24.5. Designing interfaces for Makefile fragments
1.73      rillig   8381:
1.107     rillig   8382:         24.5.1. Procedures with parameters
                   8383:         24.5.2. Actions taken on behalf of parameters
1.73      rillig   8384:
1.107     rillig   8385:     24.6. The order in which files are loaded
1.81      rillig   8386:
1.107     rillig   8387:         24.6.1. The order in bsd.prefs.mk
                   8388:         24.6.2. The order in bsd.pkg.mk
1.73      rillig   8389:
1.107     rillig   8390: 25. Regression tests
1.73      rillig   8391:
1.107     rillig   8392:     25.1. The regression tests framework
                   8393:     25.2. Running the regression tests
                   8394:     25.3. Adding a new regression test
1.73      rillig   8395:
1.107     rillig   8396:         25.3.1. Overridable functions
                   8397:         25.3.2. Helper functions
1.73      rillig   8398:
1.107     rillig   8399: 26. Porting pkgsrc
1.73      rillig   8400:
1.107     rillig   8401:     26.1. Porting pkgsrc to a new operating system
                   8402:     26.2. Adding support for a new compiler
1.73      rillig   8403:
1.107     rillig   8404: Chapter 24. Design of the pkgsrc infrastructure
1.73      rillig   8405:
                   8406: Table of Contents
                   8407:
1.107     rillig   8408: 24.1. The meaning of variable definitions
                   8409: 24.2. Avoiding problems before they arise
                   8410: 24.3. Variable evaluation
1.81      rillig   8411:
1.107     rillig   8412:     24.3.1. At load time
                   8413:     24.3.2. At runtime
1.81      rillig   8414:
1.107     rillig   8415: 24.4. How can variables be specified?
                   8416: 24.5. Designing interfaces for Makefile fragments
1.73      rillig   8417:
1.107     rillig   8418:     24.5.1. Procedures with parameters
                   8419:     24.5.2. Actions taken on behalf of parameters
1.73      rillig   8420:
1.107     rillig   8421: 24.6. The order in which files are loaded
1.73      rillig   8422:
1.107     rillig   8423:     24.6.1. The order in bsd.prefs.mk
                   8424:     24.6.2. The order in bsd.pkg.mk
1.73      rillig   8425:
                   8426: The pkgsrc infrastructure consists of many small Makefile fragments. Each such
                   8427: fragment needs a properly specified interface. This chapter explains how such
                   8428: an interface looks like.
                   8429:
1.107     rillig   8430: 24.1. The meaning of variable definitions
1.81      rillig   8431:
                   8432: Whenever a variable is defined in the pkgsrc infrastructure, the location and
                   8433: the way of definition provide much information about the intended use of that
                   8434: variable. Additionally, more documentation may be found in a header comment or
                   8435: in this pkgsrc guide.
                   8436:
                   8437: A special file is mk/defaults/mk.conf, which lists all variables that are
                   8438: intended to be user-defined. They are either defined using the ?= operator or
                   8439: they are left undefined because defining them to anything would effectively
                   8440: mean "yes". All these variables may be overridden by the pkgsrc user in the
                   8441: MAKECONF file.
                   8442:
                   8443: Outside this file, the following conventions apply: Variables that are defined
                   8444: using the ?= operator may be overridden by a package.
                   8445:
                   8446: Variables that are defined using the = operator may be used read-only at
                   8447: run-time.
                   8448:
                   8449: Variables whose name starts with an underscore must not be accessed outside the
                   8450: pkgsrc infrastructure at all. They may change without further notice.
                   8451:
                   8452: Note
1.73      rillig   8453:
1.81      rillig   8454: These conventions are currently not applied consistently to the complete pkgsrc
                   8455: infrastructure.
                   8456:
1.107     rillig   8457: 24.2. Avoiding problems before they arise
1.81      rillig   8458:
                   8459: All variables that contain lists of things should default to being empty. Two
                   8460: examples that do not follow this rule are USE_LANGUAGES and DISTFILES. These
                   8461: variables cannot simply be modified using the += operator in package Makefiles
                   8462: (or other files included by them), since there is no guarantee whether the
                   8463: variable is already set or not, and what its value is. In the case of
                   8464: DISTFILES, the packages "know" the default value and just define it as in the
                   8465: following example.
                   8466:
1.101     rillig   8467: DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
1.81      rillig   8468:
                   8469: Because of the selection of this default value, the same value appears in many
                   8470: package Makefiles. Similarly for USE_LANGUAGES, but in this case the default
                   8471: value ("c") is so short that it doesn't stand out. Nevertheless it is mentioned
                   8472: in many files.
                   8473:
1.107     rillig   8474: 24.3. Variable evaluation
1.81      rillig   8475:
1.107     rillig   8476: 24.3.1. At load time
1.73      rillig   8477:
                   8478: Variable evaluation takes place either at load time or at runtime, depending on
                   8479: the context in which they occur. The contexts where variables are evaluated at
                   8480: load time are:
                   8481:
                   8482:   * The right hand side of the := and != operators,
                   8483:
                   8484:   * Make directives like .if or .for,
                   8485:
                   8486:   * Dependency lines.
                   8487:
                   8488: A special exception are references to the iteration variables of .for loops,
                   8489: which are expanded inline, no matter in which context they appear.
                   8490:
                   8491: As the values of variables may change during load time, care must be taken not
                   8492: to evaluate them by accident. Typical examples for variables that should not be
                   8493: evaluated at load time are DEPENDS and CONFIGURE_ARGS. To make the effect more
                   8494: clear, here is an example:
                   8495:
1.101     rillig   8496: CONFIGURE_ARGS=         # none
                   8497: CFLAGS=                 -O
                   8498: CONFIGURE_ARGS+=        CFLAGS=${CFLAGS:Q}
1.73      rillig   8499:
1.101     rillig   8500: CONFIGURE_ARGS:=        ${CONFIGURE_ARGS}
1.73      rillig   8501:
1.101     rillig   8502: CFLAGS+=                -Wall
1.73      rillig   8503:
                   8504:
                   8505: This code shows how the use of the := operator can quickly lead to unexpected
                   8506: results. The first paragraph is fairly common code. The second paragraph
                   8507: evaluates the CONFIGURE_ARGS variable, which results in CFLAGS=-O. In the third
                   8508: paragraph, the -Wall is appended to the CFLAGS, but this addition will not
                   8509: appear in CONFIGURE_ARGS. In actual code, the three paragraphs from above
                   8510: typically occur in completely unrelated files.
                   8511:
1.107     rillig   8512: 24.3.2. At runtime
1.73      rillig   8513:
                   8514: After all the files have been loaded, the values of the variables cannot be
                   8515: changed anymore. Variables that are used in the shell commands are expanded at
                   8516: this point.
                   8517:
1.107     rillig   8518: 24.4. How can variables be specified?
1.78      rillig   8519:
                   8520: There are many ways in which the definition and use of a variable can be
                   8521: restricted in order to detect bugs and violations of the (mostly unwritten)
                   8522: policies. See the pkglint developer's documentation for further details.
                   8523:
1.107     rillig   8524: 24.5. Designing interfaces for Makefile fragments
1.73      rillig   8525:
                   8526: Most of the .mk files fall into one of the following classes. Cases where a
                   8527: file falls into more than one class should be avoided as it often leads to
                   8528: subtle bugs.
                   8529:
1.107     rillig   8530: 24.5.1. Procedures with parameters
1.73      rillig   8531:
                   8532: In a traditional imperative programming language some of the .mk files could be
1.128     jakllsch 8533: described as procedures. They take some input parameters and?after
                   8534: inclusion?provide a result in output parameters. Since all variables in
                   8535: Makefiles have global scope care must be taken not to use parameter names that
                   8536: have already another meaning. For example, PKGNAME is a bad choice for a
                   8537: parameter name.
1.73      rillig   8538:
                   8539: Procedures are completely evaluated at preprocessing time. That is, when
                   8540: calling a procedure all input parameters must be completely resolvable. For
                   8541: example, CONFIGURE_ARGS should never be an input parameter since it is very
                   8542: likely that further text will be added after calling the procedure, which would
                   8543: effectively apply the procedure to only a part of the variable. Also,
                   8544: references to other variables wit will be modified after calling the procedure.
                   8545:
                   8546: A procedure can declare its output parameters either as suitable for use in
                   8547: preprocessing directives or as only available at runtime. The latter
                   8548: alternative is for variables that contain references to other runtime
                   8549: variables.
                   8550:
                   8551: Procedures shall be written such that it is possible to call the procedure more
                   8552: than once. That is, the file must not contain multiple-inclusion guards.
1.72      rillig   8553:
1.73      rillig   8554: Examples for procedures are mk/bsd.options.mk and mk/buildlink3/bsd.builtin.mk.
                   8555: To express that the parameters are evaluated at load time, they should be
                   8556: assigned using the := operator, which should be used only for this purpose.
1.72      rillig   8557:
1.107     rillig   8558: 24.5.2. Actions taken on behalf of parameters
1.72      rillig   8559:
1.73      rillig   8560: Action files take some input parameters and may define runtime variables. They
                   8561: shall not define loadtime variables. There are action files that are included
                   8562: implicitly by the pkgsrc infrastructure, while other must be included
                   8563: explicitly.
1.72      rillig   8564:
1.73      rillig   8565: An example for action files is mk/subst.mk.
1.72      rillig   8566:
1.107     rillig   8567: 24.6. The order in which files are loaded
1.81      rillig   8568:
                   8569: Package Makefiles usually consist of a set of variable definitions, and include
                   8570: the file ../../mk/bsd.pkg.mk in the very last line. Before that, they may also
                   8571: include various other *.mk files if they need to query the availability of
                   8572: certain features like the type of compiler or the X11 implementation. Due to
                   8573: the heavy use of preprocessor directives like .if and .for, the order in which
                   8574: the files are loaded matters.
                   8575:
                   8576: This section describes at which point the various files are loaded and gives
                   8577: reasons for that order.
                   8578:
1.107     rillig   8579: 24.6.1. The order in bsd.prefs.mk
1.81      rillig   8580:
1.93      rillig   8581: The very first action in bsd.prefs.mk is to define some essential variables
                   8582: like OPSYS, OS_VERSION and MACHINE_ARCH.
1.81      rillig   8583:
1.105     rillig   8584: Then, the user settings are loaded from the file specified in MAKECONF, which
                   8585: is usually mk.conf. After that, those variables that have not been overridden
                   8586: by the user are loaded from mk/defaults/mk.conf.
1.81      rillig   8587:
                   8588: After the user settings, the system settings and platform settings are loaded,
                   8589: which may override the user settings.
                   8590:
                   8591: Then, the tool definitions are loaded. The tool wrappers are not yet in effect.
                   8592: This only happens when building a package, so the proper variables must be used
                   8593: instead of the direct tool names.
                   8594:
                   8595: As the last steps, some essential variables from the wrapper and the package
                   8596: system flavor are loaded, as well as the variables that have been cached in
                   8597: earlier phases of a package build.
                   8598:
1.107     rillig   8599: 24.6.2. The order in bsd.pkg.mk
1.81      rillig   8600:
                   8601: First, bsd.prefs.mk is loaded.
                   8602:
                   8603: Then, the various *-vars.mk files are loaded, which fill default values for
1.93      rillig   8604: those variables that have not been defined by the package. These variables may
                   8605: later be used even in unrelated files.
1.81      rillig   8606:
                   8607: Then, the file bsd.pkg.error.mk provides the target error-check that is added
                   8608: as a special dependency to all other targets that use DELAYED_ERROR_MSG or
                   8609: DELAYED_WARNING_MSG.
                   8610:
                   8611: Then, the package-specific hacks from hacks.mk are included.
                   8612:
                   8613: Then, various other files follow. Most of them don't have any dependencies on
                   8614: what they need to have included before or after them, though some do.
                   8615:
                   8616: The code to check PKG_FAIL_REASON and PKG_SKIP_REASON is then executed, which
                   8617: restricts the use of these variables to all the files that have been included
                   8618: before. Appearances in later files will be silently ignored.
                   8619:
                   8620: Then, the files for the main targets are included, in the order of later
                   8621: execution, though the actual order should not matter.
                   8622:
                   8623: At last, some more files are included that don't set any interesting variables
                   8624: but rather just define make targets to be executed.
                   8625:
1.107     rillig   8626: Chapter 25. Regression tests
1.72      rillig   8627:
                   8628: Table of Contents
                   8629:
1.107     rillig   8630: 25.1. The regression tests framework
                   8631: 25.2. Running the regression tests
                   8632: 25.3. Adding a new regression test
1.72      rillig   8633:
1.107     rillig   8634:     25.3.1. Overridable functions
                   8635:     25.3.2. Helper functions
1.72      rillig   8636:
                   8637: The pkgsrc infrastructure consists of a large codebase, and there are many
                   8638: corners where every little bit of a file is well thought out, making pkgsrc
                   8639: likely to fail as soon as anything is changed near those parts. To prevent most
                   8640: changes from breaking anything, a suite of regression tests should go along
                   8641: with every important part of the pkgsrc infrastructure. This chapter describes
                   8642: how regression tests work in pkgsrc and how you can add new tests.
                   8643:
1.107     rillig   8644: 25.1. The regression tests framework
1.72      rillig   8645:
1.107     rillig   8646: 25.2. Running the regression tests
1.72      rillig   8647:
                   8648: You first need to install the pkgtools/pkg_regress package, which provides the
                   8649: pkg_regress command. Then you can simply run that command, which will run all
                   8650: tests in the regress category.
                   8651:
1.107     rillig   8652: 25.3. Adding a new regression test
1.72      rillig   8653:
                   8654: Every directory in the regress category that contains a file called spec is
                   8655: considered a regression test. This file is a shell program that is included by
                   8656: the pkg_regress command. The following functions can be overridden to suit your
                   8657: needs.
                   8658:
1.107     rillig   8659: 25.3.1. Overridable functions
1.72      rillig   8660:
                   8661: These functions do not take any parameters. They are all called in "set -e"
                   8662: mode, so you should be careful to check the exitcodes of any commands you run
                   8663: in the test.
                   8664:
                   8665: do_setup()
                   8666:
                   8667:     This function prepares the environment for the test. By default it does
                   8668:     nothing.
                   8669:
                   8670: do_test()
                   8671:
                   8672:     This function runs the actual test. By default, it calls TEST_MAKE with the
                   8673:     arguments MAKEARGS_TEST and writes its output including error messages into
                   8674:     the file TEST_OUTFILE.
                   8675:
                   8676: check_result()
                   8677:
                   8678:     This function is run after the test and is typically used to compare the
                   8679:     actual output from the one that is expected. It can make use of the various
                   8680:     helper functions from the next section.
                   8681:
                   8682: do_cleanup()
                   8683:
                   8684:     This function cleans everything up after the test has been run. By default
                   8685:     it does nothing.
                   8686:
1.107     rillig   8687: 25.3.2. Helper functions
1.72      rillig   8688:
                   8689: exit_status(expected)
                   8690:
                   8691:     This function compares the exitcode of the do_test() function with its
                   8692:     first parameter. If they differ, the test will fail.
                   8693:
                   8694: output_require(regex...)
                   8695:
                   8696:     This function checks for each of its parameters if the output from do_test
                   8697:     () matches the extended regular expression. If it does not, the test will
                   8698:     fail.
                   8699:
                   8700: output_prohibit(regex...)
                   8701:
                   8702:     This function checks for each of its parameters if the output from do_test
                   8703:     () does not match the extended regular expression. If any of the regular
                   8704:     expressions matches, the test will fail.
                   8705:
1.107     rillig   8706: Chapter 26. Porting pkgsrc
1.79      rillig   8707:
                   8708: Table of Contents
                   8709:
1.107     rillig   8710: 26.1. Porting pkgsrc to a new operating system
                   8711: 26.2. Adding support for a new compiler
1.69      rillig   8712:
                   8713: The pkgsrc system has already been ported to many operating systems, hardware
                   8714: architectures and compilers. This chapter explains the necessary steps to make
                   8715: pkgsrc even more portable.
                   8716:
1.107     rillig   8717: 26.1. Porting pkgsrc to a new operating system
1.69      rillig   8718:
                   8719: To port pkgsrc to a new operating system (called MyOS in this example), you
                   8720: need to touch the following files:
                   8721:
1.93      rillig   8722: pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk
1.69      rillig   8723:
                   8724:     This file contains some basic definitions, for example the name of the C
                   8725:     compiler.
                   8726:
                   8727: mk/bsd.prefs.mk
                   8728:
                   8729:     Insert code that defines the variables OPSYS, OS_VERSION, LOWER_OS_VERSION,
                   8730:     LOWER_VENDOR, MACHINE_ARCH, OBJECT_FMT, APPEND_ELF, and the other variables
                   8731:     that appear in this file.
                   8732:
                   8733: mk/platform/MyOS.mk
                   8734:
                   8735:     This file contains the platform-specific definitions that are used by
                   8736:     pkgsrc. Start by copying one of the other files and edit it to your needs.
                   8737:
                   8738: mk/platform/MyOS.pkg.dist
                   8739:
                   8740:     This file contains a list of directories, together with their permission
                   8741:     bits and ownership. These directories will be created automatically with
1.99      wiz      8742:     every package that explicitly sets USE_MTREE. This feature will be removed.
1.69      rillig   8743:
                   8744: mk/platform/MyOS.x11.dist
                   8745:
                   8746:     Just copy one of the pre-existing x11.dist files to your MyOS.x11.dist.
                   8747:
                   8748: mk/tools/bootstrap.mk
                   8749:
                   8750:     On some operating systems, the tools that are provided with the base system
                   8751:     are not good enough for pkgsrc. For example, there are many versions of sed
                   8752:     (1) that have a narrow limit on the line length they can process. Therefore
                   8753:     pkgsrc brings its own tools, which can be enabled here.
                   8754:
1.93      rillig   8755: mk/tools/tools.MyOS.mk
1.69      rillig   8756:
                   8757:     This file defines the paths to all the tools that are needed by one or the
                   8758:     other package in pkgsrc, as well as by pkgsrc itself. Find out where these
                   8759:     tools are on your platform and add them.
                   8760:
                   8761: Now, you should be able to build some basic packages, like lang/perl5, shells/
                   8762: bash.
                   8763:
1.107     rillig   8764: 26.2. Adding support for a new compiler
1.69      rillig   8765:
                   8766: TODO
                   8767:
1.46      gdt      8768: Appendix A. A simple example package: bison
1.1       grant    8769:
                   8770: Table of Contents
                   8771:
1.46      gdt      8772: A.1. files
1.20      ben      8773:
1.46      gdt      8774:     A.1.1. Makefile
                   8775:     A.1.2. DESCR
                   8776:     A.1.3. PLIST
                   8777:     A.1.4. Checking a package with pkglint
1.20      ben      8778:
1.46      gdt      8779: A.2. Steps for building, installing, packaging
1.1       grant    8780:
                   8781: We checked to find a piece of software that wasn't in the packages collection,
1.20      ben      8782: and picked GNU bison. Quite why someone would want to have bison when Berkeley
1.1       grant    8783: yacc is already present in the tree is beyond us, but it's useful for the
                   8784: purposes of this exercise.
                   8785:
1.46      gdt      8786: A.1. files
1.1       grant    8787:
1.46      gdt      8788: A.1.1. Makefile
1.1       grant    8789:
1.101     rillig   8790: # $NetBSD$
                   8791: #
1.51      rillig   8792:
1.101     rillig   8793: DISTNAME=       bison-1.25
                   8794: CATEGORIES=     devel
                   8795: MASTER_SITES=   ${MASTER_SITE_GNU}
                   8796:
                   8797: MAINTAINER=     thorpej@NetBSD.org
                   8798: HOMEPAGE=       http://www.gnu.org/software/bison/bison.html
                   8799: COMMENT=        GNU yacc clone
1.1       grant    8800:
1.101     rillig   8801: GNU_CONFIGURE=  yes
                   8802: INFO_FILES=     bison.info
1.1       grant    8803:
1.101     rillig   8804: .include "../../mk/bsd.pkg.mk"
1.1       grant    8805:
1.46      gdt      8806: A.1.2. DESCR
1.1       grant    8807:
1.101     rillig   8808: GNU version of yacc.  Can make re-entrant parsers, and numerous other
                   8809: improvements.  Why you would want this when Berkeley yacc(1) is part
                   8810: of the NetBSD source tree is beyond me.
1.1       grant    8811:
1.46      gdt      8812: A.1.3. PLIST
1.1       grant    8813:
1.101     rillig   8814: @comment $NetBSD$
                   8815: bin/bison
                   8816: man/man1/bison.1.gz
                   8817: share/bison.simple
                   8818: share/bison.hairy
1.1       grant    8819:
1.46      gdt      8820: A.1.4. Checking a package with pkglint
1.1       grant    8821:
                   8822: The NetBSD package system comes with pkgtools/pkglint which helps to check the
                   8823: contents of these files. After installation it is quite easy to use, just
                   8824: change to the directory of the package you wish to examine and execute pkglint:
                   8825:
                   8826: $ pkglint
                   8827: looks fine.
                   8828:
1.60      rillig   8829: Depending on the supplied command line arguments (see pkglint(1)), more checks
                   8830: will be performed. Use e.g. pkglint -Call -Wall for a very thorough check.
1.1       grant    8831:
1.46      gdt      8832: A.2. Steps for building, installing, packaging
1.1       grant    8833:
                   8834: Create the directory where the package lives, plus any auxiliary directories:
                   8835:
                   8836: # cd /usr/pkgsrc/lang
                   8837: # mkdir bison
                   8838: # cd bison
                   8839: # mkdir patches
                   8840:
1.107     rillig   8841: Create Makefile, DESCR and PLIST (see Chapter 11, Package components - files,
1.1       grant    8842: directories and contents) then continue with fetching the distfile:
                   8843:
                   8844: # make fetch
                   8845: >> bison-1.25.tar.gz doesn't seem to exist on this system.
                   8846: >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
                   8847: Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
                   8848: ftp: Error retrieving file: 500 Internal error
                   8849:
                   8850: >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
                   8851: Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
                   8852: ftp: Error retrieving file: 500 Internal error
                   8853:
                   8854: >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
                   8855: Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
                   8856: Successfully retrieved file.
                   8857:
                   8858: Generate the checksum of the distfile into distinfo:
                   8859:
1.88      wiz      8860: # make makedistinfo
1.1       grant    8861:
                   8862: Now compile:
                   8863:
                   8864: # make
                   8865: >> Checksum OK for bison-1.25.tar.gz.
                   8866: ===>  Extracting for bison-1.25
                   8867: ===>  Patching for bison-1.25
                   8868: ===>   Ignoring empty patch directory
                   8869: ===>  Configuring for bison-1.25
                   8870: creating cache ./config.cache
                   8871: checking for gcc... cc
                   8872: checking whether we are using GNU C... yes
                   8873: checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
                   8874: checking how to run the C preprocessor... cc -E
                   8875: checking for minix/config.h... no
                   8876: checking for POSIXized ISC... no
                   8877: checking whether cross-compiling... no
                   8878: checking for ANSI C header files... yes
                   8879: checking for string.h... yes
                   8880: checking for stdlib.h... yes
                   8881: checking for memory.h... yes
                   8882: checking for working const... yes
                   8883: checking for working alloca.h... no
                   8884: checking for alloca... yes
                   8885: checking for strerror... yes
                   8886: updating cache ./config.cache
                   8887: creating ./config.status
                   8888: creating Makefile
                   8889: ===>  Building for bison-1.25
                   8890: 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
                   8891: 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
                   8892: 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
                   8893: 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
                   8894: 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
1.20      ben      8895: 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
1.1       grant    8896: 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
                   8897: 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
                   8898: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lalr.c
                   8899: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lex.c
                   8900: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g main.c
                   8901: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g nullable.c
                   8902: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g output.c
                   8903: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g print.c
                   8904: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reader.c
                   8905: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reduce.c
                   8906: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g symtab.c
                   8907: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g warshall.c
                   8908: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g version.c
                   8909: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt.c
                   8910: cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt1.c
                   8911: 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
                   8912: ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
                   8913: rm -f bison.s1
                   8914: sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
                   8915:
                   8916: Everything seems OK, so install the files:
                   8917:
                   8918: # make install
                   8919: >> Checksum OK for bison-1.25.tar.gz.
                   8920: ===>  Installing for bison-1.25
                   8921: sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
                   8922: rm -f /usr/pkg/bin/bison
                   8923: cd /usr/pkg/share; rm -f bison.simple bison.hairy
                   8924: rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
                   8925: install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
                   8926: /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
                   8927: /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
                   8928: cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
                   8929: /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
                   8930: ===>  Registering installation for bison-1.25
                   8931:
                   8932: You can now use bison, and also - if you decide so - remove it with pkg_delete
                   8933: bison. Should you decide that you want a binary package, do this now:
                   8934:
                   8935: # make package
                   8936: >> Checksum OK for bison-1.25.tar.gz.
                   8937: ===>  Building package for bison-1.25
                   8938: Creating package bison-1.25.tgz
                   8939: Registering depends:.
                   8940: Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
                   8941:
                   8942: Now that you don't need the source and object files any more, clean up:
                   8943:
                   8944: # make clean
                   8945: ===>  Cleaning for bison-1.25
                   8946:
1.46      gdt      8947: Appendix B. Build logs
1.1       grant    8948:
                   8949: Table of Contents
                   8950:
1.46      gdt      8951: B.1. Building figlet
                   8952: B.2. Packaging figlet
1.1       grant    8953:
1.46      gdt      8954: B.1. Building figlet
1.1       grant    8955:
                   8956: # make
                   8957: ===> Checking for vulnerabilities in figlet-2.2.1nb2
                   8958: => figlet221.tar.gz doesn't seem to exist on this system.
                   8959: => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
                   8960: => [172219 bytes]
                   8961: Connected to ftp.plig.net.
                   8962: 220 ftp.plig.org NcFTPd Server (licensed copy) ready.
                   8963: 331 Guest login ok, send your complete e-mail address as password.
                   8964: 230-You are user #5 of 500 simultaneous users allowed.
                   8965: 230-
1.20      ben      8966: 230-  ___ _             _ _
                   8967: 230- |  _| |_ ___   ___| |_|___   ___ ___ ___
1.1       grant    8968: 230- |  _|  _| . |_| . | | | . |_| . |  _| . |
                   8969: 230- |_| |_| |  _|_|  _|_|_|_  |_|___|_| |_  |
                   8970: 230-         |_|   |_|     |___|         |___|
                   8971: 230-
                   8972: 230-** Welcome to ftp.plig.org **
                   8973: 230-
                   8974: 230-Please note that all transfers from this FTP site are logged. If you
                   8975: 230-do not like this, please disconnect now.
                   8976: 230-
1.121     snj      8977: 230-This archive is available via
1.1       grant    8978: 230-
                   8979: 230-HTTP:  http://ftp.plig.org/
                   8980: 230-FTP:   ftp://ftp.plig.org/     (max 500 connections)
                   8981: 230-RSYNC: rsync://ftp.plig.org/   (max  30 connections)
                   8982: 230-
                   8983: 230-Please email comments, bug reports and requests for packages to be
1.20      ben      8984: 230-mirrored to ftp-admin@plig.org.
1.1       grant    8985: 230-
                   8986: 230-
                   8987: 230 Logged in anonymously.
                   8988: Remote system type is UNIX.
                   8989: Using binary mode to transfer files.
                   8990: 200 Type okay.
                   8991: 250 "/pub" is new cwd.
                   8992: 250-"/pub/figlet" is new cwd.
                   8993: 250-
                   8994: 250-Welcome to the figlet archive at ftp.figlet.org
1.20      ben      8995: 250-
1.1       grant    8996: 250-    ftp://ftp.figlet.org/pub/figlet/
                   8997: 250-
                   8998: 250-The official FIGlet web page is:
                   8999: 250-    http://www.figlet.org/
                   9000: 250-
                   9001: 250-If you have questions, please mailto:info@figlet.org. If you want to
                   9002: 250-contribute a font or something else, you can email us.
1.20      ben      9003: 250
1.1       grant    9004: 250 "/pub/figlet/program" is new cwd.
                   9005: 250 "/pub/figlet/program/unix" is new cwd.
                   9006: local: figlet221.tar.gz remote: figlet221.tar.gz
                   9007: 502 Unimplemented command.
                   9008: 227 Entering Passive Mode (195,40,6,41,246,104)
                   9009: 150 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
                   9010: 38% |**************                       | 65800      64.16 KB/s    00:01 ETA
                   9011: 226 Transfer completed.
                   9012: 172219 bytes received in 00:02 (75.99 KB/s)
                   9013: 221 Goodbye.
                   9014: => Checksum OK for figlet221.tar.gz.
                   9015: ===> Extracting for figlet-2.2.1nb2
                   9016: ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found
                   9017: ===> Patching for figlet-2.2.1nb2
                   9018: ===> Applying pkgsrc patches for figlet-2.2.1nb2
                   9019: ===> Overriding tools for figlet-2.2.1nb2
                   9020: ===> Creating toolchain wrappers for figlet-2.2.1nb2
                   9021: ===> Configuring for figlet-2.2.1nb2
                   9022: ===> Building for figlet-2.2.1nb2
                   9023: gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\"  -DDEFAULTFONTFILE=\"standard.flf\"  figlet.c zipio.c crc.c inflate.c -o figlet
                   9024: chmod a+x figlet
                   9025: gcc -O2 -o chkfont chkfont.c
                   9026: => Unwrapping files-to-be-installed.
                   9027: #
                   9028: # make install
                   9029: ===> Checking for vulnerabilities in figlet-2.2.1nb2
                   9030: ===> Installing for figlet-2.2.1nb2
                   9031: install -d -o root -g wheel -m 755 /usr/pkg/bin
                   9032: install -d -o root -g wheel -m 755 /usr/pkg/man/man6
                   9033: mkdir -p /usr/pkg/share/figlet
                   9034: cp figlet /usr/pkg/bin
                   9035: cp chkfont /usr/pkg/bin
                   9036: chmod 555 figlist showfigfonts
                   9037: cp figlist /usr/pkg/bin
                   9038: cp showfigfonts /usr/pkg/bin
                   9039: cp fonts/*.flf /usr/pkg/share/figlet
                   9040: cp fonts/*.flc /usr/pkg/share/figlet
                   9041: cp figlet.6 /usr/pkg/man/man6
                   9042: ===> Registering installation for figlet-2.2.1nb2
                   9043: #
                   9044:
1.46      gdt      9045: B.2. Packaging figlet
1.1       grant    9046:
                   9047: # make package
                   9048: ===> Checking for vulnerabilities in figlet-2.2.1nb2
                   9049: ===> Packaging figlet-2.2.1nb2
                   9050: ===> Building binary package for figlet-2.2.1nb2
                   9051: Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
                   9052: Using SrcDir value of /usr/pkg
1.20      ben      9053: Registering depends:.
1.1       grant    9054: #
                   9055:
1.76      rillig   9056: Appendix C. Directory layout of the pkgsrc FTP server
                   9057:
                   9058: Table of Contents
                   9059:
1.128     jakllsch 9060: C.1. distfiles: The distributed source files
                   9061: C.2. misc: Miscellaneous things
                   9062: C.3. packages: Binary packages
                   9063: C.4. reports: Bulk build reports
                   9064: C.5. current, pkgsrc-20xxQy: source packages
1.76      rillig   9065:
                   9066: As in other big projects, the directory layout of pkgsrc is quite complex for
                   9067: newbies. This chapter explains where you find things on the FTP server. The
1.89      rillig   9068: base directory on ftp.NetBSD.org is /pub/pkgsrc/. On other servers it may be
                   9069: different, but inside this directory, everything should look the same, no
                   9070: matter on which server you are. This directory contains some subdirectories,
                   9071: which are explained below.
1.76      rillig   9072:
1.128     jakllsch 9073: C.1. distfiles: The distributed source files
1.76      rillig   9074:
                   9075: The directory distfiles contains lots of archive files from all pkgsrc
                   9076: packages, which are mirrored here. The subdirectories are called after their
                   9077: package names and are used when the distributed files have names that don't
                   9078: explicitly contain a version number or are otherwise too generic (for example
                   9079: release.tar.gz).
                   9080:
1.128     jakllsch 9081: C.2. misc: Miscellaneous things
1.76      rillig   9082:
                   9083: This directory contains things that individual pkgsrc developers find worth
                   9084: publishing.
                   9085:
1.128     jakllsch 9086: C.3. packages: Binary packages
1.76      rillig   9087:
1.103     rillig   9088: This directory contains binary packages for the various platforms that are
                   9089: supported by pkgsrc. Each subdirectory is of the form OPSYS/ARCH/OSVERSION_TAG.
                   9090: The meaning of these variables is:
                   9091:
                   9092:   * OPSYS is the name of the operating system for which the packages have been
1.110     rillig   9093:     built. The name is taken from the output of the uname command, so it may
                   9094:     differ from the one you are used to hear.
1.103     rillig   9095:
1.109     rillig   9096:   * ARCH is the hardware architecture of the platform for which the packages
1.111     hubertf  9097:     have been built. It also includes the ABI (Application Binary Interface)
                   9098:     for platforms that have several of them.
1.103     rillig   9099:
1.109     rillig   9100:   * OSVERSION is the version of the operating system. For version numbers that
                   9101:     change often (for example NetBSD-current), the often-changing part should
                   9102:     be replaced with an x, for example 4.99.x.
1.103     rillig   9103:
1.128     jakllsch 9104:   * TAG is either 20xxQy for a stable branch, or head for packages built from
1.109     rillig   9105:     the HEAD branch. The latter should only be used when the packages are
                   9106:     updated on a regular basis. Otherwise the date from checking out pkgsrc
                   9107:     should be appended, for example head_20071015.
1.103     rillig   9108:
                   9109: The rationale for exactly this scheme is that the pkgsrc users looking for
                   9110: binary packages can quickly click through the directories on the server and
                   9111: find the best binary packages for their machines. Since they usually know the
                   9112: operating system and the hardware architecture, OPSYS and ARCH are placed
                   9113: first. After these choices, they can select the best combination of OSVERSION
                   9114: and TAG together, since it is usually the case that packages stay compatible
                   9115: between different version of the operating system.
                   9116:
                   9117: In each of these directories, there is a whole binary packages collection for a
                   9118: specific platform. It has a directory called All which contains all binary
                   9119: packages. Besides that, there are various category directories that contain
                   9120: symbolic links to the real binary packages.
1.1       grant    9121:
1.128     jakllsch 9122: C.4. reports: Bulk build reports
1.109     rillig   9123:
                   9124: Here are the reports from bulk builds, for those who want to fix packages that
                   9125: didn't build on some of the platforms. The structure of subdirectories should
1.128     jakllsch 9126: look like the one in Section C.3, "packages: Binary packages".
1.109     rillig   9127:
1.128     jakllsch 9128: C.5. current, pkgsrc-20xxQy: source packages
1.1       grant    9129:
1.76      rillig   9130: These directories contain the "real" pkgsrc, that is the files that define how
                   9131: to create binary packages from source archives.
1.20      ben      9132:
1.76      rillig   9133: The directory pkgsrc contains a snapshot of the CVS repository, which is
1.89      rillig   9134: updated regularly. The file pkgsrc.tar.gz contains the same as the directory,
                   9135: ready to be downloaded as a whole.
1.20      ben      9136:
1.76      rillig   9137: In the directories for the quarterly branches, there is an additional file
1.128     jakllsch 9138: called pkgsrc-20xxQy.tar.gz, which contains the state of pkgsrc when it was
1.76      rillig   9139: branched.
1.20      ben      9140:
1.46      gdt      9141: Appendix D. Editing guidelines for the pkgsrc guide
1.2       hubertf  9142:
                   9143: Table of Contents
                   9144:
1.79      rillig   9145: D.1. Make targets
1.46      gdt      9146: D.2. Procedure
1.1       grant    9147:
1.2       hubertf  9148: This section contains information on editing the pkgsrc guide itself.
1.1       grant    9149:
1.79      rillig   9150: D.1. Make targets
1.1       grant    9151:
1.2       hubertf  9152: The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several
                   9153: files are created from it:
                   9154:
1.23      wiz      9155:   * pkgsrc/doc/pkgsrc.txt
1.20      ben      9156:
1.2       hubertf  9157:   * pkgsrc/doc/pkgsrc.html
1.20      ben      9158:
1.102     rillig   9159:   * http://www.NetBSD.org/docs/pkgsrc/
1.20      ben      9160:
1.102     rillig   9161:   * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.pdf: The PDF version of the pkgsrc
                   9162:     guide.
1.20      ben      9163:
1.102     rillig   9164:   * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps: PostScript version of the
                   9165:     pkgsrc guide.
1.20      ben      9166:
1.46      gdt      9167: D.2. Procedure
1.2       hubertf  9168:
                   9169: The procedure to edit the pkgsrc guide is:
                   9170:
1.83      wiz      9171:  1. Make sure you have the packages needed to regenerate the pkgsrc guide (and
1.79      rillig   9172:     other XML-based NetBSD documentation) installed. These are meta-pkgs/
                   9173:     netbsd-doc for creating the ASCII and HTML versions, and meta-pkgs/
                   9174:     netbsd-doc-print for the PostScript and PDF versions. You will need both
                   9175:     packages installed, to make sure documentation is consistent across all
                   9176:     formats.
                   9177:
                   9178:  2. Run cd doc/guide to get to the right directory. All further steps will take
                   9179:     place here.
1.20      ben      9180:
1.79      rillig   9181:  3. Edit the XML file(s) in files/.
1.20      ben      9182:
1.79      rillig   9183:  4. Run bmake to check the pkgsrc guide for valid XML and to build the final
                   9184:     output files. If you get any errors at this stage, you can just edit the
                   9185:     files, as there are only symbolic links in the working directory, pointing
                   9186:     to the files in files/.
1.20      ben      9187:
1.79      rillig   9188:  5. (cd files && cvs commit)
1.20      ben      9189:
1.79      rillig   9190:  6. Run bmake clean && bmake to regenerate the output files with the proper RCS
                   9191:     Ids.
1.20      ben      9192:
1.91      rillig   9193:  7. Run bmake regen to install and commit the files in both pkgsrc/doc and
                   9194:     htdocs.
                   9195:
                   9196:     Note
1.20      ben      9197:
1.91      rillig   9198:     If you have added, removed or renamed some chapters, you need to
1.83      wiz      9199:     synchronize them using cvs add or cvs delete in the htdocs directory.
1.20      ben      9200:

CVSweb <webmaster@jp.NetBSD.org>