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

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

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
1.135     wiz       230:             14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and
                    231:                 BUILDLINK_ABI_DEPENDS.pkg in buildlink3.mk files
1.20      ben       232:
1.107     rillig    233:         14.3. Writing builtin.mk files
1.20      ben       234:
1.107     rillig    235:             14.3.1. Anatomy of a builtin.mk file
                    236:             14.3.2. Global preferences for native or pkgsrc software
1.20      ben       237:
1.107     rillig    238:     15. The pkginstall framework
1.20      ben       239:
1.107     rillig    240:         15.1. Files and directories outside the installation prefix
1.20      ben       241:
1.107     rillig    242:             15.1.1. Directory manipulation
                    243:             15.1.2. File manipulation
1.20      ben       244:
1.107     rillig    245:         15.2. Configuration files
1.35      jmmv      246:
1.107     rillig    247:             15.2.1. How PKG_SYSCONFDIR is set
                    248:             15.2.2. Telling the software where configuration files are
                    249:             15.2.3. Patching installations
                    250:             15.2.4. Disabling handling of configuration files
1.35      jmmv      251:
1.107     rillig    252:         15.3. System startup scripts
1.35      jmmv      253:
1.107     rillig    254:             15.3.1. Disabling handling of system startup scripts
1.35      jmmv      255:
1.107     rillig    256:         15.4. System users and groups
                    257:         15.5. System shells
1.35      jmmv      258:
1.107     rillig    259:             15.5.1. Disabling shell registration
1.65      hubertf   260:
1.107     rillig    261:         15.6. Fonts
1.65      hubertf   262:
1.107     rillig    263:             15.6.1. Disabling automatic update of the fonts databases
1.35      jmmv      264:
1.107     rillig    265:     16. Options handling
1.35      jmmv      266:
1.107     rillig    267:         16.1. Global default options
                    268:         16.2. Converting packages to use bsd.options.mk
                    269:         16.3. Option Names
1.108     rillig    270:         16.4. Determining the options of dependencies
1.35      jmmv      271:
1.107     rillig    272:     17. The build process
1.35      jmmv      273:
1.107     rillig    274:         17.1. Introduction
                    275:         17.2. Program location
                    276:         17.3. Directories used during the build process
                    277:         17.4. Running a phase
                    278:         17.5. The fetch phase
1.81      rillig    279:
1.107     rillig    280:             17.5.1. What to fetch and where to get it from
                    281:             17.5.2. How are the files fetched?
1.81      rillig    282:
1.107     rillig    283:         17.6. The checksum phase
                    284:         17.7. The extract phase
                    285:         17.8. The patch phase
                    286:         17.9. The tools phase
                    287:         17.10. The wrapper phase
                    288:         17.11. The configure phase
                    289:         17.12. The build phase
                    290:         17.13. The test phase
                    291:         17.14. The install phase
                    292:         17.15. The package phase
                    293:         17.16. Cleaning up
                    294:         17.17. Other helpful targets
1.35      jmmv      295:
1.107     rillig    296:     18. Tools needed for building or running
1.35      jmmv      297:
1.107     rillig    298:         18.1. Tools for pkgsrc builds
                    299:         18.2. Tools needed by packages
                    300:         18.3. Tools provided by platforms
                    301:         18.4. Questions regarding the tools
1.68      rillig    302:
1.107     rillig    303:     19. Making your package work
1.68      rillig    304:
1.107     rillig    305:         19.1. General operation
1.68      rillig    306:
1.107     rillig    307:             19.1.1. Portability of packages
1.130     wiz       308:             19.1.2. How to pull in user-settable variables from mk.conf
1.107     rillig    309:             19.1.3. User interaction
                    310:             19.1.4. Handling licenses
                    311:             19.1.5. Restricted packages
                    312:             19.1.6. Handling dependencies
                    313:             19.1.7. Handling conflicts with other packages
                    314:             19.1.8. Packages that cannot or should not be built
                    315:             19.1.9. Packages which should not be deleted, once installed
                    316:             19.1.10. Handling packages with security problems
                    317:             19.1.11. How to handle incrementing versions when fixing an
1.31      wiz       318:                 existing package
1.107     rillig    319:             19.1.12. Substituting variable text in the package files (the SUBST
1.79      rillig    320:                 framework)
1.20      ben       321:
1.107     rillig    322:         19.2. Fixing problems in the fetch phase
1.20      ben       323:
1.107     rillig    324:             19.2.1. Packages whose distfiles aren't available for plain
1.1       grant     325:                 downloading
1.107     rillig    326:             19.2.2. How to handle modified distfiles with the 'old' name
1.20      ben       327:
1.107     rillig    328:         19.3. Fixing problems in the configure phase
1.20      ben       329:
1.107     rillig    330:             19.3.1. Shared libraries - libtool
                    331:             19.3.2. Using libtool on GNU packages that already support libtool
                    332:             19.3.3. GNU Autoconf/Automake
                    333:
                    334:         19.4. Programming languages
                    335:
                    336:             19.4.1. C, C++, and Fortran
                    337:             19.4.2. Java
                    338:             19.4.3. Packages containing perl scripts
                    339:             19.4.4. Other programming languages
                    340:
                    341:         19.5. Fixing problems in the build phase
                    342:
                    343:             19.5.1. Compiling C and C++ code conditionally
                    344:             19.5.2. How to handle compiler bugs
1.130     wiz       345:             19.5.3. Undefined reference to "..."
1.107     rillig    346:             19.5.4. Running out of memory
                    347:
                    348:         19.6. Fixing problems in the install phase
                    349:
                    350:             19.6.1. Creating needed directories
                    351:             19.6.2. Where to install documentation
                    352:             19.6.3. Installing highscore files
                    353:             19.6.4. Adding DESTDIR support to packages
                    354:             19.6.5. Packages with hardcoded paths to other interpreters
                    355:             19.6.6. Packages installing perl modules
                    356:             19.6.7. Packages installing info files
                    357:             19.6.8. Packages installing man pages
1.108     rillig    358:             19.6.9. Packages installing GConf data files
1.120     mishka    359:             19.6.10. Packages installing scrollkeeper/rarian data files
1.107     rillig    360:             19.6.11. Packages installing X11 fonts
                    361:             19.6.12. Packages installing GTK2 modules
                    362:             19.6.13. Packages installing SGML or XML data
                    363:             19.6.14. Packages installing extensions to the MIME database
                    364:             19.6.15. Packages using intltool
                    365:             19.6.16. Packages installing startup scripts
                    366:             19.6.17. Packages installing TeX modules
                    367:             19.6.18. Packages supporting running binaries in emulation
                    368:             19.6.19. Packages installing hicolor theme icons
                    369:             19.6.20. Packages installing desktop files
                    370:
                    371:         19.7. Marking packages as having problems
                    372:
                    373:     20. Debugging
                    374:     21. Submitting and Committing
                    375:
                    376:         21.1. Submitting binary packages
                    377:         21.2. Submitting source packages (for non-NetBSD-developers)
                    378:         21.3. General notes when adding, updating, or removing packages
                    379:         21.4. Committing: Importing a package into CVS
                    380:         21.5. Updating a package to a newer version
1.123     reed      381:         21.6. Renaming a package in pkgsrc
                    382:         21.7. Moving a package in pkgsrc
1.107     rillig    383:
                    384:     22. Frequently Asked Questions
                    385:     23. GNOME packaging and porting
                    386:
                    387:         23.1. Meta packages
                    388:         23.2. Packaging a GNOME application
                    389:         23.3. Updating GNOME to a newer version
                    390:         23.4. Patching guidelines
1.69      rillig    391:
1.73      rillig    392: III. The pkgsrc infrastructure internals
1.72      rillig    393:
1.107     rillig    394:     24. Design of the pkgsrc infrastructure
1.72      rillig    395:
1.107     rillig    396:         24.1. The meaning of variable definitions
                    397:         24.2. Avoiding problems before they arise
                    398:         24.3. Variable evaluation
1.81      rillig    399:
1.107     rillig    400:             24.3.1. At load time
                    401:             24.3.2. At runtime
1.81      rillig    402:
1.107     rillig    403:         24.4. How can variables be specified?
                    404:         24.5. Designing interfaces for Makefile fragments
1.72      rillig    405:
1.107     rillig    406:             24.5.1. Procedures with parameters
                    407:             24.5.2. Actions taken on behalf of parameters
1.72      rillig    408:
1.107     rillig    409:         24.6. The order in which files are loaded
1.72      rillig    410:
1.107     rillig    411:             24.6.1. The order in bsd.prefs.mk
                    412:             24.6.2. The order in bsd.pkg.mk
1.73      rillig    413:
1.107     rillig    414:     25. Regression tests
1.73      rillig    415:
1.107     rillig    416:         25.1. The regression tests framework
                    417:         25.2. Running the regression tests
                    418:         25.3. Adding a new regression test
1.73      rillig    419:
1.107     rillig    420:             25.3.1. Overridable functions
                    421:             25.3.2. Helper functions
1.73      rillig    422:
1.107     rillig    423:     26. Porting pkgsrc
1.73      rillig    424:
1.107     rillig    425:         26.1. Porting pkgsrc to a new operating system
                    426:         26.2. Adding support for a new compiler
1.69      rillig    427:
1.46      gdt       428: A. A simple example package: bison
1.20      ben       429:
1.46      gdt       430:     A.1. files
1.20      ben       431:
1.46      gdt       432:         A.1.1. Makefile
                    433:         A.1.2. DESCR
                    434:         A.1.3. PLIST
                    435:         A.1.4. Checking a package with pkglint
1.20      ben       436:
1.46      gdt       437:     A.2. Steps for building, installing, packaging
1.20      ben       438:
1.46      gdt       439: B. Build logs
1.20      ben       440:
1.46      gdt       441:     B.1. Building figlet
                    442:     B.2. Packaging figlet
1.20      ben       443:
1.76      rillig    444: C. Directory layout of the pkgsrc FTP server
                    445:
1.128     jakllsch  446:     C.1. distfiles: The distributed source files
                    447:     C.2. misc: Miscellaneous things
                    448:     C.3. packages: Binary packages
                    449:     C.4. reports: Bulk build reports
                    450:     C.5. current, pkgsrc-20xxQy: source packages
1.76      rillig    451:
1.46      gdt       452: D. Editing guidelines for the pkgsrc guide
1.20      ben       453:
1.79      rillig    454:     D.1. Make targets
1.46      gdt       455:     D.2. Procedure
1.20      ben       456:
1.82      rillig    457: List of Tables
                    458:
                    459: 1.1. Platforms supported by pkgsrc
1.107     rillig    460: 11.1. Patching examples
                    461: 23.1. PLIST handling for GNOME packages
1.82      rillig    462:
1.51      rillig    463: Chapter 1. What is pkgsrc?
1.1       grant     464:
                    465: Table of Contents
                    466:
                    467: 1.1. Introduction
1.82      rillig    468:
                    469:     1.1.1. Why pkgsrc?
                    470:     1.1.2. Supported platforms
                    471:
1.1       grant     472: 1.2. Overview
                    473: 1.3. Terminology
1.74      rillig    474:
1.88      wiz       475:     1.3.1. Roles involved in pkgsrc
1.74      rillig    476:
1.1       grant     477: 1.4. Typography
                    478:
                    479: 1.1. Introduction
                    480:
1.82      rillig    481: There is a lot of software freely available for Unix-based systems, which is
                    482: usually available in form of the source code. Before such software can be used,
                    483: it needs to be configured to the local system, compiled and installed, and this
                    484: is exactly what The NetBSD Packages Collection (pkgsrc) does. pkgsrc also has
                    485: some basic commands to handle binary packages, so that not every user has to
                    486: build the packages for himself, which is a time-costly task.
1.1       grant     487:
                    488: pkgsrc currently contains several thousand packages, including:
                    489:
                    490:   * www/apache - The Apache web server
1.20      ben       491:
1.83      wiz       492:   * www/firefox - The Firefox web browser
1.20      ben       493:
1.1       grant     494:   * meta-pkgs/gnome - The GNOME Desktop Environment
1.20      ben       495:
1.1       grant     496:   * meta-pkgs/kde3 - The K Desktop Environment
1.20      ben       497:
1.1       grant     498: ...just to name a few.
                    499:
                    500: pkgsrc has built-in support for handling varying dependencies, such as pthreads
                    501: and X11, and extended features such as IPv6 support on a range of platforms.
                    502:
1.82      rillig    503: 1.1.1. Why pkgsrc?
                    504:
                    505: pkgsrc provides the following key features:
                    506:
                    507:   * Easy building of software from source as well as the creation and
                    508:     installation of binary packages. The source and latest patches are
                    509:     retrieved from a master or mirror download site, checksum verified, then
                    510:     built on your system. Support for binary-only distributions is available
                    511:     for both native platforms and NetBSD emulated platforms.
                    512:
                    513:   * All packages are installed in a consistent directory tree, including
                    514:     binaries, libraries, man pages and other documentation.
                    515:
                    516:   * Package dependencies, including when performing package updates, are
                    517:     handled automatically. The configuration files of various packages are
                    518:     handled automatically during updates, so local changes are preserved.
                    519:
                    520:   * Like NetBSD, pkgsrc is designed with portability in mind and consists of
                    521:     highly portable code. This allows the greatest speed of development when
1.134     spz       522:     porting to a new platform. This portability also ensures that pkgsrc is
1.82      rillig    523:     consistent across all platforms.
                    524:
                    525:   * The installation prefix, acceptable software licenses, international
                    526:     encryption requirements and build-time options for a large number of
                    527:     packages are all set in a simple, central configuration file.
                    528:
                    529:   * The entire source (not including the distribution files) is freely
                    530:     available under a BSD license, so you may extend and adapt pkgsrc to your
                    531:     needs. Support for local packages and patches is available right out of the
                    532:     box, so you can configure it specifically for your environment.
                    533:
1.91      rillig    534: The following principles are basic to pkgsrc:
                    535:
                    536:   * "It should only work if it's right." ? That means, if a package contains
                    537:     bugs, it's better to find them and to complain about them rather than to
                    538:     just install the package and hope that it works. There are numerous checks
                    539:     in pkgsrc that try to find such bugs: Static analysis tools (pkgtools/
                    540:     pkglint), build-time checks (portability of shell scripts), and
                    541:     post-installation checks (installed files, references to shared libraries,
                    542:     script interpreters).
                    543:
                    544:   * "If it works, it should work everywhere" ? Like NetBSD has been ported to
                    545:     many hardware architectures, pkgsrc has been ported to many operating
                    546:     systems. Care is taken that packages behave the same on all platforms.
                    547:
1.82      rillig    548: 1.1.2. Supported platforms
                    549:
                    550: pkgsrc consists of both a source distribution and a binary distribution for
                    551: these operating systems. After retrieving the required source or binaries, you
                    552: can be up and running with pkgsrc in just minutes!
                    553:
1.1       grant     554: pkgsrc was derived from FreeBSD's ports system, and initially developed for
                    555: NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
                    556: platforms:
                    557:
1.82      rillig    558: Table 1.1. Platforms supported by pkgsrc
1.20      ben       559:
1.82      rillig    560: +----------------------------------------------------------------+
                    561: |                  Platform                   |Date Support Added|
                    562: |---------------------------------------------+------------------|
                    563: |NetBSD                                       |     Aug 1997     |
                    564: |---------------------------------------------+------------------|
                    565: |Solaris                                      |     Mar 1999     |
                    566: |---------------------------------------------+------------------|
                    567: |Linux                                        |     Jun 1999     |
                    568: |---------------------------------------------+------------------|
                    569: |Darwin (Mac OS X)                            |     Oct 2001     |
                    570: |---------------------------------------------+------------------|
                    571: |FreeBSD                                      |     Nov 2002     |
                    572: |---------------------------------------------+------------------|
                    573: |OpenBSD                                      |     Nov 2002     |
                    574: |---------------------------------------------+------------------|
                    575: |IRIX                                         |     Dec 2002     |
                    576: |---------------------------------------------+------------------|
                    577: |BSD/OS                                       |     Dec 2003     |
                    578: |---------------------------------------------+------------------|
                    579: |AIX                                          |     Dec 2003     |
                    580: |---------------------------------------------+------------------|
                    581: |Interix (Microsoft Windows Services for Unix)|     Mar 2004     |
                    582: |---------------------------------------------+------------------|
                    583: |DragonFlyBSD                                 |     Oct 2004     |
                    584: |---------------------------------------------+------------------|
                    585: |OSF/1                                        |     Nov 2004     |
1.99      wiz       586: |---------------------------------------------+------------------|
                    587: |HP-UX                                        |     Apr 2007     |
1.130     wiz       588: |---------------------------------------------+------------------|
                    589: |Haiku                                        |     Sep 2010     |
1.82      rillig    590: +----------------------------------------------------------------+
1.20      ben       591:
1.91      rillig    592:
1.1       grant     593: 1.2. Overview
                    594:
1.73      rillig    595: This document is divided into three parts. The first, The pkgsrc user's guide,
1.1       grant     596: describes how one can use one of the packages in the Package Collection, either
                    597: by installing a precompiled binary package, or by building one's own copy using
1.2       hubertf   598: the NetBSD package system. The second part, The pkgsrc developer's guide,
                    599: explains how to prepare a package so it can be easily built by other NetBSD
1.73      rillig    600: users without knowing about the package's building details. The third part, The
                    601: pkgsrc infrastructure internals is intended for those who want to understand
                    602: how pkgsrc is implemented.
1.20      ben       603:
1.73      rillig    604: This document is available in various formats: HTML, PDF, PS, TXT.
1.20      ben       605:
1.1       grant     606: 1.3. Terminology
                    607:
                    608: There has been a lot of talk about "ports", "packages", etc. so far. Here is a
                    609: description of all the terminology used within this document.
                    610:
                    611: Package
1.20      ben       612:
1.1       grant     613:     A set of files and building instructions that describe what's necessary to
                    614:     build a certain piece of software using pkgsrc. Packages are traditionally
                    615:     stored under /usr/pkgsrc.
1.20      ben       616:
1.1       grant     617: The NetBSD package system
1.20      ben       618:
1.1       grant     619:     This is the former name of "pkgsrc". It is part of the NetBSD operating
1.27      rillig    620:     system and can be bootstrapped to run on non-NetBSD operating systems as
                    621:     well. It handles building (compiling), installing, and removing of
                    622:     packages.
1.20      ben       623:
1.1       grant     624: Distfile
1.20      ben       625:
1.1       grant     626:     This term describes the file or files that are provided by the author of
                    627:     the piece of software to distribute his work. All the changes necessary to
                    628:     build on NetBSD are reflected in the corresponding package. Usually the
                    629:     distfile is in the form of a compressed tar-archive, but other types are
                    630:     possible, too. Distfiles are usually stored below /usr/pkgsrc/distfiles.
1.20      ben       631:
1.1       grant     632: Port
1.20      ben       633:
1.1       grant     634:     This is the term used by FreeBSD and OpenBSD people for what we call a
                    635:     package. In NetBSD terminology, "port" refers to a different architecture.
1.20      ben       636:
1.1       grant     637: Precompiled/binary package
1.20      ben       638:
1.1       grant     639:     A set of binaries built with pkgsrc from a distfile and stuffed together in
                    640:     a single .tgz file so it can be installed on machines of the same machine
                    641:     architecture without the need to recompile. Packages are usually generated
                    642:     in /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.
1.20      ben       643:
1.1       grant     644:     Sometimes, this is referred to by the term "package" too, especially in the
                    645:     context of precompiled packages.
1.20      ben       646:
1.1       grant     647: Program
1.20      ben       648:
1.1       grant     649:     The piece of software to be installed which will be constructed from all
1.47      reed      650:     the files in the distfile by the actions defined in the corresponding
1.1       grant     651:     package.
1.20      ben       652:
1.88      wiz       653: 1.3.1. Roles involved in pkgsrc
1.74      rillig    654:
                    655: pkgsrc users
                    656:
                    657:     The pkgsrc users are people who use the packages provided by pkgsrc.
                    658:     Typically they are system administrators. The people using the software
                    659:     that is inside the packages (maybe called "end users") are not covered by
                    660:     the pkgsrc guide.
                    661:
                    662:     There are two kinds of pkgsrc users: Some only want to install pre-built
                    663:     binary packages. Others build the pkgsrc packages from source, either for
                    664:     installing them directly or for building binary packages themselves. For
                    665:     pkgsrc users Part I, "The pkgsrc user's guide" should provide all necessary
                    666:     documentation.
                    667:
                    668: package maintainers
                    669:
                    670:     A package maintainer creates packages as described in Part II, "The pkgsrc
                    671:     developer's guide".
                    672:
                    673: infrastructure developers
                    674:
                    675:     These people are involved in all those files that live in the mk/ directory
                    676:     and below. Only these people should need to read through Part III, "The
                    677:     pkgsrc infrastructure internals", though others might be curious, too.
                    678:
1.1       grant     679: 1.4. Typography
                    680:
                    681: When giving examples for commands, shell prompts are used to show if the
                    682: command should/can be issued as root, or if "normal" user privileges are
1.27      rillig    683: sufficient. We use a # for root's shell prompt, and a % for users' shell
1.1       grant     684: prompt, assuming they use the C-shell or tcsh.
                    685:
1.48      dillo     686: Part I. The pkgsrc user's guide
1.1       grant     687:
                    688: Table of Contents
                    689:
1.59      rillig    690: 2. Where to get pkgsrc and how to keep it up-to-date
1.20      ben       691:
1.75      rillig    692:     2.1. Getting pkgsrc for the first time
                    693:
                    694:         2.1.1. As tar file
1.130     wiz       695:         2.1.2. Via anonymous CVS
1.75      rillig    696:
                    697:     2.2. Keeping pkgsrc up-to-date
                    698:
                    699:         2.2.1. Via tar files
                    700:         2.2.2. Via CVS
1.20      ben       701:
1.1       grant     702: 3. Using pkgsrc on systems other than NetBSD
1.20      ben       703:
1.82      rillig    704:     3.1. Binary distribution
                    705:     3.2. Bootstrapping pkgsrc
                    706:     3.3. Platform-specific notes
                    707:
                    708:         3.3.1. Darwin (Mac OS X)
                    709:         3.3.2. FreeBSD
                    710:         3.3.3. Interix
                    711:         3.3.4. IRIX
                    712:         3.3.5. Linux
                    713:         3.3.6. OpenBSD
                    714:         3.3.7. Solaris
1.20      ben       715:
1.1       grant     716: 4. Using pkgsrc
1.20      ben       717:
1.70      rillig    718:     4.1. Using binary packages
1.20      ben       719:
1.70      rillig    720:         4.1.1. Finding binary packages
                    721:         4.1.2. Installing binary packages
1.82      rillig    722:         4.1.3. Deinstalling packages
                    723:         4.1.4. Getting information about installed packages
                    724:         4.1.5. Checking for security vulnerabilities in installed packages
                    725:         4.1.6. Finding if newer versions of your installed packages are in
                    726:             pkgsrc
                    727:         4.1.7. Other administrative functions
                    728:         4.1.8. A word of warning
1.20      ben       729:
1.1       grant     730:     4.2. Building packages from source
1.20      ben       731:
1.1       grant     732:         4.2.1. Requirements
                    733:         4.2.2. Fetching distfiles
                    734:         4.2.3. How to build and install
1.20      ben       735:
1.38      dillo     736: 5. Configuring pkgsrc
                    737:
1.45      wiz       738:     5.1. General configuration
                    739:     5.2. Variables affecting the build process
1.110     rillig    740:     5.3. Variables affecting the installation process
1.104     wiz       741:     5.4. Selecting and configuring the compiler
1.78      rillig    742:
1.104     wiz       743:         5.4.1. Selecting the compiler
                    744:         5.4.2. Additional flags to the compiler (CFLAGS)
                    745:         5.4.3. Additional flags to the linker (LDFLAGS)
1.78      rillig    746:
1.104     wiz       747:     5.5. Developer/advanced settings
                    748:     5.6. Selecting Build Options
1.20      ben       749:
1.38      dillo     750: 6. Creating binary packages
                    751:
                    752:     6.1. Building a single binary package
                    753:     6.2. Settings for creation of binary packages
                    754:
1.107     rillig    755: 7. Creating binary packages for everything in pkgsrc (bulk builds)
                    756:
                    757:     7.1. Think first, build later
                    758:     7.2. Requirements of a bulk build
                    759:     7.3. Running an old-style bulk build
                    760:
                    761:         7.3.1. Configuration
                    762:         7.3.2. Other environmental considerations
                    763:         7.3.3. Operation
                    764:         7.3.4. What it does
                    765:         7.3.5. Disk space requirements
                    766:         7.3.6. Setting up a sandbox for chrooted builds
                    767:         7.3.7. Building a partial set of packages
                    768:         7.3.8. Uploading results of a bulk build
                    769:
                    770:     7.4. Running a pbulk-style bulk build
                    771:
1.117     rillig    772:         7.4.1. Preparation
                    773:         7.4.2. Configuration
1.107     rillig    774:
                    775:     7.5. Creating a multiple CD-ROM packages collection
                    776:
                    777:         7.5.1. Example of cdpack
                    778:
                    779: 8. Directory layout of the installed files
                    780:
                    781:     8.1. File system layout in ${LOCALBASE}
                    782:     8.2. File system layout in ${VARBASE}
                    783:
                    784: 9. Frequently Asked Questions
                    785:
                    786:     9.1. Are there any mailing lists for pkg-related discussion?
                    787:     9.2. Where's the pkgviews documentation?
                    788:     9.3. Utilities for package management (pkgtools)
                    789:     9.4. How to use pkgsrc as non-root
                    790:     9.5. How to resume transfers when fetching distfiles?
                    791:     9.6. How can I install/use modular X.org from pkgsrc?
                    792:     9.7. How to fetch files from behind a firewall
                    793:     9.8. How do I tell make fetch to do passive FTP?
                    794:     9.9. How to fetch all distfiles at once
1.130     wiz       795:     9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
                    796:     9.11. What does "Could not find bsd.own.mk" mean?
1.107     rillig    797:     9.12. Using 'sudo' with pkgsrc
                    798:     9.13. How do I change the location of configuration files?
                    799:     9.14. Automated security checks
                    800:     9.15. Why do some packages ignore my CFLAGS?
                    801:     9.16. A package does not build. What shall I do?
1.130     wiz       802:     9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
                    803:         conflicts" mean?
1.20      ben       804:
1.59      rillig    805: Chapter 2. Where to get pkgsrc and how to keep it up-to-date
1.1       grant     806:
                    807: Table of Contents
                    808:
1.75      rillig    809: 2.1. Getting pkgsrc for the first time
                    810:
                    811:     2.1.1. As tar file
1.130     wiz       812:     2.1.2. Via anonymous CVS
1.75      rillig    813:
                    814: 2.2. Keeping pkgsrc up-to-date
                    815:
                    816:     2.2.1. Via tar files
                    817:     2.2.2. Via CVS
                    818:
1.91      rillig    819: Before you download and extract the files, you need to decide where you want to
                    820: extract them. When using pkgsrc as root user, pkgsrc is usually installed in /
                    821: usr/pkgsrc. You are though free to install the sources and binary packages
                    822: wherever you want in your filesystem, provided that the pathname does not
                    823: contain white-space or other characters that are interpreted specially by the
                    824: shell and some other programs. A safe bet is to use only letters, digits,
                    825: underscores and dashes.
1.75      rillig    826:
                    827: 2.1. Getting pkgsrc for the first time
                    828:
1.132     wiz       829: Before you download any pkgsrc files, you should decide whether you want the
1.75      rillig    830: current branch or the stable branch. The latter is forked on a quarterly basis
                    831: from the current branch and only gets modified for security updates. The names
                    832: of the stable branches are built from the year and the quarter, for example
1.125     snj       833: 2009Q1.
1.1       grant     834:
1.75      rillig    835: The second step is to decide how you want to download pkgsrc. You can get it as
1.130     wiz       836: a tar file or via CVS. Both ways are described here.
1.1       grant     837:
1.75      rillig    838: 2.1.1. As tar file
1.1       grant     839:
1.75      rillig    840: The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/
                    841: pkgsrc/. There are a number of subdirectories for different purposes, which are
1.76      rillig    842: described in detail in Appendix C, Directory layout of the pkgsrc FTP server.
1.1       grant     843:
1.75      rillig    844: The tar file for the current branch is in the directory current and is called
                    845: pkgsrc.tar.gz. It is autogenerated daily.
                    846:
1.125     snj       847: The tar file for the stable branch 2009Q1 is in the directory pkgsrc-2009Q1 and
                    848: is also called pkgsrc-2009Q1.tar.gz.
1.75      rillig    849:
1.113     weinem    850: To download a pkgsrc stable tarball, run:
                    851:
1.128     jakllsch  852: $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-20xxQy/pkgsrc-20xxQy.tar.gz
1.113     weinem    853:
1.132     wiz       854: Where pkgsrc-20xxQy is the stable branch to be downloaded, for example, "
                    855: pkgsrc-2009Q1".
1.113     weinem    856:
                    857: Then, extract it with:
                    858:
1.128     jakllsch  859: $ tar -xzf pkgsrc-20xxQy.tar.gz -C /usr
1.113     weinem    860:
                    861: This will create the directory pkgsrc/ in /usr/ and all the package source will
                    862: be stored under /usr/pkgsrc/.
                    863:
                    864: To download pkgsrc-current, run:
                    865:
                    866: $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
1.75      rillig    867:
1.130     wiz       868: 2.1.2. Via anonymous CVS
                    869:
                    870: To fetch a specific pkgsrc stable branch, run:
1.1       grant     871:
1.130     wiz       872: $ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-20xxQy -P pkgsrc
1.1       grant     873:
1.132     wiz       874: Where pkgsrc-20xxQy is the stable branch to be checked out, for example, "
                    875: pkgsrc-2009Q1"
1.130     wiz       876:
                    877: This will create the directory pkgsrc/ in your /usr/ directory and all the
                    878: package source will be stored under /usr/pkgsrc/.
1.1       grant     879:
1.130     wiz       880: To fetch the pkgsrc current branch, run:
1.114     weinem    881:
1.130     wiz       882: $ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
1.1       grant     883:
1.130     wiz       884: Refer to list of available CVS mirrors to choose faster one.
1.75      rillig    885:
1.130     wiz       886: If you get error messages from rsh, you need to set CVS_RSH variable. E.g.:
1.75      rillig    887:
1.130     wiz       888: $ cd /usr && env CVS_RSH=ssh cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
1.75      rillig    889:
1.130     wiz       890: Refer to documentation on your command shell how to set CVS_RSH=ssh
                    891: permanently. For Bourne shells, you can set it in your .profile or better
                    892: globally in /etc/profile:
1.1       grant     893:
1.130     wiz       894: # set CVS remote shell command
                    895: CVS_RSH=ssh
                    896: export CVS_RSH
1.113     weinem    897:
1.114     weinem    898: By default, CVS doesn't do things like most people would expect it to do. But
                    899: there is a way to convince CVS, by creating a file called .cvsrc in your home
1.113     weinem    900: directory and saving the following lines to it. This file will save you lots of
                    901: headache and some bug reports, so we strongly recommend it. You can find an
                    902: explanation of this file in the CVS documentation.
1.102     rillig    903:
                    904: # recommended CVS configuration file from the pkgsrc guide
1.130     wiz       905: cvs -q -z3
1.102     rillig    906: checkout -P
1.104     wiz       907: update -dP
                    908: diff -upN
1.102     rillig    909: rdiff -u
1.130     wiz       910: release -d
1.1       grant     911:
1.75      rillig    912: 2.2. Keeping pkgsrc up-to-date
                    913:
                    914: The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you
                    915: have first installed it via a tar file). It saves bandwidth and hard disk
                    916: activity, compared to downloading the tar file again.
                    917:
                    918: 2.2.1. Via tar files
                    919:
                    920: Warning
                    921:
1.77      rillig    922: When updating from a tar file, you first need to completely remove the old
                    923: pkgsrc directory. Otherwise those files that have been removed from pkgsrc in
                    924: the mean time will not be removed on your local disk, resulting in
                    925: inconsistencies. When removing the old files, any changes that you have done to
                    926: the pkgsrc files will be lost after updating. Therefore updating via CVS is
                    927: strongly recommended.
1.1       grant     928:
1.82      rillig    929: Note that by default the distfiles and the binary packages are saved in the
                    930: pkgsrc tree, so don't forget to rescue them before updating. You can also
                    931: configure pkgsrc to use other than the default directories by setting the
                    932: DISTDIR and PACKAGES variables. See Chapter 5, Configuring pkgsrc for the
                    933: details.
                    934:
1.75      rillig    935: To update pkgsrc from a tar file, download the tar file as explained above.
                    936: Then, make sure that you have not made any changes to the files in the pkgsrc
                    937: directory. Remove the pkgsrc directory and extract the new tar file. Done.
                    938:
                    939: 2.2.2. Via CVS
                    940:
1.134     spz       941: To update pkgsrc via CVS, change to the pkgsrc directory and run cvs:
1.113     weinem    942:
1.134     spz       943: $ cd /usr/pkgsrc && cvs update -dP
                    944:
                    945: If you get error messages from rsh, you need to set CVS_RSH variable as
                    946: described above. E.g.:
                    947:
                    948: $ cd /usr/pkgsrc && env CVS_RSH=ssh cvs up -dP
1.75      rillig    949:
                    950: 2.2.2.1. Switching between different pkgsrc branches
                    951:
                    952: When updating pkgsrc, the CVS program keeps track of the branch you selected.
                    953: But if you, for whatever reason, want to switch from the stable branch to the
                    954: current one, you can do it by adding the option "-A" after the "update"
1.132     wiz       955: keyword. To switch from the current branch back to the stable branch, add the "
                    956: -rpkgsrc-2009Q3" option.
1.75      rillig    957:
                    958: 2.2.2.2. What happens to my changes when updating?
                    959:
                    960: When you update pkgsrc, the CVS program will only touch those files that are
                    961: registered in the CVS repository. That means that any packages that you created
                    962: on your own will stay unmodified. If you change files that are managed by CVS,
                    963: later updates will try to merge your changes with those that have been done by
                    964: others. See the CVS manual, chapter "update" for details.
1.59      rillig    965:
1.1       grant     966: Chapter 3. Using pkgsrc on systems other than NetBSD
                    967:
                    968: Table of Contents
                    969:
1.82      rillig    970: 3.1. Binary distribution
                    971: 3.2. Bootstrapping pkgsrc
                    972: 3.3. Platform-specific notes
                    973:
                    974:     3.3.1. Darwin (Mac OS X)
                    975:     3.3.2. FreeBSD
                    976:     3.3.3. Interix
                    977:     3.3.4. IRIX
                    978:     3.3.5. Linux
                    979:     3.3.6. OpenBSD
                    980:     3.3.7. Solaris
                    981:
                    982: 3.1. Binary distribution
                    983:
1.110     rillig    984: See Section 4.1, "Using binary packages".
1.20      ben       985:
1.82      rillig    986: 3.2. Bootstrapping pkgsrc
1.20      ben       987:
1.82      rillig    988: Installing the bootstrap kit from source should be as simple as:
1.1       grant     989:
                    990: # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
                    991: # cd pkgsrc/bootstrap
                    992: # ./bootstrap
                    993:
1.87      wiz       994:
1.59      rillig    995: See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways
                    996: to get pkgsrc before bootstrapping. The given bootstrap command will use the
                    997: defaults of /usr/pkg for the prefix where programs will be installed in, and /
                    998: var/db/pkg for the package database directory where pkgsrc will do its internal
                    999: bookkeeping. However, these can also be set using command-line arguments.
1.1       grant    1000:
1.47      reed     1001: Note
                   1002:
                   1003: The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
                   1004: For examples in this guide, use bmake instead of "make".
                   1005:
1.82      rillig   1006: 3.3. Platform-specific notes
1.1       grant    1007:
                   1008: Here are some platform-specific notes you should be aware of.
                   1009:
1.82      rillig   1010: 3.3.1. Darwin (Mac OS X)
1.1       grant    1011:
1.128     jakllsch 1012: Darwin 5.x and up are supported. Before you start, you will need to download
                   1013: and install the Mac OS X Developer Tools from Apple's Developer Connection. See
                   1014: http://developer.apple.com/macosx/ for details. Also, make sure you install X11
                   1015: (an optional package included with the Developer Tools) if you intend to build
                   1016: packages that use the X11 Window System.
1.1       grant    1017:
1.82      rillig   1018: 3.3.2. FreeBSD
1.1       grant    1019:
                   1020: FreeBSD 4.7 and 5.0 have been tested and are supported, other versions may
                   1021: work.
                   1022:
                   1023: Care should be taken so that the tools that this kit installs do not conflict
                   1024: with the FreeBSD userland tools. There are several steps:
                   1025:
                   1026:  1. FreeBSD stores its ports pkg database in /var/db/pkg. It is therefore
                   1027:     recommended that you choose a different location (e.g. /usr/pkgdb) by using
                   1028:     the --pkgdbdir option to the bootstrap script.
1.20      ben      1029:
1.1       grant    1030:  2. If you do not intend to use the FreeBSD ports tools, it's probably a good
                   1031:     idea to move them out of the way to avoid confusion, e.g.
1.20      ben      1032:
1.1       grant    1033:     # cd /usr/sbin
                   1034:     # mv pkg_add pkg_add.orig
                   1035:     # mv pkg_create pkg_create.orig
                   1036:     # mv pkg_delete pkg_delete.orig
                   1037:     # mv pkg_info pkg_info.orig
1.20      ben      1038:
1.87      wiz      1039:
1.105     rillig   1040:  3. An example mk.conf file will be placed in /etc/mk.conf.example file when
                   1041:     you use the bootstrap script.
1.20      ben      1042:
1.82      rillig   1043: 3.3.3. Interix
1.1       grant    1044:
1.47      reed     1045: Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a
1.1       grant    1046: Unix-like environment with a tighter kernel integration than available with
                   1047: Cygwin. It is part of the Windows Services for Unix package, available for free
1.22      tv       1048: for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU
                   1049: can be downloaded from http://www.microsoft.com/windows/sfu/.
1.1       grant    1050:
1.93      rillig   1051: Services for Unix 3.5 has been tested. 3.0 or 3.1 may work, but are not
                   1052: officially supported. (The main difference in 3.0/3.1 is lack of pthreads, but
                   1053: other parts of libc may also be lacking.)
                   1054:
                   1055: Services for Unix Applications (aka SUA) is an integrated component of Windows
1.130     wiz      1056: Server 2003 R2 (5.2), Windows Vista and Windows Server 2008 (6.0), Windows 7
1.131     wiz      1057: and Windows Server 2008 R2 (6.1). As of this writing, the SUA's Interix 6.0
                   1058: (32bit) and 6.1 (64bit) subsystems have been tested. Other versions may work as
                   1059: well. The Interix 5.x subsystem has not yet been tested with pkgsrc.
1.1       grant    1060:
1.82      rillig   1061: 3.3.3.1. When installing Interix/SFU
1.1       grant    1062:
                   1063: At an absolute minimum, the following packages must be installed from the
                   1064: Windows Services for Unix 3.5 distribution in order to use pkgsrc:
                   1065:
                   1066:   * Utilities -> Base Utilities
1.20      ben      1067:
1.1       grant    1068:   * Interix GNU Components -> (all)
1.20      ben      1069:
1.1       grant    1070:   * Remote Connectivity
1.20      ben      1071:
1.1       grant    1072:   * Interix SDK
1.20      ben      1073:
1.1       grant    1074: When using pkgsrc on Interix, DO NOT install the Utilities subcomponent "UNIX
                   1075: Perl". That is Perl 5.6 without shared module support, installed to /usr/local,
                   1076: and will only cause confusion. Instead, install Perl 5.8 from pkgsrc (or from a
                   1077: binary package).
                   1078:
                   1079: The Remote Connectivity subcomponent "Windows Remote Shell Service" does not
                   1080: need to be installed, but Remote Connectivity itself should be installed in
                   1081: order to have a working inetd.
                   1082:
1.52      tv       1083: During installation you may be asked whether to enable setuid behavior for
                   1084: Interix programs, and whether to make pathnames default to case-sensitive.
1.1       grant    1085: Setuid should be enabled, and case-sensitivity MUST be enabled. (Without
                   1086: case-sensitivity, a large number of packages including perl will not build.)
                   1087:
1.52      tv       1088: NOTE: Newer Windows service packs change the way binary execution works (via
                   1089: the Data Execution Prevention feature). In order to use pkgsrc and other
                   1090: gcc-compiled binaries reliably, a hotfix containing POSIX.EXE, PSXDLL.DLL,
                   1091: PSXRUN.EXE, and PSXSS.EXE (899522 or newer) must be installed. Hotfixes are
1.115     jmcneill 1092: available from Microsoft through a support contract; however, Debian Interix
                   1093: Port has made most Interix hotfixes available for personal use from http://
                   1094: www.debian-interix.net/hotfixes/.
1.52      tv       1095:
1.93      rillig   1096: In addition to the hotfix noted above, it may be necessary to disable Data
                   1097: Execution Prevention entirely to make Interix functional. This may happen only
                   1098: with certain types of CPUs; the cause is not fully understood at this time. If
                   1099: gcc or other applications still segfault repeatedly after installing one of the
                   1100: hotfixes note above, the following option can be added to the appropriate
                   1101: "boot.ini" line on the Windows boot drive: /NoExecute=AlwaysOff (WARNING, this
                   1102: will disable DEP completely, which may be a security risk if applications are
                   1103: often run as a user in the Administrators group!)
                   1104:
1.82      rillig   1105: 3.3.3.2. What to do if Interix/SFU is already installed
1.1       grant    1106:
                   1107: If SFU is already installed and you wish to alter these settings to work with
                   1108: pkgsrc, note the following things.
                   1109:
                   1110:   * To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft Windows
                   1111:     Services for UNIX, then click Change. In the installer, choose Add or
                   1112:     Remove, then uncheck Utilities->UNIX Perl.
1.20      ben      1113:
1.47      reed     1114:   * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change
1.1       grant    1115:     the following registry key:
1.20      ben      1116:
1.1       grant    1117:     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
1.20      ben      1118:
1.1       grant    1119:     Set the DWORD value "obcaseinsensitive" to 0; then reboot.
1.20      ben      1120:
1.1       grant    1121:   * To enable setuid binaries (optional), run REGEDIT.EXE, and change the
                   1122:     following registry key:
1.20      ben      1123:
1.1       grant    1124:     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX
1.20      ben      1125:
1.1       grant    1126:     Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.
1.20      ben      1127:
1.82      rillig   1128: 3.3.3.3. Important notes for using pkgsrc
1.1       grant    1129:
1.52      tv       1130: The package manager (either the pkgsrc "su" user, or the user running
1.1       grant    1131: "pkg_add") must be a member of the local Administrators group. Such a user must
                   1132: also be used to run the bootstrap. This is slightly relaxed from the normal
                   1133: pkgsrc requirement of "root".
                   1134:
                   1135: The package manager should use a umask of 002. "make install" will
                   1136: automatically complain if this is not the case. This ensures that directories
                   1137: written in /var/db/pkg are Administrators-group writeable.
                   1138:
                   1139: The popular Interix binary packages from http://www.interopsystems.com/ use an
                   1140: older version of pkgsrc's pkg_* tools. Ideally, these should NOT be used in
                   1141: conjunction with pkgsrc. If you choose to use them at the same time as the
                   1142: pkgsrc packages, ensure that you use the proper pkg_* tools for each type of
                   1143: binary package.
                   1144:
1.22      tv       1145: The TERM setting used for DOS-type console windows (including those invoked by
                   1146: the csh and ksh startup shortcuts) is "interix". Most systems don't have a
                   1147: termcap/terminfo entry for it, but the following .termcap entry provides
                   1148: adequate emulation in most cases:
                   1149:
1.101     rillig   1150: interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
1.87      wiz      1151:
1.22      tv       1152:
1.82      rillig   1153: 3.3.3.4. Limitations of the Interix platform
1.52      tv       1154:
                   1155: Though Interix suffices as a familiar and flexible substitute for a full
                   1156: Unix-like platform, it has some drawbacks that should be noted for those
                   1157: desiring to make the most of Interix.
                   1158:
1.57      minskim  1159:   * X11:
1.52      tv       1160:
                   1161:     Interix comes with the standard set of X11R6 client libraries, and can run
1.57      minskim  1162:     X11 based applications, but it does not come with an X server. Some options
                   1163:     are StarNet X-Win32, Hummingbird Exceed (available in a trimmed version for
                   1164:     Interix from Interop Systems as the Interop X Server), and the free X11
1.52      tv       1165:     server included with Cygwin.
                   1166:
1.57      minskim  1167:   * X11 acceleration:
1.52      tv       1168:
                   1169:     Because Interix runs in a completely different NT subsystem from Win32
                   1170:     applications, it does not currently support various X11 protocol extensions
                   1171:     for acceleration (such as MIT-SHM or DGA). Most interactive applications to
                   1172:     a local X server will run reasonably fast, but full motion video and other
                   1173:     graphics intensive applications may require a faster-than-expected CPU.
                   1174:
                   1175:   * Audio:
                   1176:
1.53      tv       1177:     Interix has no native support for audio output. For audio support, pkgsrc
                   1178:     uses the esound client/server audio system on Interix. Unlike on most
                   1179:     platforms, the audio/esound package does not contain the esd server
                   1180:     component. To output audio via an Interix host, the emulators/cygwin_esound
                   1181:     package must also be installed.
1.52      tv       1182:
                   1183:   * CD/DVDs, USB, and SCSI:
                   1184:
                   1185:     Direct device access is not currently supported in Interix, so it is not
                   1186:     currently possible to access CD/DVD drives, USB devices, or SCSI devices
                   1187:     through non-filesystem means. Among other things, this makes it impossible
                   1188:     to use Interix directly for CD/DVD burning.
                   1189:
                   1190:   * Tape drives:
                   1191:
                   1192:     Due to the same limitations as for CD-ROMs and SCSI devices, tape drives
                   1193:     are also not directly accessible in Interix. However, support is in work to
                   1194:     make tape drive access possible by using Cygwin as a bridge (similarly to
                   1195:     audio bridged via Cygwin's esound server).
                   1196:
1.82      rillig   1197: 3.3.3.5. Known issues for pkgsrc on Interix
1.52      tv       1198:
                   1199: It is not necessary, in general, to have a "root" user on the Windows system;
                   1200: any member of the local Administrators group will suffice. However, some
                   1201: packages currently assume that the user named "root" is the privileged user. To
                   1202: accommodate these, you may create such a user; make sure it is in the local
                   1203: group Administrators (or your language equivalent).
                   1204:
1.87      wiz      1205: pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time
                   1206: being, install packages as the local Administrator (or your language
1.52      tv       1207: equivalent), or run the following command after installing a package to work
                   1208: around the issue:
                   1209:
                   1210: # chmod -R g+w $PKG_DBDIR
                   1211:
1.87      wiz      1212:
1.82      rillig   1213: 3.3.4. IRIX
1.1       grant    1214:
                   1215: You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro
                   1216: compiler (cc/c89). Please set the CC environment variable according to your
                   1217: preference. If you do not have a license for the MIPSpro compiler suite, you
                   1218: can download a gcc tardist file from http://freeware.sgi.com/.
                   1219:
                   1220: Please note that you will need IRIX 6.5.17 or higher, as this is the earliest
                   1221: version of IRIX providing support for if_indextoname(3), if_nametoindex(3),
                   1222: etc.
                   1223:
1.87      wiz      1224: At this point in time, pkgsrc only supports one ABI at a time. That is, you
                   1225: cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit
                   1226: ABI. If you start out using "abi=n32", that's what all your packages will be
                   1227: built with.
1.1       grant    1228:
                   1229: Therefore, please make sure that you have no conflicting CFLAGS in your
1.105     rillig   1230: environment or the mk.conf. Particularly, make sure that you do not try to link
                   1231: n32 object files with lib64 or vice versa. Check your /etc/compiler.defaults!
1.1       grant    1232:
                   1233: If you have the actual pkgsrc tree mounted via NFS from a different host,
                   1234: please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX
1.47      reed     1235: linker occasionally runs into issues when trying to link over a network-mounted
                   1236: file system.
1.1       grant    1237:
                   1238: The bootstrapping process should set all the right options for programs such as
                   1239: imake(1), but you may want to set some options depending on your local setup.
1.27      rillig   1240: Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages
1.11      ben      1241: for details.
1.1       grant    1242:
1.22      tv       1243: If you are using SGI's MIPSPro compiler, please set
                   1244:
1.101     rillig   1245: PKGSRC_COMPILER=        mipspro
1.87      wiz      1246:
1.22      tv       1247:
1.105     rillig   1248: in mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up
1.22      tv       1249: passing invalid flags to the compiler. Note that bootstrap should create an
                   1250: appropriate mk.conf.example by default.
                   1251:
                   1252: If you have both the MIPSPro compiler chain installed as well as gcc, but want
1.93      rillig   1253: to make sure that MIPSPro is used, please set your PATH to not include the
1.22      tv       1254: location of gcc (often /usr/freeware/bin), and (important) pass the
                   1255: '--preserve-path' flag.
                   1256:
1.82      rillig   1257: 3.3.5. Linux
1.22      tv       1258:
                   1259: Some versions of Linux (for example Debian GNU/Linux) need either libtermcap or
                   1260: libcurses (libncurses). Installing the distributions libncurses-dev package (or
                   1261: equivalent) should fix the problem.
                   1262:
                   1263: pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++
                   1264: Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested.
                   1265:
                   1266: To bootstrap using icc, assuming the default icc installation directory:
                   1267:
1.101     rillig   1268: env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \
                   1269: ac_cv___attribute__=yes ./bootstrap
1.87      wiz      1270:
1.22      tv       1271:
                   1272: Note
                   1273:
                   1274: icc 8.1 needs the `-i-static' argument instead of -static-libcxa.
                   1275:
                   1276: icc supports __attribute__, but the GNU configure test uses a nested function,
                   1277: which icc does not support. #undef'ing __attribute__ has the unfortunate
                   1278: side-effect of breaking many of the Linux header files, which cannot be
                   1279: compiled properly without __attribute__. The test must be overridden so that
                   1280: __attribute__ is assumed supported by the compiler.
                   1281:
1.105     rillig   1282: After bootstrapping, you should set PKGSRC_COMPILER in mk.conf:
1.22      tv       1283:
1.101     rillig   1284: PKGSRC_COMPILER=        icc
1.87      wiz      1285:
1.22      tv       1286:
                   1287: The default installation directory for icc is /opt/intel_cc_80, which is also
                   1288: the pkgsrc default. If you have installed it into a different directory, set
1.105     rillig   1289: ICCBASE in mk.conf:
1.22      tv       1290:
1.101     rillig   1291: ICCBASE=                /opt/icc
1.87      wiz      1292:
1.22      tv       1293:
                   1294: pkgsrc uses the static linking method of the runtime libraries provided by icc,
                   1295: so binaries can be run on other systems which do not have the shared libraries
                   1296: installed.
                   1297:
                   1298: Libtool, however, extracts a list of libraries from the ld(1) command run when
                   1299: linking a C++ shared library and records it, throwing away the -Bstatic and
                   1300: -Bdynamic options interspersed between the libraries. This means that
                   1301: libtool-linked C++ shared libraries will have a runtime dependency on the icc
                   1302: libraries until this is fixed in libtool.
                   1303:
1.82      rillig   1304: 3.3.6. OpenBSD
1.1       grant    1305:
                   1306: OpenBSD 3.0 and 3.2 are tested and supported.
                   1307:
                   1308: Care should be taken so that the tools that this kit installs do not conflict
                   1309: with the OpenBSD userland tools. There are several steps:
                   1310:
                   1311:  1. OpenBSD stores its ports pkg database in /var/db/pkg. It is therefore
                   1312:     recommended that you choose a different location (e.g. /usr/pkgdb) by using
                   1313:     the --pkgdbdir option to the bootstrap script.
1.20      ben      1314:
1.1       grant    1315:  2. If you do not intend to use the OpenBSD ports tools, it's probably a good
                   1316:     idea to move them out of the way to avoid confusion, e.g.
1.20      ben      1317:
1.1       grant    1318:     # cd /usr/sbin
                   1319:     # mv pkg_add pkg_add.orig
                   1320:     # mv pkg_create pkg_create.orig
                   1321:     # mv pkg_delete pkg_delete.orig
                   1322:     # mv pkg_info pkg_info.orig
1.20      ben      1323:
1.87      wiz      1324:
1.105     rillig   1325:  3. An example mk.conf file will be placed in /etc/mk.conf.example file when
                   1326:     you use the bootstrap script. OpenBSD's make program uses mk.conf as well.
                   1327:     You can work around this by enclosing all the pkgsrc-specific parts of the
                   1328:     file with:
1.20      ben      1329:
1.101     rillig   1330:     .ifdef BSD_PKG_MK
                   1331:     # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
                   1332:     .else
                   1333:     # OpenBSD stuff
                   1334:     .endif
1.87      wiz      1335:
1.20      ben      1336:
1.82      rillig   1337: 3.3.7. Solaris
1.1       grant    1338:
                   1339: Solaris 2.6 through 9 are supported on both x86 and sparc. You will need a
                   1340: working C compiler. Both gcc 2.95.3 and Sun WorkShop 5 have been tested.
                   1341:
                   1342: The following packages are required on Solaris 8 for the bootstrap process and
                   1343: to build packages.
                   1344:
                   1345:   * SUNWsprot
1.20      ben      1346:
1.1       grant    1347:   * SUNWarc
1.20      ben      1348:
1.1       grant    1349:   * SUNWbtool
1.20      ben      1350:
1.1       grant    1351:   * SUNWtoo
1.20      ben      1352:
1.1       grant    1353:   * SUNWlibm
1.20      ben      1354:
1.78      rillig   1355: Please note that the use of GNU binutils on Solaris is not supported, as of
                   1356: June 2006.
1.1       grant    1357:
1.70      rillig   1358: Whichever compiler you use, please ensure the compiler tools and your $prefix
                   1359: are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/
                   1360: {bin,sbin}.
                   1361:
1.82      rillig   1362: 3.3.7.1. If you are using gcc
1.1       grant    1363:
                   1364: It makes life much simpler if you only use the same gcc consistently for
                   1365: building all packages.
                   1366:
                   1367: It is recommended that an external gcc be used only for bootstrapping, then
                   1368: either build gcc from lang/gcc or install a binary gcc package, then remove gcc
                   1369: used during bootstrapping.
                   1370:
1.93      rillig   1371: Binary packages of gcc can be found through http://www.sunfreeware.com/.
1.1       grant    1372:
1.82      rillig   1373: 3.3.7.2. If you are using Sun WorkShop
1.1       grant    1374:
                   1375: You will need at least the following packages installed (from WorkShop 5.0)
                   1376:
                   1377:   * SPROcc - Sun WorkShop Compiler C 5.0
1.20      ben      1378:
1.1       grant    1379:   * SPROcpl - Sun WorkShop Compiler C++ 5.0
1.20      ben      1380:
1.1       grant    1381:   * SPROild - Sun WorkShop Incremental Linker
1.20      ben      1382:
1.1       grant    1383:   * SPROlang - Sun WorkShop Compilers common components
1.20      ben      1384:
1.96      rillig   1385: You should set the following variables in your mk.conf file:
1.1       grant    1386:
1.101     rillig   1387: CC=     cc
                   1388: CXX=    CC
                   1389: CPP=    cc -E
                   1390: CXXCPP= CC -E
1.87      wiz      1391:
1.96      rillig   1392: Note
                   1393:
                   1394: The CPP setting might break some packages that use the C preprocessor for
                   1395: processing things other than C source code.
1.1       grant    1396:
1.93      rillig   1397: 3.3.7.3. Building 64-bit binaries with SunPro
1.1       grant    1398:
1.96      rillig   1399: To build 64-bit packages, you just need to have the following lines in your
                   1400: mk.conf file:
1.70      rillig   1401:
1.101     rillig   1402: PKGSRC_COMPILER=        sunpro
                   1403: ABI=                    64
1.87      wiz      1404:
1.96      rillig   1405: Note
1.70      rillig   1406:
1.96      rillig   1407: This setting has been tested for the SPARC architecture. Intel and AMD machines
                   1408: need some more work.
1.1       grant    1409:
1.82      rillig   1410: 3.3.7.4. Common problems
1.68      rillig   1411:
                   1412: Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The
                   1413: workaround is to use another shell for the configure scripts, for example by
1.69      rillig   1414: installing shells/bash and adding the following lines to your mk.conf:
1.68      rillig   1415:
1.101     rillig   1416: CONFIG_SHELL=   ${LOCALBASE}/bin/bash
                   1417: WRAPPER_SHELL=  ${LOCALBASE}/bin/bash
1.87      wiz      1418:
1.68      rillig   1419:
1.71      wiz      1420: Then, rebuild the devel/libtool-base package.
                   1421:
1.1       grant    1422: Chapter 4. Using pkgsrc
                   1423:
                   1424: Table of Contents
                   1425:
1.70      rillig   1426: 4.1. Using binary packages
1.20      ben      1427:
1.70      rillig   1428:     4.1.1. Finding binary packages
                   1429:     4.1.2. Installing binary packages
1.82      rillig   1430:     4.1.3. Deinstalling packages
                   1431:     4.1.4. Getting information about installed packages
                   1432:     4.1.5. Checking for security vulnerabilities in installed packages
                   1433:     4.1.6. Finding if newer versions of your installed packages are in pkgsrc
                   1434:     4.1.7. Other administrative functions
                   1435:     4.1.8. A word of warning
1.20      ben      1436:
1.1       grant    1437: 4.2. Building packages from source
1.20      ben      1438:
1.1       grant    1439:     4.2.1. Requirements
                   1440:     4.2.2. Fetching distfiles
                   1441:     4.2.3. How to build and install
1.20      ben      1442:
1.70      rillig   1443: Basically, there are two ways of using pkgsrc. The first is to only install the
                   1444: package tools and to use binary packages that someone else has prepared. This
                   1445: is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
                   1446: Then you are able to build your own packages, and you can still use binary
                   1447: packages from someone else.
                   1448:
                   1449: 4.1. Using binary packages
                   1450:
1.110     rillig   1451: On the ftp.NetBSD.org server and its mirrors, there are collections of binary
                   1452: packages, ready to be installed. These binary packages have been built using
                   1453: the default settings for the directories, that is:
                   1454:
                   1455:   * /usr/pkg for LOCALBASE, where most of the files are installed,
                   1456:
                   1457:   * /usr/pkg/etc for configuration files,
                   1458:
                   1459:   * /var for VARBASE, where those files are installed that may change after
                   1460:     installation.
                   1461:
                   1462: If you cannot use these directories for whatever reasons (maybe because you're
                   1463: not root), you cannot use these binary packages, but have to build the packages
                   1464: yourself, which is explained in Section 3.2, "Bootstrapping pkgsrc".
1.70      rillig   1465:
                   1466: 4.1.1. Finding binary packages
                   1467:
1.106     weinem   1468: To install binary packages, you first need to know from where to get them. The
                   1469: first place where you should look is on the main pkgsrc FTP server in the
                   1470: directory /pub/pkgsrc/packages.
                   1471:
                   1472: This directory contains binary packages for multiple platforms. First, select
                   1473: your operating system. (Ignore the directories with version numbers attached to
                   1474: it, they just exist for legacy reasons.) Then, select your hardware
                   1475: architecture, and in the third step, the OS version and the "version" of
1.110     rillig   1476: pkgsrc.
                   1477:
                   1478: In this directory, you often find a file called bootstrap.tar.gz which contains
                   1479: the package management tools. If the file is missing, it is likely that your
                   1480: operating system already provides those tools. Download the file and extract it
                   1481: in the / directory. It will create the directories /usr/pkg (containing the
                   1482: tools for managing binary packages) and /var/db/pkg (the database of installed
                   1483: packages).
1.1       grant    1484:
1.70      rillig   1485: 4.1.2. Installing binary packages
1.1       grant    1486:
1.110     rillig   1487: In the directory from the last section, there is a subdirectory called All,
                   1488: which contains all the binary packages that are available for the platform,
                   1489: excluding those that may not be distributed via FTP or CDROM (depending on
1.130     wiz      1490: which medium you are using).
1.110     rillig   1491:
                   1492: To install packages directly from an FTP or HTTP server, run the following
                   1493: commands in a Bourne-compatible shell (be sure to su to root first):
                   1494:
                   1495: # PATH="/usr/pkg/sbin:$PATH"
                   1496: # PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All"
                   1497: # export PATH PKG_PATH
                   1498:
                   1499: Instead of URLs, you can also use local paths, for example if you are
                   1500: installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want
                   1501: to install packages from multiple sources, you can separate them by a semicolon
                   1502: in PKG_PATH.
                   1503:
                   1504: After these preparations, installing a package is very easy:
                   1505:
                   1506: # pkg_add openoffice2
                   1507: # pkg_add kde-3.5.7
                   1508: # pkg_add ap2-php5-*
1.1       grant    1509:
1.27      rillig   1510: Note that any prerequisite packages needed to run the package in question will
                   1511: be installed, too, assuming they are present where you install from.
1.1       grant    1512:
1.132     wiz      1513: Adding packages might install vulnerable packages. Thus you should run
1.130     wiz      1514: pkg_admin audit regularly, especially after installing new packages, and verify
                   1515: that the vulnerabilities are acceptable for your configuration.
                   1516:
1.27      rillig   1517: After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
                   1518: in your PATH so you can actually start the just installed program.
1.1       grant    1519:
1.82      rillig   1520: 4.1.3. Deinstalling packages
                   1521:
                   1522: To deinstall a package, it does not matter whether it was installed from source
                   1523: code or from a binary package. The pkg_delete command does not know it anyway.
                   1524: To delete a package, you can just run pkg_delete package-name. The package name
                   1525: can be given with or without version number. Wildcards can also be used to
                   1526: deinstall a set of packages, for example *emacs*. Be sure to include them in
                   1527: quotes, so that the shell does not expand them before pkg_delete sees them.
                   1528:
                   1529: The -r option is very powerful: it removes all the packages that require the
                   1530: package in question and then removes the package itself. For example:
                   1531:
1.88      wiz      1532: # pkg_delete -r jpeg
                   1533:
1.82      rillig   1534:
                   1535: will remove jpeg and all the packages that used it; this allows upgrading the
                   1536: jpeg package.
                   1537:
                   1538: 4.1.4. Getting information about installed packages
                   1539:
                   1540: The pkg_info shows information about installed packages or binary package
                   1541: files.
                   1542:
                   1543: 4.1.5. Checking for security vulnerabilities in installed packages
                   1544:
                   1545: The NetBSD Security-Officer and Packages Groups maintain a list of known
                   1546: security vulnerabilities to packages which are (or have been) included in
                   1547: pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/
                   1548: pub/pkgsrc/distfiles/vulnerabilities.
                   1549:
1.126     wiz      1550: Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded
                   1551: automatically, and a security audit of all packages installed on a system can
                   1552: take place.
                   1553:
                   1554: There are two components to auditing. The first step, pkg_admin
                   1555: fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
                   1556: the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of
                   1557: your installed packages are vulnerable. If a package is vulnerable, you will
                   1558: see output similar to the following:
1.82      rillig   1559:
                   1560: Package samba-2.0.9 has a local-root-shell vulnerability, see
1.88      wiz      1561:     http://www.samba.org/samba/whatsnew/macroexploit.html
1.82      rillig   1562:
1.126     wiz      1563: You may wish to have the vulnerabilities file downloaded daily so that it
                   1564: remains current. This may be done by adding an appropriate entry to the root
                   1565: users crontab(5) entry. For example the entry
                   1566:
                   1567: # download vulnerabilities file
                   1568: 0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
                   1569:
                   1570:
                   1571: will update the vulnerability list every day at 3AM. You may wish to do this
                   1572: more often than once a day. In addition, you may wish to run the package audit
                   1573: from the daily security script. This may be accomplished by adding the
                   1574: following line to /etc/security.local:
                   1575:
                   1576: /usr/sbin/pkg_admin audit
                   1577:
1.82      rillig   1578:
                   1579: 4.1.6. Finding if newer versions of your installed packages are in pkgsrc
                   1580:
1.113     weinem   1581: Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
                   1582: if your packages are up-to-date, e.g.
1.82      rillig   1583:
                   1584: % lintpkgsrc -i
                   1585: ...
                   1586: Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
                   1587:
1.88      wiz      1588:
1.82      rillig   1589: You can then use make update to update the package on your system and rebuild
                   1590: any dependencies.
                   1591:
                   1592: 4.1.7. Other administrative functions
                   1593:
                   1594: The pkg_admin executes various administrative functions on the package system.
                   1595:
                   1596: 4.1.8. A word of warning
1.1       grant    1597:
                   1598: Please pay very careful attention to the warnings expressed in the pkg_add(1)
                   1599: manual page about the inherent dangers of installing binary packages which you
                   1600: did not create yourself, and the security holes that can be introduced onto
                   1601: your system by indiscriminate adding of such files.
                   1602:
1.66      rillig   1603: The same warning of course applies to every package you install from source
                   1604: when you haven't completely read and understood the source code of the package,
                   1605: the compiler that is used to build the package and all the other tools that are
                   1606: involved.
                   1607:
1.1       grant    1608: 4.2. Building packages from source
                   1609:
1.82      rillig   1610: After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
1.132     wiz      1611: organized into categories. You can browse the online index of packages, or run
1.82      rillig   1612: make readme from the pkgsrc directory to build local README.html files for all
1.83      wiz      1613: packages, viewable with any web browser such as www/lynx or www/firefox.
1.82      rillig   1614:
                   1615: The default prefix for installed packages is /usr/pkg. If you wish to change
                   1616: this, you should do so by setting LOCALBASE in mk.conf. You should not try to
                   1617: use multiple different LOCALBASE definitions on the same system (inside a
                   1618: chroot is an exception).
                   1619:
                   1620: The rest of this chapter assumes that the package is already in pkgsrc. If it
                   1621: is not, see Part II, "The pkgsrc developer's guide" for instructions how to
                   1622: create your own packages.
1.1       grant    1623:
                   1624: 4.2.1. Requirements
                   1625:
1.82      rillig   1626: To build packages from source, you need a working C compiler. On NetBSD, you
                   1627: need to install the "comp" and the "text" distribution sets. If you want to
                   1628: build X11-related packages, the "xbase" and "xcomp" distribution sets are
                   1629: required, too.
1.1       grant    1630:
                   1631: 4.2.2. Fetching distfiles
                   1632:
1.27      rillig   1633: The first step for building a package is downloading the distfiles (i.e. the
                   1634: unmodified source). If they have not yet been downloaded, pkgsrc will fetch
                   1635: them automatically.
1.1       grant    1636:
1.82      rillig   1637: If you have all files that you need in the distfiles directory, you don't need
                   1638: to connect. If the distfiles are on CD-ROM, you can mount the CD-ROM on /cdrom
                   1639: and add:
                   1640:
                   1641: DISTDIR=/cdrom/pkgsrc/distfiles
                   1642:
                   1643: to your mk.conf.
                   1644:
1.91      rillig   1645: By default a list of distribution sites will be randomly intermixed to prevent
                   1646: huge load on servers which holding popular packages (for example,
                   1647: SourceForge.net mirrors). Thus, every time when you need to fetch yet another
                   1648: distfile all the mirrors will be tried in new (random) order. You can turn this
                   1649: feature off by setting MASTER_SORT_RANDOM=NO (for PKG_DEVELOPERs it's already
                   1650: disabled).
                   1651:
1.1       grant    1652: You can overwrite some of the major distribution sites to fit to sites that are
1.88      wiz      1653: close to your own. By setting one or two variables you can modify the order in
                   1654: which the master sites are accessed. MASTER_SORT contains a whitespace
                   1655: delimited list of domain suffixes. MASTER_SORT_REGEX is even more flexible, it
                   1656: contains a whitespace delimited list of regular expressions. It has higher
                   1657: priority than MASTER_SORT. Have a look at pkgsrc/mk/defaults/mk.conf to find
                   1658: some examples. This may save some of your bandwidth and time.
1.1       grant    1659:
                   1660: You can change these settings either in your shell's environment, or, if you
1.105     rillig   1661: want to keep the settings, by editing the mk.conf file, and adding the
1.1       grant    1662: definitions there.
                   1663:
1.82      rillig   1664: If a package depends on many other packages (such as meta-pkgs/kde3), the build
                   1665: process may alternate between periods of downloading source, and compiling. To
                   1666: ensure you have all the source downloaded initially you can run the command:
                   1667:
                   1668: % make fetch-list | sh
                   1669:
                   1670: which will output and run a set of shell commands to fetch the necessary files
                   1671: into the distfiles directory. You can also choose to download the files
                   1672: manually.
1.1       grant    1673:
                   1674: 4.2.3. How to build and install
                   1675:
1.82      rillig   1676: Once the software has downloaded, any patches will be applied, then it will be
                   1677: compiled for you. This may take some time depending on your computer, and how
                   1678: many other packages the software depends on and their compile time.
1.47      reed     1679:
                   1680: Note
                   1681:
                   1682: If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
                   1683: command instead of "make" in the examples in this guide.
                   1684:
                   1685: For example, type
1.1       grant    1686:
                   1687: % cd misc/figlet
                   1688: % make
                   1689:
1.88      wiz      1690:
1.82      rillig   1691: at the shell prompt to build the various components of the package.
                   1692:
                   1693: The next stage is to actually install the newly compiled program onto your
                   1694: system. Do this by entering:
                   1695:
1.88      wiz      1696: % make install
                   1697:
1.82      rillig   1698:
                   1699: while you are still in the directory for whatever package you are installing.
1.1       grant    1700:
1.82      rillig   1701: Installing the package on your system may require you to be root. However,
                   1702: pkgsrc has a just-in-time-su feature, which allows you to only become root for
                   1703: the actual installation step.
                   1704:
                   1705: That's it, the software should now be installed and setup for use. You can now
                   1706: enter:
                   1707:
1.88      wiz      1708: % make clean
                   1709:
1.82      rillig   1710:
                   1711: to remove the compiled files in the work directory, as you shouldn't need them
                   1712: any more. If other packages were also added to your system (dependencies) to
                   1713: allow your program to compile, you can tidy these up also with the command:
1.1       grant    1714:
1.88      wiz      1715: % make clean-depends
                   1716:
1.1       grant    1717:
                   1718: Taking the figlet utility as an example, we can install it on our system by
1.46      gdt      1719: building as shown in Appendix B, Build logs.
1.1       grant    1720:
                   1721: The program is installed under the default root of the packages tree - /usr/
                   1722: pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
                   1723: environment, and it will use that value as the root of your packages tree. So,
                   1724: to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
                   1725: that you should use a directory which is dedicated to packages and not shared
1.47      reed     1726: with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
1.1       grant    1727: not try to add any of your own files or directories (such as src/, obj/, or
                   1728: pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
                   1729: between programs and other files installed by the package system and whatever
                   1730: else may have been installed there.
                   1731:
1.105     rillig   1732: Some packages look in mk.conf to alter some configuration options at build
1.11      ben      1733: time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will
                   1734: be set there by default. Environment variables such as LOCALBASE can be set in
1.105     rillig   1735: mk.conf to save having to remember to set them each time you want to use
1.11      ben      1736: pkgsrc.
1.1       grant    1737:
                   1738: Occasionally, people want to "look under the covers" to see what is going on
                   1739: when a package is building or being installed. This may be for debugging
                   1740: purposes, or out of simple curiosity. A number of utility values have been
                   1741: added to help with this.
                   1742:
                   1743:  1. If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a huge
                   1744:     amount of information will be displayed. For example,
1.20      ben      1745:
1.1       grant    1746:     make patch PKG_DEBUG_LEVEL=2
1.20      ben      1747:
1.132     wiz      1748:     will show all the commands that are invoked, up to and including the "patch
                   1749:     " stage.
1.20      ben      1750:
1.1       grant    1751:  2. If you want to know the value of a certain make(1) definition, then the
                   1752:     VARNAME definition should be used, in conjunction with the show-var target.
1.22      tv       1753:     e.g. to show the expansion of the make(1) variable LOCALBASE:
1.20      ben      1754:
1.1       grant    1755:     % make show-var VARNAME=LOCALBASE
                   1756:     /usr/pkg
                   1757:     %
1.20      ben      1758:
                   1759:
1.1       grant    1760: If you want to install a binary package that you've either created yourself
                   1761: (see next section), that you put into pkgsrc/packages manually or that is
1.8       wiz      1762: located on a remote FTP server, you can use the "bin-install" target. This
1.1       grant    1763: target will install a binary package - if available - via pkg_add(1), else do a
                   1764: make package. The list of remote FTP sites searched is kept in the variable
1.11      ben      1765: BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
                   1766: to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
                   1767: for more details.
1.1       grant    1768:
1.47      reed     1769: A final word of warning: If you set up a system that has a non-standard setting
1.1       grant    1770: for LOCALBASE, be sure to set that before any packages are installed, as you
1.86      schwarz  1771: cannot use several directories for the same purpose. Doing so will result in
1.1       grant    1772: pkgsrc not being able to properly detect your installed packages, and fail
                   1773: miserably. Note also that precompiled binary packages are usually built with
                   1774: the default LOCALBASE of /usr/pkg, and that you should not install any if you
                   1775: use a non-standard LOCALBASE.
                   1776:
1.38      dillo    1777: Chapter 5. Configuring pkgsrc
                   1778:
                   1779: Table of Contents
                   1780:
1.45      wiz      1781: 5.1. General configuration
                   1782: 5.2. Variables affecting the build process
1.110     rillig   1783: 5.3. Variables affecting the installation process
1.104     wiz      1784: 5.4. Selecting and configuring the compiler
1.78      rillig   1785:
1.104     wiz      1786:     5.4.1. Selecting the compiler
                   1787:     5.4.2. Additional flags to the compiler (CFLAGS)
                   1788:     5.4.3. Additional flags to the linker (LDFLAGS)
1.78      rillig   1789:
1.104     wiz      1790: 5.5. Developer/advanced settings
                   1791: 5.6. Selecting Build Options
1.38      dillo    1792:
1.89      rillig   1793: The whole pkgsrc system is configured in a single file, usually called mk.conf.
                   1794: In which directory pkgsrc looks for that file depends on the installation. On
                   1795: NetBSD, when you use make(1) from the base system, it is in the directory /etc
                   1796: /. In all other cases the default location is ${PREFIX}/etc/, depending on
                   1797: where you told the bootstrap program to install the binary packages.
                   1798:
                   1799: During the bootstrap, an example configuration file is created. To use that,
                   1800: you have to create the directory ${PREFIX}/etc and copy the example file there.
                   1801:
                   1802: The format of the configuration file is that of the usual BSD-style Makefiles.
                   1803: The whole pkgsrc configuration is done by setting variables in this file. Note
                   1804: that you can define all kinds of variables, and no special error checking (for
                   1805: example for spelling mistakes) takes place, so you have to try it out to see if
                   1806: it works.
                   1807:
1.45      wiz      1808: 5.1. General configuration
                   1809:
1.47      reed     1810: In this section, you can find some variables that apply to all pkgsrc packages.
1.89      rillig   1811: A complete list of the variables that can be configured by the user is
                   1812: available in mk/defaults/mk.conf, together with some comments that describe
                   1813: each variable's intent.
1.45      wiz      1814:
                   1815:   * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
                   1816:     not mix binary packages with different LOCALBASEs!
                   1817:
                   1818:   * CROSSBASE: Where "cross" category packages will be installed. The default
                   1819:     is ${LOCALBASE}/cross.
                   1820:
                   1821:   * X11BASE: Where X11 is installed on the system. The default is /usr/X11R6.
                   1822:
                   1823:   * DISTDIR: Where to store the downloaded copies of the original source
                   1824:     distributions used for building pkgsrc packages. The default is $
                   1825:     {PKGSRCDIR}/distfiles.
                   1826:
1.97      wiz      1827:   * PKG_DBDIR: Where the database about installed packages is stored. The
1.98      rillig   1828:     default is /var/db/pkg.
1.97      wiz      1829:
1.45      wiz      1830:   * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
                   1831:     value.
                   1832:
                   1833:   * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
                   1834:     files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
1.134     spz      1835:     respectively. The defaults are ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/$
                   1836:     {DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$
1.45      wiz      1837:     {DIST_SUBDIR}/.
                   1838:
1.93      rillig   1839:   * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
                   1840:     with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
1.45      wiz      1841:
1.126     wiz      1842:   * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
                   1843:     case-sensitive. Whenever you try to build a package whose license is not in
                   1844:     this list, you will get an error message. If the license condition is
                   1845:     simple enough, the error message will include specific instructions on how
                   1846:     to change this variable.
1.82      rillig   1847:
1.45      wiz      1848: 5.2. Variables affecting the build process
                   1849:
                   1850: XXX
                   1851:
                   1852:   * PACKAGES: The top level directory for the binary packages. The default is $
                   1853:     {PKGSRCDIR}/packages.
                   1854:
                   1855:   * WRKOBJDIR: The top level directory where, if defined, the separate working
                   1856:     directories will get created, and symbolically linked to from ${WRKDIR}
                   1857:     (see below). This is useful for building packages on several architectures,
                   1858:     then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
                   1859:     architecture. (It should be noted that PKGSRCDIR should not be set by the
                   1860:     user ? it is an internal definition which refers to the root of the pkgsrc
                   1861:     tree. It is possible to have many pkgsrc tree instances.)
                   1862:
                   1863:   * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
1.107     rillig   1864:     Section 11.3, "patches/*" for more information.
1.45      wiz      1865:
                   1866:   * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
                   1867:     Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
                   1868:     up settings used by builds in /usr/src.
                   1869:
1.82      rillig   1870:   * DEPENDS_TARGET: By default, dependencies are only installed, and no binary
                   1871:     package is created for them. You can set this variable to package to
                   1872:     automatically create binary packages after installing dependencies.
                   1873:
1.110     rillig   1874: 5.3. Variables affecting the installation process
1.78      rillig   1875:
1.133     wiz      1876: Most packages support installation into a subdirectory of WRKDIR. This allows a
                   1877: package to be built, before the actual filesystem is touched. DESTDIR support
                   1878: exists in two variations:
1.104     wiz      1879:
                   1880:   * Basic DESTDIR support means that the package installation and packaging is
                   1881:     still run as root.
                   1882:
                   1883:   * Full DESTDIR support can run the complete build, installation and packaging
                   1884:     as normal user. Root privileges are only needed to add packages.
                   1885:
1.133     wiz      1886: DESTDIR support is now the default. To switch back to non-DESTDIR, you can set
                   1887: USE_DESTDIR=no; this setting will be deprecated though, so it's preferable to
                   1888: convert a package to DESTDIR instead.
1.104     wiz      1889:
                   1890: DESTDIR support changes the behaviour of various targets slightly. To install a
                   1891: package after building it, use package-install. package and install don't do
                   1892: that any longer. package-install can be used as DEPENDS_TARGET. bin-install
                   1893: will ask for the root password to install the package and fail, package-install
                   1894: will ask again.
                   1895:
                   1896: With basic DESTDIR support, make clean needs to be run as root.
                   1897:
1.119     imil     1898: Considering the foo/bar package, DESTDIR full support can be tested using the
                   1899: following commands
                   1900:
                   1901: $ id
                   1902: uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
                   1903: $ mkdir $HOME/packages
                   1904: $ cd $PKGSRCDIR/foo/bar
                   1905:
                   1906: Verify DESTDIR full support, no root privileges should be needed
                   1907:
1.124     snj      1908: $ make USE_DESTDIR=yes install
1.119     imil     1909:
                   1910: Create a package without root privileges
                   1911:
1.124     snj      1912: $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package
1.119     imil     1913:
                   1914: For the following command, you must be able to gain root privileges using su(1)
                   1915:
1.124     snj      1916: $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install
1.119     imil     1917:
                   1918: Then, as a simple user
                   1919:
                   1920: $ make clean
                   1921:
1.104     wiz      1922: 5.4. Selecting and configuring the compiler
                   1923:
                   1924: 5.4.1. Selecting the compiler
1.89      rillig   1925:
                   1926: By default, pkgsrc will use GCC to build packages. This may be overridden by
                   1927: setting the following variables in /etc/mk.conf:
                   1928:
                   1929: PKGSRC_COMPILER:
                   1930:
                   1931:     This is a list of values specifying the chain of compilers to invoke when
                   1932:     building packages. Valid values are:
                   1933:
                   1934:       * distcc: distributed C/C++ (chainable)
                   1935:
                   1936:       * ccache: compiler cache (chainable)
                   1937:
                   1938:       * gcc: GNU C/C++ Compiler
                   1939:
                   1940:       * mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)
                   1941:
                   1942:       * mipspro: Silicon Graphics, Inc. MIPSpro (o32)
                   1943:
                   1944:       * sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio
                   1945:
                   1946:     The default is "gcc". You can use ccache and/or distcc with an appropriate
                   1947:     PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
1.94      dmcmahil 1948:     terminated with a value for a real compiler. Note that only one real
                   1949:     compiler should be listed (e.g. "sunpro gcc" is not allowed).
1.89      rillig   1950:
                   1951: GCC_REQD:
                   1952:
                   1953:     This specifies the minimum version of GCC to use when building packages. If
                   1954:     the system GCC doesn't satisfy this requirement, then pkgsrc will build and
                   1955:     install one of the GCC packages to use instead.
                   1956:
1.104     wiz      1957: 5.4.2. Additional flags to the compiler (CFLAGS)
1.78      rillig   1958:
                   1959: If you wish to set the CFLAGS variable, please make sure to use the += operator
                   1960: instead of the = operator:
                   1961:
1.101     rillig   1962: CFLAGS+=        -your -flags
1.78      rillig   1963:
                   1964: Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
1.118     jnemeth  1965: need to add their own flags. You may want to take a look at the devel/cpuflags
1.130     wiz      1966: package if you're interested in optimization specifically for the current CPU.
1.78      rillig   1967:
1.104     wiz      1968: 5.4.3. Additional flags to the linker (LDFLAGS)
1.88      wiz      1969:
                   1970: If you want to pass flags to the linker, both in the configure step and the
                   1971: build step, you can do this in two ways. Either set LDFLAGS or LIBS. The
                   1972: difference between the two is that LIBS will be appended to the command line,
                   1973: while LDFLAGS come earlier. LDFLAGS is pre-loaded with rpath settings for ELF
                   1974: machines depending on the setting of USE_IMAKE or the inclusion of mk/
                   1975: x11.buildlink3.mk. As with CFLAGS, if you do not wish to override these
                   1976: settings, use the += operator:
                   1977:
1.101     rillig   1978: LDFLAGS+=        -your -linkerflags
1.88      wiz      1979:
1.104     wiz      1980: 5.5. Developer/advanced settings
1.45      wiz      1981:
                   1982: XXX
                   1983:
                   1984:   * PKG_DEVELOPER: Run some sanity checks that package developers want:
                   1985:
                   1986:       o make sure patches apply with zero fuzz
                   1987:
                   1988:       o run check-shlibs to see that all binaries will find their shared libs.
                   1989:
                   1990:   * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst
                   1991:     making and installing the package. The default value for this is 0, which
                   1992:     will not display the commands as they are executed (normal, default, quiet
                   1993:     operation); the value 1 will display all shell commands before their
                   1994:     invocation, and the value 2 will display both the shell commands before
                   1995:     their invocation, and their actual execution progress with set -x will be
                   1996:     displayed.
                   1997:
1.104     wiz      1998: 5.6. Selecting Build Options
1.38      dillo    1999:
                   2000: Some packages have build time options, usually to select between different
                   2001: dependencies, enable optional support for big dependencies or enable
                   2002: experimental features.
                   2003:
                   2004: To see which options, if any, a package supports, and which options are
                   2005: mutually exclusive, run make show-options, for example:
                   2006:
1.51      rillig   2007:     The following options are supported by this package:
1.70      rillig   2008:         ssl      Enable SSL support.
1.51      rillig   2009:     Exactly one of the following gecko options is required:
1.70      rillig   2010:         firefox  Use firefox as gecko rendering engine.
                   2011:         mozilla  Use mozilla as gecko rendering engine.
1.51      rillig   2012:     At most one of the following database options may be selected:
1.70      rillig   2013:         mysql    Enable support for MySQL database.
                   2014:         pgsql    Enable support for PostgreSQL database.
1.38      dillo    2015:
1.51      rillig   2016:     These options are enabled by default: firefox
                   2017:     These options are currently enabled: mozilla ssl
1.38      dillo    2018:
1.105     rillig   2019: The following variables can be defined in mk.conf to select which options to
                   2020: enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
1.38      dillo    2021: disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
                   2022: which can be used to select or disable options specifically for package pkgbase
                   2023: . Options listed in these variables are selected, options preceded by "-" are
1.67      hubertf  2024: disabled. A few examples:
                   2025:
1.105     rillig   2026: $ grep "PKG.*OPTION" mk.conf
1.67      hubertf  2027: PKG_DEFAULT_OPTIONS=    -arts -dvdread -esound
                   2028: PKG_OPTIONS.kdebase=    debug -sasl
                   2029: PKG_OPTIONS.apache=     suexec
1.38      dillo    2030:
1.112     rillig   2031: It is important to note that options that were specifically suggested by the
1.121     snj      2032: package maintainer must be explicitly removed if you do not wish to include the
                   2033: option. If you are unsure you can view the current state with make show-options
                   2034: .
1.112     rillig   2035:
1.39      dillo    2036: The following settings are consulted in the order given, and the last setting
                   2037: that selects or disables an option is used:
1.38      dillo    2038:
                   2039:  1. the default options as suggested by the package maintainer
                   2040:
                   2041:  2. the options implied by the settings of legacy variables (see below)
                   2042:
                   2043:  3. PKG_DEFAULT_OPTIONS
                   2044:
                   2045:  4. PKG_OPTIONS.pkgbase
                   2046:
                   2047: For groups of mutually exclusive options, the last option selected is used, all
                   2048: others are automatically disabled. If an option of the group is explicitly
                   2049: disabled, the previously selected option, if any, is used. It is an error if no
                   2050: option from a required group of options is selected, and building the package
                   2051: will fail.
                   2052:
                   2053: Before the options framework was introduced, build options were selected by
1.105     rillig   2054: setting a variable (often named USE_FOO) in mk.conf for each option. To ease
                   2055: transition to the options framework for the user, these legacy variables are
                   2056: converted to the appropriate options setting (PKG_OPTIONS.pkgbase)
                   2057: automatically. A warning is issued to prompt the user to update mk.conf to use
                   2058: the options framework directly. Support for the legacy variables will be
1.65      hubertf  2059: removed eventually.
1.38      dillo    2060:
                   2061: Chapter 6. Creating binary packages
1.1       grant    2062:
                   2063: Table of Contents
                   2064:
1.38      dillo    2065: 6.1. Building a single binary package
                   2066: 6.2. Settings for creation of binary packages
1.20      ben      2067:
1.38      dillo    2068: 6.1. Building a single binary package
1.1       grant    2069:
                   2070: Once you have built and installed a package, you can create a binary package
1.47      reed     2071: which can be installed on another system with pkg_add(1). This saves having to
1.1       grant    2072: build the same package on a group of hosts and wasting CPU time. It also
                   2073: provides a simple means for others to install your package, should you
                   2074: distribute it.
                   2075:
                   2076: To create a binary package, change into the appropriate directory in pkgsrc,
                   2077: and run make package:
                   2078:
                   2079: # cd misc/figlet
                   2080: # make package
                   2081:
1.87      wiz      2082:
1.1       grant    2083: This will build and install your package (if not already done), and then build
                   2084: a binary package from what was installed. You can then use the pkg_* tools to
                   2085: manipulate it. Binary packages are created by default in /usr/pkgsrc/packages,
1.46      gdt      2086: in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a
1.1       grant    2087: continuation of the above misc/figlet example.
                   2088:
1.107     rillig   2089: See Chapter 21, Submitting and Committing for information on how to submit such
1.1       grant    2090: a binary package.
                   2091:
1.38      dillo    2092: 6.2. Settings for creation of binary packages
1.1       grant    2093:
1.107     rillig   2094: See Section 17.17, "Other helpful targets".
                   2095:
                   2096: Chapter 7. Creating binary packages for everything in pkgsrc (bulk builds)
                   2097:
                   2098: Table of Contents
                   2099:
                   2100: 7.1. Think first, build later
                   2101: 7.2. Requirements of a bulk build
                   2102: 7.3. Running an old-style bulk build
                   2103:
                   2104:     7.3.1. Configuration
                   2105:     7.3.2. Other environmental considerations
                   2106:     7.3.3. Operation
                   2107:     7.3.4. What it does
                   2108:     7.3.5. Disk space requirements
                   2109:     7.3.6. Setting up a sandbox for chrooted builds
                   2110:     7.3.7. Building a partial set of packages
                   2111:     7.3.8. Uploading results of a bulk build
                   2112:
                   2113: 7.4. Running a pbulk-style bulk build
                   2114:
1.117     rillig   2115:     7.4.1. Preparation
                   2116:     7.4.2. Configuration
1.107     rillig   2117:
                   2118: 7.5. Creating a multiple CD-ROM packages collection
                   2119:
                   2120:     7.5.1. Example of cdpack
                   2121:
                   2122: When you have multiple machines that should run the same packages, it is wasted
                   2123: time if they all build their packages themselves from source. There are two
                   2124: ways of getting a set of binary packages: The old bulk build system, or the new
                   2125: (as of 2007) parallel bulk build (pbulk) system. This chapter describes how to
                   2126: set them up so that the packages are most likely to be usable later.
                   2127:
                   2128: 7.1. Think first, build later
                   2129:
                   2130: Since a bulk build takes several days or even weeks to finish, you should think
                   2131: about the setup before you start everything. Pay attention to at least the
                   2132: following points:
1.1       grant    2133:
1.107     rillig   2134:   * If you want to upload the binary packages to ftp.NetBSD.org, make sure the
                   2135:     setup complies to the requirements for binary packages:
1.1       grant    2136:
1.107     rillig   2137:       o To end up on ftp.NetBSD.org, the packages must be built by a NetBSD
                   2138:         developer on a trusted machine (that is, where you and only you have
                   2139:         root access).
1.63      dillo    2140:
1.107     rillig   2141:       o Packages on ftp.NetBSD.org should only be created from the stable
1.125     snj      2142:         branches (like 2009Q1), so that users browsing the available
1.107     rillig   2143:         collections can see at a glance how old the packages are.
1.1       grant    2144:
1.107     rillig   2145:       o The packages must be built as root, since some packages require set-uid
                   2146:         binaries at runtime, and creating those packages as unprivileged user
                   2147:         doesn't work well at the moment.
1.1       grant    2148:
1.107     rillig   2149:   * Make sure that the bulk build cannot break anything in your system. Most
                   2150:     bulk builds run as root, so they should be run at least in a chroot
                   2151:     environment or something even more restrictive, depending on what the
                   2152:     operating system provides. There have been numerous cases where certain
                   2153:     packages tried to install files outside the LOCALBASE or wanted to edit
                   2154:     some files in /etc. Furthermore, the bulk builds install and deinstall
                   2155:     packages in /usr/pkg (or whatever LOCALBASE is) during their operation, so
                   2156:     be sure that you don't need any package during the build.
                   2157:
                   2158: 7.2. Requirements of a bulk build
                   2159:
                   2160: A complete bulk build requires lots of disk space. Some of the disk space can
                   2161: be read-only, some other must be writable. Some can be on remote filesystems
                   2162: (such as NFS) and some should be local. Some can be temporary filesystems,
                   2163: others must survive a sudden reboot.
                   2164:
                   2165:   * 10 GB for the distfiles (read-write, remote, temporary)
                   2166:
                   2167:   * 10 GB for the binary packages (read-write, remote, permanent)
                   2168:
                   2169:   * 400 MB for the pkgsrc tree (read-only, remote, permanent)
                   2170:
                   2171:   * 5 GB for LOCALBASE (read-write, local, temporary for pbulk, permanent for
                   2172:     old-bulk)
                   2173:
                   2174:   * 5 GB for the log files (read-write, remote, permanent)
                   2175:
                   2176:   * 5 GB for temporary files (read-write, local, temporary)
                   2177:
                   2178: 7.3. Running an old-style bulk build
                   2179:
1.117     rillig   2180: Note
1.107     rillig   2181:
1.132     wiz      2182: There are two ways of doing a bulk build. The old-style one and the new-style "
                   2183: pbulk". The latter is the recommended way.
1.107     rillig   2184:
                   2185: 7.3.1. Configuration
                   2186:
                   2187: 7.3.1.1. build.conf
1.63      dillo    2188:
                   2189: The build.conf file is the main configuration file for bulk builds. You can
                   2190: configure how your copy of pkgsrc is kept up to date, how the distfiles are
                   2191: downloaded, how the packages are built and how the report is generated. You can
                   2192: find an annotated example file in pkgsrc/mk/bulk/build.conf-example. To use it,
                   2193: copy build.conf-example to build.conf and edit it, following the comments in
                   2194: that file.
                   2195:
1.107     rillig   2196: 7.3.1.2. mk.conf
1.1       grant    2197:
1.105     rillig   2198: You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf
                   2199: for details of the default settings. You will want to ensure that
1.11      ben      2200: ACCEPTABLE_LICENSES meet your local policy. As used in this example,
1.126     wiz      2201: SKIP_LICENSE_CHECK=yes completely bypasses the license check.
1.1       grant    2202:
1.101     rillig   2203: PACKAGES?=      ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
                   2204: WRKOBJDIR?=     /usr/tmp/pkgsrc   # build here instead of in pkgsrc
                   2205: BSDSRCDIR=      /usr/src
                   2206: BSDXSRCDIR=     /usr/xsrc         # for x11/xservers
                   2207: OBJHOSTNAME?=   yes               # use work.`hostname`
                   2208: FAILOVER_FETCH= yes               # insist on the correct checksum
                   2209: PKG_DEVELOPER?= yes
1.126     wiz      2210: SKIP_LICENSE_CHECK=    yes
1.1       grant    2211:
1.63      dillo    2212: Some options that are especially useful for bulk builds can be found at the top
                   2213: lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are
                   2214: briefly described here.
                   2215:
1.132     wiz      2216:   * If you are on a slow machine, you may want to set USE_BULK_BROKEN_CHECK to
1.63      dillo    2217:     "no".
                   2218:
                   2219:   * If you are doing bulk builds from a read-only copy of pkgsrc, you have to
                   2220:     set BULKFILESDIR to the directory where all log files are created.
                   2221:     Otherwise the log files are created in the pkgsrc directory.
1.1       grant    2222:
1.63      dillo    2223:   * Another important variable is BULK_PREREQ, which is a list of packages that
                   2224:     should be always available while building other packages.
1.1       grant    2225:
1.68      rillig   2226: Some other options are scattered in the pkgsrc infrastructure:
                   2227:
1.69      rillig   2228:   * ALLOW_VULNERABLE_PACKAGES should be set to yes. The purpose of the bulk
                   2229:     builds is creating binary packages, no matter if they are vulnerable or
1.130     wiz      2230:     not. Leaving this variable unset would prevent the bulk build system from
                   2231:     even trying to build them, so possible building errors would not show up.
1.69      rillig   2232:
1.93      rillig   2233:   * CHECK_FILES (pkgsrc/mk/check/check-files.mk) can be set to "yes" to check
                   2234:     that the installed set of files matches the PLIST.
1.68      rillig   2235:
1.132     wiz      2236:   * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to "yes
                   2237:     " to check that the installed "#!"-scripts will find their interpreter.
1.68      rillig   2238:
1.91      rillig   2239:   * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before
                   2240:     installing it. Note that some packages make heavy use of "good" random
                   2241:     numbers, so you need to assure that the machine on which you are doing the
                   2242:     bulk builds is not completely idle. Otherwise some test programs will seem
                   2243:     to hang, while they are just waiting for new random data to be available.
                   2244:
1.107     rillig   2245: 7.3.1.3. pre-build.local
1.1       grant    2246:
1.47      reed     2247: It is possible to configure the bulk build to perform certain site-specific
1.1       grant    2248: tasks at the end of the pre-build stage. If the file pre-build.local exists in
1.23      wiz      2249: /usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the
1.1       grant    2250: usual pre-build stage. An example use of pre-build.local is to have the line:
                   2251:
1.71      wiz      2252: echo "I do not have enough disk space to build this pig." \
1.87      wiz      2253:         > misc/openoffice/$BROKENF
1.1       grant    2254:
                   2255: to prevent the system from trying to build a particular package which requires
                   2256: nearly 3 GB of disk space.
                   2257:
1.107     rillig   2258: 7.3.2. Other environmental considerations
1.1       grant    2259:
                   2260: As /usr/pkg will be completely deleted at the start of bulk builds, make sure
                   2261: your login shell is placed somewhere else. Either drop it into /usr/local/bin
1.20      ben      2262: (and adjust your login shell in the passwd file), or (re-)install it via
1.1       grant    2263: pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that
                   2264: your current process won't die if the package is removed, you just can't start
                   2265: any new instances of the shell any more). Also, if you use NetBSD earlier than
                   2266: 1.5, or you still want to use the pkgsrc version of ssh for some reason, be
                   2267: sure to install ssh before starting it from rc.local:
                   2268:
1.101     rillig   2269: (cd /usr/pkgsrc/security/ssh && make bulk-install)
                   2270: if [ -f /usr/pkg/etc/rc.d/sshd ]; then
                   2271:   /usr/pkg/etc/rc.d/sshd
                   2272: fi
1.1       grant    2273:
                   2274: Not doing so will result in you being not able to log in via ssh after the bulk
                   2275: build is finished or if the machine gets rebooted or crashes. You have been
                   2276: warned! :)
                   2277:
1.107     rillig   2278: 7.3.3. Operation
1.1       grant    2279:
                   2280: Make sure you don't need any of the packages still installed.
                   2281:
                   2282: Warning
                   2283:
1.100     rillig   2284: During the bulk build, all packages, their configuration files and some more
1.101     rillig   2285: files from /var, /home and possibly other locations will be removed! So don't
                   2286: run a bulk build with privileges that might harm your system.
1.1       grant    2287:
                   2288: Be sure to remove all other things that might interfere with builds, like some
                   2289: libs installed in /usr/local, etc. then become root and type:
                   2290:
                   2291: # cd /usr/pkgsrc
                   2292: # sh mk/bulk/build
                   2293:
1.87      wiz      2294:
1.1       grant    2295: If for some reason your last build didn't complete (power failure, system
                   2296: panic, ...), you can continue it by running:
                   2297:
                   2298: # sh mk/bulk/build restart
                   2299:
                   2300: At the end of the bulk build, you will get a summary via mail, and find build
                   2301: logs in the directory specified by FTP in the build.conf file.
                   2302:
1.107     rillig   2303: 7.3.4. What it does
1.1       grant    2304:
                   2305: The bulk builds consist of three steps:
                   2306:
                   2307: 1. pre-build
1.20      ben      2308:
1.1       grant    2309:     The script updates your pkgsrc tree via (anon)cvs, then cleans out any
                   2310:     broken distfiles, and removes all packages installed.
1.20      ben      2311:
1.1       grant    2312: 2. the bulk build
1.20      ben      2313:
1.1       grant    2314:     This is basically "make bulk-package" with an optimised order in which
                   2315:     packages will be built. Packages that don't require other packages will be
                   2316:     built first, and packages with many dependencies will be built later.
1.20      ben      2317:
1.1       grant    2318: 3. post-build
1.20      ben      2319:
1.1       grant    2320:     Generates a report that's placed in the directory specified in the
                   2321:     build.conf file named broken.html, a short version of that report will also
                   2322:     be mailed to the build's admin.
1.20      ben      2323:
1.1       grant    2324: During the build, a list of broken packages will be compiled in /usr/pkgsrc
                   2325: /.broken (or .../.broken.${MACHINE} if OBJMACHINE is set), individual build
                   2326: logs of broken builds can be found in the package's directory. These files are
                   2327: used by the bulk-targets to mark broken builds to not waste time trying to
                   2328: rebuild them, and they can be used to debug these broken package builds later.
                   2329:
1.107     rillig   2330: 7.3.5. Disk space requirements
1.1       grant    2331:
                   2332: Currently, roughly the following requirements are valid for NetBSD 2.0/i386:
                   2333:
                   2334:   * 10 GB - distfiles (NFS ok)
1.20      ben      2335:
1.1       grant    2336:   * 8 GB - full set of all binaries (NFS ok)
1.20      ben      2337:
1.1       grant    2338:   * 5 GB - temp space for compiling (local disk recommended)
1.20      ben      2339:
1.1       grant    2340: Note that all pkgs will be de-installed as soon as they are turned into a
                   2341: binary package, and that sources are removed, so there is no excessively huge
                   2342: demand to disk space. Afterwards, if the package is needed again, it will be
                   2343: installed via pkg_add(1) instead of building again, so there are no cycles
                   2344: wasted by recompiling.
                   2345:
1.107     rillig   2346: 7.3.6. Setting up a sandbox for chrooted builds
1.1       grant    2347:
1.12      agc      2348: If you don't want all the packages nuked from a machine (rendering it useless
1.23      wiz      2349: for anything but pkg compiling), there is the possibility of doing the package
                   2350: bulk build inside a chroot environment.
1.1       grant    2351:
1.12      agc      2352: The first step is to set up a chroot sandbox, e.g. /usr/sandbox. This can be
                   2353: done by using null mounts, or manually.
                   2354:
                   2355: There is a shell script called pkgsrc/mk/bulk/mksandbox which will set up the
                   2356: sandbox environment using null mounts. It will also create a script called
                   2357: sandbox in the root of the sandbox environment, which will allow the null
                   2358: mounts to be activated using the sandbox mount command and deactivated using
                   2359: the sandbox umount command.
                   2360:
                   2361: To set up a sandbox environment by hand, after extracting all the sets from a
                   2362: NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in /usr/
                   2363: src/etc, be sure the following items are present and properly configured:
1.1       grant    2364:
                   2365:  1. Kernel
1.20      ben      2366:
1.1       grant    2367:     # cp /netbsd /usr/sandbox
1.20      ben      2368:
1.1       grant    2369:  2. /dev/*
1.20      ben      2370:
1.1       grant    2371:     # cd /usr/sandbox/dev ; sh MAKEDEV all
1.20      ben      2372:
1.1       grant    2373:  3. /etc/resolv.conf (for security/smtpd and mail):
1.20      ben      2374:
1.1       grant    2375:     # cp /etc/resolv.conf /usr/sandbox/etc
1.20      ben      2376:
1.1       grant    2377:  4. Working(!) mail config (hostname, sendmail.cf):
1.20      ben      2378:
1.1       grant    2379:     # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
1.20      ben      2380:
1.1       grant    2381:  5. /etc/localtime (for security/smtpd):
1.20      ben      2382:
1.1       grant    2383:     # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
1.20      ben      2384:
1.71      wiz      2385:  6. /usr/src (system sources, e. g. for sysutils/aperture):
1.20      ben      2386:
1.1       grant    2387:     # ln -s ../disk1/cvs .
1.87      wiz      2388:               # ln -s cvs/src-2.0 src
1.20      ben      2389:
1.1       grant    2390:  7. Create /var/db/pkg (not part of default install):
1.20      ben      2391:
1.1       grant    2392:     # mkdir /usr/sandbox/var/db/pkg
1.20      ben      2393:
1.1       grant    2394:  8. Create /usr/pkg (not part of default install):
1.20      ben      2395:
1.1       grant    2396:     # mkdir /usr/sandbox/usr/pkg
1.20      ben      2397:
1.1       grant    2398:  9. Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:
1.20      ben      2399:
1.1       grant    2400:     # cd /usr/sandbox/usr
                   2401:     # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
1.20      ben      2402:
1.87      wiz      2403:
1.1       grant    2404:     Do not mount/link this to the copy of your pkgsrc tree you do development
                   2405:     in, as this will likely cause problems!
1.20      ben      2406:
1.1       grant    2407: 10. Make /usr/sandbox/usr/pkgsrc/packages and .../distfiles point somewhere
                   2408:     appropriate. NFS- and/or nullfs-mounts may come in handy!
1.20      ben      2409:
1.130     wiz      2410: 11. Edit mk.conf, see Section 7.3.1.2, "mk.conf".
1.20      ben      2411:
1.1       grant    2412: 12. Adjust mk/bulk/build.conf to suit your needs.
1.20      ben      2413:
1.47      reed     2414: When the chroot sandbox is set up, you can start the build with the following
1.1       grant    2415: steps:
                   2416:
                   2417: # cd /usr/sandbox/usr/pkgsrc
                   2418: # sh mk/bulk/do-sandbox-build
                   2419:
1.87      wiz      2420:
1.1       grant    2421: This will just jump inside the sandbox and start building. At the end of the
                   2422: build, mail will be sent with the results of the build. Created binary pkgs
                   2423: will be in /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/
                   2424: from).
                   2425:
1.107     rillig   2426: 7.3.7. Building a partial set of packages
1.1       grant    2427:
                   2428: In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk
                   2429: /bulk/build script may be used to build a subset of the packages contained in
1.105     rillig   2430: pkgsrc. By setting SPECIFIC_PKGS in mk.conf, the variables
1.1       grant    2431:
                   2432:   * SITE_SPECIFIC_PKGS
1.20      ben      2433:
1.1       grant    2434:   * HOST_SPECIFIC_PKGS
1.20      ben      2435:
1.1       grant    2436:   * GROUP_SPECIFIC_PKGS
1.20      ben      2437:
1.1       grant    2438:   * USER_SPECIFIC_PKGS
1.20      ben      2439:
1.1       grant    2440: will define the set of packages which should be built. The bulk build code will
                   2441: also include any packages which are needed as dependencies for the explicitly
                   2442: listed packages.
                   2443:
                   2444: One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
                   2445: periodically to have a complete set of the binary packages needed for your site
                   2446: available without the overhead of building extra packages that are not needed.
                   2447:
1.107     rillig   2448: 7.3.8. Uploading results of a bulk build
1.13      hubertf  2449:
                   2450: This section describes how pkgsrc developers can upload binary pkgs built by
                   2451: bulk builds to ftp.NetBSD.org.
                   2452:
1.17      sketch   2453: If you would like to automatically create checksum files for the binary
                   2454: packages you intend to upload, remember to set MKSUMS=yes in your mk/bulk/
                   2455: build.conf.
                   2456:
                   2457: If you would like to PGP sign the checksum files (highly recommended!),
                   2458: remember to set SIGN_AS=username@NetBSD.org in your mk/bulk/build.conf. This
1.23      wiz      2459: will prompt you for your GPG password to sign the files before uploading
1.17      sketch   2460: everything.
                   2461:
                   2462: Then, make sure that you have RSYNC_DST set properly in your mk/bulk/build.conf
                   2463: file, i.e. adjust it to something like one of the following:
1.13      hubertf  2464:
1.134     spz      2465: RSYNC_DST=ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload
1.13      hubertf  2466:
1.134     spz      2467: Please use appropriate values for "20xxQy" (the branch), "a.b.c" (the OS
                   2468: version) and "arch" here. If your login on ftp.NetBSD.org is different from
                   2469: your local login, write your login directly into the variable, e.g. my local
                   2470: account is "feyrer", but for my login "hubertf", I use:
1.13      hubertf  2471:
1.134     spz      2472: RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload
1.13      hubertf  2473:
                   2474: A separate upload directory is used here to allow "closing" the directory
                   2475: during upload. To do so, run the following command on ftp.NetBSD.org next:
                   2476:
1.134     spz      2477: nbftp% mkdir -p -m 750 /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload
1.13      hubertf  2478:
1.23      wiz      2479: Before uploading the binary pkgs, ssh authentication needs to be set up. This
1.47      reed     2480: example shows how to set up temporary keys for the root account inside the
1.13      hubertf  2481: sandbox (assuming that no keys should be present there usually):
                   2482:
1.20      ben      2483: # chroot /usr/sandbox
                   2484: chroot-# rm $HOME/.ssh/id-dsa*
1.134     spz      2485: chroot-# ssh-keygen -t rsa
                   2486: chroot-# cat $HOME/.ssh/id-rsa.pub
1.13      hubertf  2487:
1.87      wiz      2488:
1.134     spz      2489: Now take the output of id-rsa.pub and append it to your ~/.ssh/authorized_keys
                   2490: file on ftp.NetBSD.org. You should remove the key after the upload is done!
1.13      hubertf  2491:
                   2492: Next, test if your ssh connection really works:
                   2493:
1.20      ben      2494: chroot-# ssh ftp.NetBSD.org date
1.13      hubertf  2495:
                   2496: Use "-l yourNetBSDlogin" here as appropriate!
                   2497:
                   2498: Now after all this works, you can exit the sandbox and start the upload:
                   2499:
1.20      ben      2500: chroot-# exit
                   2501: # cd /usr/sandbox/usr/pkgsrc
                   2502: # sh mk/bulk/do-sandbox-upload
1.13      hubertf  2503:
1.87      wiz      2504:
1.24      wiz      2505: The upload process may take quite some time. Use ls(1) or du(1) on the FTP
                   2506: server to monitor progress of the upload. The upload script will take care of
1.129     spz      2507: not uploading restricted packages.
1.13      hubertf  2508:
                   2509: After the upload has ended, first thing is to revoke ssh access:
                   2510:
                   2511: nbftp% vi ~/.ssh/authorized_keys
1.87      wiz      2512:       Gdd:x!
1.13      hubertf  2513:
                   2514: Use whatever is needed to remove the key you've entered before! Last, move the
                   2515: uploaded packages out of the upload directory to have them accessible to
                   2516: everyone:
                   2517:
1.134     spz      2518: nbftp% cd /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy
1.13      hubertf  2519: nbftp% mv upload/* .
                   2520: nbftp% rmdir upload
1.134     spz      2521: nbftp% chgrp -R netbsd .
                   2522: nbftp% find . -type d | xargs chmod 775
1.13      hubertf  2523:
1.87      wiz      2524:
1.107     rillig   2525: 7.4. Running a pbulk-style bulk build
                   2526:
1.117     rillig   2527: Running a pbulk-style bulk build works roughly as follows:
                   2528:
                   2529:   * First, build the pbulk infrastructure in a fresh pkgsrc location.
                   2530:
                   2531:   * Then, build each of the packages from a clean installation directory using
                   2532:     the infrastructure.
                   2533:
                   2534: 7.4.1. Preparation
                   2535:
                   2536: First, you need to create a pkgsrc installation for the pbulk infrastructure.
                   2537: No matter on which platform you are (even on NetBSD), you should bootstrap into
1.118     jnemeth  2538: its own directory. Let's take the directory /usr/pbulk or $HOME/pbulk for it.
                   2539: This installation will be bootstrapped and all the tools that are required for
                   2540: the bulk build will be installed there.
1.117     rillig   2541:
                   2542: $ cd /usr/pkgsrc
                   2543: $ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap
                   2544: $ rm -rf /tmp/pbulk-bootstrap
                   2545:
                   2546: Now the basic environment for the pbulk infrastructure is installed. The
                   2547: specific tools are still missing. This is a good time to edit the pkgsrc
                   2548: configuration file /usr/pbulk/etc/mk.conf to fit your needs. Typical things you
                   2549: might set now are:
                   2550:
                   2551:   * PKG_DEVELOPER=yes, to enable many consistency checks,
                   2552:
                   2553:   * WRKOBJDIR=/tmp/pbulk-outer, to keep /usr/pkgsrc free from any
                   2554:     modifications,
                   2555:
                   2556:   * DISTDIR=/distfiles, to have only one directory in which all distfiles (for
                   2557:     the infrastructure and for the actual packages) are downloaded,
                   2558:
                   2559:   * ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual
                   2560:     Free/Open Source licenses that are acceptable to you,
                   2561:
1.126     wiz      2562:   * SKIP_LICENSE_CHECK=yes, to bypass the license checks.
1.117     rillig   2563:
                   2564: Now you are ready to build the rest of the pbulk infrastructure.
                   2565:
                   2566: $ cd pkgtools/pbulk
                   2567: $ /usr/pbulk/bin/bmake install
                   2568: $ rm -rf /tmp/pbulk-outer
                   2569:
                   2570: Now the pbulk infrastructure is built and installed. It still needs to be
                   2571: configured, and after some more preparation, we will be able to start the real
                   2572: bulk build.
                   2573:
                   2574: 7.4.2. Configuration
1.107     rillig   2575:
1.115     jmcneill 2576: TODO; see pkgsrc/doc/HOWTO-pbulk for more information.
1.107     rillig   2577:
1.117     rillig   2578: TODO: continue writing
                   2579:
1.107     rillig   2580: 7.5. Creating a multiple CD-ROM packages collection
1.1       grant    2581:
                   2582: After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
                   2583: of the resulting binary packages to assist in installing packages on other
                   2584: machines. The pkgtools/cdpack package provides a simple tool for creating the
                   2585: ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
1.47      reed     2586: keeps all the dependencies for a given package on the same CD as that package.
1.1       grant    2587:
1.107     rillig   2588: 7.5.1. Example of cdpack
1.1       grant    2589:
1.47      reed     2590: Complete documentation for cdpack is found in the cdpack(1) man page. The
1.1       grant    2591: following short example assumes that the binary packages are left in /usr/
                   2592: pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
                   2593: ISO 9660 images.
                   2594:
                   2595: # mkdir /u2/images
                   2596: # pkg_add /usr/pkgsrc/packages/All/cdpack
                   2597: # cdpack /usr/pkgsrc/packages/All /u2/images
                   2598:
1.87      wiz      2599:
1.1       grant    2600: If you wish to include a common set of files (COPYRIGHT, README, etc.) on each
                   2601: CD in the collection, then you need to create a directory which contains these
                   2602: files. e.g.
                   2603:
                   2604: # mkdir /tmp/common
                   2605: # echo "This is a README" > /tmp/common/README
                   2606: # echo "Another file" > /tmp/common/COPYING
                   2607: # mkdir /tmp/common/bin
                   2608: # echo "#!/bin/sh" > /tmp/common/bin/myscript
                   2609: # echo "echo Hello world" >> /tmp/common/bin/myscript
                   2610: # chmod 755 /tmp/common/bin/myscript
                   2611:
1.87      wiz      2612:
1.1       grant    2613: Now create the images:
                   2614:
                   2615: # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
                   2616:
                   2617: Each image will contain README, COPYING, and bin/myscript in their root
                   2618: directories.
                   2619:
1.107     rillig   2620: Chapter 8. Directory layout of the installed files
1.90      rillig   2621:
                   2622: Table of Contents
                   2623:
1.107     rillig   2624: 8.1. File system layout in ${LOCALBASE}
                   2625: 8.2. File system layout in ${VARBASE}
1.90      rillig   2626:
                   2627: The files that are installed by pkgsrc are organized in a way that is similar
                   2628: to what you find in the /usr directory of the base system. But some details are
                   2629: different. This is because pkgsrc initially came from FreeBSD and had adopted
                   2630: its file system hierarchy. Later it was largely influenced by NetBSD. But no
                   2631: matter which operating system you are using pkgsrc with, you can expect the
                   2632: same layout for pkgsrc.
                   2633:
1.91      rillig   2634: There are mainly four root directories for pkgsrc, which are all configurable
                   2635: in the bootstrap/bootstrap script. When pkgsrc has been installed as root, the
                   2636: default locations are:
                   2637:
1.101     rillig   2638: LOCALBASE=              /usr/pkg
                   2639: PKG_SYSCONFBASE=        /usr/pkg/etc
                   2640: VARBASE=                /var
                   2641: PKG_DBDIR=              /var/db/pkg
1.91      rillig   2642:
                   2643: In unprivileged mode (when pkgsrc has been installed as any other user), the
                   2644: default locations are:
                   2645:
1.101     rillig   2646: LOCALBASE=              ${HOME}/pkg
                   2647: PKG_SYSCONFBASE=        ${HOME}/pkg/etc
                   2648: VARBASE=                ${HOME}/pkg/var
                   2649: PKG_DBDIR=              ${HOME}/pkg/var/db/pkg
1.91      rillig   2650:
                   2651: What these four directories are for, and what they look like is explained
                   2652: below.
1.90      rillig   2653:
1.132     wiz      2654:   * LOCALBASE corresponds to the /usr directory in the base system. It is the "
                   2655:     main" directory where the files are installed and contains the well-known
1.90      rillig   2656:     subdirectories like bin, include, lib, share and sbin.
                   2657:
                   2658:   * VARBASE corresponds to /var in the base system. Some programs (especially
                   2659:     games, network daemons) need write access to it during normal operation.
                   2660:
                   2661:   * PKG_SYSCONFDIR corresponds to /etc in the base system. It contains
                   2662:     configuration files of the packages, as well as pkgsrc's mk.conf itself.
                   2663:
1.107     rillig   2664: 8.1. File system layout in ${LOCALBASE}
1.90      rillig   2665:
1.91      rillig   2666: The following directories exist in a typical pkgsrc installation in $
                   2667: {LOCALBASE}.
1.90      rillig   2668:
                   2669: bin
                   2670:
                   2671:     Contains executable programs that are intended to be directly used by the
                   2672:     end user.
                   2673:
                   2674: emul
                   2675:
                   2676:     Contains files for the emulation layers of various other operating systems,
                   2677:     especially for NetBSD.
                   2678:
                   2679: etc (the usual location of ${PKG_SYSCONFDIR})
                   2680:
                   2681:     Contains the configuration files.
                   2682:
                   2683: include
                   2684:
                   2685:     Contains headers for the C and C++ programming languages.
                   2686:
                   2687: info
                   2688:
                   2689:     Contains GNU info files of various packages.
                   2690:
                   2691: lib
                   2692:
                   2693:     Contains shared and static libraries.
                   2694:
                   2695: libdata
                   2696:
                   2697:     Contains data files that don't change after installation. Other data files
                   2698:     belong into ${VARBASE}.
                   2699:
                   2700: libexec
                   2701:
                   2702:     Contains programs that are not intended to be used by end users, such as
                   2703:     helper programs or network daemons.
                   2704:
                   2705: libexec/cgi-bin
                   2706:
                   2707:     Contains programs that are intended to be executed as CGI scripts by a web
                   2708:     server.
                   2709:
                   2710: man (the usual value of ${PKGMANDIR})
                   2711:
                   2712:     Contains brief documentation in form of manual pages.
                   2713:
                   2714: sbin
                   2715:
                   2716:     Contains programs that are intended to be used only by the super-user.
                   2717:
                   2718: share
                   2719:
                   2720:     Contains platform-independent data files that don't change after
                   2721:     installation.
                   2722:
                   2723: share/doc
                   2724:
                   2725:     Contains documentation files provided by the packages.
                   2726:
                   2727: share/examples
                   2728:
                   2729:     Contains example files provided by the packages. Among others, the original
                   2730:     configuration files are saved here and copied to ${PKG_SYSCONFDIR} during
                   2731:     installation.
                   2732:
                   2733: share/examples/rc.d
                   2734:
                   2735:     Contains the original files for rc.d scripts.
                   2736:
                   2737: var (the usual location of ${VARBASE})
                   2738:
                   2739:     Contains files that may be modified after installation.
                   2740:
1.107     rillig   2741: 8.2. File system layout in ${VARBASE}
1.90      rillig   2742:
                   2743: db/pkg (the usual location of ${PKG_DBDIR})
                   2744:
                   2745:     Contains information about the currently installed packages.
                   2746:
                   2747: games
                   2748:
                   2749:     Contains highscore files.
                   2750:
                   2751: log
                   2752:
                   2753:     Contains log files.
                   2754:
                   2755: run
                   2756:
                   2757:     Contains informational files about daemons that are currently running.
                   2758:
1.107     rillig   2759: Chapter 9. Frequently Asked Questions
1.1       grant    2760:
                   2761: Table of Contents
                   2762:
1.107     rillig   2763: 9.1. Are there any mailing lists for pkg-related discussion?
                   2764: 9.2. Where's the pkgviews documentation?
                   2765: 9.3. Utilities for package management (pkgtools)
                   2766: 9.4. How to use pkgsrc as non-root
                   2767: 9.5. How to resume transfers when fetching distfiles?
                   2768: 9.6. How can I install/use modular X.org from pkgsrc?
                   2769: 9.7. How to fetch files from behind a firewall
                   2770: 9.8. How do I tell make fetch to do passive FTP?
                   2771: 9.9. How to fetch all distfiles at once
1.130     wiz      2772: 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
                   2773: 9.11. What does "Could not find bsd.own.mk" mean?
1.107     rillig   2774: 9.12. Using 'sudo' with pkgsrc
                   2775: 9.13. How do I change the location of configuration files?
                   2776: 9.14. Automated security checks
                   2777: 9.15. Why do some packages ignore my CFLAGS?
                   2778: 9.16. A package does not build. What shall I do?
1.130     wiz      2779: 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
                   2780:     conflicts" mean?
1.1       grant    2781:
                   2782: This section contains hints, tips & tricks on special things in pkgsrc that we
                   2783: didn't find a better place for in the previous chapters, and it contains items
                   2784: for both pkgsrc users and developers.
                   2785:
1.107     rillig   2786: 9.1. Are there any mailing lists for pkg-related discussion?
1.1       grant    2787:
1.18      xtraeme  2788: The following mailing lists may be of interest to pkgsrc users:
1.1       grant    2789:
1.78      rillig   2790:   * pkgsrc-users: This is a general purpose list for most issues regarding
                   2791:     pkgsrc, regardless of platform, e.g. soliciting user help for pkgsrc
                   2792:     configuration, unexpected build failures, using particular packages,
                   2793:     upgrading pkgsrc installations, questions regarding the pkgsrc release
                   2794:     branches, etc. General announcements or proposals for changes that impact
                   2795:     the pkgsrc user community, e.g. major infrastructure changes, new features,
                   2796:     package removals, etc., may also be posted.
1.20      ben      2797:
1.34      wiz      2798:   * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and
                   2799:     discussed.
1.20      ben      2800:
1.71      wiz      2801:   * pkgsrc-changes: This list is for those who are interested in getting a
                   2802:     commit message for every change committed to pkgsrc. It is also available
                   2803:     in digest form, meaning one daily message containing all commit messages
                   2804:     for changes to the package source tree in that 24 hour period.
                   2805:
1.18      xtraeme  2806: To subscribe, do:
                   2807:
1.101     rillig   2808: % echo subscribe listname | mail majordomo@NetBSD.org
1.18      xtraeme  2809:
                   2810: Archives for all these mailing lists are available from http://
                   2811: mail-index.NetBSD.org/.
1.1       grant    2812:
1.107     rillig   2813: 9.2. Where's the pkgviews documentation?
1.1       grant    2814:
                   2815: Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's
                   2816: guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.
                   2817:
1.107     rillig   2818: 9.3. Utilities for package management (pkgtools)
1.1       grant    2819:
1.80      rillig   2820: The directory pkgsrc/pkgtools contains a number of useful utilities for both
                   2821: users and developers of pkgsrc. This section attempts only to make the reader
                   2822: aware of the utilities and when they might be useful, and not to duplicate the
                   2823: documentation that comes with each package.
1.1       grant    2824:
                   2825: Utilities used by pkgsrc (automatically installed when needed):
                   2826:
1.34      wiz      2827:   * pkgtools/x11-links: Symlinks for use by buildlink.
1.20      ben      2828:
1.1       grant    2829: OS tool augmentation (automatically installed when needed):
                   2830:
1.34      wiz      2831:   * pkgtools/digest: Calculates various kinds of checksums (including SHA1).
1.20      ben      2832:
1.34      wiz      2833:   * pkgtools/libnbcompat: Compatibility library for pkgsrc tools.
1.20      ben      2834:
1.34      wiz      2835:   * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree.
1.20      ben      2836:
1.34      wiz      2837:   * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or
                   2838:     for use on operating systems where pkg_install is not present.
1.20      ben      2839:
1.1       grant    2840: Utilities used by pkgsrc (not automatically installed):
                   2841:
1.34      wiz      2842:   * pkgtools/pkg_tarup: Create a binary package from an already-installed
                   2843:     package. Used by make replace to save the old package.
1.20      ben      2844:
1.34      wiz      2845:   * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch
1.5       hubertf  2846:     distfiles from multiple locations. It currently supports the following
                   2847:     methods: multiple CD-ROMs and network FTP/HTTP connections.
1.20      ben      2848:
1.34      wiz      2849:   * pkgtools/xpkgwedge: Put X11 packages someplace else (enabled by default).
1.20      ben      2850:
1.34      wiz      2851:   * devel/cpuflags: Determine the best compiler flags to optimise code for your
1.130     wiz      2852:     current CPU and compiler.
1.20      ben      2853:
1.1       grant    2854: Utilities for keeping track of installed packages, being up to date, etc:
                   2855:
1.34      wiz      2856:   * pkgtools/pkg_chk: Reports on packages whose installed versions do not match
                   2857:     the latest pkgsrc entries.
1.20      ben      2858:
1.34      wiz      2859:   * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a
                   2860:     strategy for updating.
1.20      ben      2861:
1.34      wiz      2862:   * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses
                   2863:     graphviz).
1.20      ben      2864:
1.113     weinem   2865:   * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors.
                   2866:
                   2867:   * pkgtools/lintpkgsrc: The lintpkgsrc(1) program does various checks on the
                   2868:     complete pkgsrc system.
1.20      ben      2869:
1.34      wiz      2870:   * pkgtools/pkgsurvey: Report what packages you have installed.
1.20      ben      2871:
1.1       grant    2872: Utilities for people maintaining or creating individual packages:
                   2873:
1.34      wiz      2874:   * pkgtools/pkgdiff: Automate making and maintaining patches for a package
                   2875:     (includes pkgdiff, pkgvi, mkpatches, etc.).
1.20      ben      2876:
1.34      wiz      2877:   * pkgtools/rpm2pkg, pkgtools/url2pkg: Aids in converting to pkgsrc.
1.20      ben      2878:
1.34      wiz      2879:   * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package.
1.20      ben      2880:
1.47      reed     2881: Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
1.20      ben      2882:
1.34      wiz      2883:   * pkgtools/pkg_comp: Build packages in a chrooted area.
1.20      ben      2884:
1.34      wiz      2885:   * pkgtools/libkver: Spoof kernel version for chrooted cross builds.
1.20      ben      2886:
1.107     rillig   2887: 9.4. How to use pkgsrc as non-root
1.1       grant    2888:
                   2889: If you want to use pkgsrc as non-root user, you can set some variables to make
1.33      jmmv     2890: pkgsrc work under these conditions. At the very least, you need to set
                   2891: UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple
                   2892: related variables to allow installation of packages as non-root.
                   2893:
                   2894: In case the defaults are not enough, you may want to tune some other variables
                   2895: used. For example, if the automatic user/group detection leads to incorrect
                   2896: values (or not the ones you would like to use), you can change them by setting
                   2897: UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively.
                   2898:
                   2899: As regards bootstrapping, please note that the bootstrap script will ease
                   2900: non-root configuration when given the "--ignore-user-check" flag, as it will
                   2901: choose and use multiple default directories under ~/pkg as the installation
1.93      rillig   2902: targets. These directories can be overridden by the "--prefix" flag provided by
1.33      jmmv     2903: the script, as well as some others that allow finer tuning of the tree layout.
1.1       grant    2904:
1.107     rillig   2905: 9.5. How to resume transfers when fetching distfiles?
1.14      xtraeme  2906:
1.47      reed     2907: By default, resuming transfers in pkgsrc is disabled, but you can enable this
1.105     rillig   2908: feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
                   2909: a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.
1.15      xtraeme  2910:
                   2911: You can also use a different program than the default ftp(1) by changing the
1.118     jnemeth  2912: FETCH_USING variable. You can specify the program by using of ftp, fetch, wget
                   2913: or curl. Alternatively, fetching can be disabled by using the value manual. A
                   2914: value of custom disables the system defaults and dependency tracking for the
                   2915: fetch program. In that case you have to provide FETCH_CMD, FETCH_BEFORE_ARGS,
                   2916: FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.
1.14      xtraeme  2917:
1.118     jnemeth  2918: For example, if you want to use wget to download, you'll have to use something
                   2919: like:
1.14      xtraeme  2920:
1.118     jnemeth  2921: FETCH_USING=    wget
1.14      xtraeme  2922:
1.107     rillig   2923: 9.6. How can I install/use modular X.org from pkgsrc?
1.1       grant    2924:
1.104     wiz      2925: If you want to use modular X.org from pkgsrc instead of your system's own X11
1.105     rillig   2926: (/usr/X11R6, /usr/openwin, ...) you will have to add the following line into
                   2927: mk.conf:
1.14      xtraeme  2928:
1.104     wiz      2929: X11_TYPE=modular
1.14      xtraeme  2930:
1.70      rillig   2931: Note
                   2932:
1.104     wiz      2933: The DragonFly operating system defaults to using modular X.org from pkgsrc.
1.70      rillig   2934:
1.107     rillig   2935: 9.7. How to fetch files from behind a firewall
1.1       grant    2936:
                   2937: If you are sitting behind a firewall which does not allow direct connections to
                   2938: Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
1.47      reed     2939: is done using an environment variable in the form of a URL, e.g. in Amdahl, the
1.1       grant    2940: machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
                   2941: the proxy port number. So the proxy environment variables are:
                   2942:
1.101     rillig   2943: ftp_proxy=ftp://orpheus.amdahl.com:80/
                   2944: http_proxy=http://orpheus.amdahl.com:80/
1.1       grant    2945:
1.107     rillig   2946: 9.8. How do I tell make fetch to do passive FTP?
1.1       grant    2947:
                   2948: This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
                   2949: FETCH_CMD is assigned the first available command from the following list:
                   2950:
1.34      wiz      2951:   * ${LOCALBASE}/bin/ftp
                   2952:
                   2953:   * /usr/bin/ftp
1.1       grant    2954:
                   2955: On a default NetBSD installation, this will be /usr/bin/ftp, which
                   2956: automatically tries passive connections first, and falls back to active
                   2957: connections if the server refuses to do passive. For the other tools, add the
1.105     rillig   2958: following to your mk.conf file: PASSIVE_FETCH=1.
1.1       grant    2959:
                   2960: Having that option present will prevent /usr/bin/ftp from falling back to
                   2961: active transfers.
                   2962:
1.107     rillig   2963: 9.9. How to fetch all distfiles at once
1.1       grant    2964:
                   2965: You would like to download all the distfiles in a single batch from work or
                   2966: university, where you can't run a make fetch. There is an archive of distfiles
                   2967: on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
                   2968:
1.47      reed     2969: The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
1.1       grant    2970: subdirectories, carry the resulting list to your machine at work/school and use
1.72      rillig   2971: it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work,
1.1       grant    2972: don't forget to set FETCH_CMD to something that fetches a URL:
                   2973:
                   2974: At home:
                   2975:
                   2976: % cd /usr/pkgsrc
                   2977: % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
                   2978: % scp /tmp/fetch.sh work:/tmp
                   2979:
                   2980: At work:
                   2981:
                   2982: % sh /tmp/fetch.sh
                   2983:
                   2984: then tar up /tmp/distfiles and take it home.
                   2985:
                   2986: If you have a machine running NetBSD, and you want to get all distfiles (even
                   2987: ones that aren't for your machine architecture), you can do so by using the
                   2988: above-mentioned make fetch-list approach, or fetch the distfiles directly by
                   2989: running:
                   2990:
                   2991: % make mirror-distfiles
                   2992:
                   2993: If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can get
                   2994: everything by running:
                   2995:
                   2996: % make fetch NO_SKIP=yes
                   2997:
1.107     rillig   2998: 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
1.1       grant    2999:
                   3000: When compiling the pkgtools/pkg_install package, you get the error from make
                   3001: that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
1.23      wiz      3002: that you don't have installed the "text" set (nroff, ...) from the NetBSD base
1.47      reed     3003: distribution on your machine. It is recommended to do that to format man pages.
1.1       grant    3004:
                   3005: In the case of the pkgtools/pkg_install package, you can get away with setting
1.105     rillig   3006: NOMAN=YES either in the environment or in mk.conf.
1.1       grant    3007:
1.107     rillig   3008: 9.11. What does "Could not find bsd.own.mk" mean?
1.1       grant    3009:
                   3010: You didn't install the compiler set, comp.tgz, when you installed your NetBSD
1.47      reed     3011: machine. Please get and install it, by extracting it in /:
1.1       grant    3012:
                   3013: # cd /
                   3014: # tar --unlink -zxvpf .../comp.tgz
                   3015:
                   3016: comp.tgz is part of every NetBSD release. Get the one that corresponds to your
                   3017: release (determine via uname -r).
                   3018:
1.107     rillig   3019: 9.12. Using 'sudo' with pkgsrc
1.1       grant    3020:
                   3021: When installing packages as non-root user and using the just-in-time su(1)
                   3022: feature of pkgsrc, it can become annoying to type in the root password for each
                   3023: required package installed. To avoid this, the sudo package can be used, which
                   3024: does password caching over a limited time. To use it, install sudo (either as
1.105     rillig   3025: binary package or from security/sudo) and then put the following into your
                   3026: mk.conf, somewhere after the definition of the LOCALBASE variable:
1.1       grant    3027:
1.101     rillig   3028: .if exists(${LOCALBASE}/bin/sudo)
                   3029: SU_CMD=        ${LOCALBASE}/bin/sudo /bin/sh -c
                   3030: .endif
1.14      xtraeme  3031:
1.107     rillig   3032: 9.13. How do I change the location of configuration files?
1.1       grant    3033:
1.35      jmmv     3034: As the system administrator, you can choose where configuration files are
                   3035: installed. The default settings make all these files go into ${PREFIX}/etc or
                   3036: some of its subdirectories; this may be suboptimal depending on your
                   3037: expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine
                   3038: configuration of the provided packages).
                   3039:
                   3040: In order to change the defaults, you can modify the PKG_SYSCONFBASE variable
1.105     rillig   3041: (in mk.conf) to point to your preferred configuration directory; some common
                   3042: examples include /etc or /etc/pkg.
1.35      jmmv     3043:
                   3044: Furthermore, you can change this value on a per-package basis by setting the
                   3045: PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
                   3046: matches the name of the package you would like to modify, that is, the contents
                   3047: of PKGBASE.
1.1       grant    3048:
1.47      reed     3049: Note that after changing these settings, you must rebuild and reinstall any
1.35      jmmv     3050: affected packages.
1.1       grant    3051:
1.107     rillig   3052: 9.14. Automated security checks
1.1       grant    3053:
                   3054: Please be aware that there can often be bugs in third-party software, and some
                   3055: of these bugs can leave a machine vulnerable to exploitation by attackers. In
                   3056: an effort to lessen the exposure, the NetBSD packages team maintains a database
                   3057: of known-exploits to packages which have at one time been included in pkgsrc.
                   3058: The database can be downloaded automatically, and a security audit of all
1.115     jmcneill 3059: packages installed on a system can take place. To do this, refer to the
                   3060: following two tools (installed as part of the pkgtools/pkg_install package):
1.1       grant    3061:
1.123     reed     3062:  1. pkg_admin fetch-pkg-vulnerabilities, an easy way to download a list of the
                   3063:     security vulnerabilities information. This list is kept up to date by the
1.134     spz      3064:     pkgsrc security team, and is distributed from the NetBSD ftp server:
1.20      ben      3065:
1.134     spz      3066:     ftp://ftp.NetBSD.org/pkgsrc/distfiles/pkg-vulnerabilities
1.20      ben      3067:
1.123     reed     3068:  2. pkg_admin audit, an easy way to audit the current machine, checking each
1.130     wiz      3069:     known vulnerability. If a vulnerable package is installed, it will be shown
                   3070:     by output to stdout, including a description of the type of vulnerability,
                   3071:     and a URL containing more information.
1.20      ben      3072:
1.115     jmcneill 3073: Use of these tools is strongly recommended! After "pkg_install" is installed,
                   3074: please read the package's message, which you can get by running pkg_info -D
                   3075: pkg_install.
1.1       grant    3076:
1.58      erh      3077: If this package is installed, pkgsrc builds will use it to perform a security
                   3078: check before building any package. See Section 5.2, "Variables affecting the
1.59      rillig   3079: build process" for ways to control this check.
1.58      erh      3080:
1.107     rillig   3081: 9.15. Why do some packages ignore my CFLAGS?
1.74      rillig   3082:
                   3083: When you add your own preferences to the CFLAGS variable in your mk.conf, these
                   3084: flags are passed in environment variables to the ./configure scripts and to
                   3085: make(1). Some package authors ignore the CFLAGS from the environment variable
                   3086: by overriding them in the Makefiles of their package.
                   3087:
                   3088: Currently there is no solution to this problem. If you really need the package
                   3089: to use your CFLAGS you should run make patch in the package directory and then
                   3090: inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly.
                   3091: Usually you can remove these lines. But be aware that some "smart" programmers
                   3092: write so bad code that it only works for the specific combination of CFLAGS
                   3093: they have chosen.
                   3094:
1.107     rillig   3095: 9.16. A package does not build. What shall I do?
1.80      rillig   3096:
                   3097:  1. Make sure that your copy of pkgsrc is consistent. A case that occurs often
                   3098:     is that people only update pkgsrc in parts, because of performance reasons.
                   3099:     Since pkgsrc is one large system, not a collection of many small systems,
                   3100:     there are sometimes changes that only work when the whole pkgsrc tree is
                   3101:     updated.
                   3102:
1.132     wiz      3103:  2. Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or "
                   3104:     >>>>>>" in all your pkgsrc files.
1.80      rillig   3105:
1.132     wiz      3106:  3. Make sure that you don't have old copies of the packages extracted. Run
1.80      rillig   3107:     make clean clean-depends to verify this.
                   3108:
                   3109:  4. If the problem still exists, write a mail to the pkgsrc-users mailing list.
                   3110:
1.107     rillig   3111: 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
1.89      rillig   3112: conflicts" mean?
                   3113:
                   3114: You have modified a file from pkgsrc, and someone else has modified that same
                   3115: file afterwards in the CVS repository. Both changes are in the same region of
                   3116: the file, so when you updated pkgsrc, the cvs command marked the conflicting
                   3117: changes in the file. Because of these markers, the file is no longer a valid
                   3118: Makefile.
                   3119:
                   3120: Have a look at that file, and if you don't need your local changes anymore, you
                   3121: can remove that file and run cvs -q update -dP in that directory to download
                   3122: the current version.
                   3123:
1.48      dillo    3124: Part II. The pkgsrc developer's guide
1.1       grant    3125:
1.77      rillig   3126: This part of the book deals with creating and modifying packages. It starts
                   3127: with a "HOWTO"-like guide on creating a new package. The remaining chapters are
                   3128: more like a reference manual for pkgsrc.
                   3129:
1.1       grant    3130: Table of Contents
                   3131:
1.107     rillig   3132: 10. Creating a new pkgsrc package from scratch
1.91      rillig   3133:
1.107     rillig   3134:     10.1. Common types of packages
1.91      rillig   3135:
1.107     rillig   3136:         10.1.1. Perl modules
                   3137:         10.1.2. KDE applications
1.119     imil     3138:         10.1.3. Python modules and programs
1.91      rillig   3139:
1.107     rillig   3140:     10.2. Examples
1.91      rillig   3141:
1.107     rillig   3142:         10.2.1. How the www/nvu package came into pkgsrc
1.91      rillig   3143:
1.107     rillig   3144: 11. Package components - files, directories and contents
1.27      rillig   3145:
1.107     rillig   3146:     11.1. Makefile
                   3147:     11.2. distinfo
                   3148:     11.3. patches/*
1.85      jmmv     3149:
1.107     rillig   3150:         11.3.1. Structure of a single patch file
                   3151:         11.3.2. Creating patch files
                   3152:         11.3.3. Sources where the patch files come from
                   3153:         11.3.4. Patching guidelines
                   3154:         11.3.5. Feedback to the author
1.85      jmmv     3155:
1.107     rillig   3156:     11.4. Other mandatory files
                   3157:     11.5. Optional files
1.78      rillig   3158:
1.107     rillig   3159:         11.5.1. Files affecting the binary package
                   3160:         11.5.2. Files affecting the build process
                   3161:         11.5.3. Files affecting nothing at all
1.78      rillig   3162:
1.107     rillig   3163:     11.6. work*
                   3164:     11.7. files/*
1.27      rillig   3165:
1.107     rillig   3166: 12. Programming in Makefiles
1.25      rillig   3167:
1.107     rillig   3168:     12.1. Caveats
                   3169:     12.2. Makefile variables
1.25      rillig   3170:
1.107     rillig   3171:         12.2.1. Naming conventions
1.27      rillig   3172:
1.107     rillig   3173:     12.3. Code snippets
1.27      rillig   3174:
1.107     rillig   3175:         12.3.1. Adding things to a list
                   3176:         12.3.2. Converting an internal list into an external list
                   3177:         12.3.3. Passing variables to a shell command
                   3178:         12.3.4. Quoting guideline
                   3179:         12.3.5. Workaround for a bug in BSD Make
1.20      ben      3180:
1.107     rillig   3181: 13. PLIST issues
1.20      ben      3182:
1.107     rillig   3183:     13.1. RCS ID
                   3184:     13.2. Semi-automatic PLIST generation
                   3185:     13.3. Tweaking output of make print-PLIST
                   3186:     13.4. Variable substitution in PLIST
                   3187:     13.5. Man page compression
                   3188:     13.6. Changing PLIST source with PLIST_SRC
                   3189:     13.7. Platform-specific and differing PLISTs
                   3190:     13.8. Sharing directories between packages
1.20      ben      3191:
1.107     rillig   3192: 14. Buildlink methodology
1.20      ben      3193:
1.107     rillig   3194:     14.1. Converting packages to use buildlink3
                   3195:     14.2. Writing buildlink3.mk files
1.20      ben      3196:
1.107     rillig   3197:         14.2.1. Anatomy of a buildlink3.mk file
1.135     wiz      3198:         14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.
                   3199:             pkg in buildlink3.mk files
1.20      ben      3200:
1.107     rillig   3201:     14.3. Writing builtin.mk files
1.20      ben      3202:
1.107     rillig   3203:         14.3.1. Anatomy of a builtin.mk file
                   3204:         14.3.2. Global preferences for native or pkgsrc software
1.20      ben      3205:
1.107     rillig   3206: 15. The pkginstall framework
1.35      jmmv     3207:
1.107     rillig   3208:     15.1. Files and directories outside the installation prefix
1.20      ben      3209:
1.107     rillig   3210:         15.1.1. Directory manipulation
                   3211:         15.1.2. File manipulation
1.20      ben      3212:
1.107     rillig   3213:     15.2. Configuration files
1.20      ben      3214:
1.107     rillig   3215:         15.2.1. How PKG_SYSCONFDIR is set
                   3216:         15.2.2. Telling the software where configuration files are
                   3217:         15.2.3. Patching installations
                   3218:         15.2.4. Disabling handling of configuration files
1.35      jmmv     3219:
1.107     rillig   3220:     15.3. System startup scripts
1.35      jmmv     3221:
1.107     rillig   3222:         15.3.1. Disabling handling of system startup scripts
1.35      jmmv     3223:
1.107     rillig   3224:     15.4. System users and groups
                   3225:     15.5. System shells
1.35      jmmv     3226:
1.107     rillig   3227:         15.5.1. Disabling shell registration
1.65      hubertf  3228:
1.107     rillig   3229:     15.6. Fonts
1.65      hubertf  3230:
1.107     rillig   3231:         15.6.1. Disabling automatic update of the fonts databases
1.35      jmmv     3232:
1.107     rillig   3233: 16. Options handling
1.35      jmmv     3234:
1.107     rillig   3235:     16.1. Global default options
                   3236:     16.2. Converting packages to use bsd.options.mk
                   3237:     16.3. Option Names
1.108     rillig   3238:     16.4. Determining the options of dependencies
1.35      jmmv     3239:
1.107     rillig   3240: 17. The build process
1.35      jmmv     3241:
1.107     rillig   3242:     17.1. Introduction
                   3243:     17.2. Program location
                   3244:     17.3. Directories used during the build process
                   3245:     17.4. Running a phase
                   3246:     17.5. The fetch phase
1.81      rillig   3247:
1.107     rillig   3248:         17.5.1. What to fetch and where to get it from
                   3249:         17.5.2. How are the files fetched?
1.81      rillig   3250:
1.107     rillig   3251:     17.6. The checksum phase
                   3252:     17.7. The extract phase
                   3253:     17.8. The patch phase
                   3254:     17.9. The tools phase
                   3255:     17.10. The wrapper phase
                   3256:     17.11. The configure phase
                   3257:     17.12. The build phase
                   3258:     17.13. The test phase
                   3259:     17.14. The install phase
                   3260:     17.15. The package phase
                   3261:     17.16. Cleaning up
                   3262:     17.17. Other helpful targets
1.35      jmmv     3263:
1.107     rillig   3264: 18. Tools needed for building or running
1.35      jmmv     3265:
1.107     rillig   3266:     18.1. Tools for pkgsrc builds
                   3267:     18.2. Tools needed by packages
                   3268:     18.3. Tools provided by platforms
                   3269:     18.4. Questions regarding the tools
1.68      rillig   3270:
1.107     rillig   3271: 19. Making your package work
1.68      rillig   3272:
1.107     rillig   3273:     19.1. General operation
1.68      rillig   3274:
1.107     rillig   3275:         19.1.1. Portability of packages
1.130     wiz      3276:         19.1.2. How to pull in user-settable variables from mk.conf
1.107     rillig   3277:         19.1.3. User interaction
                   3278:         19.1.4. Handling licenses
                   3279:         19.1.5. Restricted packages
                   3280:         19.1.6. Handling dependencies
                   3281:         19.1.7. Handling conflicts with other packages
                   3282:         19.1.8. Packages that cannot or should not be built
                   3283:         19.1.9. Packages which should not be deleted, once installed
                   3284:         19.1.10. Handling packages with security problems
                   3285:         19.1.11. How to handle incrementing versions when fixing an existing
1.1       grant    3286:             package
1.107     rillig   3287:         19.1.12. Substituting variable text in the package files (the SUBST
1.79      rillig   3288:             framework)
1.77      rillig   3289:
1.107     rillig   3290:     19.2. Fixing problems in the fetch phase
1.77      rillig   3291:
1.107     rillig   3292:         19.2.1. Packages whose distfiles aren't available for plain downloading
                   3293:         19.2.2. How to handle modified distfiles with the 'old' name
1.77      rillig   3294:
1.107     rillig   3295:     19.3. Fixing problems in the configure phase
1.77      rillig   3296:
1.107     rillig   3297:         19.3.1. Shared libraries - libtool
                   3298:         19.3.2. Using libtool on GNU packages that already support libtool
                   3299:         19.3.3. GNU Autoconf/Automake
                   3300:
                   3301:     19.4. Programming languages
                   3302:
                   3303:         19.4.1. C, C++, and Fortran
                   3304:         19.4.2. Java
                   3305:         19.4.3. Packages containing perl scripts
                   3306:         19.4.4. Other programming languages
                   3307:
                   3308:     19.5. Fixing problems in the build phase
                   3309:
                   3310:         19.5.1. Compiling C and C++ code conditionally
                   3311:         19.5.2. How to handle compiler bugs
1.130     wiz      3312:         19.5.3. Undefined reference to "..."
1.107     rillig   3313:         19.5.4. Running out of memory
                   3314:
                   3315:     19.6. Fixing problems in the install phase
                   3316:
                   3317:         19.6.1. Creating needed directories
                   3318:         19.6.2. Where to install documentation
                   3319:         19.6.3. Installing highscore files
                   3320:         19.6.4. Adding DESTDIR support to packages
                   3321:         19.6.5. Packages with hardcoded paths to other interpreters
                   3322:         19.6.6. Packages installing perl modules
                   3323:         19.6.7. Packages installing info files
                   3324:         19.6.8. Packages installing man pages
1.108     rillig   3325:         19.6.9. Packages installing GConf data files
1.120     mishka   3326:         19.6.10. Packages installing scrollkeeper/rarian data files
1.107     rillig   3327:         19.6.11. Packages installing X11 fonts
                   3328:         19.6.12. Packages installing GTK2 modules
                   3329:         19.6.13. Packages installing SGML or XML data
                   3330:         19.6.14. Packages installing extensions to the MIME database
                   3331:         19.6.15. Packages using intltool
                   3332:         19.6.16. Packages installing startup scripts
                   3333:         19.6.17. Packages installing TeX modules
                   3334:         19.6.18. Packages supporting running binaries in emulation
                   3335:         19.6.19. Packages installing hicolor theme icons
                   3336:         19.6.20. Packages installing desktop files
                   3337:
                   3338:     19.7. Marking packages as having problems
                   3339:
                   3340: 20. Debugging
                   3341: 21. Submitting and Committing
                   3342:
                   3343:     21.1. Submitting binary packages
                   3344:     21.2. Submitting source packages (for non-NetBSD-developers)
                   3345:     21.3. General notes when adding, updating, or removing packages
                   3346:     21.4. Committing: Importing a package into CVS
                   3347:     21.5. Updating a package to a newer version
1.123     reed     3348:     21.6. Renaming a package in pkgsrc
                   3349:     21.7. Moving a package in pkgsrc
1.107     rillig   3350:
                   3351: 22. Frequently Asked Questions
                   3352: 23. GNOME packaging and porting
                   3353:
                   3354:     23.1. Meta packages
                   3355:     23.2. Packaging a GNOME application
                   3356:     23.3. Updating GNOME to a newer version
                   3357:     23.4. Patching guidelines
1.77      rillig   3358:
1.107     rillig   3359: Chapter 10. Creating a new pkgsrc package from scratch
1.77      rillig   3360:
1.91      rillig   3361: Table of Contents
                   3362:
1.107     rillig   3363: 10.1. Common types of packages
1.91      rillig   3364:
1.107     rillig   3365:     10.1.1. Perl modules
                   3366:     10.1.2. KDE applications
1.119     imil     3367:     10.1.3. Python modules and programs
1.91      rillig   3368:
1.107     rillig   3369: 10.2. Examples
1.91      rillig   3370:
1.107     rillig   3371:     10.2.1. How the www/nvu package came into pkgsrc
1.91      rillig   3372:
1.77      rillig   3373: When you find a package that is not yet in pkgsrc, you most likely have a URL
                   3374: from where you can download the source code. Starting with this URL, creating a
                   3375: package involves only a few steps.
                   3376:
                   3377:  1. First, install the packages pkgtools/url2pkg and pkgtools/pkglint.
                   3378:
                   3379:  2. Then, choose one of the top-level directories as the category in which you
                   3380:     want to place your package. You can also create a directory of your own
                   3381:     (maybe called local). In that category directory, create another directory
                   3382:     for your package and change into it.
                   3383:
                   3384:  3. Run the program url2pkg, which will ask you for a URL. Enter the URL of the
                   3385:     distribution file (in most cases a .tar.gz file) and watch how the basic
                   3386:     ingredients of your package are created automatically. The distribution
                   3387:     file is extracted automatically to fill in some details in the Makefile
                   3388:     that would otherwise have to be done manually.
                   3389:
                   3390:  4. Examine the extracted files to determine the dependencies of your package.
                   3391:     Ideally, this is mentioned in some README file, but things may differ. For
                   3392:     each of these dependencies, look where it exists in pkgsrc, and if there is
                   3393:     a file called buildlink3.mk in that directory, add a line to your package
                   3394:     Makefile which includes that file just before the last line. If the
1.134     spz      3395:     buildlink3.mk file does not exist, it must be created first. The
                   3396:     buildlink3.mk file makes sure that the package's include files and
                   3397:     libraries are provided.
                   3398:
                   3399:     If you just need binaries from a package, add a DEPENDS line to the
                   3400:     Makefile, which specifies the version of the dependency and where it can be
                   3401:     found in pkgsrc. This line should be placed in the third paragraph. If the
1.77      rillig   3402:     dependency is only needed for building the package, but not when using it,
                   3403:     use BUILD_DEPENDS instead of DEPENDS. Your package may then look like this:
                   3404:
1.101     rillig   3405:     [...]
1.77      rillig   3406:
1.101     rillig   3407:     BUILD_DEPENDS+= lua>=5.0:../../lang/lua
                   3408:     DEPENDS+=       screen-[0-9]*:../../misc/screen
                   3409:     DEPENDS+=       screen>=4.0:../../misc/screen
1.77      rillig   3410:
1.101     rillig   3411:     [...]
1.77      rillig   3412:
1.101     rillig   3413:     .include "../../category/package/buildlink3.mk"
                   3414:     .include "../../devel/glib2/buildlink3.mk"
                   3415:     .include "../../mk/bsd.pkg.mk"
1.77      rillig   3416:
                   3417:  5. Run pkglint to see what things still need to be done to make your package a
                   3418:     "good" one. If you don't know what pkglint's warnings want to tell you, try
                   3419:     pkglint --explain or pkglint -e, which outputs additional explanations.
1.25      rillig   3420:
1.91      rillig   3421:  6. In many cases the package is not yet ready to build. You can find
1.107     rillig   3422:     instructions for the most common cases in the next section, Section 10.1,
1.91      rillig   3423:     "Common types of packages". After you have followed the instructions over
                   3424:     there, you can hopefully continue here.
                   3425:
                   3426:  7. Run bmake clean to clean the working directory from the extracted files.
                   3427:     Besides these files, a lot of cache files and other system information has
                   3428:     been saved in the working directory, which may become wrong after you
                   3429:     edited the Makefile.
                   3430:
                   3431:  8. Now, run bmake to build the package. For the various things that can go
1.107     rillig   3432:     wrong in this phase, consult Chapter 19, Making your package work.
1.25      rillig   3433:
1.132     wiz      3434:  9. When the package builds fine, the next step is to install the package. Run
1.77      rillig   3435:     bmake install and hope that everything works.
1.25      rillig   3436:
1.91      rillig   3437: 10. Up to now, the file PLIST, which contains a list of the files that are
1.77      rillig   3438:     installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to
                   3439:     generate a probably correct list. Check the file using your preferred text
                   3440:     editor to see if the list of files looks plausible.
1.25      rillig   3441:
1.91      rillig   3442: 11. Run pkglint again to see if the generated PLIST contains garbage or not.
1.25      rillig   3443:
1.91      rillig   3444: 12. When you ran bmake install, the package has been registered in the database
1.77      rillig   3445:     of installed files, but with an empty list of files. To fix this, run bmake
                   3446:     deinstall and bmake install again. Now the package is registered with the
                   3447:     list of files from PLIST.
1.69      rillig   3448:
1.91      rillig   3449: 13. Run bmake package to create a binary package from the set of installed
1.77      rillig   3450:     files.
                   3451:
1.107     rillig   3452: 10.1. Common types of packages
1.91      rillig   3453:
1.107     rillig   3454: 10.1.1. Perl modules
1.91      rillig   3455:
                   3456: Simple Perl modules are handled automatically by url2pkg, including
                   3457: dependencies.
                   3458:
1.107     rillig   3459: 10.1.2. KDE applications
1.91      rillig   3460:
                   3461: KDE applications should always include meta-pkgs/kde3/kde3.mk, which contains
                   3462: numerous settings that are typical of KDE packages.
                   3463:
1.119     imil     3464: 10.1.3. Python modules and programs
                   3465:
                   3466: Python modules and programs packages are easily created using a set of
                   3467: predefined variables.
                   3468:
                   3469: Most Python packages use either "distutils" or easy-setup ("eggs"). If the
                   3470: software uses "distutils", set the PYDISTUTILSPKG variable to "yes" so pkgsrc
                   3471: will make use of this framework. "distutils" uses a script called setup.py, if
                   3472: the "distutils" driver is not called setup.py, set the PYSETUP variable to the
                   3473: name of the script.
                   3474:
                   3475: If the default Python versions are not supported by the software, set the
                   3476: PYTHON_VERSIONS_ACCEPTED variable to the Python versions the software is known
                   3477: to work with, from the most recent to the older one, e.g.
                   3478:
1.127     wiz      3479: PYTHON_VERSIONS_ACCEPTED=       25 24
1.119     imil     3480:
                   3481: If the packaged software is a Python module, include "../../lang/python/
1.132     wiz      3482: extension.mk". In this case, the package directory should be called "
                   3483: py-software" and PKGNAME should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.
1.119     imil     3484:
                   3485: DISTNAME=   foopymodule-1.2.10
                   3486: PKGNAME=    ${PYPKGPREFIX}-${DISTNAME}
                   3487:
                   3488: If it is an application, also include "../../lang/python/application.mk" before
                   3489: "extension.mk".
                   3490:
                   3491: If the packaged software, either it is an application or a module, is
                   3492: egg-aware, you only need to include "../../lang/python/egg.mk".
                   3493:
                   3494: In order to correctly set the path to the Python interpreter, use the
                   3495: REPLACE_PYTHON variable and set it to the list of files that must be corrected.
                   3496: For example :
                   3497:
                   3498: REPLACE_PYTHON=   ${WRKSRC}/*.py
                   3499:
1.107     rillig   3500: 10.2. Examples
1.91      rillig   3501:
1.107     rillig   3502: 10.2.1. How the www/nvu package came into pkgsrc
1.91      rillig   3503:
1.107     rillig   3504: 10.2.1.1. The initial package
1.91      rillig   3505:
                   3506: Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet
                   3507: been imported into pkgsrc. As the description says it has to do with the web,
                   3508: the obvious choice for the category is "www".
                   3509:
1.101     rillig   3510: $ mkdir www/nvu
                   3511: $ cd www/nvu
1.91      rillig   3512:
                   3513: The web site says that the sources are available as a tar file, so I fed that
                   3514: URL to the url2pkg program:
                   3515:
1.101     rillig   3516: $ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
1.91      rillig   3517:
                   3518: My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the
                   3519: package name should not have the word "sources" in it. I also filled in the
                   3520: MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like
                   3521: that:
                   3522:
1.101     rillig   3523: # $NetBSD$
                   3524: #
1.91      rillig   3525:
1.101     rillig   3526: DISTNAME=       nvu-1.0-sources
                   3527: PKGNAME=        nvu-1.0
                   3528: CATEGORIES=     www
                   3529: MASTER_SITES=   http://cvs.nvu.com/download/
                   3530: EXTRACT_SUFX=   .tar.bz2
                   3531:
                   3532: MAINTAINER=     rillig@NetBSD.org
                   3533: HOMEPAGE=       http://cvs.nvu.com/
                   3534: COMMENT=        Web Authoring System
1.91      rillig   3535:
1.101     rillig   3536: # url2pkg-marker (please do not remove this line.)
                   3537: .include "../../mk/bsd.pkg.mk"
1.91      rillig   3538:
                   3539: Then, I quit the editor and watched pkgsrc downloading a large source archive:
                   3540:
1.101     rillig   3541: url2pkg> Running "make makesum" ...
                   3542: => Required installed package digest>=20010302: digest-20060826 found
                   3543: => Fetching nvu-1.0-sources.tar.bz2
                   3544: Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
                   3545: 100% |*************************************| 28992 KB  150.77 KB/s00:00 ETA
                   3546: 29687976 bytes retrieved in 03:12 (150.77 KB/s)
                   3547: url2pkg> Running "make extract" ...
                   3548: => Required installed package digest>=20010302: digest-20060826 found
                   3549: => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
                   3550: => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
                   3551: work.bacc -> /tmp/roland/pkgsrc/www/nvu/work.bacc
                   3552: ===> Installing dependencies for nvu-1.0
                   3553: ===> Overriding tools for nvu-1.0
                   3554: ===> Extracting for nvu-1.0
                   3555: url2pkg> Adjusting the Makefile.
1.91      rillig   3556:
1.101     rillig   3557: Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done!
1.91      rillig   3558:
1.101     rillig   3559: Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)
1.91      rillig   3560:
1.107     rillig   3561: 10.2.1.2. Fixing all kinds of problems to make the package work
1.91      rillig   3562:
                   3563: Now that the package has been extracted, let's see what's inside it. The
                   3564: package has a README.txt, but that only says something about mozilla, so it's
                   3565: probably useless for seeing what dependencies this package has. But since there
                   3566: is a GNU configure script in the package, let's hope that it will complain
                   3567: about everything it needs.
                   3568:
1.101     rillig   3569: $ bmake
                   3570: => Required installed package digest>=20010302: digest-20060826 found
                   3571: => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
                   3572: => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
                   3573: ===> Patching for nvu-1.0
                   3574: ===> Creating toolchain wrappers for nvu-1.0
                   3575: ===> Configuring for nvu-1.0
                   3576: [...]
                   3577: configure: error: Perl 5.004 or higher is required.
                   3578: [...]
                   3579: WARNING: Please add USE_TOOLS+=perl to the package Makefile.
                   3580: [...]
1.91      rillig   3581:
                   3582: That worked quite well. So I opened the package Makefile in my editor, and
                   3583: since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
                   3584: dependencies of the package have changed now, and since a perl wrapper is
                   3585: automatically installed in the "tools" phase, I need to build the package from
                   3586: scratch.
                   3587:
1.101     rillig   3588: $ bmake clean
                   3589: ===> Cleaning for nvu-1.0
                   3590: $ bmake
                   3591: [...]
                   3592: *** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \
                   3593: GNU Make.  You will not be able to build Mozilla without GNU Make.
                   3594: [...]
1.91      rillig   3595:
                   3596: So I added "gmake" to the USE_TOOLS line and tried again (from scratch).
                   3597:
1.101     rillig   3598: [...]
                   3599: checking for GTK - version >= 1.2.0... no
                   3600: *** Could not run GTK test program, checking why...
                   3601: [...]
1.91      rillig   3602:
                   3603: Now to the other dependencies. The first question is: Where is the GTK package
                   3604: hidden in pkgsrc?
                   3605:
1.101     rillig   3606: $ echo ../../*/gtk*
                   3607: [many packages ...]
                   3608: $ echo ../../*/gtk
                   3609: ../../x11/gtk
                   3610: $ echo ../../*/gtk2
                   3611: ../../x11/gtk2
                   3612: $ echo ../../*/gtk2/bui*
                   3613: ../../x11/gtk2/buildlink3.mk
1.91      rillig   3614:
                   3615: The first try was definitely too broad. The second one had exactly one result,
                   3616: which is very good. But there is one pitfall with GNOME packages. Before GNOME
                   3617: 2 had been released, there were already many GNOME 1 packages in pkgsrc. To be
                   3618: able to continue to use these packages, the GNOME 2 packages were imported as
                   3619: separate packages, and their names usually have a "2" appended. So I checked
                   3620: whether this was the case here, and indeed it was.
                   3621:
                   3622: Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
                   3623: easy. I just inserted an .include line before the last line of the package
                   3624: Makefile, so that it now looks like this:
                   3625:
1.101     rillig   3626: [...]
                   3627: .include "../../x11/gtk2/buildlink3.mk"
                   3628: .include "../../mk/bsd.pkg.mk
1.91      rillig   3629:
                   3630: After another bmake clean && bmake, the answer was:
                   3631:
1.101     rillig   3632: [...]
                   3633: checking for gtk-config... /home/roland/pkg/bin/gtk-config
                   3634: checking for GTK - version >= 1.2.0... no
                   3635: *** Could not run GTK test program, checking why...
                   3636: *** The test program failed to compile or link. See the file config.log for the
                   3637: *** exact error that occured. This usually means GTK was incorrectly installed
                   3638: *** or that you have moved GTK since it was installed. In the latter case, you
                   3639: *** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config
                   3640: configure: error: Test for GTK failed.
                   3641: [...]
1.91      rillig   3642:
                   3643: In this particular case, the assumption that "every package prefers GNOME 2"
                   3644: had been wrong. The first of the lines above told me that this package really
                   3645: wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
                   3646: it would have looked for pkg-config instead of gtk-config. So I changed the x11
                   3647: /gtk2 to x11/gtk in the package Makefile, and tried again.
                   3648:
1.101     rillig   3649: [...]
                   3650: 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
                   3651: In file included from xpidl.c:42:
                   3652: xpidl.h:53:24: libIDL/IDL.h: No such file or directory
                   3653: In file included from xpidl.c:42:
                   3654: xpidl.h:132: error: parse error before "IDL_ns"
                   3655: [...]
1.91      rillig   3656:
                   3657: The package still does not find all of its dependencies. Now the question is:
                   3658: Which package provides the libIDL/IDL.h header file?
                   3659:
1.101     rillig   3660: $ echo ../../*/*idl*
                   3661: ../../devel/py-idle ../../wip/idled ../../x11/acidlaunch
                   3662: $ echo ../../*/*IDL*
                   3663: ../../net/libIDL
1.91      rillig   3664:
                   3665: Let's take the one from the second try. So I included the ../../net/libIDL/
                   3666: buildlink3.mk file and tried again. But the error didn't change. After digging
                   3667: through some of the code, I concluded that the build process of the package was
                   3668: broken and couldn't have ever worked, but since the Mozilla source tree is
                   3669: quite large, I didn't want to fix it. So I added the following to the package
                   3670: Makefile and tried again:
                   3671:
1.101     rillig   3672: CPPFLAGS+=              -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0
                   3673: BUILDLINK_TRANSFORM+=   -l:IDL:IDL-2
1.91      rillig   3674:
                   3675: The latter line is needed because the package expects the library libIDL.so,
                   3676: but only libIDL-2.so is available. So I told the compiler wrapper to rewrite
                   3677: that on the fly.
                   3678:
                   3679: The next problem was related to a recent change of the FreeType interface. I
                   3680: looked up in www/seamonkey which patch files were relevant for this issue and
                   3681: copied them to the patches directory. Then I retried, fixed the patches so that
                   3682: they applied cleanly and retried again. This time, everything worked.
                   3683:
1.107     rillig   3684: 10.2.1.3. Installing the package
1.91      rillig   3685:
1.101     rillig   3686: $ bmake CHECK_FILES=no install
                   3687: [...]
                   3688: $ bmake print-PLIST >PLIST
                   3689: $ bmake deinstall
                   3690: $ bmake install
1.91      rillig   3691:
1.107     rillig   3692: Chapter 11. Package components - files, directories and contents
1.1       grant    3693:
                   3694: Table of Contents
                   3695:
1.107     rillig   3696: 11.1. Makefile
                   3697: 11.2. distinfo
                   3698: 11.3. patches/*
                   3699:
                   3700:     11.3.1. Structure of a single patch file
                   3701:     11.3.2. Creating patch files
                   3702:     11.3.3. Sources where the patch files come from
                   3703:     11.3.4. Patching guidelines
                   3704:     11.3.5. Feedback to the author
                   3705:
                   3706: 11.4. Other mandatory files
                   3707: 11.5. Optional files
                   3708:
                   3709:     11.5.1. Files affecting the binary package
                   3710:     11.5.2. Files affecting the build process
                   3711:     11.5.3. Files affecting nothing at all
1.78      rillig   3712:
1.107     rillig   3713: 11.6. work*
                   3714: 11.7. files/*
1.1       grant    3715:
                   3716: Whenever you're preparing a package, there are a number of files involved which
                   3717: are described in the following sections.
                   3718:
1.107     rillig   3719: 11.1. Makefile
1.1       grant    3720:
                   3721: Building, installation and creation of a binary package are all controlled by
1.23      wiz      3722: the package's Makefile. The Makefile describes various things about a package,
                   3723: for example from where to get it, how to configure, build, and install it.
                   3724:
                   3725: A package Makefile contains several sections that describe the package.
                   3726:
                   3727: In the first section there are the following variables, which should appear
1.87      wiz      3728: exactly in the order given here. The order and grouping of the variables is
1.81      rillig   3729: mostly historical and has no further meaning.
1.23      wiz      3730:
                   3731:   * DISTNAME is the basename of the distribution file to be downloaded from the
                   3732:     package's website.
                   3733:
                   3734:   * PKGNAME is the name of the package, as used by pkgsrc. You only need to
1.87      wiz      3735:     provide it if DISTNAME (which is the default) is not a good name for the
                   3736:     package in pkgsrc. Usually it is the pkgsrc directory name together with
                   3737:     the version number. It must match the regular expression ^[A-Za-z0-9]
                   3738:     [A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains
                   3739:     only letters, digits, dashes, underscores, dots and plus signs.
                   3740:
                   3741:   * SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't
                   3742:     unique on a SVR4 system. The default is PKGNAME, which may be shortened
                   3743:     when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not
                   3744:     produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME
                   3745:     is limited to 5 characters.
1.23      wiz      3746:
                   3747:   * CATEGORIES is a list of categories which the package fits in. You can
                   3748:     choose any of the top-level directories of pkgsrc for it.
                   3749:
1.45      wiz      3750:     Currently the following values are available for CATEGORIES. If more than
                   3751:     one is used, they need to be separated by spaces:
                   3752:
1.101     rillig   3753:     archivers     cross         geography     meta-pkgs     security
                   3754:     audio         databases     graphics      misc          shells
                   3755:     benchmarks    devel         ham           multimedia    sysutils
                   3756:     biology       editors       inputmethod   net           textproc
                   3757:     cad           emulators     lang          news          time
                   3758:     chat          finance       mail          parallel      wm
                   3759:     comms         fonts         math          pkgtools      www
                   3760:     converters    games         mbone         print         x11
1.45      wiz      3761:
1.81      rillig   3762:   * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
1.107     rillig   3763:     are discussed in detail in Section 17.5, "The fetch phase".
1.45      wiz      3764:
                   3765: The second section contains information about separately downloaded patches, if
                   3766: any.
                   3767:
1.47      reed     3768:   * PATCHFILES: Name(s) of additional files that contain distribution patches.
1.45      wiz      3769:     There is no default. pkgsrc will look for them at PATCH_SITES. They will
                   3770:     automatically be uncompressed before patching if the names end with .gz or
                   3771:     .Z.
                   3772:
                   3773:   * PATCH_SITES: Primary location(s) for distribution patch files (see
                   3774:     PATCHFILES below) if not found locally.
                   3775:
                   3776: The third section contains the following variables.
                   3777:
1.50      rillig   3778:   * MAINTAINER is the email address of the person who feels responsible for
                   3779:     this package, and who is most likely to look at problems or questions
                   3780:     regarding this package which have been reported with send-pr(1). Other
1.115     jmcneill 3781:     developers may contact the MAINTAINER before making changes to the package,
                   3782:     but are not required to do so. When packaging a new program, set MAINTAINER
                   3783:     to yourself. If you really can't maintain the package for future updates,
                   3784:     set it to <pkgsrc-users@NetBSD.org>.
                   3785:
                   3786:   * OWNER should be used instead of MAINTAINER when you do not want other
                   3787:     developers to update or change the package without contacting you first. A
                   3788:     package Makefile should contain one of MAINTAINER or OWNER, but not both.
1.23      wiz      3789:
                   3790:   * HOMEPAGE is a URL where users can find more information about the package.
1.1       grant    3791:
1.45      wiz      3792:   * COMMENT is a one-line description of the package (should not include the
                   3793:     package name).
1.1       grant    3794:
1.45      wiz      3795: Other variables that affect the build:
1.1       grant    3796:
1.50      rillig   3797:   * WRKSRC: The directory where the interesting distribution files of the
                   3798:     package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
                   3799:     most packages.
                   3800:
                   3801:     If a package doesn't create a subdirectory for itself (most GNU software
                   3802:     does, for instance), but extracts itself in the current directory, you
1.87      wiz      3803:     should set WRKSRC=${WRKDIR}.
1.50      rillig   3804:
                   3805:     If a package doesn't create a subdirectory with the name of DISTNAME but
                   3806:     some different name, set WRKSRC to point to the proper name in ${WRKDIR},
1.87      wiz      3807:     for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
1.50      rillig   3808:     other examples.
                   3809:
                   3810:     The name of the working directory created by pkgsrc is taken from the
                   3811:     WRKDIR_BASENAME variable. By default, its value is work. If you want to use
                   3812:     the same pkgsrc tree for building different kinds of binary packages, you
                   3813:     can change the variable according to your needs. Two other variables handle
                   3814:     common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
1.105     rillig   3815:     defined in mk.conf, the first component of the host's name is attached to
                   3816:     the directory name. If OBJMACHINE is defined, the platform name is
1.50      rillig   3817:     attached, which might look like work.i386 or work.sparc.
1.1       grant    3818:
                   3819: Please pay attention to the following gotchas:
                   3820:
1.47      reed     3821:   * Add MANCOMPRESSED if man pages are installed in compressed form by the
1.88      wiz      3822:     package. For packages using BSD-style makefiles which honor MANZ, there is
                   3823:     MANCOMPRESSED_IF_MANZ.
1.20      ben      3824:
1.1       grant    3825:   * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
1.20      ben      3826:
1.107     rillig   3827:   * If the package installs any info files, see Section 19.6.7, "Packages
1.1       grant    3828:     installing info files".
1.20      ben      3829:
1.107     rillig   3830: 11.2. distinfo
1.1       grant    3831:
1.50      rillig   3832: The distinfo file contains the message digest, or checksum, of each distfile
                   3833: needed for the package. This ensures that the distfiles retrieved from the
                   3834: Internet have not been corrupted during transfer or altered by a malign force
                   3835: to introduce a security hole. Due to recent rumor about weaknesses of digest
                   3836: algorithms, all distfiles are protected using both SHA1 and RMD160 message
                   3837: digests, as well as the file size.
1.1       grant    3838:
1.50      rillig   3839: The distinfo file also contains the checksums for all the patches found in the
1.107     rillig   3840: patches directory (see Section 11.3, "patches/*").
1.50      rillig   3841:
                   3842: To regenerate the distinfo file, use the make makedistinfo or make mdi command.
                   3843:
                   3844: Some packages have different sets of distfiles depending on the platform, for
1.130     wiz      3845: example lang/openjdk7. These are kept in the same distinfo file and care should
                   3846: be taken when upgrading such a package to ensure distfile information is not
                   3847: lost.
1.1       grant    3848:
1.107     rillig   3849: 11.3. patches/*
1.1       grant    3850:
1.93      rillig   3851: Many packages still don't work out-of-the box on the various platforms that are
                   3852: supported by pkgsrc. Therefore, a number of custom patch files are needed to
                   3853: make the package work. These patch files are found in the patches/ directory.
                   3854:
                   3855: In the patch phase, these patches are applied to the files in WRKSRC directory
1.132     wiz      3856: after extracting them, in alphabetic order.
1.93      rillig   3857:
1.107     rillig   3858: 11.3.1. Structure of a single patch file
1.1       grant    3859:
                   3860: The patch-* files should be in diff -bu format, and apply without a fuzz to
                   3861: avoid problems. (To force patches to apply with fuzz you can set
1.94      dmcmahil 3862: PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
1.93      rillig   3863: a single file, and no file should be patched by more than one patch file. This
                   3864: helps to keep future modifications simple.
                   3865:
                   3866: Each patch file is structured as follows: In the first line, there is the RCS
                   3867: Id of the patch itself. The second line should be empty for aesthetic reasons.
                   3868: After that, there should be a comment for each change that the patch does.
                   3869: There are a number of standard cases:
                   3870:
                   3871:   * Patches for commonly known vulnerabilities should mention the vulnerability
                   3872:     ID (CAN, CVE).
                   3873:
                   3874:   * Patches that change source code should mention the platform and other
                   3875:     environment (for example, the compiler) that the patch is needed for.
                   3876:
1.132     wiz      3877: In all, the patch should be commented so that any developer who knows the code
                   3878: of the application can make some use of the patch. Special care should be taken
                   3879: for the upstream developers, since we generally want that they accept our
                   3880: patches, so we have less work in the future.
1.93      rillig   3881:
1.107     rillig   3882: 11.3.2. Creating patch files
1.1       grant    3883:
                   3884: One important thing to mention is to pay attention that no RCS IDs get stored
                   3885: in the patch files, as these will cause problems when later checked into the
1.93      rillig   3886: NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
                   3887: avoid these problems.
1.1       grant    3888:
                   3889: For even more automation, we recommend using mkpatches from the same package to
                   3890: make a whole set of patches. You just have to backup files before you edit them
1.132     wiz      3891: to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using
1.1       grant    3892: pkgvi again from the same package. If you upgrade a package this way, you can
1.132     wiz      3893: easily compare the new set of patches with the previously existing one with
                   3894: patchdiff. The files in patches are replaced by new files, so carefully check
                   3895: if you want to take all the changes.
1.1       grant    3896:
                   3897: When you have finished a package, remember to generate the checksums for the
1.107     rillig   3898: patch files by using the make makepatchsum command, see Section 11.2,
1.90      rillig   3899: "distinfo".
1.1       grant    3900:
1.87      wiz      3901: When adding a patch that corrects a problem in the distfile (rather than e.g.
                   3902: enforcing pkgsrc's view of where man pages should go), send the patch as a bug
                   3903: report to the maintainer. This benefits non-pkgsrc users of the package, and
                   3904: usually makes it possible to remove the patch in future version.
                   3905:
1.132     wiz      3906: The file names of the patch files are usually of the form patch-
                   3907: path_to_file__with__underscores.c. Many packages still use the previous
                   3908: convention patch-[a-z][a-z], but new patches should be of the form containing
                   3909: the filename. mkpatches included in pkgtools/pkgdiff takes care of the name
                   3910: automatically.
1.102     rillig   3911:
1.107     rillig   3912: 11.3.3. Sources where the patch files come from
1.93      rillig   3913:
1.87      wiz      3914: If you want to share patches between multiple packages in pkgsrc, e.g. because
                   3915: they use the same distfiles, set PATCHDIR to the path where the patch files can
                   3916: be found, e.g.:
                   3917:
1.101     rillig   3918: PATCHDIR= ${.CURDIR}/../xemacs/patches
1.87      wiz      3919:
1.1       grant    3920: Patch files that are distributed by the author or other maintainers can be
1.87      wiz      3921: listed in PATCHFILES.
1.1       grant    3922:
                   3923: If it is desired to store any patches that should not be committed into pkgsrc,
                   3924: they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
                   3925: directory tree there is expected to have the same "category/package" structure
                   3926: as pkgsrc, and patches are expected to be stored inside these dirs (also known
1.47      reed     3927: as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
                   3928: for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
                   3929: files in the named directory are expected to be patch files, and they are
                   3930: applied after pkgsrc patches are applied.
1.1       grant    3931:
1.107     rillig   3932: 11.3.4. Patching guidelines
1.85      jmmv     3933:
                   3934: When fixing a portability issue in the code do not use preprocessor magic to
                   3935: check for the current operating system nor platform. Doing so hurts portability
                   3936: to other platforms because the OS-specific details are not abstracted
                   3937: appropriately.
                   3938:
                   3939: The general rule to follow is: instead of checking for the operating system the
                   3940: application is being built on, check for the specific features you need. For
                   3941: example, instead of assuming that kqueue is available under NetBSD and using
                   3942: the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
                   3943: kqueue itself ? yes, this generally involves patching the configure script.
                   3944: There is absolutely nothing that prevents some OSes from adopting interfaces
                   3945: from other OSes (e.g. Linux implementing kqueue), something that the above
                   3946: checks cannot take into account.
                   3947:
                   3948: Of course, checking for features generally involves more work on the
1.87      wiz      3949: developer's side, but the resulting changes are cleaner and there are chances
1.85      jmmv     3950: they will work on many other platforms. Not to mention that there are higher
                   3951: chances of being later integrated into the mainstream sources. Remember: It
                   3952: doesn't work unless it is right!
                   3953:
                   3954: Some typical examples:
                   3955:
1.107     rillig   3956: Table 11.1. Patching examples
1.85      jmmv     3957:
1.101     rillig   3958: +-------------------------------------------------------------------------------------------+
                   3959: |  Where  |        Incorrect         |                       Correct                        |
                   3960: |---------+--------------------------+------------------------------------------------------|
                   3961: |         |case ${target_os} in      |                                                      |
                   3962: |configure|netbsd*) have_kvm=yes ;;  |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)|
                   3963: |script   |*)       have_kvm=no  ;;  |                                                      |
                   3964: |         |esac                      |                                                      |
                   3965: |---------+--------------------------+------------------------------------------------------|
1.102     rillig   3966: |C source |#if defined(__NetBSD__)   |#if defined(HAVE_SYS_EVENT_H)                         |
                   3967: |file     |#  include <sys/event.h>  |#  include <sys/event.h>                              |
                   3968: |         |#endif                    |#endif                                                |
1.101     rillig   3969: |---------+--------------------------+------------------------------------------------------|
                   3970: |         |int                       |int                                                   |
                   3971: |         |monitor_file(...)         |monitor_file(...)                                     |
                   3972: |         |{                         |{                                                     |
                   3973: |         |#if defined(__NetBSD__)   |#if defined(HAVE_KQUEUE)                              |
                   3974: |C source |        int fd = kqueue();|        int fd = kqueue();                            |
                   3975: |file     |        ...               |        ...                                           |
                   3976: |         |#else                     |#else                                                 |
                   3977: |         |        ...               |        ...                                           |
                   3978: |         |#endif                    |#endif                                                |
                   3979: |         |}                         |}                                                     |
                   3980: +-------------------------------------------------------------------------------------------+
1.85      jmmv     3981:
1.91      rillig   3982:
1.85      jmmv     3983: For more information, please read the Making packager-friendly software article
                   3984: (part 1, part 2). It summarizes multiple details on how to make software easier
                   3985: to package; all the suggestions in it were collected from our experience in
                   3986: pkgsrc work, so they are possibly helpful when creating patches too.
                   3987:
1.107     rillig   3988: 11.3.5. Feedback to the author
1.85      jmmv     3989:
                   3990: Always, always, always feed back any portability fixes or improvements you do
                   3991: to a package to the mainstream developers. This is the only way to get their
                   3992: attention on portability issues and to ensure that future versions can be built
                   3993: out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will
                   3994: get the fixes straight from the packaged code.
                   3995:
1.93      rillig   3996: This generally involves cleaning up the patches (because sometimes the patches
                   3997: that are added to pkgsrc are quick hacks), filling bug reports in the
                   3998: appropriate trackers for the projects and working with the mainstream authors
                   3999: to accept your changes. It is extremely important that you do it so that the
                   4000: packages in pkgsrc are kept simple and thus further changes can be done without
                   4001: much hassle.
1.85      jmmv     4002:
1.132     wiz      4003: When you have done this, please add a URL to the upstream bug report to the
                   4004: patch comment.
                   4005:
1.85      jmmv     4006: Support the idea of free software!
                   4007:
1.107     rillig   4008: 11.4. Other mandatory files
1.1       grant    4009:
                   4010: DESCR
1.20      ben      4011:
1.1       grant    4012:     A multi-line description of the piece of software. This should include any
                   4013:     credits where they are due. Please bear in mind that others do not share
                   4014:     your sense of humour (or spelling idiosyncrasies), and that others will
                   4015:     read everything that you write here.
1.20      ben      4016:
1.1       grant    4017: PLIST
1.20      ben      4018:
1.1       grant    4019:     This file governs the files that are installed on your system: all the
                   4020:     binaries, manual pages, etc. There are other directives which may be
                   4021:     entered in this file, to control the creation and deletion of directories,
1.107     rillig   4022:     and the location of inserted files. See Chapter 13, PLIST issues for more
1.1       grant    4023:     information.
1.20      ben      4024:
1.107     rillig   4025: 11.5. Optional files
1.1       grant    4026:
1.107     rillig   4027: 11.5.1. Files affecting the binary package
1.78      rillig   4028:
1.1       grant    4029: INSTALL
1.20      ben      4030:
1.1       grant    4031:     This shell script is invoked twice by pkg_add(1). First time after package
                   4032:     extraction and before files are moved in place, the second time after the
                   4033:     files to install are moved in place. This can be used to do any custom
1.20      ben      4034:     procedures not possible with @exec commands in PLIST. See pkg_add(1) and
1.107     rillig   4035:     pkg_create(1) for more information. See also Section 15.1, "Files and
1.87      wiz      4036:     directories outside the installation prefix".
1.20      ben      4037:
1.1       grant    4038: DEINSTALL
1.20      ben      4039:
1.1       grant    4040:     This script is executed before and after any files are removed. It is this
                   4041:     script's responsibility to clean up any additional messy details around the
                   4042:     package's installation, since all pkg_delete knows is how to delete the
1.20      ben      4043:     files created in the original distribution. See pkg_delete(1) and
1.1       grant    4044:     pkg_create(1) for more information.
1.20      ben      4045:
1.1       grant    4046: MESSAGE
1.20      ben      4047:
1.50      rillig   4048:     This file is displayed after installation of the package. Useful for things
                   4049:     like legal notices on almost-free software and hints for updating config
                   4050:     files after installing modules for apache, PHP etc. Please note that you
                   4051:     can modify variables in it easily by using MESSAGE_SUBST in the package's
1.1       grant    4052:     Makefile:
1.20      ben      4053:
1.101     rillig   4054:     MESSAGE_SUBST+=  SOMEVAR="somevalue"
1.20      ben      4055:
1.87      wiz      4056:     replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
                   4057:     is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE,
1.118     jnemeth  4058:     PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.
1.87      wiz      4059:
                   4060:     You can display a different or additional files by setting the MESSAGE_SRC
                   4061:     variable. Its default is MESSAGE, if the file exists.
1.20      ben      4062:
1.78      rillig   4063: ALTERNATIVES
                   4064:
                   4065:     FIXME: There is no documentation on the alternatives framework.
                   4066:
1.107     rillig   4067: 11.5.2. Files affecting the build process
1.78      rillig   4068:
                   4069: Makefile.common
                   4070:
                   4071:     This file contains arbitrary things that could also go into a Makefile, but
                   4072:     its purpose is to be used by more than one package. This file should only
                   4073:     be used when the packages that will use the file are known in advance. For
                   4074:     other purposes it is often better to write a *.mk file and give it a good
                   4075:     name that describes what it does.
                   4076:
                   4077: buildlink3.mk
                   4078:
                   4079:     This file contains the dependency information for the buildlink3 framework
1.107     rillig   4080:     (see Chapter 14, Buildlink methodology).
1.78      rillig   4081:
                   4082: hacks.mk
                   4083:
                   4084:     This file contains workarounds for compiler bugs and similar things. It is
                   4085:     included automatically by the pkgsrc infrastructure, so you don't need an
                   4086:     extra .include line for it.
                   4087:
                   4088: options.mk
                   4089:
                   4090:     This file contains the code for the package-specific options (see
1.107     rillig   4091:     Chapter 16, Options handling) that can be selected by the user. If a
1.78      rillig   4092:     package has only one or two options, it is equally acceptable to put the
                   4093:     code directly into the Makefile.
                   4094:
1.107     rillig   4095: 11.5.3. Files affecting nothing at all
1.78      rillig   4096:
                   4097: README*
                   4098:
                   4099:     These files do not take place in the creation of a package and thus are
                   4100:     purely informative to the package developer.
                   4101:
                   4102: TODO
                   4103:
                   4104:     This file contains things that need to be done to make the package even
                   4105:     better.
                   4106:
1.107     rillig   4107: 11.6. work*
1.1       grant    4108:
1.47      reed     4109: When you type make, the distribution files are unpacked into the directory
1.45      wiz      4110: denoted by WRKDIR. It can be removed by running make clean. Besides the
                   4111: sources, this directory is also used to keep various timestamp files. The
                   4112: directory gets removed completely on clean. The default is ${.CURDIR}/work or $
                   4113: {.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
1.1       grant    4114:
1.107     rillig   4115: 11.7. files/*
1.1       grant    4116:
                   4117: If you have any files that you wish to be placed in the package prior to
1.87      wiz      4118: configuration or building, you could place these files here and use a ${CP}
1.1       grant    4119: command in the "pre-configure" target to achieve this. Alternatively, you could
                   4120: simply diff the file against /dev/null and use the patch mechanism to manage
                   4121: the creation of this file.
                   4122:
1.87      wiz      4123: If you want to share files in this way with other packages, set the FILESDIR
                   4124: variable to point to the other package's files directory, e.g.:
                   4125:
1.101     rillig   4126: FILESDIR=${.CURDIR}/../xemacs/files
1.87      wiz      4127:
1.107     rillig   4128: Chapter 12. Programming in Makefiles
1.27      rillig   4129:
                   4130: Table of Contents
                   4131:
1.107     rillig   4132: 12.1. Caveats
                   4133: 12.2. Makefile variables
1.27      rillig   4134:
1.107     rillig   4135:     12.2.1. Naming conventions
1.27      rillig   4136:
1.107     rillig   4137: 12.3. Code snippets
1.27      rillig   4138:
1.107     rillig   4139:     12.3.1. Adding things to a list
                   4140:     12.3.2. Converting an internal list into an external list
                   4141:     12.3.3. Passing variables to a shell command
                   4142:     12.3.4. Quoting guideline
                   4143:     12.3.5. Workaround for a bug in BSD Make
1.27      rillig   4144:
                   4145: Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
                   4146: part of the pkgsrc system. Using the make(1) system as a programming language
                   4147: for a big system like pkgsrc requires some discipline to keep the code correct
                   4148: and understandable.
                   4149:
                   4150: The basic ingredients for Makefile programming are variables (which are
                   4151: actually macros) and shell commands. Among these shell commands may even be
                   4152: more complex ones like awk(1) programs. To make sure that every shell command
                   4153: runs as intended it is necessary to quote all variables correctly when they are
                   4154: used.
                   4155:
                   4156: This chapter describes some patterns, that appear quite often in Makefiles,
                   4157: including the pitfalls that come along with them.
                   4158:
1.107     rillig   4159: 12.1. Caveats
1.98      rillig   4160:
                   4161:   * When you are creating a file as a target of a rule, always write the data
                   4162:     to a temporary file first and finally rename that file. Otherwise there
                   4163:     might occur an error in the middle of generating the file, and when the
                   4164:     user runs make(1) for the second time, the file exists and will not be
                   4165:     regenerated properly. Example:
                   4166:
1.101     rillig   4167:     wrong:
                   4168:             @echo "line 1" > ${.TARGET}
                   4169:             @echo "line 2" >> ${.TARGET}
                   4170:             @false
                   4171:
                   4172:     correct:
                   4173:             @echo "line 1" > ${.TARGET}.tmp
                   4174:             @echo "line 2" >> ${.TARGET}.tmp
                   4175:             @false
                   4176:             @mv ${.TARGET}.tmp ${.TARGET}
1.98      rillig   4177:
                   4178:     When you run make wrong twice, the file wrong will exist, although there
                   4179:     was an error message in the first run. On the other hand, running make
                   4180:     correct gives an error message twice, as expected.
                   4181:
                   4182:     You might remember that make(1) sometimes removes ${.TARGET} in case of
                   4183:     error, but this only happens when it is interrupted, for example by
                   4184:     pressing ^C. This does not happen when one of the commands fails (like
                   4185:     false(1) above).
                   4186:
1.107     rillig   4187: 12.2. Makefile variables
1.27      rillig   4188:
                   4189: Makefile variables contain strings that can be processed using the five
                   4190: operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
                   4191: make(1) man page.
                   4192:
                   4193: When a variable's value is parsed from a Makefile, the hash character ``#'' and
                   4194: the backslash character ``\'' are handled specially. If a backslash is followed
                   4195: by a newline, any whitespace immediately in front of the backslash, the
                   4196: backslash, the newline, and any whitespace immediately behind the newline are
1.74      rillig   4197: replaced with a single space. A backslash character and an immediately
1.47      reed     4198: following hash character are replaced with a single hash character. Otherwise,
1.27      rillig   4199: the backslash is passed as is. In a variable assignment, any hash character
                   4200: that is not preceded by a backslash starts a comment that continues upto the
                   4201: end of the logical line.
                   4202:
                   4203: Note: Because of this parsing algorithm the only way to create a variable
                   4204: consisting of a single backslash is using the ``!='' operator, for example:
                   4205: BACKSLASH!=echo "\\".
                   4206:
                   4207: So far for defining variables. The other thing you can do with variables is
                   4208: evaluating them. A variable is evaluated when it is part of the right side of
                   4209: the ``:='' or the ``!='' operator, or directly before executing a shell command
1.47      reed     4210: which the variable is part of. In all other cases, make(1) performs lazy
1.27      rillig   4211: evaluation, that is, variables are not evaluated until there's no other way.
                   4212: The ``modifiers'' mentioned in the man page also evaluate the variable.
                   4213:
                   4214: Some of the modifiers split the string into words and then operate on the
1.47      reed     4215: words, others operate on the string as a whole. When a string is split into
                   4216: words, it is split as you would expect it from sh(1).
1.27      rillig   4217:
                   4218: No rule without exception?the .for loop does not follow the shell quoting rules
                   4219: but splits at sequences of whitespace.
                   4220:
                   4221: There are several types of variables that should be handled differently.
                   4222: Strings and two types of lists.
                   4223:
1.47      reed     4224:   * Strings can contain arbitrary characters. Nevertheless, you should restrict
1.27      rillig   4225:     yourself to only using printable characters. Examples are PREFIX and
                   4226:     COMMENT.
                   4227:
                   4228:   * Internal lists are lists that are never exported to any shell command.
1.47      reed     4229:     Their elements are separated by whitespace. Therefore, the elements
1.27      rillig   4230:     themselves cannot have embedded whitespace. Any other characters are
                   4231:     allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
                   4232:     BUILD_DEPENDS.
                   4233:
                   4234:   * External lists are lists that may be exported to a shell command. Their
                   4235:     elements can contain any characters, including whitespace. That's why they
                   4236:     cannot be used in .for loops. Examples are DISTFILES and MASTER_SITES.
                   4237:
1.107     rillig   4238: 12.2.1. Naming conventions
1.27      rillig   4239:
                   4240:   * All variable names starting with an underscore are reserved for use by the
                   4241:     pkgsrc infrastructure. They shall not be used by package Makefiles.
                   4242:
                   4243:   * In .for loops you should use lowercase variable names for the iteration
                   4244:     variables.
                   4245:
                   4246:   * All list variables should have a ``plural'' name, e.g. PKG_OPTIONS or
                   4247:     DISTFILES.
                   4248:
1.107     rillig   4249: 12.3. Code snippets
1.27      rillig   4250:
                   4251: This section presents you with some code snippets you should use in your own
                   4252: code. If you don't find anything appropriate here, you should test your code
                   4253: and add it here.
                   4254:
1.107     rillig   4255: 12.3.1. Adding things to a list
1.27      rillig   4256:
1.101     rillig   4257: STRING=                 foo * bar `date`
                   4258: INT_LIST=               # empty
                   4259: ANOTHER_INT_LIST=       apache-[0-9]*:../../www/apache
                   4260: EXT_LIST=               # empty
                   4261: ANOTHER_EXT_LIST=       a=b c=d
                   4262:
                   4263: INT_LIST+=              ${STRING}               # 1
                   4264: INT_LIST+=              ${ANOTHER_INT_LIST}     # 2
                   4265: EXT_LIST+=              ${STRING:Q}             # 3
                   4266: EXT_LIST+=              ${ANOTHER_EXT_LIST}     # 4
1.27      rillig   4267:
                   4268: When you add a string to an external list (example 3), it must be quoted. In
                   4269: all other cases, you must not add a quoting level. You must not merge internal
                   4270: and external lists, unless you are sure that all entries are correctly
                   4271: interpreted in both lists.
                   4272:
1.107     rillig   4273: 12.3.2. Converting an internal list into an external list
1.27      rillig   4274:
1.101     rillig   4275: EXT_LIST=       # empty
                   4276: .for i in ${INT_LIST}
                   4277: EXT_LIST+=      ${i:Q}""
                   4278: .endfor
1.27      rillig   4279:
                   4280: This code converts the internal list INT_LIST into the external list EXT_LIST.
                   4281: As the elements of an internal list are unquoted they must be quoted here. The
                   4282: reason for appending "" is explained below.
                   4283:
1.107     rillig   4284: 12.3.3. Passing variables to a shell command
1.27      rillig   4285:
1.79      rillig   4286: Sometimes you may want to print an arbitrary string. There are many ways to get
                   4287: it wrong and only few that can handle every nastiness.
                   4288:
1.101     rillig   4289: STRING=         foo bar <    > * `date` $$HOME ' "
                   4290: EXT_LIST=       string=${STRING:Q} x=second\ item
1.27      rillig   4291:
1.101     rillig   4292: all:
                   4293:         echo ${STRING}                  # 1
                   4294:         echo "${STRING}"                # 2
                   4295:         echo "${STRING:Q}"              # 3
                   4296:         echo ${STRING:Q}                # 4
                   4297:         echo x${STRING:Q} | sed 1s,.,,  # 5
                   4298:         printf "%s\\n" ${STRING:Q}""    # 6
                   4299:         env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
1.27      rillig   4300:
                   4301: Example 1 leads to a syntax error in the shell, as the characters are just
                   4302: copied.
                   4303:
                   4304: Example 2 leads to a syntax error too, and if you leave out the last "
                   4305: character from ${STRING}, date(1) will be executed. The $HOME shell variable
                   4306: would be evaluated, too.
                   4307:
                   4308: Example 3 outputs each space character preceded by a backslash (or not),
                   4309: depending on the implementation of the echo(1) command.
                   4310:
                   4311: Example 4 handles correctly every string that does not start with a dash. In
                   4312: that case, the result depends on the implementation of the echo(1) command. As
1.47      reed     4313: long as you can guarantee that your input does not start with a dash, this form
1.27      rillig   4314: is appropriate.
                   4315:
                   4316: Example 5 handles even the case of a leading dash correctly.
                   4317:
1.79      rillig   4318: Example 6 also works with every string and is the light-weight solution, since
                   4319: it does not involve a pipe, which has its own problems.
                   4320:
1.47      reed     4321: The EXT_LIST does not need to be quoted because the quoting has already been
                   4322: done when adding elements to the list.
1.27      rillig   4323:
                   4324: As internal lists shall not be passed to the shell, there is no example for it.
                   4325:
1.107     rillig   4326: 12.3.4. Quoting guideline
1.27      rillig   4327:
                   4328: There are many possible sources of wrongly quoted variables. This section lists
                   4329: some of the commonly known ones.
                   4330:
                   4331:   * Whenever you use the value of a list, think about what happens to leading
1.47      reed     4332:     or trailing whitespace. If the list is a well-formed shell expression, you
1.27      rillig   4333:     can apply the :M* modifier to strip leading and trailing whitespace from
                   4334:     each word. The :M operator first splits its argument according to the rules
                   4335:     of the shell, and then creates a new list consisting of all words that
                   4336:     match the shell glob expression *, that is: all. One class of situations
                   4337:     where this is needed is when adding a variable like CPPFLAGS to
1.47      reed     4338:     CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
1.27      rillig   4339:     strips the leading and trailing whitespace from the variable and then
                   4340:     passes it to the other configure scripts. But these configure scripts
                   4341:     expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
                   4342:     That's why we better pass the CPPFLAGS value properly trimmed. And here is
                   4343:     how we do it:
                   4344:
1.101     rillig   4345:     CPPFLAGS=               # empty
                   4346:     CPPFLAGS+=              -Wundef -DPREFIX=\"${PREFIX:Q}\"
                   4347:     CPPFLAGS+=              ${MY_CPPFLAGS}
                   4348:
                   4349:     CONFIGURE_ARGS+=        CPPFLAGS=${CPPFLAGS:M*:Q}
                   4350:
                   4351:     all:
                   4352:             echo x${CPPFLAGS:Q}x            # leading and trailing whitespace
                   4353:             echo x${CONFIGURE_ARGS}x        # properly trimmed
1.27      rillig   4354:
                   4355:   * The example above contains one bug: The ${PREFIX} is a properly quoted
                   4356:     shell expression, but there is the C compiler after it, which also expects
                   4357:     a properly quoted string (this time in C syntax). The version above is
                   4358:     therefore only correct if ${PREFIX} does not have embedded backslashes or
                   4359:     double quotes. If you want to allow these, you have to add another layer of
                   4360:     quoting to each variable that is used as a C string literal. You cannot use
                   4361:     the :Q operator for it, as this operator only works for the shell.
                   4362:
1.47      reed     4363:   * Whenever a variable can be empty, the :Q operator can have surprising
1.27      rillig   4364:     results. Here are two completely different cases which can be solved with
                   4365:     the same trick.
                   4366:
1.101     rillig   4367:     EMPTY=                  # empty
                   4368:     empty_test:
                   4369:             for i in a ${EMPTY:Q} c; do \
                   4370:                 echo "$$i"; \
                   4371:             done
                   4372:
                   4373:     for_test:
                   4374:     .for i in a:\ a:\test.txt
                   4375:             echo ${i:Q}
                   4376:             echo "foo"
                   4377:     .endfor
1.27      rillig   4378:
                   4379:     The first example will only print two of the three lines we might have
                   4380:     expected. This is because ${EMPTY:Q} expands to the empty string, which the
                   4381:     shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
                   4382:     be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
                   4383:     these are wrong).
                   4384:
                   4385:     The second example will only print three lines instead of four. The first
                   4386:     line looks like a:\ echo foo. This is because the backslash of the value a:
                   4387:     \ is interpreted as a line-continuation by make(1), which makes the second
                   4388:     line the arguments of the echo(1) command from the first line. To avoid
                   4389:     this, write ${i:Q}"".
                   4390:
1.107     rillig   4391: 12.3.5. Workaround for a bug in BSD Make
1.27      rillig   4392:
                   4393: The pkgsrc bmake program does not handle the following assignment correctly. In
                   4394: case _othervar_ contains a ``-'' character, one of the closing braces is
                   4395: included in ${VAR} after this code executes.
                   4396:
1.101     rillig   4397: VAR:=   ${VAR:N${_othervar_:C/-//}}
1.27      rillig   4398:
                   4399: For a more complex code snippet and a workaround, see the package regress/
                   4400: make-quoting, testcase bug1.
                   4401:
1.107     rillig   4402: Chapter 13. PLIST issues
1.1       grant    4403:
                   4404: Table of Contents
                   4405:
1.107     rillig   4406: 13.1. RCS ID
                   4407: 13.2. Semi-automatic PLIST generation
                   4408: 13.3. Tweaking output of make print-PLIST
                   4409: 13.4. Variable substitution in PLIST
                   4410: 13.5. Man page compression
                   4411: 13.6. Changing PLIST source with PLIST_SRC
                   4412: 13.7. Platform-specific and differing PLISTs
                   4413: 13.8. Sharing directories between packages
1.1       grant    4414:
                   4415: The PLIST file contains a package's "packing list", i.e. a list of files that
                   4416: belong to the package (relative to the ${PREFIX} directory it's been installed
1.47      reed     4417: in) plus some additional statements - see the pkg_create(1) man page for a full
1.1       grant    4418: list. This chapter addresses some issues that need attention when dealing with
                   4419: the PLIST file (or files, see below!).
                   4420:
1.107     rillig   4421: 13.1. RCS ID
1.1       grant    4422:
                   4423: Be sure to add a RCS ID line as the first thing in any PLIST file you write:
                   4424:
1.101     rillig   4425: @comment $NetBSD$
1.87      wiz      4426:
1.1       grant    4427:
1.107     rillig   4428: 13.2. Semi-automatic PLIST generation
1.1       grant    4429:
                   4430: You can use the make print-PLIST command to output a PLIST that matches any new
1.107     rillig   4431: files since the package was extracted. See Section 17.17, "Other helpful
1.1       grant    4432: targets" for more information on this target.
                   4433:
1.107     rillig   4434: 13.3. Tweaking output of make print-PLIST
1.1       grant    4435:
1.107     rillig   4436: If you have used any of the *-dirs packages, as explained in Section 13.8,
1.1       grant    4437: "Sharing directories between packages", you may have noticed that make
                   4438: print-PLIST outputs a set of @comments instead of real @dirrm lines. You can
                   4439: also do this for specific directories and files, so that the results of that
                   4440: command are very close to reality. This helps a lot during the update of
                   4441: packages.
                   4442:
                   4443: The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
                   4444: used to filter the output of print-PLIST. You can append any chunk of AWK
                   4445: scripting you like to it, but be careful with quoting.
                   4446:
                   4447: For example, to get all files inside the libdata/foo directory removed from the
                   4448: resulting PLIST:
                   4449:
1.101     rillig   4450: PRINT_PLIST_AWK+=       /^libdata\/foo/ { next; }
1.87      wiz      4451:
1.1       grant    4452:
                   4453: And to get all the @dirrm lines referring to a specific (shared) directory
                   4454: converted to @comments:
                   4455:
1.101     rillig   4456: PRINT_PLIST_AWK+=       /^@dirrm share\/specific/ { print "@comment " $$0; next; }
1.87      wiz      4457:
1.1       grant    4458:
1.107     rillig   4459: 13.4. Variable substitution in PLIST
1.1       grant    4460:
                   4461: A number of variables are substituted automatically in PLISTs when a package is
                   4462: installed on a system. This includes the following variables:
                   4463:
                   4464: ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
1.20      ben      4465:
1.1       grant    4466:     Some packages like emacs and perl embed information about which
                   4467:     architecture they were built on into the pathnames where they install their
1.47      reed     4468:     files. To handle this case, PLIST will be preprocessed before actually
                   4469:     used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
                   4470:     gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
                   4471:     PLIST somewhere - use this on packages that have GNU autoconf-created
                   4472:     configure scripts.
1.20      ben      4473:
1.1       grant    4474:     Legacy note
1.20      ben      4475:
1.1       grant    4476:     There used to be a symbol "$ARCH" that was replaced by the output of uname
                   4477:     -m, but that's no longer supported and has been removed.
1.20      ben      4478:
1.1       grant    4479: ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
1.20      ben      4480:
1.1       grant    4481:     Some packages want to embed the OS name and version into some paths. To do
                   4482:     this, use these variables in the PLIST:
1.20      ben      4483:
1.1       grant    4484:       * ${OPSYS} - output of "uname -s"
1.20      ben      4485:
1.1       grant    4486:       * ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
1.20      ben      4487:
1.1       grant    4488:       * ${OS_VERSION} - "uname -r"
1.20      ben      4489:
1.1       grant    4490: For a complete list of values which are replaced by default, please look in
                   4491: bsd.pkg.mk (and search for PLIST_SUBST).
                   4492:
                   4493: If you want to change other variables not listed above, you can add variables
                   4494: and their expansions to this variable in the following way, similar to
1.107     rillig   4495: MESSAGE_SUBST (see Section 11.5, "Optional files"):
1.1       grant    4496:
1.101     rillig   4497: PLIST_SUBST+=   SOMEVAR="somevalue"
1.87      wiz      4498:
1.1       grant    4499:
                   4500: This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".
                   4501:
1.121     snj      4502: The PLIST_VARS variable can be used to simplify the common case of
                   4503: conditionally including some PLIST entries. It can be done by adding
                   4504: PLIST_VARS+=foo and setting the corresponding PLIST.foo variable to yes if the
                   4505: entry should be included. This will substitute "${PLIST.foo}" in the PLIST with
                   4506: either """" or ""@comment "". For example, in Makefile:
1.120     mishka   4507:
                   4508: PLIST_VARS+=    foo
                   4509: .if condition
                   4510: PLIST.foo=      yes
                   4511: .else
                   4512:
                   4513:
                   4514: And then in PLIST:
                   4515:
                   4516: @comment $NetBSD$
                   4517: bin/bar
                   4518: man/man1/bar.1
                   4519: ${PLIST.foo}bin/foo
                   4520: ${PLIST.foo}man/man1/foo.1
                   4521: ${PLIST.foo}share/bar/foo.data
                   4522: ${PLIST.foo}@dirrm share/bar
                   4523:
                   4524:
1.107     rillig   4525: 13.5. Man page compression
1.1       grant    4526:
1.47      reed     4527: Man pages should be installed in compressed form if MANZ is set (in
                   4528: bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
                   4529: suffix ".gz" is appended/removed automatically for man pages according to MANZ
                   4530: and MANCOMPRESSED being set or not, see above for details. This modification of
                   4531: the PLIST file is done on a copy of it, not PLIST itself.
1.1       grant    4532:
1.107     rillig   4533: 13.6. Changing PLIST source with PLIST_SRC
1.1       grant    4534:
                   4535: To use one or more files as source for the PLIST used in generating the binary
                   4536: package, set the variable PLIST_SRC to the names of that file(s). The files are
1.87      wiz      4537: later concatenated using cat(1), and the order of things is important. The
                   4538: default for PLIST_SRC is ${PKGDIR}/PLIST.
1.1       grant    4539:
1.107     rillig   4540: 13.7. Platform-specific and differing PLISTs
1.1       grant    4541:
                   4542: Some packages decide to install a different set of files based on the operating
                   4543: system being used. These differences can be automatically handled by using the
                   4544: following files:
                   4545:
                   4546:   * PLIST.common
1.20      ben      4547:
1.1       grant    4548:   * PLIST.${OPSYS}
1.20      ben      4549:
1.21      ben      4550:   * PLIST.${MACHINE_ARCH}
                   4551:
                   4552:   * PLIST.${OPSYS}-${MACHINE_ARCH}
                   4553:
1.1       grant    4554:   * PLIST.common_end
                   4555:
1.107     rillig   4556: 13.8. Sharing directories between packages
1.1       grant    4557:
                   4558: A "shared directory" is a directory where multiple (and unrelated) packages
1.126     wiz      4559: install files. These directories were problematic because you had to add
1.1       grant    4560: special tricks in the PLIST to conditionally remove them, or have some
                   4561: centralized package handle them.
                   4562:
1.126     wiz      4563: In pkgsrc, it is now easy: Each package should create directories and install
                   4564: files as needed; pkg_delete will remove any directories left empty after
                   4565: uninstalling a package.
1.20      ben      4566:
1.126     wiz      4567: If a package needs an empty directory to work, create the directory during
                   4568: installation as usual, and also add an entry to the PLIST:
1.20      ben      4569:
1.126     wiz      4570: @pkgdir path/to/empty/directory
1.1       grant    4571:
                   4572:
1.107     rillig   4573: Chapter 14. Buildlink methodology
1.1       grant    4574:
                   4575: Table of Contents
                   4576:
1.107     rillig   4577: 14.1. Converting packages to use buildlink3
                   4578: 14.2. Writing buildlink3.mk files
1.20      ben      4579:
1.107     rillig   4580:     14.2.1. Anatomy of a buildlink3.mk file
1.135     wiz      4581:     14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.pkg in
                   4582:         buildlink3.mk files
1.20      ben      4583:
1.107     rillig   4584: 14.3. Writing builtin.mk files
1.20      ben      4585:
1.107     rillig   4586:     14.3.1. Anatomy of a builtin.mk file
                   4587:     14.3.2. Global preferences for native or pkgsrc software
1.20      ben      4588:
1.1       grant    4589: Buildlink is a framework in pkgsrc that controls what headers and libraries are
                   4590: seen by a package's configure and build processes. This is implemented in a two
                   4591: step process:
                   4592:
                   4593:  1. Symlink headers and libraries for dependencies into BUILDLINK_DIR, which by
                   4594:     default is a subdirectory of WRKDIR.
1.20      ben      4595:
1.1       grant    4596:  2. Create wrapper scripts that are used in place of the normal compiler tools
                   4597:     that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib into
                   4598:     references to BUILDLINK_DIR. The wrapper scripts also make native compiler
                   4599:     on some operating systems look like GCC, so that packages that expect GCC
                   4600:     won't require modifications to build with those native compilers.
1.20      ben      4601:
1.1       grant    4602: This normalizes the environment in which a package is built so that the package
                   4603: may be built consistently despite what other software may be installed. Please
                   4604: note that the normal system header and library paths, e.g. /usr/include, /usr/
                   4605: lib, etc., are always searched -- buildlink3 is designed to insulate the
                   4606: package build from non-system-supplied software.
                   4607:
1.107     rillig   4608: 14.1. Converting packages to use buildlink3
1.1       grant    4609:
1.132     wiz      4610: The process of converting packages to use the buildlink3 framework ("bl3ifying"
                   4611: ) is fairly straightforward. The things to keep in mind are:
1.1       grant    4612:
1.22      tv       4613:  1. Ensure that the build always calls the wrapper scripts instead of the
1.1       grant    4614:     actual toolchain. Some packages are tricky, and the only way to know for
                   4615:     sure is the check ${WRKDIR}/.work.log to see if the wrappers are being
                   4616:     invoked.
1.20      ben      4617:
1.22      tv       4618:  2. Don't override PREFIX from within the package Makefile, e.g. Java VMs,
1.1       grant    4619:     standalone shells, etc., because the code to symlink files into $
                   4620:     {BUILDLINK_DIR} looks for files relative to "pkg_info -qp pkgname".
1.20      ben      4621:
1.22      tv       4622:  3. Remember that only the buildlink3.mk files that you list in a package's
1.1       grant    4623:     Makefile are added as dependencies for that package.
1.20      ben      4624:
1.1       grant    4625: If a dependency on a particular package is required for its libraries and
                   4626: headers, then we replace:
                   4627:
1.101     rillig   4628: DEPENDS+=       foo>=1.1.0:../../category/foo
1.1       grant    4629:
                   4630: with
                   4631:
1.101     rillig   4632: .include "../../category/foo/buildlink3.mk"
1.1       grant    4633:
1.47      reed     4634: The buildlink3.mk files usually define the required dependencies. If you need a
                   4635: newer version of the dependency when using buildlink3.mk files, then you can
                   4636: define it in your Makefile; for example:
                   4637:
1.101     rillig   4638: BUILDLINK_API_DEPENDS.foo+=   foo>=1.1.0
                   4639: .include "../../category/foo/buildlink3.mk"
1.47      reed     4640:
1.1       grant    4641: There are several buildlink3.mk files in pkgsrc/mk that handle special package
                   4642: issues:
                   4643:
                   4644:   * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
                   4645:     implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.
1.20      ben      4646:
1.47      reed     4647:   * curses.buildlink3.mk: If the system comes with neither Curses nor NCurses,
1.1       grant    4648:     this will take care to install the devel/ncurses package.
1.20      ben      4649:
1.1       grant    4650:   * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding
                   4651:     a dependency on Heimdal or MIT-krb5 for packages that require a Kerberos 5
                   4652:     implementation.
1.20      ben      4653:
1.1       grant    4654:   * motif.buildlink3.mk checks for a system-provided Motif installation or adds
1.88      wiz      4655:     a dependency on x11/lesstif or x11/openmotif. The user can set MOTIF_TYPE
                   4656:     to "dt", "lesstif", or "openmotif" to choose which Motif version will be
                   4657:     used.
1.20      ben      4658:
1.71      wiz      4659:   * oss.buildlink3.mk defines several variables that may be used by packages
                   4660:     that use the Open Sound System (OSS) API.
1.20      ben      4661:
1.93      rillig   4662:   * pgsql.buildlink3.mk will accept either Postgres 8.0, 8.1, or 8.2, whichever
1.91      rillig   4663:     is found installed. See the file for more information.
1.20      ben      4664:
1.1       grant    4665:   * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native
1.47      reed     4666:     pthreads or adds a dependency on devel/pth as needed.
1.20      ben      4667:
1.1       grant    4668:   * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena
                   4669:     widgets library.
1.20      ben      4670:
1.1       grant    4671: The comments in those buildlink3.mk files provide a more complete description
                   4672: of how to use them properly.
                   4673:
1.107     rillig   4674: 14.2. Writing buildlink3.mk files
1.1       grant    4675:
                   4676: A package's buildlink3.mk file is included by Makefiles to indicate the need to
                   4677: compile and link against header files and libraries provided by the package. A
                   4678: buildlink3.mk file should always provide enough information to add the correct
                   4679: type of dependency relationship and include any other buildlink3.mk files that
                   4680: it needs to find headers and libraries that it needs in turn.
                   4681:
1.20      ben      4682: To generate an initial buildlink3.mk file for further editing, Rene Hexel's
1.1       grant    4683: pkgtools/createbuildlink package is highly recommended. For most packages, the
                   4684: following command will generate a good starting point for buildlink3.mk files:
                   4685:
                   4686: % cd pkgsrc/category/pkgdir
1.49      rillig   4687: % createbuildlink >buildlink3.mk
1.1       grant    4688:
1.87      wiz      4689:
1.107     rillig   4690: 14.2.1. Anatomy of a buildlink3.mk file
1.1       grant    4691:
                   4692: The following real-life example buildlink3.mk is taken from pkgsrc/graphics/
                   4693: tiff:
                   4694:
1.121     snj      4695: # $NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp $
1.1       grant    4696:
1.121     snj      4697: BUILDLINK_TREE+=        tiff
1.1       grant    4698:
1.121     snj      4699: .if !defined(TIFF_BUILDLINK3_MK)
                   4700: TIFF_BUILDLINK3_MK:=
1.1       grant    4701:
1.121     snj      4702: BUILDLINK_API_DEPENDS.tiff+=    tiff>=3.6.1
                   4703: BUILDLINK_ABI_DEPENDS.tiff+=    tiff>=3.7.2nb1
1.101     rillig   4704: BUILDLINK_PKGSRCDIR.tiff?=      ../../graphics/tiff
1.1       grant    4705:
1.101     rillig   4706: .include "../../devel/zlib/buildlink3.mk"
                   4707: .include "../../graphics/jpeg/buildlink3.mk"
1.121     snj      4708: .endif # TIFF_BUILDLINK3_MK
1.1       grant    4709:
1.121     snj      4710: BUILDLINK_TREE+=        -tiff
1.1       grant    4711:
1.121     snj      4712: The header and footer manipulate BUILDLINK_TREE, which is common across all
                   4713: buildlink3.mk files and is used to track the dependency tree.
1.1       grant    4714:
1.121     snj      4715: The main section is protected from multiple inclusion and controls how the
1.1       grant    4716: dependency on pkg is added. Several important variables are set in the section:
                   4717:
1.72      rillig   4718:   * BUILDLINK_API_DEPENDS.pkg is the actual dependency recorded in the
                   4719:     installed package; this should always be set using += to ensure that we're
                   4720:     appending to any pre-existing list of values. This variable should be set
1.135     wiz      4721:     to the first version of the package that had an backwards-incompatible API
                   4722:     change.
1.20      ben      4723:
1.47      reed     4724:   * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory.
1.20      ben      4725:
1.1       grant    4726:   * BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
                   4727:     BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
                   4728:     is selected by setting BUILDLINK_DEPMETHOD.pkg to "build". By default, the
                   4729:     full dependency is used.
1.20      ben      4730:
1.67      hubertf  4731:   * BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS.pkg (not shown above) are lists
                   4732:     of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and
1.1       grant    4733:     library search paths. These default to "include" and "lib" respectively.
1.20      ben      4734:
1.1       grant    4735:   * BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags
                   4736:     to add to CPPFLAGS, which are passed on to the configure and build phases.
                   4737:     The "-I" option should be avoided and instead be handled using
                   4738:     BUILDLINK_INCDIRS.pkg as above.
1.20      ben      4739:
1.1       grant    4740: The following variables are all optionally defined within this second section
                   4741: (protected against multiple inclusion) and control which package files are
                   4742: symlinked into ${BUILDLINK_DIR} and how their names are transformed during the
                   4743: symlinking:
                   4744:
                   4745:   * BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to $
                   4746:     {BUILDLINK_PREFIX.pkg} to be symlinked into ${BUILDLINK_DIR}, e.g. include/
                   4747:     *.h.
1.20      ben      4748:
1.1       grant    4749:   * BUILDLINK_FILES_CMD.pkg (not shown above) is a shell pipeline that outputs
                   4750:     to stdout a list of files relative to ${BUILDLINK_PREFIX.pkg}. The
                   4751:     resulting files are to be symlinked into ${BUILDLINK_DIR}. By default, this
                   4752:     takes the +CONTENTS of a pkg and filters it through $
                   4753:     {BUILDLINK_CONTENTS_FILTER.pkg}.
1.20      ben      4754:
1.1       grant    4755:   * BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that
                   4756:     filters +CONTENTS input into a list of files relative to $
                   4757:     {BUILDLINK_PREFIX.pkg} on stdout. By default for overwrite packages,
                   4758:     BUILDLINK_CONTENTS_FILTER.pkg outputs the contents of the include and lib
                   4759:     directories in the package +CONTENTS, and for pkgviews packages, it outputs
                   4760:     any libtool archives in lib directories.
1.20      ben      4761:
1.95      tron     4762:   * BUILDLINK_FNAME_TRANSFORM.pkg (not shown above) is a list of sed arguments
                   4763:     used to transform the name of the source filename into a destination
                   4764:     filename, e.g. -e "s|/curses.h|/ncurses.h|g".
1.20      ben      4765:
1.121     snj      4766: This section can additionally include any buildlink3.mk needed for pkg's
                   4767: library dependencies. Including these buildlink3.mk files means that the
                   4768: headers and libraries for these dependencies are also symlinked into $
                   4769: {BUILDLINK_DIR} whenever the pkg buildlink3.mk file is included. Dependencies
                   4770: are only added for directly include buildlink3.mk files.
1.1       grant    4771:
1.135     wiz      4772: 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.pkg in
                   4773: buildlink3.mk files
1.20      ben      4774:
1.135     wiz      4775: These two variables differ in that one describes source compatibility (API) and
                   4776: the other binary compatibility (ABI). The difference is that a change in the
                   4777: API breaks compilation of programs while changes in the ABI stop compiled
                   4778: programs from running.
                   4779:
1.136   ! wiz      4780: Changes to the BUILDLINK_API_DEPENDS.pkg variable in a buildlink3.mk file
        !          4781: happen very rarely. One possible reason is that all packages depending on this
        !          4782: already need a newer version. In case it is bumped see the description below.
1.135     wiz      4783:
                   4784: The most common example of an ABI change is that the major version of a shared
                   4785: library is increased. In this case, BUILDLINK_ABI_DEPENDS.pkg should be
                   4786: adjusted to require at least the new package version. Then the packages that
                   4787: depend on this package need their PKGREVISIONs increased and, if they have
                   4788: buildlink3.mk files, their BUILDLINK_ABI_DEPENDS.pkg adjusted, too. This is
                   4789: needed so pkgsrc will require the correct package dependency and not settle for
                   4790: an older one when building the source.
1.72      rillig   4791:
1.107     rillig   4792: See Section 19.1.6, "Handling dependencies" for more information about
1.72      rillig   4793: dependencies on other packages, including the BUILDLINK_ABI_DEPENDS and
                   4794: ABI_DEPENDS definitions.
                   4795:
                   4796: Please take careful consideration before adjusting BUILDLINK_API_DEPENDS.pkg or
                   4797: BUILDLINK_ABI_DEPENDS.pkg as we don't want to cause unneeded package deletions
                   4798: and rebuilds. In many cases, new versions of packages work just fine with older
                   4799: dependencies.
                   4800:
                   4801: Also it is not needed to set BUILDLINK_ABI_DEPENDS.pkg when it is identical to
                   4802: BUILDLINK_API_DEPENDS.pkg.
1.1       grant    4803:
1.107     rillig   4804: 14.3. Writing builtin.mk files
1.1       grant    4805:
                   4806: Some packages in pkgsrc install headers and libraries that coincide with
                   4807: headers and libraries present in the base system. Aside from a buildlink3.mk
                   4808: file, these packages should also include a builtin.mk file that includes the
                   4809: necessary checks to decide whether using the built-in software or the pkgsrc
                   4810: software is appropriate.
                   4811:
                   4812: The only requirements of a builtin.mk file for pkg are:
                   4813:
                   4814:  1. It should set USE_BUILTIN.pkg to either "yes" or "no" after it is included.
1.20      ben      4815:
1.1       grant    4816:  2. It should not override any USE_BUILTIN.pkg which is already set before the
                   4817:     builtin.mk file is included.
1.20      ben      4818:
1.1       grant    4819:  3. It should be written to allow multiple inclusion. This is very important
                   4820:     and takes careful attention to Makefile coding.
1.20      ben      4821:
1.107     rillig   4822: 14.3.1. Anatomy of a builtin.mk file
1.1       grant    4823:
                   4824: The following is the recommended template for builtin.mk files:
                   4825:
1.101     rillig   4826: .if !defined(IS_BUILTIN.foo)
                   4827: #
                   4828: # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
                   4829: # genuinely exists in the system or not.
                   4830: #
                   4831: IS_BUILTIN.foo?=        no
                   4832:
                   4833: # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
                   4834: # version can be determined.
                   4835: #
                   4836: .  if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
                   4837: BUILTIN_PKG.foo?=       foo-1.0
                   4838: .  endif
                   4839: .endif  # IS_BUILTIN.foo
                   4840:
                   4841: .if !defined(USE_BUILTIN.foo)
                   4842: USE_BUILTIN.foo?=       ${IS_BUILTIN.foo}
                   4843: .  if defined(BUILTIN_PKG.foo)
                   4844: .    for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
                   4845: .      if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
                   4846: USE_BUILTIN.foo!=                                                       \
                   4847:         ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}            \
                   4848:         && ${ECHO} "yes" || ${ECHO} "no"
                   4849: .      endif
                   4850: .    endfor
                   4851: .  endif
                   4852: .endif  # USE_BUILTIN.foo
1.51      rillig   4853:
1.101     rillig   4854: CHECK_BUILTIN.foo?=     no
                   4855: .if !empty(CHECK_BUILTIN.foo:M[nN][oO])
                   4856: #
                   4857: # Here we place code that depends on whether USE_BUILTIN.foo is set to
                   4858: # "yes" or "no".
                   4859: #
                   4860: .endif  # CHECK_BUILTIN.foo
1.1       grant    4861:
                   4862: The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the
                   4863: base system. This should not be a base system software with similar
                   4864: functionality to pkg; it should only be "yes" if the actual package is included
                   4865: as part of the base system. This variable is only used internally within the
                   4866: builtin.mk file.
                   4867:
                   4868: The second section sets BUILTIN_PKG.pkg to the version of pkg in the base
                   4869: system if it exists (if IS_BUILTIN.pkg is "yes"). This variable is only used
                   4870: internally within the builtin.mk file.
                   4871:
                   4872: The third section sets USE_BUILTIN.pkg and is required in all builtin.mk files.
                   4873: The code in this section must make the determination whether the built-in
1.72      rillig   4874: software is adequate to satisfy the dependencies listed in
                   4875: BUILDLINK_API_DEPENDS.pkg. This is typically done by comparing BUILTIN_PKG.pkg
1.132     wiz      4876: against each of the dependencies in BUILDLINK_API_DEPENDS.pkg. USE_BUILTIN.pkg
1.72      rillig   4877: must be set to the correct value by the end of the builtin.mk file. Note that
                   4878: USE_BUILTIN.pkg may be "yes" even if IS_BUILTIN.pkg is "no" because we may make
                   4879: the determination that the built-in version of the software is similar enough
                   4880: to be used as a replacement.
1.1       grant    4881:
                   4882: The last section is guarded by CHECK_BUILTIN.pkg, and includes code that uses
                   4883: the value of USE_BUILTIN.pkg set in the previous section. This typically
                   4884: includes, e.g., adding additional dependency restrictions and listing
                   4885: additional files to symlink into ${BUILDLINK_DIR} (via BUILDLINK_FILES.pkg).
                   4886:
1.107     rillig   4887: 14.3.2. Global preferences for native or pkgsrc software
1.1       grant    4888:
                   4889: When building packages, it's possible to choose whether to set a global
                   4890: preference for using either the built-in (native) version or the pkgsrc version
                   4891: of software to satisfy a dependency. This is controlled by setting
1.132     wiz      4892: PREFER_PKGSRC and PREFER_NATIVE. These variables take values of either "yes", "
                   4893: no", or a list of packages. PREFER_PKGSRC tells pkgsrc to use the pkgsrc
1.1       grant    4894: versions of software, while PREFER_NATIVE tells pkgsrc to use the built-in
                   4895: versions. Preferences are determined by the most specific instance of the
                   4896: package in either PREFER_PKGSRC or PREFER_NATIVE. If a package is specified in
                   4897: neither or in both variables, then PREFER_PKGSRC has precedence over
                   4898: PREFER_NATIVE. For example, to require using pkgsrc versions of software for
                   4899: all but the most basic bits on a NetBSD system, you can set:
                   4900:
1.101     rillig   4901: PREFER_PKGSRC=  yes
                   4902: PREFER_NATIVE=  getopt skey tcp_wrappers
1.1       grant    4903:
                   4904: A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise
                   4905: it is simply ignored in that list.
                   4906:
1.107     rillig   4907: Chapter 15. The pkginstall framework
1.35      jmmv     4908:
                   4909: Table of Contents
                   4910:
1.107     rillig   4911: 15.1. Files and directories outside the installation prefix
1.35      jmmv     4912:
1.107     rillig   4913:     15.1.1. Directory manipulation
                   4914:     15.1.2. File manipulation
1.35      jmmv     4915:
1.107     rillig   4916: 15.2. Configuration files
1.35      jmmv     4917:
1.107     rillig   4918:     15.2.1. How PKG_SYSCONFDIR is set
                   4919:     15.2.2. Telling the software where configuration files are
                   4920:     15.2.3. Patching installations
                   4921:     15.2.4. Disabling handling of configuration files
1.35      jmmv     4922:
1.107     rillig   4923: 15.3. System startup scripts
1.35      jmmv     4924:
1.107     rillig   4925:     15.3.1. Disabling handling of system startup scripts
1.35      jmmv     4926:
1.107     rillig   4927: 15.4. System users and groups
                   4928: 15.5. System shells
1.35      jmmv     4929:
1.107     rillig   4930:     15.5.1. Disabling shell registration
1.65      hubertf  4931:
1.107     rillig   4932: 15.6. Fonts
1.65      hubertf  4933:
1.107     rillig   4934:     15.6.1. Disabling automatic update of the fonts databases
1.35      jmmv     4935:
                   4936: This chapter describes the framework known as pkginstall, whose key features
                   4937: are:
                   4938:
                   4939:   * Generic installation and manipulation of directories and files outside the
                   4940:     pkgsrc-handled tree, LOCALBASE.
                   4941:
                   4942:   * Automatic handling of configuration files during installation, provided
                   4943:     that packages are correctly designed.
                   4944:
                   4945:   * Generation and installation of system startup scripts.
                   4946:
                   4947:   * Registration of system users and groups.
                   4948:
                   4949:   * Registration of system shells.
                   4950:
1.65      hubertf  4951:   * Automatic updating of fonts databases.
1.35      jmmv     4952:
1.65      hubertf  4953: The following sections inspect each of the above points in detail.
1.35      jmmv     4954:
                   4955: You may be thinking that many of the things described here could be easily done
                   4956: with simple code in the package's post-installation target (post-install). This
                   4957: is incorrect, as the code in them is only executed when building from source.
                   4958: Machines using binary packages could not benefit from it at all (as the code
                   4959: itself could be unavailable). Therefore, the only way to achieve any of the
                   4960: items described above is by means of the installation scripts, which are
                   4961: automatically generated by pkginstall.
                   4962:
1.107     rillig   4963: 15.1. Files and directories outside the installation prefix
1.35      jmmv     4964:
                   4965: As you already know, the PLIST file holds a list of files and directories that
                   4966: belong to a package. The names used in it are relative to the installation
                   4967: prefix (${PREFIX}), which means that it cannot register files outside this
                   4968: directory (absolute path names are not allowed). Despite this restriction, some
                   4969: packages need to install files outside this location; e.g., under ${VARBASE} or
1.87      wiz      4970: ${PKG_SYSCONFDIR}. The only way to achieve this is to create such files during
                   4971: installation time by using installation scripts.
1.35      jmmv     4972:
1.87      wiz      4973: The generic installation scripts are shell scripts that can contain arbitrary
                   4974: code. The list of scripts to execute is taken from the INSTALL_FILE variable,
                   4975: which defaults to INSTALL. A similar variable exists for package removal
                   4976: (DEINSTALL_FILE, whose default is DEINSTALL). These scripts can run arbitrary
                   4977: commands, so they have the potential to create and manage files anywhere in the
                   4978: file system.
                   4979:
                   4980: Using these general installation files is not recommended, but may be needed in
                   4981: some special cases. One reason for avoiding them is that the user has to trust
                   4982: the packager that there is no unwanted or simply erroneous code included in the
                   4983: installation script. Also, previously there were many similar scripts for the
                   4984: same functionality, and fixing a common error involved finding and changing all
                   4985: of them.
                   4986:
                   4987: The pkginstall framework offers another, standardized way. It provides generic
                   4988: scripts to abstract the manipulation of such files and directories based on
                   4989: variables set in the package's Makefile. The rest of this section describes
                   4990: these variables.
1.35      jmmv     4991:
1.107     rillig   4992: 15.1.1. Directory manipulation
1.35      jmmv     4993:
                   4994: The following variables can be set to request the creation of directories
1.47      reed     4995: anywhere in the file system:
1.35      jmmv     4996:
                   4997:   * MAKE_DIRS and OWN_DIRS contain a list of directories that should be created
                   4998:     and should attempt to be destroyed by the installation scripts. The
                   4999:     difference between the two is that the latter prompts the administrator to
                   5000:     remove any directories that may be left after deinstallation (because they
                   5001:     were not empty), while the former does not.
                   5002:
                   5003:   * MAKE_DIRS_PERMS and OWN_DIRS_PERMS contain a list of tuples describing
                   5004:     which directories should be created and should attempt to be destroyed by
                   5005:     the installation scripts. Each tuple holds the following values, separated
                   5006:     by spaces: the directory name, its owner, its group and its numerical mode.
                   5007:     For example:
                   5008:
1.101     rillig   5009:     MAKE_DIRS_PERMS+=         ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
1.35      jmmv     5010:
                   5011:     The difference between the two is exactly the same as their non-PERMS
                   5012:     counterparts.
                   5013:
1.107     rillig   5014: 15.1.2. File manipulation
1.35      jmmv     5015:
                   5016: Creating non-empty files outside the installation prefix is tricky because the
                   5017: PLIST forces all files to be inside it. To overcome this problem, the only
                   5018: solution is to extract the file in the known place (i.e., inside the
                   5019: installation prefix) and copy it to the appropriate location during
                   5020: installation (done by the installation scripts generated by pkginstall). We
                   5021: will call the former the master file in the following paragraphs, which
                   5022: describe the variables that can be used to automatically and consistently
                   5023: handle files outside the installation prefix:
                   5024:
                   5025:   * CONF_FILES and SUPPORT_FILES are pairs of master and target files. During
                   5026:     installation time, the master file is copied to the target one if and only
                   5027:     if the latter does not exist. Upon deinstallation, the target file is
                   5028:     removed provided that it was not modified by the installation.
                   5029:
                   5030:     The difference between the two is that the latter prompts the administrator
                   5031:     to remove any files that may be left after deinstallation (because they
                   5032:     were not empty), while the former does not.
                   5033:
                   5034:   * CONF_FILES_PERMS and SUPPORT_FILES_PERMS contain tuples describing master
                   5035:     files as well as their target locations. For each of them, it also
                   5036:     specifies their owner, their group and their numeric permissions, in this
                   5037:     order. For example:
                   5038:
1.101     rillig   5039:     SUPPORT_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
1.35      jmmv     5040:
                   5041:     The difference between the two is exactly the same as their non-PERMS
                   5042:     counterparts.
                   5043:
1.107     rillig   5044: 15.2. Configuration files
1.35      jmmv     5045:
                   5046: Configuration files are special in the sense that they are installed in their
                   5047: own specific directory, PKG_SYSCONFDIR, and need special treatment during
                   5048: installation (most of which is automated by pkginstall). The main concept you
1.36      wiz      5049: must bear in mind is that files marked as configuration files are automatically
1.35      jmmv     5050: copied to the right place (somewhere inside PKG_SYSCONFDIR) during installation
                   5051: if and only if they didn't exist before. Similarly, they will not be removed if
1.36      wiz      5052: they have local modifications. This ensures that administrators never lose any
1.35      jmmv     5053: custom changes they may have made.
                   5054:
1.107     rillig   5055: 15.2.1. How PKG_SYSCONFDIR is set
1.35      jmmv     5056:
                   5057: As said before, the PKG_SYSCONFDIR variable specifies where configuration files
                   5058: shall be installed. Its contents are set based upon the following variables:
                   5059:
                   5060:   * PKG_SYSCONFBASE: The configuration's root directory. Defaults to ${PREFIX}/
1.36      wiz      5061:     etc although it may be overridden by the user to point to his preferred
1.35      jmmv     5062:     location (e.g., /etc, /etc/pkg, etc.). Packages must not use it directly.
                   5063:
                   5064:   * PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the
                   5065:     configuration files for the package being built shall be installed. The
                   5066:     definition of this variable only makes sense in the package's Makefile
1.47      reed     5067:     (i.e., it is not user-customizable).
1.35      jmmv     5068:
                   5069:     As an example, consider the Apache package, www/apache2, which places its
                   5070:     configuration files under the httpd/ subdirectory of PKG_SYSCONFBASE. This
                   5071:     should be set in the package Makefile.
                   5072:
                   5073:   * PKG_SYSCONFVAR: Specifies the name of the variable that holds this
                   5074:     package's configuration directory (if different from PKG_SYSCONFBASE). It
                   5075:     defaults to PKGBASE's value, and is always prefixed with PKG_SYSCONFDIR.
                   5076:
                   5077:   * PKG_SYSCONFDIR.${PKG_SYSCONFVAR}: Holds the directory where the
                   5078:     configuration files for the package identified by PKG_SYSCONFVAR's shall be
                   5079:     placed.
                   5080:
                   5081: Based on the above variables, pkginstall determines the value of
                   5082: PKG_SYSCONFDIR, which is the only variable that can be used within a package to
                   5083: refer to its configuration directory. The algorithm used to set its value is
                   5084: basically the following:
                   5085:
                   5086:  1. If PKG_SYSCONFDIR.${PKG_SYSCONFVAR} is set, its value is used.
                   5087:
                   5088:  2. If the previous variable is not defined but PKG_SYSCONFSUBDIR is set in the
                   5089:     package's Makefile, the resulting value is ${PKG_SYSCONFBASE}/$
                   5090:     {PKG_SYSCONFSUBDIR}.
                   5091:
                   5092:  3. Otherwise, it is set to ${PKG_SYSCONFBASE}.
                   5093:
                   5094: It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
1.118     jnemeth  5095: OWN_DIRS. See Section 15.1.1, "Directory manipulation" what this means. This
                   5096: does not apply to subdirectories of ${PKG_SYSCONFDIR}, they still have to be
                   5097: created with OWN_DIRS or MAKE_DIRS.
1.35      jmmv     5098:
1.107     rillig   5099: 15.2.2. Telling the software where configuration files are
1.35      jmmv     5100:
                   5101: Given that pkgsrc (and users!) expect configuration files to be in a known
1.36      wiz      5102: place, you need to teach each package where it shall install its files. In some
1.35      jmmv     5103: cases you will have to patch the package Makefiles to achieve it. If you are
                   5104: lucky, though, it may be as easy as passing an extra flag to the configuration
1.47      reed     5105: script; this is the case of GNU Autoconf- generated files:
1.35      jmmv     5106:
1.101     rillig   5107: CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
1.35      jmmv     5108:
                   5109: Note that this specifies where the package has to look for its configuration
                   5110: files, not where they will be originally installed (although the difference is
                   5111: never explicit, unfortunately).
                   5112:
1.107     rillig   5113: 15.2.3. Patching installations
1.35      jmmv     5114:
                   5115: As said before, pkginstall automatically handles configuration files. This
                   5116: means that the packages themselves must not touch the contents of $
1.36      wiz      5117: {PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts
                   5118: will, out of the box, mess with the contents of that directory. So what is the
                   5119: correct procedure to fix this issue?
1.35      jmmv     5120:
                   5121: You must teach the package (usually by manually patching it) to install any
                   5122: configuration files under the examples hierarchy, share/examples/${PKGBASE}/.
                   5123: This way, the PLIST registers them and the administrator always has the
                   5124: original copies available.
                   5125:
                   5126: Once the required configuration files are in place (i.e., under the examples
                   5127: hierarchy), the pkginstall framework can use them as master copies during the
                   5128: package installation to update what is in ${PKG_SYSCONFDIR}. To achieve this,
1.63      dillo    5129: the variables CONF_FILES and CONF_FILES_PERMS are used. Check out
1.107     rillig   5130: Section 15.1.2, "File manipulation" for information about their syntax and
1.63      dillo    5131: their purpose. Here is an example, taken from the mail/mutt package:
1.35      jmmv     5132:
1.101     rillig   5133: EGDIR=        ${PREFIX}/share/doc/mutt/samples
                   5134: CONF_FILES=   ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
1.35      jmmv     5135:
                   5136: Note that the EGDIR variable is specific to that package and has no meaning
                   5137: outside it.
                   5138:
1.107     rillig   5139: 15.2.4. Disabling handling of configuration files
1.35      jmmv     5140:
                   5141: The automatic copying of config files can be toggled by setting the environment
                   5142: variable PKG_CONFIG prior to package installation.
                   5143:
1.107     rillig   5144: 15.3. System startup scripts
1.35      jmmv     5145:
                   5146: System startup scripts are special files because they must be installed in a
                   5147: place known by the underlying OS, usually outside the installation prefix.
1.107     rillig   5148: Therefore, the same rules described in Section 15.1, "Files and directories
1.35      jmmv     5149: outside the installation prefix" apply, and the same solutions can be used.
1.36      wiz      5150: However, pkginstall provides a special mechanism to handle these files.
1.35      jmmv     5151:
                   5152: In order to provide system startup scripts, the package has to:
                   5153:
                   5154:  1. Store the script inside ${FILESDIR}, with the .sh suffix appended.
1.36      wiz      5155:     Considering the print/cups package as an example, it has a cupsd.sh in its
                   5156:     files directory.
1.35      jmmv     5157:
                   5158:  2. Tell pkginstall to handle it, appending the name of the script, without its
                   5159:     extension, to the RCD_SCRIPTS variable. Continuing the previous example:
                   5160:
1.101     rillig   5161:     RCD_SCRIPTS+=   cupsd
1.35      jmmv     5162:
                   5163: Once this is done, pkginstall will do the following steps for each script in an
                   5164: automated fashion:
                   5165:
                   5166:  1. Process the file found in the files directory applying all the
                   5167:     substitutions described in the FILES_SUBST variable.
                   5168:
                   5169:  2. Copy the script from the files directory to the examples hierarchy, $
1.36      wiz      5170:     {PREFIX}/share/examples/rc.d/. Note that this master file must be
                   5171:     explicitly registered in the PLIST.
1.35      jmmv     5172:
                   5173:  3. Add code to the installation scripts to copy the startup script from the
                   5174:     examples hierarchy into the system-wide startup scripts directory.
                   5175:
1.107     rillig   5176: 15.3.1. Disabling handling of system startup scripts
1.35      jmmv     5177:
                   5178: The automatic copying of config files can be toggled by setting the environment
                   5179: variable PKG_RCD_SCRIPTS prior to package installation. Note that the scripts
                   5180: will be always copied inside the examples hierarchy, ${PREFIX}/share/examples/
                   5181: rc.d/, no matter what the value of this variable is.
                   5182:
1.107     rillig   5183: 15.4. System users and groups
1.35      jmmv     5184:
                   5185: If a package needs to create special users and/or groups during installation,
                   5186: it can do so by using the pkginstall framework.
                   5187:
                   5188: Users can be created by adding entries to the PKG_USERS variable. Each entry
1.72      rillig   5189: has the following syntax:
1.35      jmmv     5190:
1.101     rillig   5191: user:group
1.35      jmmv     5192:
1.72      rillig   5193: Further specification of user details may be done by setting per-user
                   5194: variables. PKG_UID.user is the numeric UID for the user. PKG_GECOS.user is the
                   5195: user's description or comment. PKG_HOME.user is the user's home directory, and
                   5196: defaults to /nonexistent if not specified. PKG_SHELL.user is the user's shell,
1.94      dmcmahil 5197: and defaults to /sbin/nologin if not specified.
1.35      jmmv     5198:
1.72      rillig   5199: Similarly, groups can be created by adding entries to the PKG_GROUPS variable,
                   5200: whose syntax is:
1.35      jmmv     5201:
1.101     rillig   5202: group
1.35      jmmv     5203:
1.72      rillig   5204: The numeric GID of the group may be set by defining PKG_GID.group.
1.35      jmmv     5205:
1.72      rillig   5206: If a package needs to create the users and groups at an earlier stage, then it
                   5207: can set USERGROUP_PHASE to either configure or build to indicate the phase
                   5208: before which the users and groups are created. In this case, the numeric UIDs
                   5209: and GIDs of the created users and groups are automatically hardcoded into the
                   5210: final installation scripts.
1.35      jmmv     5211:
1.107     rillig   5212: 15.5. System shells
1.35      jmmv     5213:
                   5214: Packages that install system shells should register them in the shell database,
                   5215: /etc/shells, to make things easier to the administrator. This must be done from
                   5216: the installation scripts to keep binary packages working on any system.
                   5217: pkginstall provides an easy way to accomplish this task.
                   5218:
                   5219: When a package provides a shell interpreter, it has to set the PKG_SHELL
                   5220: variable to its absolute file name. This will add some hooks to the
                   5221: installation scripts to handle it. Consider the following example, taken from
                   5222: shells/zsh:
                   5223:
1.101     rillig   5224: PKG_SHELL=      ${PREFIX}/bin/zsh
1.35      jmmv     5225:
1.107     rillig   5226: 15.5.1. Disabling shell registration
1.35      jmmv     5227:
                   5228: The automatic registration of shell interpreters can be disabled by the
                   5229: administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.
                   5230:
1.107     rillig   5231: 15.6. Fonts
1.65      hubertf  5232:
                   5233: Packages that install X11 fonts should update the database files that index the
                   5234: fonts within each fonts directory. This can easily be accomplished within the
                   5235: pkginstall framework.
                   5236:
                   5237: When a package installs X11 fonts, it must list the directories in which fonts
                   5238: are installed in the FONTS_DIRS.type variables, where type can be one of "ttf",
                   5239: "type1" or "x11". This will add hooks to the installation scripts to run the
                   5240: appropriate commands to update the fonts database files within each of those
                   5241: directories. For convenience, if the directory path is relative, it is taken to
                   5242: be relative to the package's installation prefix. Consider the following
                   5243: example, taken from fonts/dbz-ttf:
                   5244:
1.101     rillig   5245: FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF
1.65      hubertf  5246:
1.107     rillig   5247: 15.6.1. Disabling automatic update of the fonts databases
1.65      hubertf  5248:
                   5249: The automatic update of fonts databases can be disabled by the administrator by
                   5250: setting the PKG_UPDATE_FONTS_DB environment variable to NO.
                   5251:
1.107     rillig   5252: Chapter 16. Options handling
1.1       grant    5253:
                   5254: Table of Contents
                   5255:
1.107     rillig   5256: 16.1. Global default options
                   5257: 16.2. Converting packages to use bsd.options.mk
                   5258: 16.3. Option Names
1.108     rillig   5259: 16.4. Determining the options of dependencies
1.1       grant    5260:
                   5261: Many packages have the ability to be built to support different sets of
                   5262: features. bsd.options.mk is a framework in pkgsrc that provides generic
                   5263: handling of those options that determine different ways in which the packages
                   5264: can be built. It's possible for the user to specify exactly which sets of
                   5265: options will be built into a package or to allow a set of global default
                   5266: options apply.
                   5267:
1.108     rillig   5268: There are two broad classes of behaviors that one might want to control via
                   5269: options. One is whether some particular feature is enabled in a program that
                   5270: will be built anyway, often by including or not including a dependency on some
                   5271: other package. The other is whether or not an additional program will be built
                   5272: as part of the package. Generally, it is better to make a split package for
                   5273: such additional programs instead of using options, because it enables binary
                   5274: packages to be built which can then be added separately. For example, the foo
                   5275: package might have minimal dependencies (those packages without which foo
                   5276: doesn't make sense), and then the foo-gfoo package might include the GTK
                   5277: frontend program gfoo. This is better than including a gtk option to foo that
                   5278: adds gfoo, because either that option is default, in which case binary users
                   5279: can't get foo without gfoo, or not default, in which case they can't get gfoo.
                   5280: With split packages, they can install foo without having GTK, and later decide
                   5281: to install gfoo (pulling in GTK at that time). This is an advantage to source
                   5282: users too, avoiding the need for rebuilds.
                   5283:
                   5284: Plugins with widely varying dependencies should usually be split instead of
                   5285: options.
                   5286:
                   5287: It is often more work to maintain split packages, especially if the upstream
                   5288: package does not support this. The decision of split vs. option should be made
                   5289: based on the likelihood that users will want or object to the various pieces,
                   5290: the size of the dependencies that are included, and the amount of work.
                   5291:
                   5292: A further consideration is licensing. Non-free parts, or parts that depend on
                   5293: non-free dependencies (especially plugins) should almost always be split if
                   5294: feasible.
                   5295:
1.107     rillig   5296: 16.1. Global default options
1.1       grant    5297:
                   5298: Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of
                   5299: the options that should be built into every package if that option is
1.105     rillig   5300: supported. This variable should be set in mk.conf.
1.1       grant    5301:
1.107     rillig   5302: 16.2. Converting packages to use bsd.options.mk
1.1       grant    5303:
1.27      rillig   5304: The following example shows how bsd.options.mk should be used by the
                   5305: hypothetical ``wibble'' package, either in the package Makefile, or in a file,
                   5306: e.g. options.mk, that is included by the main package Makefile.
1.1       grant    5307:
1.101     rillig   5308: PKG_OPTIONS_VAR=                PKG_OPTIONS.wibble
                   5309: PKG_SUPPORTED_OPTIONS=          wibble-foo ldap
                   5310: PKG_OPTIONS_OPTIONAL_GROUPS=    database
                   5311: PKG_OPTIONS_GROUP.database=     mysql pgsql
                   5312: PKG_SUGGESTED_OPTIONS=          wibble-foo
                   5313: PKG_OPTIONS_LEGACY_VARS+=       WIBBLE_USE_OPENLDAP:ldap
                   5314: PKG_OPTIONS_LEGACY_OPTS+=       foo:wibble-foo
                   5315:
                   5316: .include "../../mk/bsd.prefs.mk"
                   5317:
                   5318: # this package was previously named wibble2
                   5319: .if defined(PKG_OPTIONS.wibble2)
                   5320: PKG_LEGACY_OPTIONS+=            ${PKG_OPTIONS.wibble2}
                   5321: PKG_OPTIONS_DEPRECATED_WARNINGS+= \
                   5322:         "Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR} instead."
                   5323: .endif
1.51      rillig   5324:
1.101     rillig   5325: .include "../../mk/bsd.options.mk"
1.51      rillig   5326:
1.101     rillig   5327: # Package-specific option-handling
1.51      rillig   5328:
1.101     rillig   5329: ###
                   5330: ### FOO support
                   5331: ###
                   5332: .if !empty(PKG_OPTIONS:Mwibble-foo)
                   5333: CONFIGURE_ARGS+=    --enable-foo
                   5334: .endif
1.51      rillig   5335:
1.101     rillig   5336: ###
                   5337: ### LDAP support
                   5338: ###
                   5339: .if !empty(PKG_OPTIONS:Mldap)
                   5340: .  include "../../databases/openldap-client/buildlink3.mk"
                   5341: CONFIGURE_ARGS+=    --enable-ldap=${BUILDLINK_PREFIX.openldap-client}
                   5342: .endif
1.51      rillig   5343:
1.101     rillig   5344: ###
                   5345: ### database support
                   5346: ###
                   5347: .if !empty(PKG_OPTIONS:Mmysql)
                   5348: .  include "../../mk/mysql.buildlink3.mk"
                   5349: .endif
                   5350: .if !empty(PKG_OPTIONS:Mpgsql)
                   5351: .  include "../../mk/pgsql.buildlink3.mk"
                   5352: .endif
1.20      ben      5353:
1.28      rillig   5354: The first section contains the information about which build options are
1.1       grant    5355: supported by the package, and any default options settings if needed.
                   5356:
1.37      dillo    5357:  1. PKG_OPTIONS_VAR is the name of the make(1) variable that the user can set
1.57      minskim  5358:     to override the default options. It should be set to PKG_OPTIONS.pkgbase.
1.78      rillig   5359:     Do not set it to PKG_OPTIONS.${PKGBASE}, since PKGBASE is not defined at
                   5360:     the point where the options are processed.
1.20      ben      5361:
1.1       grant    5362:  2. PKG_SUPPORTED_OPTIONS is a list of build options supported by the package.
1.20      ben      5363:
1.37      dillo    5364:  3. PKG_OPTIONS_OPTIONAL_GROUPS is a list of names of groups of mutually
                   5365:     exclusive options. The options in each group are listed in
                   5366:     PKG_OPTIONS_GROUP.groupname. The most specific setting of any option from
                   5367:     the group takes precedence over all other options in the group. Options
                   5368:     from the groups will be automatically added to PKG_SUPPORTED_OPTIONS.
                   5369:
                   5370:  4. PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, but
                   5371:     building the packages will fail if no option from the group is selected.
                   5372:
1.44      gdt      5373:  5. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of options. At least
                   5374:     one option from each set must be selected. The options in each set are
                   5375:     listed in PKG_OPTIONS_SET.setname. Options from the sets will be
                   5376:     automatically added to PKG_SUPPORTED_OPTIONS. Building the package will
                   5377:     fail if no option from the set is selected.
                   5378:
                   5379:  6. PKG_SUGGESTED_OPTIONS is a list of build options which are enabled by
1.27      rillig   5380:     default.
                   5381:
1.67      hubertf  5382:  7. PKG_OPTIONS_LEGACY_VARS is a list of "USE_VARIABLE:option" pairs that map
1.105     rillig   5383:     legacy mk.conf variables to their option counterparts. Pairs should be
1.37      dillo    5384:     added with "+=" to keep the listing of global legacy variables. A warning
                   5385:     will be issued if the user uses a legacy variable.
                   5386:
1.67      hubertf  5387:  8. PKG_OPTIONS_LEGACY_OPTS is a list of "old-option:new-option" pairs that map
                   5388:     options that have been renamed to their new counterparts. Pairs should be
                   5389:     added with "+=" to keep the listing of global legacy options. A warning
1.37      dillo    5390:     will be issued if the user uses a legacy option.
                   5391:
1.44      gdt      5392:  9. PKG_LEGACY_OPTIONS is a list of options implied by deprecated variables
1.37      dillo    5393:     used. This can be used for cases that neither PKG_OPTIONS_LEGACY_VARS nor
                   5394:     PKG_OPTIONS_LEGACY_OPTS can handle, e. g. when PKG_OPTIONS_VAR is renamed.
                   5395:
1.44      gdt      5396: 10. PKG_OPTIONS_DEPRECATED_WARNINGS is a list of warnings about deprecated
1.37      dillo    5397:     variables or options used, and what to use instead.
                   5398:
                   5399: A package should never modify PKG_DEFAULT_OPTIONS or the variable named in
                   5400: PKG_OPTIONS_VAR. These are strictly user-settable. To suggest a default set of
                   5401: options, use PKG_SUGGESTED_OPTIONS.
                   5402:
1.42      dillo    5403: PKG_OPTIONS_VAR must be defined before including bsd.options.mk. If none of
                   5404: PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, and
1.47      reed     5405: PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform-specific
1.42      dillo    5406: options if none of them is supported on the current platform), PKG_OPTIONS is
                   5407: set to the empty list and the package is otherwise treated as not using the
                   5408: options framework.
1.28      rillig   5409:
                   5410: After the inclusion of bsd.options.mk, the variable PKG_OPTIONS contains the
1.37      dillo    5411: list of selected build options, properly filtered to remove unsupported and
1.28      rillig   5412: duplicate options.
1.20      ben      5413:
1.37      dillo    5414: The remaining sections contain the logic that is specific to each option. The
                   5415: correct way to check for an option is to check whether it is listed in
                   5416: PKG_OPTIONS:
                   5417:
1.101     rillig   5418: .if !empty(PKG_OPTIONS:Moption)
1.37      dillo    5419:
1.107     rillig   5420: 16.3. Option Names
1.48      dillo    5421:
                   5422: Options that enable similar features in different packages (like optional
                   5423: support for a library) should use a common name in all packages that support it
                   5424: (like the name of the library). If another package already has an option with
                   5425: the same meaning, use the same name.
                   5426:
                   5427: Options that enable features specific to one package, where it's unlikely that
                   5428: another (unrelated) package has the same (or a similar) optional feature,
                   5429: should use a name prefixed with pkgname-.
                   5430:
                   5431: If a group of related packages share an optional feature specific to that
                   5432: group, prefix it with the name of the "main" package (e. g.
                   5433: djbware-errno-hack).
                   5434:
                   5435: For new options, add a line to mk/defaults/options.description. Lines have two
                   5436: fields, separated by tab. The first field is the option name, the second its
                   5437: description. The description should be a whole sentence (starting with an
                   5438: uppercase letter and ending with a period) that describes what enabling the
                   5439: option does. E. g. "Enable ispell support." The file is sorted by option names.
1.1       grant    5440:
1.108     rillig   5441: 16.4. Determining the options of dependencies
                   5442:
                   5443: When writing buildlink3.mk files, it is often necessary to list different
                   5444: dependencies based on the options with which the package was built. For
                   5445: querying these options, the file pkgsrc/mk/pkg-build-options.mk should be used.
                   5446: A typical example looks like this:
                   5447:
                   5448: pkgbase := libpurple
                   5449: .include "../../mk/pkg-build-options.mk"
                   5450:
                   5451: .if !empty(PKG_BUILD_OPTIONS.libpurple:Mdbus)
                   5452: ...
                   5453: .endif
                   5454:
                   5455: Including pkg-build-options.mk here will set the variable
                   5456: PKG_BUILD_OPTIONS.libpurple to the build options of the libpurple package,
                   5457: which can then be queried like PKG_OPTIONS in the options.mk file. See the file
                   5458: pkg-build-options.mk for more details.
                   5459:
1.107     rillig   5460: Chapter 17. The build process
1.1       grant    5461:
                   5462: Table of Contents
                   5463:
1.107     rillig   5464: 17.1. Introduction
                   5465: 17.2. Program location
                   5466: 17.3. Directories used during the build process
                   5467: 17.4. Running a phase
                   5468: 17.5. The fetch phase
                   5469:
                   5470:     17.5.1. What to fetch and where to get it from
                   5471:     17.5.2. How are the files fetched?
                   5472:
                   5473: 17.6. The checksum phase
                   5474: 17.7. The extract phase
                   5475: 17.8. The patch phase
                   5476: 17.9. The tools phase
                   5477: 17.10. The wrapper phase
                   5478: 17.11. The configure phase
                   5479: 17.12. The build phase
                   5480: 17.13. The test phase
                   5481: 17.14. The install phase
                   5482: 17.15. The package phase
                   5483: 17.16. Cleaning up
                   5484: 17.17. Other helpful targets
1.56      rillig   5485:
1.107     rillig   5486: 17.1. Introduction
1.56      rillig   5487:
                   5488: This chapter gives a detailed description on how a package is built. Building a
                   5489: package is separated into different phases (for example fetch, build, install),
1.121     snj      5490: all of which are described in the following sections. Each phase is split into
                   5491: so-called stages, which take the name of the containing phase, prefixed by one
                   5492: of pre-, do- or post-. (Examples are pre-configure, post-build.) Most of the
                   5493: actual work is done in the do-* stages.
1.1       grant    5494:
1.97      wiz      5495: Never override the regular targets (like fetch), if you have to, override the
                   5496: do-* ones instead.
                   5497:
1.1       grant    5498: The basic steps for building a program are always the same. First the program's
                   5499: source (distfile) must be brought to the local system and then extracted. After
1.66      rillig   5500: any pkgsrc-specific patches to compile properly are applied, the software can
                   5501: be configured, then built (usually by compiling), and finally the generated
                   5502: binaries, etc. can be put into place on the system.
1.1       grant    5503:
1.97      wiz      5504: To get more details about what is happening at each step, you can set the
                   5505: PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in
                   5506: more details about the patch step.
                   5507:
1.107     rillig   5508: 17.2. Program location
1.1       grant    5509:
                   5510: Before outlining the process performed by the NetBSD package system in the next
                   5511: section, here's a brief discussion on where programs are installed, and which
                   5512: variables influence this.
                   5513:
                   5514: The automatic variable PREFIX indicates where all files of the final program
                   5515: shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
1.88      wiz      5516: pkgs in the cross category. The value of PREFIX needs to be put into the
1.1       grant    5517: various places in the program's source where paths to these files are encoded.
1.107     rillig   5518: See Section 11.3, "patches/*" and Section 19.3.1, "Shared libraries - libtool"
1.1       grant    5519: for more details.
                   5520:
                   5521: When choosing which of these variables to use, follow the following rules:
                   5522:
                   5523:   * PREFIX always points to the location where the current pkg will be
1.132     wiz      5524:     installed. When referring to a pkg's own installation path, use "${PREFIX}"
                   5525:     .
1.20      ben      5526:
1.1       grant    5527:   * LOCALBASE is where all non-X11 pkgs are installed. If you need to construct
                   5528:     a -I or -L argument to the compiler to find includes and libraries
1.78      rillig   5529:     installed by another non-X11 pkg, use "${LOCALBASE}". The name LOCALBASE
                   5530:     stems from FreeBSD, which installed all packages in /usr/local. As pkgsrc
                   5531:     leaves /usr/local for the system administrator, this variable is a
                   5532:     misnomer.
1.20      ben      5533:
1.1       grant    5534:   * X11BASE is where the actual X11 distribution (from xsrc, etc.) is
                   5535:     installed. When looking for standard X11 includes (not those installed by a
1.88      wiz      5536:     package), use "${X11BASE}".
1.20      ben      5537:
1.47      reed     5538:   * X11-based packages are special in that they may be installed in either
                   5539:     X11BASE or LOCALBASE.
1.20      ben      5540:
1.1       grant    5541:     Usually, X11 packages should be installed under LOCALBASE whenever
1.34      wiz      5542:     possible. Note that you will need to include ../../mk/x11.buildlink3.mk in
                   5543:     them to request the presence of X11 and to get the right compilation flags.
1.20      ben      5544:
1.1       grant    5545:     Even though, there are some packages that cannot be installed under
                   5546:     LOCALBASE: those that come with app-defaults files. These packages are
                   5547:     special and they must be placed under X11BASE. To accomplish this, set
                   5548:     either USE_X11BASE or USE_IMAKE in your package.
1.20      ben      5549:
1.34      wiz      5550:     Some notes: If you need to find includes or libraries installed by a pkg
1.132     wiz      5551:     that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in
1.34      wiz      5552:     both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages
                   5553:     in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default.
1.20      ben      5554:
1.1       grant    5555:   * X11PREFIX should be used to refer to the installed location of an X11
                   5556:     package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed,
                   5557:     and to LOCALBASE if xpkgwedge is installed.
1.20      ben      5558:
1.1       grant    5559:   * If xpkgwedge is installed, it is possible to have some packages installed
                   5560:     in X11BASE and some in LOCALBASE. To determine the prefix of an installed
                   5561:     package, the EVAL_PREFIX definition can be used. It takes pairs in the
                   5562:     format "DIRNAME=<package>", and the make(1) variable DIRNAME will be set to
                   5563:     the prefix of the installed package <package>, or "${X11PREFIX}" if the
                   5564:     package is not installed.
1.20      ben      5565:
1.1       grant    5566:     This is best illustrated by example.
1.20      ben      5567:
1.1       grant    5568:     The following lines are taken from pkgsrc/wm/scwm/Makefile:
1.20      ben      5569:
1.101     rillig   5570:     EVAL_PREFIX+=           GTKDIR=gtk+
                   5571:     CONFIGURE_ARGS+=        --with-guile-prefix=${LOCALBASE:Q}
                   5572:     CONFIGURE_ARGS+=        --with-gtk-prefix=${GTKDIR:Q}
                   5573:     CONFIGURE_ARGS+=        --enable-multibyte
1.20      ben      5574:
1.1       grant    5575:     Specific defaults can be defined for the packages evaluated using
                   5576:     EVAL_PREFIX, by using a definition of the form:
1.20      ben      5577:
1.101     rillig   5578:     GTKDIR_DEFAULT= ${LOCALBASE}
1.20      ben      5579:
1.1       grant    5580:     where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair.
1.20      ben      5581:
1.1       grant    5582:   * Within ${PREFIX}, packages should install files according to hier(7), with
                   5583:     the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
                   5584:     man.
1.20      ben      5585:
1.107     rillig   5586: 17.3. Directories used during the build process
1.1       grant    5587:
1.115     jmcneill 5588: When building a package, various directories are used to store source files,
1.56      rillig   5589: temporary files, pkgsrc-internal files, and so on. These directories are
                   5590: explained here.
1.1       grant    5591:
1.56      rillig   5592: Some of the directory variables contain relative pathnames. There are two
                   5593: common base directories for these relative directories: PKGSRCDIR/PKGPATH is
                   5594: used for directories that are pkgsrc-specific. WRKSRC is used for directories
1.66      rillig   5595: inside the package itself.
1.20      ben      5596:
1.66      rillig   5597: PKGSRCDIR
1.1       grant    5598:
1.56      rillig   5599:     This is an absolute pathname that points to the pkgsrc root directory.
                   5600:     Generally, you don't need it.
                   5601:
1.97      wiz      5602: PKGDIR
                   5603:
                   5604:     This is an absolute pathname that points to the current package.
                   5605:
1.66      rillig   5606: PKGPATH
1.56      rillig   5607:
                   5608:     This is a pathname relative to PKGSRCDIR that points to the current
                   5609:     package.
                   5610:
1.66      rillig   5611: WRKDIR
1.56      rillig   5612:
                   5613:     This is an absolute pathname pointing to the directory where all work takes
1.93      rillig   5614:     place. The distfiles are extracted to this directory. It also contains
1.57      minskim  5615:     temporary directories and log files used by the various pkgsrc frameworks,
                   5616:     like buildlink or the wrappers.
1.56      rillig   5617:
1.66      rillig   5618: WRKSRC
1.56      rillig   5619:
                   5620:     This is an absolute pathname pointing to the directory where the distfiles
                   5621:     are extracted. It is usually a direct subdirectory of WRKDIR, and often
1.66      rillig   5622:     it's the only directory entry that isn't hidden. This variable may be
                   5623:     changed by a package Makefile.
1.56      rillig   5624:
1.115     jmcneill 5625: The CREATE_WRKDIR_SYMLINK definition takes either the value yes or no and
1.117     rillig   5626: defaults to no. It indicates whether a symbolic link to the WRKDIR is to be
1.115     jmcneill 5627: created in the pkgsrc entry's directory. If users would like to have their
                   5628: pkgsrc trees behave in a read-only manner, then the value of
                   5629: CREATE_WRKDIR_SYMLINK should be set to no.
                   5630:
1.107     rillig   5631: 17.4. Running a phase
1.56      rillig   5632:
                   5633: You can run a particular phase by typing make phase, where phase is the name of
                   5634: the phase. This will automatically run all phases that are required for this
                   5635: phase. The default phase is build, that is, when you run make without
                   5636: parameters in a package directory, the package will be built, but not
                   5637: installed.
                   5638:
1.107     rillig   5639: 17.5. The fetch phase
1.56      rillig   5640:
1.81      rillig   5641: The first step in building a package is to fetch the distribution files
1.132     wiz      5642: (distfiles) from the sites that are providing them. This is the task of the
1.81      rillig   5643: fetch phase.
                   5644:
1.107     rillig   5645: 17.5.1. What to fetch and where to get it from
1.81      rillig   5646:
                   5647: In simple cases, MASTER_SITES defines all URLs from where the distfile, whose
                   5648: name is derived from the DISTNAME variable, is fetched. The more complicated
                   5649: cases are described below.
                   5650:
                   5651: The variable DISTFILES specifies the list of distfiles that have to be fetched.
                   5652: Its value defaults to ${DISTNAME}${EXTRACT_SUFX}, so that most packages don't
                   5653: need to define it at all. EXTRACT_SUFX is .tar.gz by default, but can be
                   5654: changed freely. Note that if your package requires additional distfiles to the
                   5655: default one, you cannot just append the additional filenames using the +=
                   5656: operator, but you have write for example:
                   5657:
1.101     rillig   5658: DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
1.88      wiz      5659:
                   5660: Each distfile is fetched from a list of sites, usually MASTER_SITES. If the
                   5661: package has multiple DISTFILES or multiple PATCHFILES from different sites, you
                   5662: can set SITES.distfile to the list of URLs where the file distfile (including
                   5663: the suffix) can be found.
                   5664:
1.101     rillig   5665: DISTFILES=      ${DISTNAME}${EXTRACT_SUFX}
                   5666: DISTFILES+=     foo-file.tar.gz
                   5667: SITES.foo-file.tar.gz= \
                   5668: http://www.somewhere.com/somehow/ \
                   5669: http://www.somewhereelse.com/mirror/somehow/
1.81      rillig   5670:
                   5671: When actually fetching the distfiles, each item from MASTER_SITES or SITES.*
                   5672: gets the name of each distfile appended to it, without an intermediate slash.
                   5673: Therefore, all site values have to end with a slash or other separator
                   5674: character. This allows for example to set MASTER_SITES to a URL of a CGI script
                   5675: that gets the name of the distfile as a parameter. In this case, the definition
                   5676: would look like:
                   5677:
1.101     rillig   5678: MASTER_SITES=   http://www.example.com/download.cgi?file=
1.81      rillig   5679:
1.126     wiz      5680: The exception to this rule are URLs starting with a dash. In that case the URL
                   5681: is taken as is, fetched and the result stored under the name of the distfile.
                   5682:
1.81      rillig   5683: There are some predefined values for MASTER_SITES, which can be used in
                   5684: packages. The names of the variables should speak for themselves.
                   5685:
1.101     rillig   5686: ${MASTER_SITE_APACHE}
                   5687: ${MASTER_SITE_BACKUP}
                   5688: ${MASTER_SITE_CYGWIN}
                   5689: ${MASTER_SITE_DEBIAN}
                   5690: ${MASTER_SITE_FREEBSD}
                   5691: ${MASTER_SITE_FREEBSD_LOCAL}
                   5692: ${MASTER_SITE_GENTOO}
                   5693: ${MASTER_SITE_GNOME}
                   5694: ${MASTER_SITE_GNU}
                   5695: ${MASTER_SITE_GNUSTEP}
                   5696: ${MASTER_SITE_IFARCHIVE}
                   5697: ${MASTER_SITE_KDE}
                   5698: ${MASTER_SITE_MOZILLA}
                   5699: ${MASTER_SITE_MYSQL}
                   5700: ${MASTER_SITE_OPENOFFICE}
                   5701: ${MASTER_SITE_PERL_CPAN}
                   5702: ${MASTER_SITE_PGSQL}
                   5703: ${MASTER_SITE_R_CRAN}
                   5704: ${MASTER_SITE_SOURCEFORGE}
                   5705: ${MASTER_SITE_SOURCEFORGE_JP}
                   5706: ${MASTER_SITE_SUNSITE}
                   5707: ${MASTER_SITE_SUSE}
                   5708: ${MASTER_SITE_TEX_CTAN}
                   5709: ${MASTER_SITE_XCONTRIB}
                   5710: ${MASTER_SITE_XEMACS}
1.88      wiz      5711:
                   5712: Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP
1.93      rillig   5713: contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org/
1.135     wiz      5714: pub/pkgsrc/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local package
1.134     spz      5715: source distributions that are maintained in ftp://ftp.NetBSD.org/pub/pkgsrc/
                   5716: distfiles/LOCAL_PORTS/.
1.81      rillig   5717:
                   5718: If you choose one of these predefined sites, you may want to specify a
                   5719: subdirectory of that site. Since these macros may expand to more than one
                   5720: actual site, you must use the following construct to specify a subdirectory:
                   5721:
1.101     rillig   5722: MASTER_SITES=   ${MASTER_SITE_GNU:=subdirectory/name/}
                   5723: MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=project_name/}
1.81      rillig   5724:
                   5725: Note the trailing slash after the subdirectory name.
                   5726:
1.107     rillig   5727: 17.5.2. How are the files fetched?
1.81      rillig   5728:
                   5729: The fetch phase makes sure that all the distfiles exist in a local directory
1.93      rillig   5730: (DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they
                   5731: are fetched using commands of the form
1.56      rillig   5732:
1.101     rillig   5733: ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
1.56      rillig   5734:
                   5735: where ${site} varies through several possibilities in turn: first,
1.72      rillig   5736: MASTER_SITE_OVERRIDE is tried, then the sites specified in either SITES.file if
1.56      rillig   5737: defined, else MASTER_SITES or PATCH_SITES, as applies, then finally the value
1.91      rillig   5738: of MASTER_SITE_BACKUP. The order of all except the first and the last can be
                   5739: optionally sorted by the user, via setting either MASTER_SORT_RANDOM, and
                   5740: MASTER_SORT_AWK or MASTER_SORT_REGEX.
1.56      rillig   5741:
1.118     jnemeth  5742: The specific command and arguments used depend on the FETCH_USING parameter.
                   5743: The example above is for FETCH_USING=custom.
                   5744:
1.97      wiz      5745: The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles
                   5746: target to mirror the distfiles, if they are freely distributable. Packages
                   5747: setting NO_SRC_ON_FTP (usually to "${RESTRICTED}") will not have their
                   5748: distfiles mirrored.
                   5749:
1.107     rillig   5750: 17.6. The checksum phase
1.56      rillig   5751:
                   5752: After the distfile(s) are fetched, their checksum is generated and compared
                   5753: with the checksums stored in the distinfo file. If the checksums don't match,
                   5754: the build is aborted. This is to ensure the same distfile is used for building,
                   5755: and that the distfile wasn't changed, e.g. by some malign force, deliberately
                   5756: changed distfiles on the master distribution site or network lossage.
                   5757:
1.107     rillig   5758: 17.7. The extract phase
1.56      rillig   5759:
                   5760: When the distfiles are present on the local system, they need to be extracted,
1.69      rillig   5761: as they usually come in the form of some compressed archive format.
                   5762:
                   5763: By default, all DISTFILES are extracted. If you only need some of them, you can
                   5764: set the EXTRACT_ONLY variable to the list of those files.
                   5765:
1.93      rillig   5766: Extracting the files is usually done by a little program, mk/extract/extract,
1.69      rillig   5767: which already knows how to extract various archive formats, so most likely you
                   5768: will not need to change anything here. But if you need, the following variables
                   5769: may help you:
                   5770:
                   5771: EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}
                   5772:
                   5773:     Use these variables to override the default options for an extract command,
1.93      rillig   5774:     which are defined in mk/extract/extract.
1.56      rillig   5775:
1.69      rillig   5776: EXTRACT_USING
1.56      rillig   5777:
1.115     jmcneill 5778:     This variable can be set to bsdtar, gtar, nbtar (which is the default
                   5779:     value), pax, or an absolute pathname pointing to the command with which tar
                   5780:     archives should be extracted. It is preferred to choose bsdtar over gtar if
                   5781:     NetBSD's pax-as-tar is not good enough.
1.69      rillig   5782:
                   5783: If the extract program doesn't serve your needs, you can also override the
                   5784: EXTRACT_CMD variable, which holds the command used for extracting the files.
                   5785: This command is executed in the ${WRKSRC} directory. During execution of this
                   5786: command, the shell variable extract_file holds the absolute pathname of the
                   5787: file that is going to be extracted.
                   5788:
                   5789: And if that still does not suffice, you can override the do-extract target in
                   5790: the package Makefile.
1.56      rillig   5791:
1.107     rillig   5792: 17.8. The patch phase
1.56      rillig   5793:
                   5794: After extraction, all the patches named by the PATCHFILES, those present in the
                   5795: patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
                   5796: /usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz
                   5797: are uncompressed before they are applied, files ending in .orig or .rej are
                   5798: ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See
1.107     rillig   5799: Section 11.3, "patches/*" for more details.
1.56      rillig   5800:
                   5801: By default patch(1) is given special args to make it fail if the patches apply
                   5802: with some lines of fuzz. Please fix (regen) the patches so that they apply
                   5803: cleanly. The rationale behind this is that patches that don't apply cleanly may
                   5804: end up being applied in the wrong place, and cause severe harm there.
                   5805:
1.107     rillig   5806: 17.9. The tools phase
1.56      rillig   5807:
1.107     rillig   5808: This is covered in Chapter 18, Tools needed for building or running.
1.56      rillig   5809:
1.107     rillig   5810: 17.10. The wrapper phase
1.56      rillig   5811:
1.72      rillig   5812: This phase creates wrapper programs for the compilers and linkers. The
                   5813: following variables can be used to tweak the wrappers.
                   5814:
                   5815: ECHO_WRAPPER_MSG
                   5816:
                   5817:     The command used to print progress messages. Does nothing by default. Set
                   5818:     to ${ECHO} to see the progress messages.
                   5819:
                   5820: WRAPPER_DEBUG
                   5821:
                   5822:     This variable can be set to yes (default) or no, depending on whether you
                   5823:     want additional information in the wrapper log file.
                   5824:
                   5825: WRAPPER_UPDATE_CACHE
                   5826:
                   5827:     This variable can be set to yes or no, depending on whether the wrapper
                   5828:     should use its cache, which will improve the speed. The default value is
                   5829:     yes, but is forced to no if the platform does not support it.
                   5830:
                   5831: WRAPPER_REORDER_CMDS
                   5832:
                   5833:     A list of reordering commands. A reordering command has the form reorder:l:
                   5834:     lib1:lib2. It ensures that that -llib1 occurs before -llib2.
                   5835:
                   5836: WRAPPER_TRANSFORM_CMDS
                   5837:
                   5838:     A list of transformation commands. [TODO: investigate further]
1.56      rillig   5839:
1.107     rillig   5840: 17.11. The configure phase
1.56      rillig   5841:
                   5842: Most pieces of software need information on the header files, system calls, and
                   5843: library routines which are available on the platform they run on. The process
                   5844: of determining this information is known as configuration, and is usually
                   5845: automated. In most cases, a script is supplied with the distfiles, and its
                   5846: invocation results in generation of header files, Makefiles, etc.
                   5847:
                   5848: If the package contains a configure script, this can be invoked by setting
                   5849: HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you
                   5850: should set GNU_CONFIGURE to "yes" instead. What happens in the configure phase
                   5851: is roughly:
                   5852:
1.101     rillig   5853: .for d in ${CONFIGURE_DIRS}
                   5854:         cd ${WRKSRC} \
                   5855:         && cd ${d} \
                   5856:         && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
                   5857: .endfor
1.56      rillig   5858:
                   5859: CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In
                   5860: each of these directories, the configure script is run with the environment
                   5861: CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV,
                   5862: CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed
                   5863: by the package.
                   5864:
                   5865: If the program uses an Imakefile for configuration, the appropriate steps can
                   5866: be invoked by setting USE_IMAKE to "yes". (If you only want the package
                   5867: installed in ${X11PREFIX} but xmkmf not being run, set USE_X11BASE instead.)
1.97      wiz      5868: You can add variables to xmkmf's environment by adding them to the SCRIPTS_ENV
                   5869: variable.
                   5870:
1.112     rillig   5871: If the program uses cmake for configuration, the appropriate steps can be
                   5872: invoked by setting USE_CMAKE to "yes". You can add variables to cmake's
                   5873: environment by adding them to the CONFIGURE_ENV variable and arguments to cmake
                   5874: by adding them to the CMAKE_ARGS variable. The top directory argument is given
                   5875: by the CMAKE_ARG_PATH variable, that defaults to "." (relative to
                   5876: CONFIGURE_DIRS)
                   5877:
1.97      wiz      5878: If there is no configure step at all, set NO_CONFIGURE to "yes".
1.56      rillig   5879:
1.107     rillig   5880: 17.12. The build phase
1.56      rillig   5881:
                   5882: For building a package, a rough equivalent of the following code is executed.
                   5883:
1.101     rillig   5884: .for d in ${BUILD_DIRS}
                   5885:         cd ${WRKSRC} \
                   5886:         && cd ${d} \
                   5887:         && env ${MAKE_ENV} \
                   5888:             ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \
                   5889:                 -f ${MAKE_FILE} \
                   5890:                 ${BUILD_TARGET}
                   5891: .endfor
1.56      rillig   5892:
                   5893: BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of
                   5894: these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and
1.87      wiz      5895: arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE
1.56      rillig   5896: and BUILD_TARGET may all be changed by the package.
                   5897:
1.132     wiz      5898: The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", "
                   5899: make" otherwise. The default value of MAKE_FILE is "Makefile", and BUILD_TARGET
                   5900: defaults to "all".
1.56      rillig   5901:
1.98      rillig   5902: If there is no build step at all, set NO_BUILD to "yes".
1.97      wiz      5903:
1.107     rillig   5904: 17.13. The test phase
1.56      rillig   5905:
                   5906: [TODO]
                   5907:
1.107     rillig   5908: 17.14. The install phase
1.56      rillig   5909:
                   5910: Once the build stage has completed, the final step is to install the software
1.68      rillig   5911: in public directories, so users can access the programs and files.
                   5912:
                   5913: In the install phase, a rough equivalent of the following code is executed.
                   5914: Additionally, before and after this code, much magic is performed to do
                   5915: consistency checks, registering the package, and so on.
                   5916:
1.101     rillig   5917: .for d in ${INSTALL_DIRS}
                   5918:         cd ${WRKSRC} \
                   5919:         && cd ${d} \
                   5920:         && env ${MAKE_ENV} \
                   5921:             ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \
                   5922:                 -f ${MAKE_FILE} \
                   5923:                 ${INSTALL_TARGET}
                   5924: .endfor
1.68      rillig   5925:
                   5926: The variable's meanings are analogous to the ones in the build phase.
                   5927: INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is "install" by default,
1.88      wiz      5928: plus "install.man" if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
                   5929: defined.
1.68      rillig   5930:
                   5931: In the install phase, the following variables are useful. They are all
                   5932: variations of the install(1) command that have the owner, group and permissions
                   5933: preset. INSTALL is the plain install command. The specialized variants,
                   5934: together with their intended use, are:
                   5935:
                   5936: INSTALL_PROGRAM_DIR
                   5937:
                   5938:     directories that contain binaries
                   5939:
                   5940: INSTALL_SCRIPT_DIR
                   5941:
                   5942:     directories that contain scripts
                   5943:
                   5944: INSTALL_LIB_DIR
                   5945:
                   5946:     directories that contain shared and static libraries
                   5947:
                   5948: INSTALL_DATA_DIR
                   5949:
                   5950:     directories that contain data files
                   5951:
                   5952: INSTALL_MAN_DIR
                   5953:
                   5954:     directories that contain man pages
                   5955:
                   5956: INSTALL_PROGRAM
                   5957:
                   5958:     binaries that can be stripped from debugging symbols
                   5959:
                   5960: INSTALL_SCRIPT
                   5961:
                   5962:     binaries that cannot be stripped
                   5963:
                   5964: INSTALL_GAME
                   5965:
                   5966:     game binaries
                   5967:
                   5968: INSTALL_LIB
                   5969:
                   5970:     shared and static libraries
                   5971:
                   5972: INSTALL_DATA
                   5973:
                   5974:     data files
                   5975:
                   5976: INSTALL_GAME_DATA
                   5977:
                   5978:     data files for games
                   5979:
                   5980: INSTALL_MAN
                   5981:
                   5982:     man pages
                   5983:
                   5984: Some other variables are:
                   5985:
                   5986: INSTALLATION_DIRS
                   5987:
                   5988:     A list of directories relative to PREFIX that are created by pkgsrc at the
1.99      wiz      5989:     beginning of the install phase. The package is supposed to create all
                   5990:     needed directories itself before installing files to it and list all other
                   5991:     directories here.
1.56      rillig   5992:
1.132     wiz      5993: In the rare cases that a package shouldn't install anything, set NO_INSTALL to
1.97      wiz      5994: "yes". This is mostly relevant for packages in the regress category.
                   5995:
1.107     rillig   5996: 17.15. The package phase
1.56      rillig   5997:
1.88      wiz      5998: Once the install stage has completed, a binary package of the installed files
                   5999: can be built. These binary packages can be used for quick installation without
                   6000: previous compilation, e.g. by the make bin-install or by using pkg_add.
                   6001:
                   6002: By default, the binary packages are created in ${PACKAGES}/All and symlinks are
                   6003: created in ${PACKAGES}/category, one for each category in the CATEGORIES
                   6004: variable. PACKAGES defaults to pkgsrc/packages.
                   6005:
1.107     rillig   6006: 17.16. Cleaning up
1.88      wiz      6007:
                   6008: Once you're finished with a package, you can clean the work directory by
                   6009: running make clean. If you want to clean the work directories of all
                   6010: dependencies too, use make clean-depends.
1.56      rillig   6011:
1.107     rillig   6012: 17.17. Other helpful targets
1.1       grant    6013:
                   6014: pre/post-*
1.20      ben      6015:
1.1       grant    6016:     For any of the main targets described in the previous section, two
                   6017:     auxiliary targets exist with "pre-" and "post-" used as a prefix for the
                   6018:     main target's name. These targets are invoked before and after the main
                   6019:     target is called, allowing extra configuration or installation steps be
                   6020:     performed from a package's Makefile, for example, which a program's
                   6021:     configure script or install target omitted.
1.20      ben      6022:
1.1       grant    6023: do-*
1.20      ben      6024:
1.1       grant    6025:     Should one of the main targets do the wrong thing, and should there be no
                   6026:     variable to fix this, you can redefine it with the do-* target. (Note that
                   6027:     redefining the target itself instead of the do-* target is a bad idea, as
                   6028:     the pre-* and post-* targets won't be called anymore, etc.) You will not
                   6029:     usually need to do this.
1.20      ben      6030:
1.1       grant    6031: reinstall
1.20      ben      6032:
1.1       grant    6033:     If you did a make install and you noticed some file was not installed
                   6034:     properly, you can repeat the installation with this target, which will
                   6035:     ignore the "already installed" flag.
1.20      ben      6036:
1.88      wiz      6037:     This is the default value of DEPENDS_TARGET except in the case of make
                   6038:     update and make package, where the defaults are "package" and "update",
                   6039:     respectively.
                   6040:
1.1       grant    6041: deinstall
1.20      ben      6042:
1.1       grant    6043:     This target does a pkg_delete(1) in the current directory, effectively
                   6044:     de-installing the package. The following variables can be used to tune the
                   6045:     behaviour:
1.20      ben      6046:
1.1       grant    6047:     PKG_VERBOSE
1.20      ben      6048:
1.1       grant    6049:         Add a "-v" to the pkg_delete(1) command.
1.20      ben      6050:
1.1       grant    6051:     DEINSTALLDEPENDS
1.20      ben      6052:
1.1       grant    6053:         Remove all packages that require (depend on) the given package. This
                   6054:         can be used to remove any packages that may have been pulled in by a
                   6055:         given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
1.132     wiz      6056:         pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding "-R
                   6057:         " to the pkg_delete(1) command line.
1.20      ben      6058:
1.88      wiz      6059: bin-install
                   6060:
                   6061:     Install a binary package from local disk and via FTP from a list of sites
                   6062:     (see the BINPKG_SITES variable), and do a make package if no binary package
                   6063:     is available anywhere. The arguments given to pkg_add can be set via
                   6064:     BIN_INSTALL_FLAGS e.g., to do verbose operation, etc.
                   6065:
1.1       grant    6066: update
1.20      ben      6067:
1.1       grant    6068:     This target causes the current package to be updated to the latest version.
                   6069:     The package and all depending packages first get de-installed, then current
                   6070:     versions of the corresponding packages get compiled and installed. This is
                   6071:     similar to manually noting which packages are currently installed, then
                   6072:     performing a series of make deinstall and make install (or whatever
                   6073:     UPDATE_TARGET is set to) for these packages.
1.20      ben      6074:
1.1       grant    6075:     You can use the "update" target to resume package updating in case a
                   6076:     previous make update was interrupted for some reason. However, in this
                   6077:     case, make sure you don't call make clean or otherwise remove the list of
1.47      reed     6078:     dependent packages in WRKDIR. Otherwise, you lose the ability to
1.1       grant    6079:     automatically update the current package along with the dependent packages
                   6080:     you have installed.
1.20      ben      6081:
1.1       grant    6082:     Resuming an interrupted make update will only work as long as the package
                   6083:     tree remains unchanged. If the source code for one of the packages to be
                   6084:     updated has been changed, resuming make update will most certainly fail!
1.20      ben      6085:
1.105     rillig   6086:     The following variables can be used either on the command line or in
1.1       grant    6087:     mk.conf to alter the behaviour of make update:
1.20      ben      6088:
1.1       grant    6089:     UPDATE_TARGET
1.20      ben      6090:
1.1       grant    6091:         Install target to recursively use for the updated package and the
                   6092:         dependent packages. Defaults to DEPENDS_TARGET if set, "install"
1.132     wiz      6093:         otherwise for make update. Other good targets are "package" or "
                   6094:         bin-install". Do not set this to "update" or you will get stuck in an
1.88      wiz      6095:         endless loop!
1.20      ben      6096:
1.1       grant    6097:     NOCLEAN
1.20      ben      6098:
1.1       grant    6099:         Don't clean up after updating. Useful if you want to leave the work
                   6100:         sources of the updated packages around for inspection or other
1.132     wiz      6101:         purposes. Be sure you eventually clean up the source tree (see the "
                   6102:         clean-update" target below) or you may run into troubles with old
1.1       grant    6103:         source code still lying around on your next make or make update.
1.20      ben      6104:
1.1       grant    6105:     REINSTALL
1.20      ben      6106:
1.1       grant    6107:         Deinstall each package before installing (making DEPENDS_TARGET). This
                   6108:         may be necessary if the "clean-update" target (see below) was called
                   6109:         after interrupting a running make update.
1.20      ben      6110:
1.1       grant    6111:     DEPENDS_TARGET
1.20      ben      6112:
1.1       grant    6113:         Allows you to disable recursion and hardcode the target for packages.
                   6114:         The default is "update" for the update target, facilitating a recursive
                   6115:         update of prerequisite packages. Only set DEPENDS_TARGET if you want to
                   6116:         disable recursive updates. Use UPDATE_TARGET instead to just set a
                   6117:         specific target for each package to be installed during make update
                   6118:         (see above).
1.20      ben      6119:
1.1       grant    6120: clean-update
1.20      ben      6121:
1.1       grant    6122:     Clean the source tree for all packages that would get updated if make
                   6123:     update was called from the current directory. This target should not be
                   6124:     used if the current package (or any of its depending packages) have already
                   6125:     been de-installed (e.g., after calling make update) or you may lose some
1.132     wiz      6126:     packages you intended to update. As a rule of thumb: only use this target
1.1       grant    6127:     before the first time you run make update and only if you have a dirty
                   6128:     package tree (e.g., if you used NOCLEAN).
1.20      ben      6129:
1.47      reed     6130:     If you are unsure about whether your tree is clean, you can either perform
                   6131:     a make clean at the top of the tree, or use the following sequence of
1.1       grant    6132:     commands from the directory of the package you want to update (before
                   6133:     running make update for the first time, otherwise you lose all the packages
                   6134:     you wanted to update!):
1.20      ben      6135:
1.1       grant    6136:     # make clean-update
                   6137:     # make clean CLEANDEPENDS=YES
                   6138:     # make update
1.20      ben      6139:
1.87      wiz      6140:
1.105     rillig   6141:     The following variables can be used either on the command line or in
1.1       grant    6142:     mk.conf to alter the behaviour of make clean-update:
1.20      ben      6143:
1.1       grant    6144:     CLEAR_DIRLIST
1.20      ben      6145:
1.1       grant    6146:         After make clean, do not reconstruct the list of directories to update
                   6147:         for this package. Only use this if make update successfully installed
                   6148:         all packages you wanted to update. Normally, this is done automatically
                   6149:         on make update, but may have been suppressed by the NOCLEAN variable
                   6150:         (see above).
1.20      ben      6151:
1.88      wiz      6152: replace
                   6153:
                   6154:     Update the installation of the current package. This differs from update in
                   6155:     that it does not replace dependent packages. You will need to install
1.93      rillig   6156:     pkgtools/pkg_tarup for this target to work.
1.88      wiz      6157:
                   6158:     Be careful when using this target! There are no guarantees that dependent
                   6159:     packages will still work, in particular they will most certainly break if
                   6160:     you make replace a library package whose shared library major version
                   6161:     changed between your installed version and the new one. For this reason,
                   6162:     this target is not officially supported and only recommended for advanced
                   6163:     users.
                   6164:
1.1       grant    6165: info
1.20      ben      6166:
1.1       grant    6167:     This target invokes pkg_info(1) for the current package. You can use this
                   6168:     to check which version of a package is installed.
1.20      ben      6169:
1.88      wiz      6170: index
                   6171:
                   6172:     This is a top-level command, i.e. it should be used in the pkgsrc
                   6173:     directory. It creates a database of all packages in the local pkgsrc tree,
                   6174:     including dependencies, comment, maintainer, and some other useful
                   6175:     information. Individual entries are created by running make describe in the
                   6176:     packages' directories. This index file is saved as pkgsrc/INDEX. It can be
                   6177:     displayed in verbose format by running make print-index. You can search in
                   6178:     it with make search key=something. You can extract a list of all packages
                   6179:     that depend on a particular one by running make show-deps PKG=somepackage.
                   6180:
                   6181:     Running this command takes a very long time, some hours even on fast
                   6182:     machines!
                   6183:
1.1       grant    6184: readme
1.20      ben      6185:
1.1       grant    6186:     This target generates a README.html file, which can be viewed using a
1.83      wiz      6187:     browser such as www/firefox or www/links. The generated files contain
1.1       grant    6188:     references to any packages which are in the PACKAGES directory on the local
                   6189:     host. The generated files can be made to refer to URLs based on
                   6190:     FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate
                   6191:     README.html files which pointed to binary packages on the local machine, in
                   6192:     the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
                   6193:     FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
                   6194:     subdirectories will be searched for all the binary packages.
1.20      ben      6195:
1.88      wiz      6196:     The target can be run at the toplevel or in category directories, in which
                   6197:     case it descends recursively.
                   6198:
1.1       grant    6199: readme-all
1.20      ben      6200:
1.88      wiz      6201:     This is a top-level command, run it in pkgsrc. Use this target to create a
                   6202:     file README-all.html which contains a list of all packages currently
                   6203:     available in the NetBSD Packages Collection, together with the category
                   6204:     they belong to and a short description. This file is compiled from the
                   6205:     pkgsrc/*/README.html files, so be sure to run this after a make readme.
1.20      ben      6206:
1.1       grant    6207: cdrom-readme
1.20      ben      6208:
1.1       grant    6209:     This is very much the same as the "readme" target (see above), but is to be
                   6210:     used when generating a pkgsrc tree to be written to a CD-ROM. This target
                   6211:     also produces README.html files, and can be made to refer to URLs based on
                   6212:     CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
1.20      ben      6213:
1.1       grant    6214: show-distfiles
1.20      ben      6215:
1.1       grant    6216:     This target shows which distfiles and patchfiles are needed to build the
1.87      wiz      6217:     package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not
                   6218:     patches/*).
1.20      ben      6219:
1.1       grant    6220: show-downlevel
1.20      ben      6221:
1.1       grant    6222:     This target shows nothing if the package is not installed. If a version of
                   6223:     this package is installed, but is not the version provided in this version
                   6224:     of pkgsrc, then a warning message is displayed. This target can be used to
                   6225:     show which of your installed packages are downlevel, and so the old
                   6226:     versions can be deleted, and the current ones added.
1.20      ben      6227:
1.1       grant    6228: show-pkgsrc-dir
1.20      ben      6229:
1.1       grant    6230:     This target shows the directory in the pkgsrc hierarchy from which the
                   6231:     package can be built and installed. This may not be the same directory as
                   6232:     the one from which the package was installed. This target is intended to be
                   6233:     used by people who may wish to upgrade many packages on a single host, and
1.132     wiz      6234:     can be invoked from the top-level pkgsrc Makefile by using the "
                   6235:     show-host-specific-pkgs" target.
1.20      ben      6236:
1.1       grant    6237: show-installed-depends
1.20      ben      6238:
1.1       grant    6239:     This target shows which installed packages match the current package's
                   6240:     DEPENDS. Useful if out of date dependencies are causing build problems.
1.20      ben      6241:
1.1       grant    6242: check-shlibs
1.20      ben      6243:
1.1       grant    6244:     After a package is installed, check all its binaries and (on ELF platforms)
                   6245:     shared libraries to see if they find the shared libs they need. Run by
1.105     rillig   6246:     default if PKG_DEVELOPER is set in mk.conf.
1.20      ben      6247:
1.1       grant    6248: print-PLIST
1.20      ben      6249:
1.1       grant    6250:     After a "make install" from a new or upgraded pkg, this prints out an
                   6251:     attempt to generate a new PLIST from a find -newer work/.extract_done. An
                   6252:     attempt is made to care for shared libs etc., but it is strongly
                   6253:     recommended to review the result before putting it into PLIST. On upgrades,
                   6254:     it's useful to diff the output of this command against an already existing
                   6255:     PLIST file.
1.20      ben      6256:
1.1       grant    6257:     If the package installs files via tar(1) or other methods that don't update
                   6258:     file access times, be sure to add these files manually to your PLIST, as
                   6259:     the "find -newer" command used by this target won't catch them!
1.20      ben      6260:
1.107     rillig   6261:     See Section 13.3, "Tweaking output of make print-PLIST" for more
1.38      dillo    6262:     information on this target.
1.20      ben      6263:
1.1       grant    6264: bulk-package
1.20      ben      6265:
1.1       grant    6266:     Used to do bulk builds. If an appropriate binary package already exists, no
                   6267:     action is taken. If not, this target will compile, install and package it
1.107     rillig   6268:     (and its depends, if PKG_DEPENDS is set properly. See Section 7.3.1,
1.47      reed     6269:     "Configuration"). After creating the binary package, the sources, the
                   6270:     just-installed package and its required packages are removed, preserving
1.1       grant    6271:     free disk space.
1.20      ben      6272:
1.1       grant    6273:     Beware that this target may deinstall all packages installed on a system!
1.20      ben      6274:
1.1       grant    6275: bulk-install
1.20      ben      6276:
1.47      reed     6277:     Used during bulk-installs to install required packages. If an up-to-date
1.132     wiz      6278:     binary package is available, it will be installed via pkg_add(1). If not,
1.47      reed     6279:     make bulk-package will be executed, but the installed binary won't be
1.1       grant    6280:     removed.
1.20      ben      6281:
1.47      reed     6282:     A binary package is considered "up-to-date" to be installed via pkg_add(1)
1.1       grant    6283:     if:
1.20      ben      6284:
1.1       grant    6285:       * None of the package's files (Makefile, ...) were modified since it was
                   6286:         built.
1.20      ben      6287:
1.1       grant    6288:       * None of the package's required (binary) packages were modified since it
                   6289:         was built.
1.20      ben      6290:
1.1       grant    6291:     Beware that this target may deinstall all packages installed on a system!
1.20      ben      6292:
1.107     rillig   6293: Chapter 18. Tools needed for building or running
1.68      rillig   6294:
                   6295: Table of Contents
                   6296:
1.107     rillig   6297: 18.1. Tools for pkgsrc builds
                   6298: 18.2. Tools needed by packages
                   6299: 18.3. Tools provided by platforms
                   6300: 18.4. Questions regarding the tools
1.68      rillig   6301:
                   6302: The USE_TOOLS definition is used both internally by pkgsrc and also for
                   6303: individual packages to define what commands are needed for building a package
                   6304: (like BUILD_DEPENDS) or for later run-time of an installed packaged (such as
                   6305: DEPENDS). If the native system provides an adequate tool, then in many cases, a
                   6306: pkgsrc package will not be used.
                   6307:
                   6308: When building a package, the replacement tools are made available in a
                   6309: directory (as symlinks or wrapper scripts) that is early in the executable
                   6310: search path. Just like the buildlink system, this helps with consistent builds.
                   6311:
                   6312: A tool may be needed to help build a specific package. For example, perl, GNU
                   6313: make (gmake) or yacc may be needed.
                   6314:
                   6315: Also a tool may be needed, for example, because the native system's supplied
                   6316: tool may be inefficient for building a package with pkgsrc. For example, a
                   6317: package may need GNU awk, bison (instead of yacc) or a better sed.
                   6318:
                   6319: The tools used by a package can be listed by running make show-tools.
                   6320:
1.107     rillig   6321: 18.1. Tools for pkgsrc builds
1.68      rillig   6322:
                   6323: The default set of tools used by pkgsrc is defined in bsd.pkg.mk. This includes
                   6324: standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be
                   6325: seen by running: make show-var VARNAME=USE_TOOLS.
                   6326:
                   6327: If a package needs a specific program to build then the USE_TOOLS variable can
                   6328: be used to define the tools needed.
                   6329:
1.107     rillig   6330: 18.2. Tools needed by packages
1.68      rillig   6331:
                   6332: In the following examples, the :pkgsrc means to use the pkgsrc version and not
                   6333: the native version for a build dependency. And the :run means that it is used
                   6334: for a run-time dependencies also (and becomes a DEPENDS). The default is a
                   6335: build dependency which can be set with :build. (So in this example, it is the
                   6336: same as gmake:build and pkg-config:build.)
                   6337:
                   6338: USE_TOOLS+=     mktemp:pkgsrc
                   6339: USE_TOOLS+=     gmake perl:run pkg-config
                   6340:
                   6341: When using the tools framework, a TOOLS_PATH.foo variable is defined which
                   6342: contains the full path to the appropriate tool. For example, TOOLS_PATH.bash
                   6343: could be "/bin/bash" on Linux systems.
                   6344:
                   6345: If you always need a pkgsrc version of the tool at run-time, then just use
                   6346: DEPENDS instead.
                   6347:
1.107     rillig   6348: 18.3. Tools provided by platforms
1.68      rillig   6349:
                   6350: When improving or porting pkgsrc to a new platform, have a look at (or create)
                   6351: the corresponding platform specific make file fragment under pkgsrc/mk/tools/
                   6352: tools.${OPSYS}.mk which defines the name of the common tools. For example:
                   6353:
                   6354: .if exists(/usr/bin/bzcat)
                   6355: TOOLS_PLATFORM.bzcat?=          /usr/bin/bzcat
                   6356: .elif exists(/usr/bin/bzip2)
                   6357: TOOLS_PLATFORM.bzcat?=          /usr/bin/bzip2 -cd
                   6358: .endif
                   6359:
                   6360: TOOLS_PLATFORM.true?=           true                    # shell builtin
                   6361:
1.107     rillig   6362: 18.4. Questions regarding the tools
1.98      rillig   6363:
1.107     rillig   6364: 18.4.1. How do I add a new tool?
                   6365: 18.4.2. How do I get a list of all available tools?
                   6366: 18.4.3. How can I get a list of all the tools that a package is using while
1.98      rillig   6367:     being built? I want to know whether it uses sed or not.
                   6368:
1.107     rillig   6369: 18.4.1. How do I add a new tool?
1.98      rillig   6370:
                   6371:         TODO
                   6372:
1.107     rillig   6373: 18.4.2. How do I get a list of all available tools?
1.98      rillig   6374:
                   6375:         TODO
                   6376:
1.107     rillig   6377: 18.4.3. How can I get a list of all the tools that a package is using while
1.98      rillig   6378:         being built? I want to know whether it uses sed or not.
                   6379:
                   6380:         Currently, you can't. (TODO: But I want to be able to do it.)
                   6381:
1.107     rillig   6382: Chapter 19. Making your package work
1.1       grant    6383:
                   6384: Table of Contents
                   6385:
1.107     rillig   6386: 19.1. General operation
1.20      ben      6387:
1.107     rillig   6388:     19.1.1. Portability of packages
1.130     wiz      6389:     19.1.2. How to pull in user-settable variables from mk.conf
1.107     rillig   6390:     19.1.3. User interaction
                   6391:     19.1.4. Handling licenses
                   6392:     19.1.5. Restricted packages
                   6393:     19.1.6. Handling dependencies
                   6394:     19.1.7. Handling conflicts with other packages
                   6395:     19.1.8. Packages that cannot or should not be built
                   6396:     19.1.9. Packages which should not be deleted, once installed
                   6397:     19.1.10. Handling packages with security problems
                   6398:     19.1.11. How to handle incrementing versions when fixing an existing
1.31      wiz      6399:         package
1.107     rillig   6400:     19.1.12. Substituting variable text in the package files (the SUBST
1.79      rillig   6401:         framework)
1.77      rillig   6402:
1.107     rillig   6403: 19.2. Fixing problems in the fetch phase
1.77      rillig   6404:
1.107     rillig   6405:     19.2.1. Packages whose distfiles aren't available for plain downloading
                   6406:     19.2.2. How to handle modified distfiles with the 'old' name
1.77      rillig   6407:
1.107     rillig   6408: 19.3. Fixing problems in the configure phase
1.77      rillig   6409:
1.107     rillig   6410:     19.3.1. Shared libraries - libtool
                   6411:     19.3.2. Using libtool on GNU packages that already support libtool
                   6412:     19.3.3. GNU Autoconf/Automake
                   6413:
                   6414: 19.4. Programming languages
                   6415:
                   6416:     19.4.1. C, C++, and Fortran
                   6417:     19.4.2. Java
                   6418:     19.4.3. Packages containing perl scripts
                   6419:     19.4.4. Other programming languages
                   6420:
                   6421: 19.5. Fixing problems in the build phase
                   6422:
                   6423:     19.5.1. Compiling C and C++ code conditionally
                   6424:     19.5.2. How to handle compiler bugs
1.130     wiz      6425:     19.5.3. Undefined reference to "..."
1.107     rillig   6426:     19.5.4. Running out of memory
                   6427:
                   6428: 19.6. Fixing problems in the install phase
                   6429:
                   6430:     19.6.1. Creating needed directories
                   6431:     19.6.2. Where to install documentation
                   6432:     19.6.3. Installing highscore files
                   6433:     19.6.4. Adding DESTDIR support to packages
                   6434:     19.6.5. Packages with hardcoded paths to other interpreters
                   6435:     19.6.6. Packages installing perl modules
                   6436:     19.6.7. Packages installing info files
                   6437:     19.6.8. Packages installing man pages
1.108     rillig   6438:     19.6.9. Packages installing GConf data files
1.120     mishka   6439:     19.6.10. Packages installing scrollkeeper/rarian data files
1.107     rillig   6440:     19.6.11. Packages installing X11 fonts
                   6441:     19.6.12. Packages installing GTK2 modules
                   6442:     19.6.13. Packages installing SGML or XML data
                   6443:     19.6.14. Packages installing extensions to the MIME database
                   6444:     19.6.15. Packages using intltool
                   6445:     19.6.16. Packages installing startup scripts
                   6446:     19.6.17. Packages installing TeX modules
                   6447:     19.6.18. Packages supporting running binaries in emulation
                   6448:     19.6.19. Packages installing hicolor theme icons
                   6449:     19.6.20. Packages installing desktop files
1.87      wiz      6450:
1.107     rillig   6451: 19.7. Marking packages as having problems
1.25      rillig   6452:
1.107     rillig   6453: 19.1. General operation
1.78      rillig   6454:
1.107     rillig   6455: 19.1.1. Portability of packages
1.78      rillig   6456:
                   6457: One appealing feature of pkgsrc is that it runs on many different platforms. As
                   6458: a result, it is important to ensure, where possible, that packages in pkgsrc
                   6459: are portable. This chapter mentions some particular details you should pay
                   6460: attention to while working on pkgsrc.
                   6461:
1.107     rillig   6462: 19.1.2. How to pull in user-settable variables from mk.conf
1.78      rillig   6463:
                   6464: The pkgsrc user can configure pkgsrc by overriding several variables in the
1.105     rillig   6465: file pointed to by MAKECONF, which is mk.conf by default. When you want to use
                   6466: those variables in the preprocessor directives of make(1) (for example .if or
                   6467: .for), you need to include the file ../../mk/bsd.prefs.mk before, which in turn
                   6468: loads the user preferences.
1.78      rillig   6469:
                   6470: But note that some variables may not be completely defined after ../../mk/
                   6471: bsd.prefs.mk has been included, as they may contain references to variables
                   6472: that are not yet defined. In shell commands this is no problem, since variables
                   6473: are actually macros, which are only expanded when they are used. But in the
                   6474: preprocessor directives mentioned above and in dependency lines (of the form
                   6475: target: dependencies) the variables are expanded at load time.
                   6476:
                   6477: Note
                   6478:
                   6479: Currently there is no exhaustive list of all variables that tells you whether
                   6480: they can be used at load time or only at run time, but it is in preparation.
                   6481:
1.107     rillig   6482: 19.1.3. User interaction
1.78      rillig   6483:
                   6484: Occasionally, packages require interaction from the user, and this can be in a
                   6485: number of ways:
                   6486:
1.79      rillig   6487:   * When fetching the distfiles, some packages require user interaction such as
                   6488:     entering username/password or accepting a license on a web page.
                   6489:
1.78      rillig   6490:   * When extracting the distfiles, some packages may ask for passwords.
1.20      ben      6491:
1.78      rillig   6492:   * help to configure the package before it is built
                   6493:
                   6494:   * help during the build process
                   6495:
                   6496:   * help during the installation of a package
1.1       grant    6497:
1.78      rillig   6498: The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of
                   6499: an interactive stage which will be needed, and this should be set in the
                   6500: package's Makefile, e.g.:
                   6501:
1.101     rillig   6502: INTERACTIVE_STAGE=      build
1.87      wiz      6503:
1.78      rillig   6504:
                   6505: Multiple interactive stages can be specified:
                   6506:
1.101     rillig   6507: INTERACTIVE_STAGE=      configure install
1.87      wiz      6508:
1.1       grant    6509:
1.88      wiz      6510: The user can then decide to skip this package by setting the BATCH variable.
                   6511:
1.107     rillig   6512: 19.1.4. Handling licenses
1.1       grant    6513:
1.99      wiz      6514: Authors of software can choose the licence under which software can be copied.
                   6515: This is due to copyright law, and reasons for license choices are outside the
                   6516: scope of pkgsrc. The pkgsrc system recognizes that there are a number of
                   6517: licenses which some users may find objectionable or difficult or impossible to
                   6518: comply with. The Free Software Foundation has declared some licenses "Free",
                   6519: and the Open Source Initiative has a definition of "Open Source". The pkgsrc
                   6520: system, as a policy choice, does not label packages which have licenses that
                   6521: are Free or Open Source. However, packages without a license meeting either of
                   6522: those tests are labeled with a license tag denoting the license. Note that a
                   6523: package with no license to copy trivially does not meet either the Free or Open
                   6524: Source test.
                   6525:
                   6526: For packages which are not Free or Open Source, pkgsrc will not build the
                   6527: package unless the user has indicated to pkgsrc that packages with that
                   6528: particular license may be built. Note that this documentation avoids the term
                   6529: "accepted the license". The pkgsrc system is merely providing a mechanism to
1.100     rillig   6530: avoid accidentally building a package with a non-free license; judgement and
1.99      wiz      6531: responsibility remain with the user. (Installation of binary packages are not
                   6532: currently subject to this mechanism; this is a bug.)
                   6533:
                   6534: One might want to only install packages with a BSD license, or the GPL, and not
1.122     jnemeth  6535: the other. The free licenses are added to the default ACCEPTABLE_LICENSES
                   6536: variable. The user can override the default by setting the ACCEPTABLE_LICENSES
                   6537: variable with "=" instead of "+=". The licenses accepted by default are:
                   6538:
                   6539:     public-domain
                   6540:     gnu-gpl-v2 gnu-lgpl-v2
                   6541:     gnu-gpl-v3 gnu-lgpl-v3
                   6542:     original-bsd modified-bsd
                   6543:     x11
                   6544:     apache-2.0
                   6545:     cddl-1.0
                   6546:     open-font-license
                   6547:
1.1       grant    6548:
1.78      rillig   6549: The license tag mechanism is intended to address copyright-related issues
                   6550: surrounding building, installing and using a package, and not to address
1.122     jnemeth  6551: redistribution issues (see RESTRICTED and NO_SRC_ON_FTP, etc.). Packages with
                   6552: redistribution restrictions should set these tags.
1.20      ben      6553:
1.99      wiz      6554: Denoting that a package may be copied according to a particular license is done
                   6555: by placing the license in pkgsrc/licenses and setting the LICENSE variable to a
                   6556: string identifying the license, e.g. in graphics/xv:
1.1       grant    6557:
1.101     rillig   6558: LICENSE=        xv-license
1.87      wiz      6559:
1.1       grant    6560:
1.78      rillig   6561: When trying to build, the user will get a notice that the package is covered by
1.99      wiz      6562: a license which has not been placed in the ACCEPTABLE_LICENSES variable:
1.1       grant    6563:
1.101     rillig   6564: % make
                   6565: ===> xv-3.10anb9 has an unacceptable license: xv-license.
                   6566: ===>     To view the license, enter "/usr/bin/make show-license".
                   6567: ===>     To indicate acceptance, add this line to your /etc/mk.conf:
                   6568: ===>     ACCEPTABLE_LICENSES+=xv-license
                   6569: *** Error code 1
1.87      wiz      6570:
1.78      rillig   6571:
1.99      wiz      6572: The license can be viewed with make show-license, and if the user so chooses,
1.105     rillig   6573: the line printed above can be added to mk.conf to convey to pkgsrc that it
1.99      wiz      6574: should not in the future fail because of that license:
1.78      rillig   6575:
1.101     rillig   6576: ACCEPTABLE_LICENSES+=xv-license
1.87      wiz      6577:
1.1       grant    6578:
1.78      rillig   6579: When adding a package with a new license, the license text should be added to
                   6580: pkgsrc/licenses for displaying. A list of known licenses can be seen in this
1.91      rillig   6581: directory.
1.31      wiz      6582:
1.99      wiz      6583: When the license changes (in a way other than formatting), please make sure
                   6584: that the new license has a different name (e.g., append the version number if
                   6585: it exists, or the date). Just because a user told pkgsrc to build programs
                   6586: under a previous version of a license does not mean that pkgsrc should build
1.100     rillig   6587: programs under the new licenses. The higher-level point is that pkgsrc does not
1.99      wiz      6588: evaluate licenses for reasonableness; the only test is a mechanistic test of
                   6589: whether a particular text has been approved by either of two bodies.
                   6590:
1.78      rillig   6591: The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar language
                   6592: is deprecated because it does not crisply refer to a particular license text.
1.99      wiz      6593: Another problem with such usage is that it does not enable a user to tell
                   6594: pkgsrc to proceed for a single package without also telling pkgsrc to proceed
                   6595: for all packages with that tag.
1.31      wiz      6596:
1.107     rillig   6597: 19.1.5. Restricted packages
1.1       grant    6598:
1.99      wiz      6599: Some licenses restrict how software may be re-distributed. Because a license
                   6600: tag is required unless the package is Free or Open Source, all packages with
                   6601: restrictions should have license tags. By declaring the restrictions, package
                   6602: tools can automatically refrain from e.g. placing binary packages on FTP sites.
                   6603:
                   6604: There are four restrictions that may be encoded, which are the cross product of
                   6605: sources (distfiles) and binaries not being placed on FTP sites and CD-ROMs.
                   6606: Because this is rarely the exact language in any license, and because non-Free
                   6607: licenses tend to be different from each other, pkgsrc adopts a definition of
                   6608: FTP and CD-ROM. Pkgsrc uses "FTP" to mean that the source or binary file should
                   6609: not be made available over the Internet at no charge. Pkgsrc uses "CD-ROM" to
                   6610: mean that the source or binary may not be made available on some kind of media,
                   6611: together with other source and binary packages, and which is sold for a
                   6612: distribution charge.
                   6613:
                   6614: In order to encode these restrictions, the package system defines five make
                   6615: variables that can be set to note these restrictions:
1.1       grant    6616:
                   6617:   * RESTRICTED
1.20      ben      6618:
1.1       grant    6619:     This variable should be set whenever a restriction exists (regardless of
                   6620:     its kind). Set this variable to a string containing the reason for the
1.99      wiz      6621:     restriction. It should be understood that those wanting to understand the
                   6622:     restriction will have to read the license, and perhaps seek advice of
                   6623:     counsel.
1.20      ben      6624:
1.1       grant    6625:   * NO_BIN_ON_CDROM
1.20      ben      6626:
1.99      wiz      6627:     Binaries may not be placed on CD-ROM containing other binary packages, for
                   6628:     which a distribution charge may be made. In this case, set this variable to
                   6629:     ${RESTRICTED}.
1.20      ben      6630:
1.1       grant    6631:   * NO_BIN_ON_FTP
1.20      ben      6632:
1.99      wiz      6633:     Binaries may not made available on the Internet without charge. In this
                   6634:     case, set this variable to ${RESTRICTED}. If this variable is set, binary
                   6635:     packages will not be included on ftp.NetBSD.org.
1.20      ben      6636:
1.1       grant    6637:   * NO_SRC_ON_CDROM
1.20      ben      6638:
1.99      wiz      6639:     Distfiles may not be placed on CD-ROM, together with other distfiles, for
                   6640:     which a fee may be charged. In this case, set this variable to $
                   6641:     {RESTRICTED}.
1.20      ben      6642:
1.1       grant    6643:   * NO_SRC_ON_FTP
1.20      ben      6644:
1.99      wiz      6645:     Distfiles may not made available via FTP at no charge. In this case, set
                   6646:     this variable to ${RESTRICTED}. If this variable is set, the distfile(s)
                   6647:     will not be mirrored on ftp.NetBSD.org.
1.20      ben      6648:
1.107     rillig   6649: 19.1.6. Handling dependencies
1.1       grant    6650:
                   6651: Your package may depend on some other package being present - and there are
                   6652: various ways of expressing this dependency. pkgsrc supports the BUILD_DEPENDS
1.47      reed     6653: and DEPENDS definitions, the USE_TOOLS definition, as well as dependencies via
                   6654: buildlink3.mk, which is the preferred way to handle dependencies, and which
1.107     rillig   6655: uses the variables named above. See Chapter 14, Buildlink methodology for more
1.47      reed     6656: information.
1.1       grant    6657:
                   6658: The basic difference between the two variables is as follows: The DEPENDS
                   6659: definition registers that pre-requisite in the binary package so it will be
                   6660: pulled in when the binary package is later installed, whilst the BUILD_DEPENDS
                   6661: definition does not, marking a dependency that is only needed for building the
                   6662: package.
                   6663:
                   6664: This means that if you only need a package present whilst you are building, it
                   6665: should be noted as a BUILD_DEPENDS.
                   6666:
                   6667: The format for a BUILD_DEPENDS and a DEPENDS definition is:
                   6668:
1.101     rillig   6669: <pre-req-package-name>:../../<category>/<pre-req-package>
1.87      wiz      6670:
1.1       grant    6671:
                   6672: Please note that the "pre-req-package-name" may include any of the wildcard
1.18      xtraeme  6673: version numbers recognized by pkg_info(1).
1.1       grant    6674:
                   6675:  1. If your package needs another package's binaries or libraries to build or
                   6676:     run, and if that package has a buildlink3.mk file available, use it:
1.20      ben      6677:
1.101     rillig   6678:     .include "../../graphics/jpeg/buildlink3.mk"
1.87      wiz      6679:
1.20      ben      6680:
1.134     spz      6681:  2. If your package needs binaries from another package to build, use the
                   6682:     BUILD_DEPENDS definition:
1.20      ben      6683:
1.134     spz      6684:     BUILD_DEPENDS+= scons-[0-9]*:../../devel/scons
1.87      wiz      6685:
1.20      ben      6686:
1.134     spz      6687:  3. If your package needs a library with which to link and there is no
                   6688:     buildlink3.mk file available, create one. Using DEPENDS won't be sufficient
                   6689:     because the include files and libraries will be hidden from the compiler.
1.20      ben      6690:
1.134     spz      6691:  4. If your package needs some executable to be able to run correctly and if
                   6692:     there's no buildlink3.mk file, this is specified using the DEPENDS
                   6693:     variable. The print/lyx package needs to be able to execute the latex
                   6694:     binary from the teTeX package when it runs, and that is specified:
1.87      wiz      6695:
1.134     spz      6696:     DEPENDS+=        teTeX-[0-9]*:../../print/teTeX
1.87      wiz      6697:
1.20      ben      6698:
1.134     spz      6699:  5. You can use wildcards in package dependencies. Note that such wildcard
                   6700:     dependencies are retained when creating binary packages. The dependency is
                   6701:     checked when installing the binary package and any package which matches
                   6702:     the pattern will be used. Wildcard dependencies should be used with care.
1.20      ben      6703:
1.1       grant    6704:     The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
                   6705:     matches such as "tk-postgresql" matching a "tk-*" DEPENDS.
1.20      ben      6706:
1.1       grant    6707:     Wildcards can also be used to specify that a package will only build
                   6708:     against a certain minimum version of a pre-requisite:
1.20      ben      6709:
1.134     spz      6710:     DEPENDS+=       ImageMagick>=6.0:../../graphics/ImageMagick
1.87      wiz      6711:
1.20      ben      6712:
1.134     spz      6713:     This means that the package will build using version 6.0 of ImageMagick or
                   6714:     newer. Such a dependency may be warranted if, for example, the command line
                   6715:     options of an executable have changed.
                   6716:
                   6717:     If you need to depend on minimum versions of libraries, see the buildlink
                   6718:     section of the pkgsrc guide.
1.20      ben      6719:
1.72      rillig   6720:     For security fixes, please update the package vulnerabilities file. See
1.107     rillig   6721:     Section 19.1.10, "Handling packages with security problems" for more
1.72      rillig   6722:     information.
1.20      ben      6723:
1.71      wiz      6724: If your package needs files from another package to build, add the relevant
                   6725: distribution files to DISTFILES, so they will be extracted automatically. See
                   6726: the print/ghostscript package for an example. (It relies on the jpeg sources
                   6727: being present in source form during the build.)
1.1       grant    6728:
1.107     rillig   6729: 19.1.7. Handling conflicts with other packages
1.1       grant    6730:
                   6731: Your package may conflict with other packages a user might already have
1.88      wiz      6732: installed on his system, e.g. if your package installs the same set of files as
                   6733: another package in the pkgsrc tree.
1.1       grant    6734:
1.47      reed     6735: In this case you can set CONFLICTS to a space-separated list of packages
1.1       grant    6736: (including version string) your package conflicts with.
                   6737:
1.47      reed     6738: For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus
                   6739: you set in pkgsrc/x11/Xaw3d/Makefile:
1.1       grant    6740:
1.101     rillig   6741: CONFLICTS=      Xaw-Xpm-[0-9]*
1.87      wiz      6742:
1.1       grant    6743:
                   6744: and in pkgsrc/x11/Xaw-Xpm/Makefile:
                   6745:
1.101     rillig   6746: CONFLICTS=      Xaw3d-[0-9]*
1.87      wiz      6747:
1.1       grant    6748:
                   6749: Packages will automatically conflict with other packages with the name prefix
                   6750: and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
                   6751: with the older version "Xaw3d-1.3".
                   6752:
1.107     rillig   6753: 19.1.8. Packages that cannot or should not be built
1.1       grant    6754:
                   6755: There are several reasons why a package might be instructed to not build under
                   6756: certain circumstances. If the package builds and runs on most platforms, the
                   6757: exceptions should be noted with NOT_FOR_PLATFORM. If the package builds and
1.45      wiz      6758: runs on a small handful of platforms, set ONLY_FOR_PLATFORM instead. Both
                   6759: ONLY_FOR_PLATFORM and NOT_FOR_PLATFORM are OS triples (OS-version-platform)
                   6760: that can use glob-style wildcards.
                   6761:
1.88      wiz      6762: Some packages are tightly bound to a specific version of an operating system,
                   6763: e.g. LKMs or sysutils/lsof. Such binary packages are not backwards compatible
                   6764: with other versions of the OS, and should be uploaded to a version specific
                   6765: directory on the FTP server. Mark these packages by setting OSVERSION_SPECIFIC
                   6766: to "yes". This variable is not currently used by any of the package system
                   6767: internals, but may be used in the future.
                   6768:
1.45      wiz      6769: If the package should be skipped (for example, because it provides
                   6770: functionality already provided by the system), set PKG_SKIP_REASON to a
                   6771: descriptive message. If the package should fail because some preconditions are
                   6772: not met, set PKG_FAIL_REASON to a descriptive message.
1.1       grant    6773:
1.107     rillig   6774: 19.1.9. Packages which should not be deleted, once installed
1.1       grant    6775:
                   6776: To ensure that a package may not be deleted, once it has been installed, the
                   6777: PKG_PRESERVE definition should be set in the package Makefile. This will be
1.132     wiz      6778: carried into any binary package that is made from this pkgsrc entry. A "
                   6779: preserved" package will not be deleted using pkg_delete(1) unless the "-f"
1.1       grant    6780: option is used.
                   6781:
1.107     rillig   6782: 19.1.10. Handling packages with security problems
1.1       grant    6783:
                   6784: When a vulnerability is found, this should be noted in localsrc/security/
1.43      wiz      6785: advisories/pkg-vulnerabilities, and after committing that file, use make upload
                   6786: in the same directory to update the file on ftp.NetBSD.org.
                   6787:
                   6788: After fixing the vulnerability by a patch, its PKGREVISION should be increased
                   6789: (this is of course not necessary if the problem is fixed by using a newer
1.72      rillig   6790: release of the software).
1.1       grant    6791:
                   6792: Also, if the fix should be applied to the stable pkgsrc branch, be sure to
                   6793: submit a pullup request!
                   6794:
1.43      wiz      6795: Binary packages already on ftp.NetBSD.org will be handled semi-automatically by
                   6796: a weekly cron job.
                   6797:
1.107     rillig   6798: 19.1.11. How to handle incrementing versions when fixing an existing package
1.1       grant    6799:
                   6800: When making fixes to an existing package it can be useful to change the version
                   6801: number in PKGNAME. To avoid conflicting with future versions by the original
                   6802: author, a "nb1", "nb2", ... suffix can be used on package versions by setting
1.87      wiz      6803: PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools.
                   6804: e.g.
1.1       grant    6805:
1.101     rillig   6806: DISTNAME=       foo-17.42
                   6807: PKGREVISION=    9
1.1       grant    6808:
1.87      wiz      6809:
                   6810: will result in a PKGNAME of "foo-17.42nb9". If you want to use the original
                   6811: value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use
                   6812: PKGNAME_NOREV.
1.1       grant    6813:
                   6814: When a new release of the package is released, the PKGREVISION should be
1.47      reed     6815: removed, e.g. on a new minor release of the above package, things should be
1.1       grant    6816: like:
                   6817:
1.101     rillig   6818: DISTNAME=       foo-17.43
1.87      wiz      6819:
1.1       grant    6820:
1.78      rillig   6821: PKGREVISION should be incremented for any non-trivial change in the resulting
                   6822: binary package. Without a PKGREVISION bump, someone with the previous version
                   6823: installed has no way of knowing that their package is out of date. Thus,
                   6824: changes without increasing PKGREVISION are essentially labeled "this is so
                   6825: trivial that no reasonable person would want to upgrade", and this is the rough
                   6826: test for when increasing PKGREVISION is appropriate. Examples of changes that
                   6827: do not merit increasing PKGREVISION are:
                   6828:
1.115     jmcneill 6829:   * Changing HOMEPAGE, MAINTAINER, OWNER, or comments in Makefile.
1.101     rillig   6830:
                   6831:   * Changing build variables if the resulting binary package is the same.
1.87      wiz      6832:
1.101     rillig   6833:   * Changing DESCR.
                   6834:
                   6835:   * Adding PKG_OPTIONS if the default options don't change.
1.78      rillig   6836:
                   6837: Examples of changes that do merit an increase to PKGREVISION include:
                   6838:
1.101     rillig   6839:   * Security fixes
                   6840:
                   6841:   * Changes or additions to a patch file
1.87      wiz      6842:
1.101     rillig   6843:   * Changes to the PLIST
1.1       grant    6844:
1.113     weinem   6845:   * A dependency is changed or renamed.
                   6846:
1.78      rillig   6847: PKGREVISION must also be incremented when dependencies have ABI changes.
1.1       grant    6848:
1.107     rillig   6849: 19.1.12. Substituting variable text in the package files (the SUBST framework)
1.79      rillig   6850:
                   6851: When you want to replace the same text in multiple files or when the
                   6852: replacement text varies, patches alone cannot help. This is where the SUBST
                   6853: framework comes in. It provides an easy-to-use interface for replacing text in
                   6854: files. Example:
                   6855:
1.101     rillig   6856: SUBST_CLASSES+=                 fix-paths
                   6857: SUBST_STAGE.fix-paths=          pre-configure
                   6858: SUBST_MESSAGE.fix-paths=        Fixing absolute paths.
                   6859: SUBST_FILES.fix-paths=          src/*.c
                   6860: SUBST_FILES.fix-paths+=         scripts/*.sh
                   6861: SUBST_SED.fix-paths=            -e 's,"/usr/local,"${PREFIX},g'
                   6862: SUBST_SED.fix-paths+=           -e 's,"/var/log,"${VARBASE}/log,g'
1.87      wiz      6863:
1.79      rillig   6864:
                   6865: SUBST_CLASSES is a list of identifiers that are used to identify the different
                   6866: SUBST blocks that are defined. The SUBST framework is heavily used by pkgsrc,
                   6867: so it is important to always use the += operator with this variable. Otherwise
                   6868: some substitutions may be skipped.
                   6869:
                   6870: The remaining variables of each SUBST block are parameterized with the
                   6871: identifier from the first line (fix-paths in this case.) They can be seen as
                   6872: parameters to a function call.
                   6873:
                   6874: SUBST_STAGE.* specifies the stage at which the replacement will take place. All
                   6875: combinations of pre-, do- and post- together with a phase name are possible,
                   6876: though only few are actually used. Most commonly used are post-patch and
                   6877: pre-configure. Of these two, pre-configure should be preferred because then it
                   6878: is possible to run bmake patch and have the state after applying the patches
                   6879: but before making any other changes. This is especially useful when you are
                   6880: debugging a package in order to create new patches for it. Similarly,
                   6881: post-build is preferred over pre-install, because the install phase should
                   6882: generally be kept as simple as possible. When you use post-build, you have the
                   6883: same files in the working directory that will be installed later, so you can
                   6884: check if the substitution has succeeded.
                   6885:
                   6886: SUBST_MESSAGE.* is an optional text that is printed just before the
                   6887: substitution is done.
                   6888:
                   6889: SUBST_FILES.* is the list of shell globbing patterns that specifies the files
                   6890: in which the substitution will take place. The patterns are interpreted
                   6891: relatively to the WRKSRC directory.
                   6892:
                   6893: SUBST_SED.* is a list of arguments to sed(1) that specify the actual
                   6894: substitution. Every sed command should be prefixed with -e, so that all SUBST
                   6895: blocks look uniform.
                   6896:
                   6897: There are some more variables, but they are so seldomly used that they are only
1.80      rillig   6898: documented in the mk/subst.mk file.
1.79      rillig   6899:
1.107     rillig   6900: 19.2. Fixing problems in the fetch phase
1.1       grant    6901:
1.107     rillig   6902: 19.2.1. Packages whose distfiles aren't available for plain downloading
1.1       grant    6903:
                   6904: If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
                   6905: a make fetch will call files/getsite.sh with the name of each file to download
                   6906: as an argument, expecting it to output the URL of the directory from which to
                   6907: download it. graphics/ns-cult3d is an example of this usage.
                   6908:
                   6909: If the download can't be automated, because the user must submit personal
                   6910: information to apply for a password, or must pay for the source, or whatever,
1.74      rillig   6911: you can set FETCH_MESSAGE to a list of lines that are displayed to the user
                   6912: before aborting the build. Example:
                   6913:
1.101     rillig   6914: FETCH_MESSAGE=  "Please download the files"
                   6915: FETCH_MESSAGE+= "    "${DISTFILES:Q}
                   6916: FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
1.87      wiz      6917:
1.1       grant    6918:
1.107     rillig   6919: 19.2.2. How to handle modified distfiles with the 'old' name
1.1       grant    6920:
                   6921: Sometimes authors of a software package make some modifications after the
                   6922: software was released, and they put up a new distfile without changing the
                   6923: package's version number. If a package is already in pkgsrc at that time, the
1.32      wiz      6924: checksum will no longer match. The contents of the new distfile should be
                   6925: compared against the old one before changing anything, to make sure the
1.1       grant    6926: distfile was really updated on purpose, and that no trojan horse or so crept
1.97      wiz      6927: in. Please mention that the distfiles were compared and what was found in your
                   6928: commit message. Then, the correct way to work around this is to set DIST_SUBDIR
                   6929: to a unique directory name, usually based on PKGNAME_NOREV. All DISTFILES and
                   6930: PATCHFILES for this package will be put in that subdirectory of the local
1.107     rillig   6931: distfiles directory. (See Section 19.1.11, "How to handle incrementing versions
1.97      wiz      6932: when fixing an existing package" for more details.) In case this happens more
                   6933: often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can
                   6934: be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget regenerating the
                   6935: distinfo file after that, since it contains the DIST_SUBDIR path in the
                   6936: filenames. Also increase the PKGREVISION if the installed package is different.
                   6937: Furthermore, a mail to the package's authors seems appropriate telling them
                   6938: that changing distfiles after releases without changing the file names is not
                   6939: good practice.
1.1       grant    6940:
1.107     rillig   6941: 19.3. Fixing problems in the configure phase
1.1       grant    6942:
1.107     rillig   6943: 19.3.1. Shared libraries - libtool
1.1       grant    6944:
                   6945: pkgsrc supports many different machines, with different object formats like
                   6946: a.out and ELF, and varying abilities to do shared library and dynamic loading
                   6947: at all. To accompany this, varying commands and options have to be passed to
                   6948: the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
1.20      ben      6949: especially if you don't have all the machines at your hand to test things. The
1.1       grant    6950: devel/libtool pkg can help here, as it just "knows" how to build both static
1.47      reed     6951: and dynamic libraries from a set of source files, thus being
                   6952: platform-independent.
1.1       grant    6953:
1.87      wiz      6954: Here's how to use libtool in a package in seven simple steps:
1.1       grant    6955:
                   6956:  1. Add USE_LIBTOOL=yes to the package Makefile.
1.20      ben      6957:
1.1       grant    6958:  2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
                   6959:     {CC}". You could even add it to the definition of CC, if only libraries are
                   6960:     being built in a given Makefile. This one command will build both PIC and
                   6961:     non-PIC library objects, so you need not have separate shared and
                   6962:     non-shared library rules.
1.20      ben      6963:
1.1       grant    6964:  3. For the linking of the library, remove any "ar", "ranlib", and "ld
                   6965:     -Bshareable" commands, and instead use:
1.20      ben      6966:
1.101     rillig   6967:     ${LIBTOOL} --mode=link \
                   6968:         ${CC} -o ${.TARGET:.a=.la} \
                   6969:             ${OBJS:.o=.lo} \
                   6970:             -rpath ${PREFIX}/lib \
                   6971:             -version-info major:minor
1.87      wiz      6972:
1.20      ben      6973:
1.1       grant    6974:     Note that the library is changed to have a .la extension, and the objects
                   6975:     are changed to have a .lo extension. Change OBJS as necessary. This
                   6976:     automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
                   6977:     necessary) in the build directory. Be sure to include "-version-info",
                   6978:     especially when major and minor are zero, as libtool will otherwise strip
                   6979:     off the shared library version.
1.20      ben      6980:
1.1       grant    6981:     From the libtool manual:
1.20      ben      6982:
1.101     rillig   6983:     So, libtool library versions are described by three integers:
1.87      wiz      6984:
1.101     rillig   6985:     CURRENT
                   6986:     The most recent interface number that this library implements.
1.20      ben      6987:
1.101     rillig   6988:     REVISION
                   6989:     The implementation number of the CURRENT interface.
1.20      ben      6990:
1.101     rillig   6991:     AGE
                   6992:     The difference between the newest and oldest interfaces that
                   6993:     this library implements.  In other words, the library implements
                   6994:     all the interface numbers in the range from number `CURRENT -
                   6995:     AGE' to `CURRENT'.
1.20      ben      6996:
1.101     rillig   6997:     If two libraries have identical CURRENT and AGE numbers, then the
                   6998:     dynamic linker chooses the library with the greater REVISION number.
1.20      ben      6999:
                   7000:
1.1       grant    7001:     The "-release" option will produce different results for a.out and ELF
1.132     wiz      7002:     (excluding symlinks) in only one case. An ELF library of the form "
                   7003:     libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
1.1       grant    7004:     platform. This is handled automatically.
1.20      ben      7005:
1.1       grant    7006:     The "-rpath argument" is the install directory of the library being built.
1.20      ben      7007:
1.19      hubertf  7008:     In the PLIST, include only the .la file, the other files will be added
                   7009:     automatically.
1.20      ben      7010:
1.1       grant    7011:  4. When linking shared object (.so) files, i.e. files that are loaded via
                   7012:     dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
                   7013:     them getting version tacked on.
1.20      ben      7014:
1.1       grant    7015:     The PLIST file gets the foo.so entry.
1.20      ben      7016:
1.1       grant    7017:  5. When linking programs that depend on these libraries before they are
                   7018:     installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
                   7019:     and it will find the correct libraries (static or shared), but please be
                   7020:     aware that libtool will not allow you to specify a relative path in -L
                   7021:     (such as "-L../somelib"), because it expects you to change that argument to
                   7022:     be the .la file. e.g.
1.20      ben      7023:
1.101     rillig   7024:     ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
1.87      wiz      7025:
1.20      ben      7026:
1.1       grant    7027:     should be changed to:
1.20      ben      7028:
1.101     rillig   7029:     ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
1.87      wiz      7030:
1.20      ben      7031:
1.1       grant    7032:     and it will do the right thing with the libraries.
1.20      ben      7033:
1.1       grant    7034:  6. When installing libraries, preface the install(1) or cp(1) command with "$
                   7035:     {LIBTOOL} --mode=install", and change the library name to .la. e.g.
1.20      ben      7036:
1.128     jakllsch 7037:     ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
1.87      wiz      7038:
1.20      ben      7039:
1.1       grant    7040:     This will install the static .a, shared library, any needed symlinks, and
                   7041:     run ldconfig(8).
1.20      ben      7042:
1.23      wiz      7043:  7. In your PLIST, include only the .la file (this is a change from previous
                   7044:     behaviour).
1.20      ben      7045:
1.107     rillig   7046: 19.3.2. Using libtool on GNU packages that already support libtool
1.1       grant    7047:
                   7048: Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
                   7049: own libtool in most cases. For older libtool using packages, libtool is made by
                   7050: ltconfig script during the do-configure step; you can check the libtool script
                   7051: location by doing make configure; find work*/ -name libtool.
                   7052:
                   7053: LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
                   7054: override. By default, it is set to "libtool */libtool */*/libtool". If this
                   7055: does not match the location of the package's libtool script(s), set it as
                   7056: appropriate.
                   7057:
                   7058: If you do not need *.a static libraries built and installed, then use
                   7059: SHLIBTOOL_OVERRIDE instead.
                   7060:
1.47      reed     7061: If your package makes use of the platform-independent library for loading
1.1       grant    7062: dynamic shared objects, that comes with libtool (libltdl), you should include
1.22      tv       7063: devel/libltdl/buildlink3.mk.
1.1       grant    7064:
                   7065: Some packages use libtool incorrectly so that the package may not work or build
                   7066: in some circumstances. Some of the more common errors are:
                   7067:
                   7068:   * The inclusion of a shared object (-module) as a dependent library in an
                   7069:     executable or library. This in itself isn't a problem if one of two things
                   7070:     has been done:
1.20      ben      7071:
1.1       grant    7072:      1. The shared object is named correctly, i.e. libfoo.la, not foo.la
1.20      ben      7073:
1.1       grant    7074:      2. The -dlopen option is used when linking an executable.
1.20      ben      7075:
1.1       grant    7076:   * The use of libltdl without the correct calls to initialisation routines.
                   7077:     The function lt_dlinit() should be called and the macro
                   7078:     LTDL_SET_PRELOADED_SYMBOLS included in executables.
1.20      ben      7079:
1.107     rillig   7080: 19.3.3. GNU Autoconf/Automake
1.1       grant    7081:
                   7082: If a package needs GNU autoconf or automake to be executed to regenerate the
                   7083: configure script and Makefile.in makefile templates, then they should be
1.35      jmmv     7084: executed in a pre-configure target.
1.1       grant    7085:
                   7086: For packages that need only autoconf:
                   7087:
1.101     rillig   7088: AUTOCONF_REQD=  2.50            # if default version is not good enough
                   7089: USE_TOOLS+=     autoconf        # use "autoconf213" for autoconf-2.13
                   7090: ...
1.87      wiz      7091:
1.101     rillig   7092: pre-configure:
                   7093:         cd ${WRKSRC} && autoconf
1.1       grant    7094:
1.101     rillig   7095: ...
1.1       grant    7096:
                   7097:
                   7098: and for packages that need automake and autoconf:
                   7099:
1.101     rillig   7100: AUTOMAKE_REQD=  1.7.1           # if default version is not good enough
                   7101: USE_TOOLS+=     automake        # use "automake14" for automake-1.4
                   7102: ...
1.87      wiz      7103:
1.101     rillig   7104: pre-configure:
                   7105:         set -e; cd ${WRKSRC}; \
                   7106:         aclocal; autoheader; automake -a --foreign -i; autoconf
                   7107:
                   7108: ...
1.51      rillig   7109:
1.1       grant    7110:
1.35      jmmv     7111: Packages which use GNU Automake will almost certainly require GNU Make.
1.1       grant    7112:
                   7113: There are times when the configure process makes additional changes to the
                   7114: generated files, which then causes the build process to try to re-execute the
                   7115: automake sequence. This is prevented by touching various files in the configure
                   7116: stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
                   7117: NO in the package Makefile.
                   7118:
1.107     rillig   7119: 19.4. Programming languages
1.87      wiz      7120:
1.107     rillig   7121: 19.4.1. C, C++, and Fortran
1.87      wiz      7122:
                   7123: Compilers for the C, C++, and Fortran languages comes with the NetBSD base
                   7124: system. By default, pkgsrc assumes that a package is written in C and will hide
1.107     rillig   7125: all other compilers (via the wrapper framework, see Chapter 14, Buildlink
1.87      wiz      7126: methodology).
                   7127:
                   7128: To declare which language's compiler a package needs, set the USE_LANGUAGES
                   7129: variable. Allowed values currently are "c", "c++", and "fortran" (and any
                   7130: combination). The default is "c". Packages using GNU configure scripts, even if
                   7131: written in C++, usually need a C compiler for the configure phase.
                   7132:
1.107     rillig   7133: 19.4.2. Java
1.87      wiz      7134:
                   7135: If a program is written in Java, use the Java framework in pkgsrc. The package
                   7136: must include ../../mk/java-vm.mk. This Makefile fragment provides the following
                   7137: variables:
                   7138:
                   7139:   * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is
                   7140:     set to "run", then there is only a runtime dependency on the JDK. The
                   7141:     default is "yes", which also adds a build dependency on the JDK.
                   7142:
                   7143:   * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The
                   7144:     supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2
                   7145:     implementation, "1.4" insists on versions 1.4 or above, and "1.5" only
                   7146:     accepts versions 1.5 or above. This variable is not set by default.
                   7147:
1.132     wiz      7148:   * PKG_JAVA_HOME is automatically set to the runtime location of the used Java
                   7149:     implementation dependency. It may be used to set JAVA_HOME to a good value
                   7150:     if the program needs this variable to be defined.
                   7151:
1.107     rillig   7152: 19.4.3. Packages containing perl scripts
1.87      wiz      7153:
                   7154: If your package contains interpreted perl scripts, add "perl" to the USE_TOOLS
                   7155: variable and set REPLACE_PERL to ensure that the proper interpreter path is
                   7156: set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that
                   7157: you want adjusted. Every occurrence of */bin/perl will be replaced with the
                   7158: full path to the perl executable.
                   7159:
                   7160: If a particular version of perl is needed, set the PERL5_REQD variable to the
                   7161: version number. The default is "5.0".
                   7162:
1.107     rillig   7163: See Section 19.6.6, "Packages installing perl modules" for information about
1.87      wiz      7164: handling perl modules.
                   7165:
1.107     rillig   7166: 19.4.4. Other programming languages
1.87      wiz      7167:
                   7168: Currently, there is no special handling for other languages in pkgsrc. If a
                   7169: compiler package provides a buildlink3.mk file, include that, otherwise just
                   7170: add a (build) dependency on the appropriate compiler package.
                   7171:
1.107     rillig   7172: 19.5. Fixing problems in the build phase
1.1       grant    7173:
1.77      rillig   7174: The most common failures when building a package are that some platforms do not
                   7175: provide certain header files, functions or libraries, or they provide the
                   7176: functions in a library that the original package author didn't know. To work
                   7177: around this, you can rewrite the source code in most cases so that it does not
                   7178: use the missing functions or provides a replacement function.
                   7179:
1.107     rillig   7180: 19.5.1. Compiling C and C++ code conditionally
1.77      rillig   7181:
                   7182: If a package already comes with a GNU configure script, the preferred way to
                   7183: fix the build failure is to change the configure script, not the code. In the
                   7184: other cases, you can utilize the C preprocessor, which defines certain macros
                   7185: depending on the operating system and hardware architecture it compiles for.
                   7186: These macros can be queried using for example #if defined(__i386). Almost every
                   7187: operating system, hardware architecture and compiler has its own macro. For
                   7188: example, if the macros __GNUC__, __i386__ and __NetBSD__ are all defined, you
                   7189: know that you are using NetBSD on an i386 compatible CPU, and your compiler is
                   7190: GCC.
                   7191:
                   7192: The list of the following macros for hardware and operating system depends on
                   7193: the compiler that is used. For example, if you want to conditionally compile
                   7194: code on Solaris, don't use __sun__, as the SunPro compiler does not define it.
                   7195: Use __sun instead.
1.1       grant    7196:
1.107     rillig   7197: 19.5.1.1. C preprocessor macros to identify the operating system
1.55      rillig   7198:
                   7199: To distinguish between 4.4 BSD-derived systems and the rest of the world, you
                   7200: should use the following code.
1.1       grant    7201:
1.101     rillig   7202: #include <sys/param.h>
                   7203: #if (defined(BSD) && BSD >= 199306)
                   7204: /* BSD-specific code goes here */
                   7205: #else
                   7206: /* non-BSD-specific code goes here */
                   7207: #endif
1.55      rillig   7208:
1.77      rillig   7209: If this distinction is not fine enough, you can also test for the following
                   7210: macros.
1.55      rillig   7211:
1.101     rillig   7212: FreeBSD     __FreeBSD__
                   7213: DragonFly   __DragonFly__
                   7214: Interix     __INTERIX
                   7215: IRIX        __sgi (TODO: get a definite source for this)
                   7216: Linux       linux, __linux, __linux__
                   7217: NetBSD      __NetBSD__
                   7218: OpenBSD     __OpenBSD__
                   7219: Solaris     sun, __sun
1.1       grant    7220:
1.107     rillig   7221: 19.5.1.2. C preprocessor macros to identify the hardware architecture
1.1       grant    7222:
1.101     rillig   7223: i386        i386, __i386, __i386__
                   7224: MIPS        __mips
                   7225: SPARC       sparc, __sparc
1.55      rillig   7226:
1.107     rillig   7227: 19.5.1.3. C preprocessor macros to identify the compiler
1.1       grant    7228:
1.101     rillig   7229: GCC         __GNUC__ (major version), __GNUC_MINOR__
                   7230: MIPSpro     _COMPILER_VERSION (0x741 for MIPSpro 7.41)
                   7231: SunPro      __SUNPRO_C (0x570 for Sun C 5.7)
                   7232: SunPro C++  __SUNPRO_CC (0x580 for Sun C++ 5.8)
1.1       grant    7233:
1.107     rillig   7234: 19.5.2. How to handle compiler bugs
1.61      rillig   7235:
1.78      rillig   7236: Some source files trigger bugs in the compiler, based on combinations of
                   7237: compiler version and architecture and almost always relation to optimisation
                   7238: being enabled. Common symptoms are gcc internal errors or never finishing
                   7239: compiling a file.
1.1       grant    7240:
1.78      rillig   7241: Typically, a workaround involves testing the MACHINE_ARCH and compiler version,
                   7242: disabling optimisation for that combination of file, MACHINE_ARCH and compiler,
                   7243: and documenting it in pkgsrc/doc/HACKS. See that file for a number of examples.
1.1       grant    7244:
1.107     rillig   7245: 19.5.3. Undefined reference to "..."
1.20      ben      7246:
1.92      rillig   7247: This error message often means that a package did not link to a shared library
1.78      rillig   7248: it needs. The following functions are known to cause this error message over
                   7249: and over.
                   7250:
                   7251: +-----------------------------------------------------+
                   7252: |        Function         |Library |Affected platforms|
                   7253: |-------------------------+--------+------------------|
                   7254: |accept, bind, connect    |-lsocket|Solaris           |
                   7255: |-------------------------+--------+------------------|
                   7256: |crypt                    |-lcrypt |DragonFly, NetBSD |
                   7257: |-------------------------+--------+------------------|
                   7258: |dlopen, dlsym            |-ldl    |Linux             |
                   7259: |-------------------------+--------+------------------|
                   7260: |gethost*                 |-lnsl   |Solaris           |
                   7261: |-------------------------+--------+------------------|
                   7262: |inet_aton                |-lresolv|Solaris           |
                   7263: |-------------------------+--------+------------------|
                   7264: |nanosleep, sem_*, timer_*|-lrt    |Solaris           |
                   7265: |-------------------------+--------+------------------|
                   7266: |openpty                  |-lutil  |Linux             |
                   7267: +-----------------------------------------------------+
                   7268:
                   7269: To fix these linker errors, it is often sufficient to say LIBS.OperatingSystem+
                   7270: = -lfoo to the package Makefile and then say bmake clean; bmake.
                   7271:
1.107     rillig   7272: 19.5.3.1. Special issue: The SunPro compiler
1.92      rillig   7273:
                   7274: When you are using the SunPro compiler, there is another possibility. That
                   7275: compiler cannot handle the following code:
                   7276:
1.101     rillig   7277: extern int extern_func(int);
1.92      rillig   7278:
1.101     rillig   7279: static inline int
                   7280: inline_func(int x)
                   7281: {
1.92      rillig   7282:         return extern_func(x);
1.101     rillig   7283: }
1.92      rillig   7284:
1.101     rillig   7285: int main(void)
                   7286: {
1.92      rillig   7287:         return 0;
1.101     rillig   7288: }
1.92      rillig   7289:
                   7290: It generates the code for inline_func even if that function is never used. This
                   7291: code then refers to extern_func, which can usually not be resolved. To solve
                   7292: this problem you can try to tell the package to disable inlining of functions.
                   7293:
1.107     rillig   7294: 19.5.4. Running out of memory
1.87      wiz      7295:
                   7296: Sometimes packages fail to build because the compiler runs into an operating
                   7297: system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be
                   7298: told to unlimit the resources. Currently, the allowed values are "datasize" and
                   7299: "stacksize" (or both). Setting this variable is similar to running the shell
                   7300: builtin ulimit command to raise the maximum data segment size or maximum stack
                   7301: size of a process, respectively, to their hard limits.
1.78      rillig   7302:
1.107     rillig   7303: 19.6. Fixing problems in the install phase
1.87      wiz      7304:
1.107     rillig   7305: 19.6.1. Creating needed directories
1.78      rillig   7306:
                   7307: The BSD-compatible install supplied with some operating systems cannot create
                   7308: more than one directory at a time. As such, you should call ${INSTALL_*_DIR}
                   7309: like this:
1.20      ben      7310:
1.101     rillig   7311: ${INSTALL_DATA_DIR} ${PREFIX}/dir1
                   7312: ${INSTALL_DATA_DIR} ${PREFIX}/dir2
1.87      wiz      7313:
1.20      ben      7314:
1.78      rillig   7315: You can also just append "dir1 dir2" to the INSTALLATION_DIRS variable, which
                   7316: will automatically do the right thing.
1.20      ben      7317:
1.107     rillig   7318: 19.6.2. Where to install documentation
1.1       grant    7319:
1.83      wiz      7320: In general, documentation should be installed into ${PREFIX}/share/doc/$
                   7321: {PKGBASE} or ${PREFIX}/share/doc/${PKGNAME} (the latter includes the version
                   7322: number of the package).
                   7323:
                   7324: Many modern packages using GNU autoconf allow to set the directory where HTML
1.84      wiz      7325: documentation is installed with the "--with-html-dir" option. Sometimes using
                   7326: this flag is needed because otherwise the documentation ends up in ${PREFIX}/
                   7327: share/doc/html or other places.
1.83      wiz      7328:
                   7329: An exception to the above is that library API documentation generated with the
                   7330: textproc/gtk-doc tools, for use by special browsers (devhelp) should be left at
                   7331: their default location, which is ${PREFIX}/share/gtk-doc. Such documentation
                   7332: can be recognized from files ending in .devhelp or .devhelp2. (It is also
1.84      wiz      7333: acceptable to install such files in ${PREFIX}/share/doc/${PKGBASE} or ${PREFIX}
                   7334: /share/doc/${PKGNAME}; the .devhelp* file must be directly in that directory
                   7335: then, no additional subdirectory level is allowed in this case. This is usually
                   7336: achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/
                   7337: gtk-doc is preferred though.)
1.1       grant    7338:
1.107     rillig   7339: 19.6.3. Installing highscore files
1.1       grant    7340:
                   7341: Certain packages, most of them in the games category, install a score file that
                   7342: allows all users on the system to record their highscores. In order for this to
                   7343: work, the binaries need to be installed setgid and the score files owned by the
                   7344: appropriate group and/or owner (traditionally the "games" user/group). The
1.11      ben      7345: following variables, documented in more detail in mk/defaults/mk.conf, control
                   7346: this behaviour: SETGIDGAME, GAMEDATAMODE, GAMEGRP, GAMEMODE, GAMEOWN.
1.1       grant    7347:
                   7348: Note that per default, setgid installation of games is disabled; setting
                   7349: SETGIDGAME=YES will set all the other variables accordingly.
                   7350:
1.115     jmcneill 7351: A package should therefore never hard code file ownership or access permissions
1.1       grant    7352: but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly.
                   7353:
1.107     rillig   7354: 19.6.4. Adding DESTDIR support to packages
1.104     wiz      7355:
1.115     jmcneill 7356: DESTDIR support means that a package installs into a staging directory, not the
                   7357: final location of the files. Then a binary package is created which can be used
                   7358: for installation as usual. There are two ways: Either the package must install
1.132     wiz      7359: as root ("destdir") or the package can install as non-root user ("user-destdir"
                   7360: ).
1.115     jmcneill 7361:
                   7362:   * PKG_DESTDIR_SUPPORT has to be set to "destdir" or "user-destdir". If
                   7363:     bsd.prefs.mk is included in the Makefile, PKG_DESTDIR_SUPPORT needs to be
                   7364:     set before the inclusion.
                   7365:
1.104     wiz      7366:   * All installation operations have to be prefixed with ${DESTDIR}.
                   7367:
                   7368:   * automake gets this DESTDIR mostly right automatically. Many manual rules
                   7369:     and pre/post-install often are incorrect; fix them.
                   7370:
1.119     imil     7371:   * If files are installed with special owner/group use SPECIAL_PERMS.
1.104     wiz      7372:
                   7373:   * In general, packages should support UNPRIVILEGED to be able to use DESTDIR.
                   7374:
1.107     rillig   7375: 19.6.5. Packages with hardcoded paths to other interpreters
1.1       grant    7376:
                   7377: Your package may also contain scripts with hardcoded paths to other
                   7378: interpreters besides (or as well as) perl. To correct the full pathname to the
                   7379: script interpreter, you need to set the following definitions in your Makefile
                   7380: (we shall use tclsh in this example):
                   7381:
1.101     rillig   7382: REPLACE_INTERPRETER+=   tcl
                   7383: REPLACE.tcl.old=        .*/bin/tclsh
                   7384: REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
                   7385: REPLACE_FILES.tcl=      # list of tcl scripts which need to be fixed,
                   7386: # relative to ${WRKSRC}, just as in REPLACE_PERL
1.87      wiz      7387:
1.1       grant    7388:
1.71      wiz      7389: Note
                   7390:
                   7391: Before March 2006, these variables were called _REPLACE.* and _REPLACE_FILES.*.
                   7392:
1.107     rillig   7393: 19.6.6. Packages installing perl modules
1.1       grant    7394:
                   7395: Makefiles of packages providing perl5 modules should include the Makefile
                   7396: fragment ../../lang/perl5/module.mk. It provides a do-configure target for the
                   7397: standard perl configuration for such modules as well as various hooks to tune
                   7398: this configuration. See comments in this file for details.
                   7399:
                   7400: Perl5 modules will install into different places depending on the version of
                   7401: perl used during the build process. To address this, pkgsrc will append lines
                   7402: to the PLIST corresponding to the files listed in the installed .packlist file
                   7403: generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to
                   7404: a space-separated list of paths to packlist files, e.g.:
                   7405:
1.101     rillig   7406: PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
1.87      wiz      7407:
1.1       grant    7408:
                   7409: The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent the
                   7410: three locations in which perl5 modules may be installed, and may be used by
                   7411: perl5 packages that don't have a packlist. These three variables are also
                   7412: substituted for in the PLIST.
                   7413:
1.107     rillig   7414: 19.6.7. Packages installing info files
1.1       grant    7415:
                   7416: Some packages install info files or use the "makeinfo" or "install-info"
1.72      rillig   7417: commands. INFO_FILES should be defined in the package Makefile so that INSTALL
                   7418: and DEINSTALL scripts will be generated to handle registration of the info
                   7419: files in the Info directory file. The "install-info" command used for the info
                   7420: files registration is either provided by the system, or by a special purpose
                   7421: package automatically added as dependency if needed.
                   7422:
                   7423: PKGINFODIR is the directory under ${PREFIX} where info files are primarily
                   7424: located. PKGINFODIR defaults to "info" and can be overridden by the user.
                   7425:
                   7426: The info files for the package should be listed in the package PLIST; however
                   7427: any split info files need not be listed.
                   7428:
                   7429: A package which needs the "makeinfo" command at build time must add "makeinfo"
                   7430: to USE_TOOLS in its Makefile. If a minimum version of the "makeinfo" command is
                   7431: needed it should be noted with the TEXINFO_REQD variable in the package
                   7432: Makefile. By default, a minimum version of 3.12 is required. If the system does
                   7433: not provide a makeinfo command or if it does not match the required minimum, a
                   7434: build dependency on the devel/gtexinfo package will be added automatically.
1.1       grant    7435:
                   7436: The build and installation process of the software provided by the package
                   7437: should not use the install-info command as the registration of info files is
1.132     wiz      7438: the task of the package INSTALL script, and it must use the appropriate
1.1       grant    7439: makeinfo command.
                   7440:
1.47      reed     7441: To achieve this goal, the pkgsrc infrastructure creates overriding scripts for
1.1       grant    7442: the install-info and makeinfo commands in a directory listed early in PATH.
                   7443:
                   7444: The script overriding install-info has no effect except the logging of a
                   7445: message. The script overriding makeinfo logs a message and according to the
1.72      rillig   7446: value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on
                   7447: error.
1.1       grant    7448:
1.107     rillig   7449: 19.6.8. Packages installing man pages
1.57      minskim  7450:
1.81      rillig   7451: All packages that install manual pages should install them into the same
                   7452: directory, so that there is one common place to look for them. In pkgsrc, this
                   7453: place is ${PREFIX}/${PKGMANDIR}, and this expression should be used in
1.132     wiz      7454: packages. The default for PKGMANDIR is "man". Another often-used value is "
                   7455: share/man".
1.57      minskim  7456:
                   7457: Note
                   7458:
1.81      rillig   7459: The support for a custom PKGMANDIR is far from complete.
1.57      minskim  7460:
                   7461: The PLIST files can just use man/ as the top level directory for the man page
1.81      rillig   7462: file entries, and the pkgsrc framework will convert as needed. In all other
                   7463: places, the correct PKGMANDIR must be used.
1.57      minskim  7464:
                   7465: Packages that are configured with GNU_CONFIGURE set as "yes", by default will
                   7466: use the ./configure --mandir switch to set where the man pages should be
                   7467: installed. The path is GNU_CONFIGURE_MANDIR which defaults to ${PREFIX}/$
                   7468: {PKGMANDIR}.
                   7469:
                   7470: Packages that use GNU_CONFIGURE but do not use --mandir, can set
                   7471: CONFIGURE_HAS_MANDIR to "no". Or if the ./configure script uses a non-standard
                   7472: use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed.
                   7473:
1.107     rillig   7474: See Section 13.5, "Man page compression" for information on installation of
1.57      minskim  7475: compressed manual pages.
                   7476:
1.108     rillig   7477: 19.6.9. Packages installing GConf data files
1.1       grant    7478:
1.108     rillig   7479: If a package installs .schemas or .entries files, used by GConf, you need to
1.1       grant    7480: take some extra steps to make sure they get registered in the database:
                   7481:
1.108     rillig   7482:  1. Include ../../devel/GConf/schemas.mk instead of its buildlink3.mk file.
                   7483:     This takes care of rebuilding the GConf database at installation and
                   7484:     deinstallation time, and tells the package where to install GConf data
1.1       grant    7485:     files using some standard configure arguments. It also disallows any access
                   7486:     to the database directly from the package.
1.20      ben      7487:
1.1       grant    7488:  2. Ensure that the package installs its .schemas files under ${PREFIX}/share/
                   7489:     gconf/schemas. If they get installed under ${PREFIX}/etc, you will need to
                   7490:     manually patch the package.
1.20      ben      7491:
1.1       grant    7492:  3. Check the PLIST and remove any entries under the etc/gconf directory, as
1.107     rillig   7493:     they will be handled automatically. See Section 9.13, "How do I change the
1.35      jmmv     7494:     location of configuration files?" for more information.
1.20      ben      7495:
1.108     rillig   7496:  4. Define the GCONF_SCHEMAS variable in your Makefile with a list of all
1.1       grant    7497:     .schemas files installed by the package, if any. Names must not contain any
                   7498:     directories in them.
1.20      ben      7499:
1.108     rillig   7500:  5. Define the GCONF_ENTRIES variable in your Makefile with a list of all
1.1       grant    7501:     .entries files installed by the package, if any. Names must not contain any
                   7502:     directories in them.
1.20      ben      7503:
1.120     mishka   7504: 19.6.10. Packages installing scrollkeeper/rarian data files
1.1       grant    7505:
1.120     mishka   7506: If a package installs .omf files, used by scrollkeeper/rarian, you need to take
                   7507: some extra steps to make sure they get registered in the database:
1.1       grant    7508:
1.120     mishka   7509:  1. Include ../../mk/omf-scrollkeeper.mk instead of rarian's buildlink3.mk
                   7510:     file. This takes care of rebuilding the scrollkeeper database at
                   7511:     installation and deinstallation time, and disallows any access to it
                   7512:     directly from the package.
1.20      ben      7513:
1.1       grant    7514:  2. Check the PLIST and remove any entries under the libdata/scrollkeeper
                   7515:     directory, as they will be handled automatically.
1.20      ben      7516:
1.1       grant    7517:  3. Remove the share/omf directory from the PLIST. It will be handled by
1.120     mishka   7518:     rarian. (make print-PLIST does this automatically.)
1.20      ben      7519:
1.107     rillig   7520: 19.6.11. Packages installing X11 fonts
1.1       grant    7521:
                   7522: If a package installs font files, you will need to rebuild the fonts database
                   7523: in the directory where they get installed at installation and deinstallation
1.65      hubertf  7524: time. This can be automatically done by using the pkginstall framework.
1.1       grant    7525:
1.65      hubertf  7526: You can list the directories where fonts are installed in the FONTS_DIRS.type
                   7527: variables, where type can be one of "ttf", "type1" or "x11". Also make sure
                   7528: that the database file fonts.dir is not listed in the PLIST.
1.1       grant    7529:
                   7530: Note that you should not create new directories for fonts; instead use the
                   7531: standard ones to avoid that the user needs to manually configure his X server
                   7532: to find them.
                   7533:
1.107     rillig   7534: 19.6.12. Packages installing GTK2 modules
1.1       grant    7535:
1.47      reed     7536: If a package installs GTK2 immodules or loaders, you need to take some extra
1.1       grant    7537: steps to get them registered in the GTK2 database properly:
                   7538:
                   7539:  1. Include ../../x11/gtk2/modules.mk instead of its buildlink3.mk file. This
                   7540:     takes care of rebuilding the database at installation and deinstallation
                   7541:     time.
1.20      ben      7542:
1.1       grant    7543:  2. Set GTK2_IMMODULES=YES if your package installs GTK2 immodules.
1.20      ben      7544:
1.1       grant    7545:  3. Set GTK2_LOADERS=YES if your package installs GTK2 loaders.
1.20      ben      7546:
1.47      reed     7547:  4. Patch the package to not touch any of the GTK2 databases directly. These
1.1       grant    7548:     are:
1.20      ben      7549:
1.1       grant    7550:       * libdata/gtk-2.0/gdk-pixbuf.loaders
1.20      ben      7551:
1.1       grant    7552:       * libdata/gtk-2.0/gtk.immodules
1.20      ben      7553:
1.1       grant    7554:  5. Check the PLIST and remove any entries under the libdata/gtk-2.0 directory,
                   7555:     as they will be handled automatically.
1.20      ben      7556:
1.107     rillig   7557: 19.6.13. Packages installing SGML or XML data
1.1       grant    7558:
                   7559: If a package installs SGML or XML data files that need to be registered in
                   7560: system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
                   7561: extra steps:
                   7562:
                   7563:  1. Include ../../textproc/xmlcatmgr/catalogs.mk in your Makefile, which takes
                   7564:     care of registering those files in system-wide catalogs at installation and
                   7565:     deinstallation time.
1.20      ben      7566:
1.1       grant    7567:  2. Set SGML_CATALOGS to the full path of any SGML catalogs installed by the
                   7568:     package.
1.20      ben      7569:
1.1       grant    7570:  3. Set XML_CATALOGS to the full path of any XML catalogs installed by the
                   7571:     package.
1.20      ben      7572:
1.1       grant    7573:  4. Set SGML_ENTRIES to individual entries to be added to the SGML catalog.
                   7574:     These come in groups of three strings; see xmlcatmgr(1) for more
                   7575:     information (specifically, arguments recognized by the 'add' action). Note
                   7576:     that you will normally not use this variable.
1.20      ben      7577:
1.1       grant    7578:  5. Set XML_ENTRIES to individual entries to be added to the XML catalog. These
                   7579:     come in groups of three strings; see xmlcatmgr(1) for more information
                   7580:     (specifically, arguments recognized by the 'add' action). Note that you
                   7581:     will normally not use this variable.
1.20      ben      7582:
1.107     rillig   7583: 19.6.14. Packages installing extensions to the MIME database
1.1       grant    7584:
                   7585: If a package provides extensions to the MIME database by installing .xml files
                   7586: inside ${PREFIX}/share/mime/packages, you need to take some extra steps to
                   7587: ensure that the database is kept consistent with respect to these new files:
                   7588:
                   7589:  1. Include ../../databases/shared-mime-info/mimedb.mk (avoid using the
                   7590:     buildlink3.mk file from this same directory, which is reserved for
                   7591:     inclusion from other buildlink3.mk files). It takes care of rebuilding the
                   7592:     MIME database at installation and deinstallation time, and disallows any
                   7593:     access to it directly from the package.
1.20      ben      7594:
1.132     wiz      7595:  2. Check the PLIST and remove any entries under the share/mime directory,
1.1       grant    7596:     except for files saved under share/mime/packages. The former are handled
1.47      reed     7597:     automatically by the update-mime-database program, but the latter are
1.1       grant    7598:     package-dependent and must be removed by the package that installed them in
                   7599:     the first place.
1.20      ben      7600:
1.1       grant    7601:  3. Remove any share/mime/* directories from the PLIST. They will be handled by
                   7602:     the shared-mime-info package.
1.20      ben      7603:
1.107     rillig   7604: 19.6.15. Packages using intltool
1.1       grant    7605:
1.93      rillig   7606: If a package uses intltool during its build, add intltool to the USE_TOOLS,
                   7607: which forces it to use the intltool package provided by pkgsrc, instead of the
                   7608: one bundled with the distribution file.
1.1       grant    7609:
                   7610: This tracks intltool's build-time dependencies and uses the latest available
                   7611: version; this way, the package benefits of any bug fixes that may have appeared
                   7612: since it was released.
                   7613:
1.107     rillig   7614: 19.6.16. Packages installing startup scripts
1.18      xtraeme  7615:
                   7616: If a package contains a rc.d script, it won't be copied into the startup
                   7617: directory by default, but you can enable it, by adding the option
1.105     rillig   7618: PKG_RCD_SCRIPTS=YES in mk.conf. This option will copy the scripts into /etc/
                   7619: rc.d when a package is installed, and it will automatically remove the scripts
                   7620: when the package is deinstalled.
1.18      xtraeme  7621:
1.107     rillig   7622: 19.6.17. Packages installing TeX modules
1.57      minskim  7623:
                   7624: If a package installs TeX packages into the texmf tree, the ls-R database of
                   7625: the tree needs to be updated.
                   7626:
                   7627: Note
                   7628:
1.126     wiz      7629: Except the main TeX packages such as kpathsea, packages should install files
                   7630: into ${PREFIX}/share/texmf-dist, not ${PREFIX}/share/texmf.
1.57      minskim  7631:
1.126     wiz      7632:  1. Include ../../print/kpathsea/texmf.mk. This takes care of rebuilding the
                   7633:     ls-R database at installation and deinstallation time.
1.57      minskim  7634:
1.126     wiz      7635:  2. If your package installs files into a texmf tree other than the one at $
                   7636:     {PREFIX}/share/texmf-dist, set TEX_TEXMF_DIRS to the list of all texmf
                   7637:     trees that need database update.
1.57      minskim  7638:
1.64      kim      7639:     If your package also installs font map files that need to be registered
1.126     wiz      7640:     using updmap, include ../../print/texlive-tetex/map.mk and set
                   7641:     TEX_MAP_FILES and/or TEX_MIXEDMAP_FILES to the list of all such font map
                   7642:     files. Then updmap will be run automatically at installation/deinstallation
                   7643:     to enable/disable font map files for TeX output drivers.
1.64      kim      7644:
1.57      minskim  7645:  3. Make sure that none of ls-R databases are included in PLIST, as they will
                   7646:     be removed only by the teTeX-bin package.
                   7647:
1.107     rillig   7648: 19.6.18. Packages supporting running binaries in emulation
1.87      wiz      7649:
                   7650: There are some packages that provide libraries and executables for running
                   7651: binaries from a one operating system on a different one (if the latter supports
                   7652: it). One example is running Linux binaries on NetBSD.
                   7653:
                   7654: The pkgtools/rpm2pkg helps in extracting and packaging Linux rpm packages.
                   7655:
                   7656: The CHECK_SHLIBS can be set to no to avoid the check-shlibs target, which tests
                   7657: if all libraries for each installed executable can be found by the dynamic
                   7658: linker. Since the standard dynamic linker is run, this fails for emulation
                   7659: packages, because the libraries used by the emulation are not in the standard
                   7660: directories.
                   7661:
1.107     rillig   7662: 19.6.19. Packages installing hicolor theme icons
1.85      jmmv     7663:
                   7664: If a package installs images under the share/icons/hicolor and/or updates the
                   7665: share/icons/hicolor/icon-theme.cache database, you need to take some extra
                   7666: steps to make sure that the shared theme directory is handled appropriately and
                   7667: that the cache database is rebuilt:
                   7668:
1.87      wiz      7669:  1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk.
1.85      jmmv     7670:
                   7671:  2. Check the PLIST and remove the entry that refers to the theme cache.
                   7672:
                   7673:  3. Ensure that the PLIST does not remove the shared icon directories from the
                   7674:     share/icons/hicolor hierarchy because they will be handled automatically.
1.1       grant    7675:
1.85      jmmv     7676: The best way to verify that the PLIST is correct with respect to the last two
                   7677: points is to regenerate it using make print-PLIST.
1.1       grant    7678:
1.107     rillig   7679: 19.6.20. Packages installing desktop files
1.85      jmmv     7680:
                   7681: If a package installs .desktop files under share/applications and these include
                   7682: MIME information, you need to take extra steps to ensure that they are
                   7683: registered into the MIME database:
                   7684:
                   7685:  1. Include ../../sysutils/desktop-file-utils/desktopdb.mk.
                   7686:
                   7687:  2. Check the PLIST and remove the entry that refers to the share/applications/
                   7688:     mimeinfo.cache file. It will be handled automatically.
                   7689:
                   7690: The best way to verify that the PLIST is correct with respect to the last point
                   7691: is to regenerate it using make print-PLIST.
1.1       grant    7692:
1.107     rillig   7693: 19.7. Marking packages as having problems
1.87      wiz      7694:
1.126     wiz      7695: In some cases one does not have the time to solve a problem immediately. In
                   7696: this case, one can plainly mark a package as broken. For this, one just sets
                   7697: the variable BROKEN to the reason why the package is broken (similar to the
                   7698: RESTRICTED variable). A user trying to build the package will immediately be
                   7699: shown this message, and the build will not be even tried.
1.87      wiz      7700:
1.126     wiz      7701: BROKEN packages are removed from pkgsrc in irregular intervals.
1.87      wiz      7702:
1.107     rillig   7703: Chapter 20. Debugging
1.1       grant    7704:
                   7705: To check out all the gotchas when building a package, here are the steps that I
                   7706: do in order to get a package working. Please note this is basically the same as
                   7707: what was explained in the previous sections, only with some debugging aids.
                   7708:
1.105     rillig   7709:   * Be sure to set PKG_DEVELOPER=yes in mk.conf.
1.20      ben      7710:
1.1       grant    7711:   * Install pkgtools/url2pkg, create a directory for a new package, change into
                   7712:     it, then run url2pkg:
1.20      ben      7713:
1.1       grant    7714:     % mkdir /usr/pkgsrc/category/examplepkg
                   7715:     % cd /usr/pkgsrc/category/examplepkg
                   7716:     % url2pkg http://www.example.com/path/to/distfile.tar.gz
1.20      ben      7717:
1.1       grant    7718:   * Edit the Makefile as requested.
1.20      ben      7719:
1.1       grant    7720:   * Fill in the DESCR file
1.20      ben      7721:
1.1       grant    7722:   * Run make configure
1.20      ben      7723:
1.1       grant    7724:   * Add any dependencies glimpsed from documentation and the configure step to
                   7725:     the package's Makefile.
1.20      ben      7726:
1.1       grant    7727:   * Make the package compile, doing multiple rounds of
1.20      ben      7728:
1.1       grant    7729:     % make
                   7730:     % pkgvi ${WRKSRC}/some/file/that/does/not/compile
                   7731:     % mkpatches
                   7732:     % patchdiff
                   7733:     % mv ${WRKDIR}/.newpatches/* patches
                   7734:     % make mps
                   7735:     % make clean
1.20      ben      7736:
1.88      wiz      7737:     Doing this step as non-root user will ensure that no files are modified
                   7738:     that shouldn't be, especially during the build phase. mkpatches, patchdiff
                   7739:     and pkgvi are from the pkgtools/pkgdiff package.
1.20      ben      7740:
1.107     rillig   7741:   * Look at the Makefile, fix if necessary; see Section 11.1, "Makefile".
1.20      ben      7742:
1.1       grant    7743:   * Generate a PLIST:
1.20      ben      7744:
1.1       grant    7745:     # make install
                   7746:     # make print-PLIST >PLIST
                   7747:     # make deinstall
                   7748:     # make install
                   7749:     # make deinstall
1.20      ben      7750:
1.1       grant    7751:     You usually need to be root to do this. Look if there are any files left:
1.20      ben      7752:
1.1       grant    7753:     # make print-PLIST
1.20      ben      7754:
1.1       grant    7755:     If this reveals any files that are missing in PLIST, add them.
1.20      ben      7756:
1.1       grant    7757:   * Now that the PLIST is OK, install the package again and make a binary
                   7758:     package:
1.20      ben      7759:
1.1       grant    7760:     # make reinstall
                   7761:     # make package
1.20      ben      7762:
1.1       grant    7763:   * Delete the installed package:
1.20      ben      7764:
1.88      wiz      7765:     # pkg_delete examplepkg
1.20      ben      7766:
1.1       grant    7767:   * Repeat the above make print-PLIST command, which shouldn't find anything
                   7768:     now:
1.20      ben      7769:
1.1       grant    7770:     # make print-PLIST
1.20      ben      7771:
1.1       grant    7772:   * Reinstall the binary package:
1.20      ben      7773:
1.93      rillig   7774:     # pkg_add .../examplepkg.tgz
1.20      ben      7775:
1.1       grant    7776:   * Play with it. Make sure everything works.
1.20      ben      7777:
1.1       grant    7778:   * Run pkglint from pkgtools/pkglint, and fix the problems it reports:
1.20      ben      7779:
1.1       grant    7780:     # pkglint
1.20      ben      7781:
1.107     rillig   7782:   * Submit (or commit, if you have cvs access); see Chapter 21, Submitting and
1.1       grant    7783:     Committing.
1.20      ben      7784:
1.107     rillig   7785: Chapter 21. Submitting and Committing
1.1       grant    7786:
                   7787: Table of Contents
                   7788:
1.107     rillig   7789: 21.1. Submitting binary packages
                   7790: 21.2. Submitting source packages (for non-NetBSD-developers)
                   7791: 21.3. General notes when adding, updating, or removing packages
                   7792: 21.4. Committing: Importing a package into CVS
                   7793: 21.5. Updating a package to a newer version
1.123     reed     7794: 21.6. Renaming a package in pkgsrc
                   7795: 21.7. Moving a package in pkgsrc
1.74      rillig   7796:
1.107     rillig   7797: 21.1. Submitting binary packages
1.74      rillig   7798:
                   7799: Our policy is that we accept binaries only from pkgsrc developers to guarantee
                   7800: that the packages don't contain any trojan horses etc. This is not to annoy
                   7801: anyone but rather to protect our users! You're still free to put up your
                   7802: home-made binary packages and tell the world where to get them. NetBSD
                   7803: developers doing bulk builds and wanting to upload them please see
1.107     rillig   7804: Section 7.3.8, "Uploading results of a bulk build".
1.74      rillig   7805:
1.107     rillig   7806: 21.2. Submitting source packages (for non-NetBSD-developers)
1.74      rillig   7807:
                   7808: First, check that your package is complete, compiles and runs well; see
1.107     rillig   7809: Chapter 20, Debugging and the rest of this document. Next, generate an
1.82      rillig   7810: uuencoded gzipped tar(1) archive that contains all files that make up the
1.87      wiz      7811: package. Finally, send this package to the pkgsrc bug tracking system, either
                   7812: with the send-pr(1) command, or if you don't have that, go to the web page
1.104     wiz      7813: http://www.NetBSD.org/support/send-pr.html, which contains some instructions
1.125     snj      7814: and a link to a form where you can submit packages. The sysutils/gtk-send-pr
                   7815: package is also available as a substitute for either of the above two tools.
1.87      wiz      7816:
                   7817: In the form of the problem report, the category should be "pkg", the synopsis
                   7818: should include the package name and version number, and the description field
                   7819: should contain a short description of your package (contents of the COMMENT
1.132     wiz      7820: variable or DESCR file are OK). The uuencoded package data should go into the "
                   7821: fix" field.
1.74      rillig   7822:
                   7823: If you want to submit several packages, please send a separate PR for each one,
                   7824: it's easier for us to track things that way.
                   7825:
                   7826: Alternatively, you can also import new packages into pkgsrc-wip ("pkgsrc
                   7827: work-in-progress"); see the homepage at http://pkgsrc-wip.sourceforge.net/ for
                   7828: details.
1.20      ben      7829:
1.107     rillig   7830: 21.3. General notes when adding, updating, or removing packages
1.41      wiz      7831:
                   7832: Please note all package additions, updates, moves, and removals in pkgsrc/doc/
1.93      rillig   7833: CHANGES-YYYY. It's very important to keep this file up to date and conforming
                   7834: to the existing format, because it will be used by scripts to automatically
                   7835: update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/
                   7836: doc/TODO file and remove the entry for the package you updated or removed, in
                   7837: case it was mentioned there.
1.41      wiz      7838:
1.71      wiz      7839: When the PKGREVISION of a package is bumped, the change should appear in pkgsrc
1.93      rillig   7840: /doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps
                   7841: that result from a dependency being updated should not be mentioned. In all
                   7842: other cases it's the developer's decision.
1.71      wiz      7843:
1.93      rillig   7844: There is a make target that helps in creating proper CHANGES-YYYY entries: make
1.41      wiz      7845: changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The
1.93      rillig   7846: general usage is to first make sure that your CHANGES-YYYY file is up-to-date
                   7847: (to avoid having to resolve conflicts later-on) and then to cd to the package
1.41      wiz      7848: directory. For package updates, make changes-entry is enough. For new packages,
                   7849: or package moves or removals, set the CTYPE variable on the command line to
1.105     rillig   7850: "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if
1.126     wiz      7851: your local login name is not the same as your NetBSD login name. The target
                   7852: also automatically removes possibly existing entries for the package in the
                   7853: TODO file. Don't forget to commit the changes, e.g. by using make
                   7854: changes-entry-commit! If you are not using a checkout directly from
1.128     jakllsch 7855: cvs.NetBSD.org, but e.g. a local copy of the repository, you can set
1.126     wiz      7856: USE_NETBSD_REPO=yes. This makes the cvs commands use the main repository.
1.41      wiz      7857:
1.107     rillig   7858: 21.4. Committing: Importing a package into CVS
1.1       grant    7859:
                   7860: This section is only of interest for pkgsrc developers with write access to the
                   7861: pkgsrc repository. Please remember that cvs imports files relative to the
                   7862: current working directory, and that the pathname that you give the cvs import
                   7863: command is so that it knows where to place the files in the repository. Newly
                   7864: created packages should be imported with a vendor tag of "TNF" and a release
                   7865: tag of "pkgsrc-base", e.g:
                   7866:
1.101     rillig   7867: $ cd .../pkgsrc/category/pkgname
                   7868: $ cvs import pkgsrc/category/pkgname TNF pkgsrc-base
1.1       grant    7869:
                   7870: Remember to move the directory from which you imported out of the way, or cvs
                   7871: will complain the next time you "cvs update" your source tree. Also don't
                   7872: forget to add the new package to the category's Makefile.
                   7873:
                   7874: The commit message of the initial import should include part of the DESCR file,
                   7875: so people reading the mailing lists know what the package is/does.
                   7876:
                   7877: For new packages, "cvs import" is preferred to "cvs add" because the former
                   7878: gets everything with a single command, and provides a consistent tag.
                   7879:
1.107     rillig   7880: 21.5. Updating a package to a newer version
1.1       grant    7881:
                   7882: Please always put a concise, appropriate and relevant summary of the changes
                   7883: between old and new versions into the commit log when updating a package. There
                   7884: are various reasons for this:
                   7885:
                   7886:   * A URL is volatile, and can change over time. It may go away completely or
                   7887:     its information may be overwritten by newer information.
1.20      ben      7888:
1.1       grant    7889:   * Having the change information between old and new versions in our CVS
                   7890:     repository is very useful for people who use either cvs or anoncvs.
1.20      ben      7891:
1.1       grant    7892:   * Having the change information between old and new versions in our CVS
                   7893:     repository is very useful for people who read the pkgsrc-changes mailing
                   7894:     list, so that they can make tactical decisions about when to upgrade the
                   7895:     package.
1.20      ben      7896:
1.18      xtraeme  7897: Please also recognize that, just because a new version of a package has been
1.1       grant    7898: released, it should not automatically be upgraded in the CVS repository. We
                   7899: prefer to be conservative in the packages that are included in pkgsrc -
                   7900: development or beta packages are not really the best thing for most places in
                   7901: which pkgsrc is used. Please use your judgement about what should go into
                   7902: pkgsrc, and bear in mind that stability is to be preferred above new and
                   7903: possibly untested features.
                   7904:
1.123     reed     7905: 21.6. Renaming a package in pkgsrc
                   7906:
                   7907: Renaming packages is not recommended.
                   7908:
                   7909: When renaming packages, be sure to fix any references to old name in other
                   7910: Makefiles, options, buildlink files, etc.
                   7911:
                   7912: Also When renaming a package, please define SUPERSEDES to the package name and
                   7913: dewey version pattern(s) of the previous package name. This may be repeated for
                   7914: multiple renames. The new package would be an exact replacement.
                   7915:
                   7916: Note that "successor" in the CHANGES-YYYY file doesn't necessarily mean that it
                   7917: supersedes, as that successor may not be an exact replacement but is a
                   7918: suggestion for the replaced functionality.
                   7919:
                   7920: 21.7. Moving a package in pkgsrc
                   7921:
                   7922: It is preferred that packages are not renamed or moved, but if needed please
                   7923: follow these steps.
1.1       grant    7924:
                   7925:  1. Make a copy of the directory somewhere else.
1.20      ben      7926:
1.1       grant    7927:  2. Remove all CVS dirs.
1.20      ben      7928:
1.1       grant    7929:     Alternatively to the first two steps you can also do:
1.20      ben      7930:
1.1       grant    7931:     % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
1.20      ben      7932:
1.1       grant    7933:     and use that for further work.
1.20      ben      7934:
1.132     wiz      7935:  3. Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of
1.1       grant    7936:     "../../category/package".
1.20      ben      7937:
1.123     reed     7938:  4. In the modified package's Makefile, consider setting PREV_PKGPATH to the
                   7939:     previous category/package pathname. The PREV_PKGPATH can be used by tools
                   7940:     for doing an update using pkgsrc building; for example, it can search the
                   7941:     pkg_summary(5) database for PREV_PKGPATH (if no SUPERSEDES) and then use
                   7942:     the corresponding new PKGPATH for that moved package. Note that it may have
                   7943:     multiple matches, so the tool should also check on the PKGBASE too. The
                   7944:     PREV_PKGPATH probably has no value unless SUPERSEDES is not set, i.e.
                   7945:     PKGBASE stays the same.
                   7946:
                   7947:  5. cvs import the modified package in the new place.
1.20      ben      7948:
1.123     reed     7949:  6. Check if any package depends on it:
1.20      ben      7950:
1.1       grant    7951:     % cd /usr/pkgsrc
                   7952:     % grep /package */*/Makefile* */*/buildlink*
1.20      ben      7953:
1.123     reed     7954:  7. Fix paths in packages from step 5 to point to new location.
1.20      ben      7955:
1.123     reed     7956:  8. cvs rm (-f) the package at the old location.
1.20      ben      7957:
1.123     reed     7958:  9. Remove from oldcategory/Makefile.
1.20      ben      7959:
1.123     reed     7960: 10. Add to newcategory/Makefile.
1.20      ben      7961:
1.123     reed     7962: 11. Commit the changed and removed files:
1.20      ben      7963:
1.1       grant    7964:     % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
1.20      ben      7965:
1.1       grant    7966:     (and any packages from step 5, of course).
1.20      ben      7967:
1.107     rillig   7968: Chapter 22. Frequently Asked Questions
1.72      rillig   7969:
                   7970: This section contains the answers to questions that may arise when you are
                   7971: writing a package. If you don't find your question answered here, first have a
                   7972: look in the other chapters, and if you still don't have the answer, ask on the
                   7973: pkgsrc-users mailing list.
                   7974:
1.107     rillig   7975: 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
                   7976: 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
                   7977: 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
                   7978: 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
1.72      rillig   7979:     BUILDLINK_LIBS?
1.107     rillig   7980: 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
                   7981: 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
1.78      rillig   7982:     the := inside it.
1.107     rillig   7983: 22.7. Which mailing lists are there for package developers?
                   7984: 22.8. Where is the pkgsrc documentation?
                   7985: 22.9. I have a little time to kill. What shall I do?
1.72      rillig   7986:
1.107     rillig   7987: 22.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
1.72      rillig   7988:
                   7989:       MAKEFLAGS are the flags passed to the pkgsrc-internal invocations of make
                   7990:       (1), while MAKE_FLAGS are the flags that are passed to the MAKE_PROGRAM
                   7991:       when building the package. [FIXME: What is .MAKEFLAGS for?]
                   7992:
1.107     rillig   7993: 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
1.72      rillig   7994:
                   7995:       MAKE is the path to the make(1) program that is used in the pkgsrc
                   7996:       infrastructure. GMAKE is the path to GNU Make, but you need to say
                   7997:       USE_TOOLS+=gmake to use that. MAKE_PROGRAM is the path to the Make
                   7998:       program that is used for building the package.
                   7999:
1.107     rillig   8000: 22.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
1.72      rillig   8001:
                   8002:       CC is the path to the real C compiler, which can be configured by the
                   8003:       pkgsrc user. PKG_CC is the path to the compiler wrapper. PKGSRC_COMPILER
                   8004:       is not a path to a compiler, but the type of compiler that should be
                   8005:       used. See mk/compiler.mk for more information about the latter variable.
                   8006:
1.107     rillig   8007: 22.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
1.72      rillig   8008:       BUILDLINK_LIBS?
                   8009:
                   8010:       [FIXME]
                   8011:
1.107     rillig   8012: 22.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
1.72      rillig   8013:
1.132     wiz      8014:       For optimization reasons, some variables are only available in the "
                   8015:       wrapper" phase and later. To "simulate" the wrapper phase, append
1.72      rillig   8016:       PKG_PHASE=wrapper to the above command.
                   8017:
1.107     rillig   8018: 22.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
1.78      rillig   8019:       the := inside it.
                   8020:
                   8021:       The := is not really an assignment operator, like you might expect at
                   8022:       first sight. Instead, it is a degenerate form of ${LIST:old_string=
                   8023:       new_string}, which is documented in the make(1) man page and which you
                   8024:       may have seen as in ${SRCS:.c=.o}. In the case of MASTER_SITE_*,
                   8025:       old_string is the empty string and new_string is package/. That's where
                   8026:       the : and the = fall together.
                   8027:
1.107     rillig   8028: 22.7. Which mailing lists are there for package developers?
1.78      rillig   8029:
                   8030:       tech-pkg
                   8031:
                   8032:           This is a list for technical discussions related to pkgsrc
                   8033:           development, e.g. soliciting feedback for changes to pkgsrc
                   8034:           infrastructure, proposed new features, questions related to porting
                   8035:           pkgsrc to a new platform, advice for maintaining a package, patches
                   8036:           that affect many packages, help requests moved from pkgsrc-users when
                   8037:           an infrastructure bug is found, etc.
                   8038:
                   8039:       pkgsrc-bugs
                   8040:
                   8041:           All bug reports in category "pkg" sent with send-pr(1) appear here.
                   8042:           Please do not report your bugs here directly; use one of the other
                   8043:           mailing lists.
                   8044:
1.107     rillig   8045: 22.8. Where is the pkgsrc documentation?
1.80      rillig   8046:
                   8047:       There are many places where you can find documentation about pkgsrc:
                   8048:
                   8049:         * The pkgsrc guide (this document) is a collection of chapters that
                   8050:           explain large parts of pkgsrc, but some chapters tend to be outdated.
                   8051:           Which ones they are is hard to say.
                   8052:
                   8053:         * On the mailing list archives (see http://mail-index.NetBSD.org/), you
                   8054:           can find discussions about certain features, announcements of new
                   8055:           parts of the pkgsrc infrastructure and sometimes even announcements
                   8056:           that a certain feature has been marked as obsolete. The benefit here
                   8057:           is that each message has a date appended to it.
                   8058:
                   8059:         * Many of the files in the mk/ directory start with a comment that
                   8060:           describes the purpose of the file and how it can be used by the
1.92      rillig   8061:           pkgsrc user and package authors. An easy way to find this
                   8062:           documentation is to run bmake help.
1.80      rillig   8063:
                   8064:         * The CVS log messages are a rich source of information, but they tend
                   8065:           to be highly abbreviated, especially for actions that occur often.
                   8066:           Some contain a detailed description of what has changed, but they are
                   8067:           geared towards the other pkgsrc developers, not towards an average
                   8068:           pkgsrc user. They also only document changes, so if you don't know
                   8069:           what has been before, these messages may not be worth too much to
                   8070:           you.
                   8071:
                   8072:         * Some parts of pkgsrc are only "implicitly documented", that is the
                   8073:           documentation exists only in the mind of the developer who wrote the
1.93      rillig   8074:           code. To get this information, use the cvs annotate command to see
                   8075:           who has written it and ask on the tech-pkg mailing list, so that
1.80      rillig   8076:           others can find your questions later (see above). To be sure that the
                   8077:           developer in charge reads the mail, you may CC him or her.
                   8078:
1.107     rillig   8079: 22.9. I have a little time to kill. What shall I do?
1.92      rillig   8080:
                   8081:       This is not really an FAQ yet, but here's the answer anyway.
                   8082:
                   8083:         * Run pkg_chk -N (from the pkgtools/pkg_chk package). It will tell you
                   8084:           about newer versions of installed packages that are available, but
                   8085:           not yet updated in pkgsrc.
                   8086:
                   8087:         * Browse pkgsrc/doc/TODO ? it contains a list of suggested new packages
                   8088:           and a list of cleanups and enhancements for pkgsrc that would be nice
                   8089:           to have.
                   8090:
                   8091:         * Review packages for which review was requested on the pkgsrc-wip
                   8092:           review mailing list.
                   8093:
1.107     rillig   8094: Chapter 23. GNOME packaging and porting
1.85      jmmv     8095:
                   8096: Table of Contents
                   8097:
1.107     rillig   8098: 23.1. Meta packages
                   8099: 23.2. Packaging a GNOME application
                   8100: 23.3. Updating GNOME to a newer version
                   8101: 23.4. Patching guidelines
1.85      jmmv     8102:
                   8103: Quoting GNOME's web site:
                   8104:
                   8105:     The GNOME project provides two things: The GNOME desktop environment, an
                   8106:     intuitive and attractive desktop for users, and the GNOME development
                   8107:     platform, an extensive framework for building applications that integrate
                   8108:     into the rest of the desktop.
                   8109:
                   8110: pkgsrc provides a seamless way to automatically build and install a complete
                   8111: GNOME environment under many different platforms. We can say with confidence
                   8112: that pkgsrc is one of the most advanced build and packaging systems for GNOME
                   8113: due to its included technologies buildlink3, the wrappers and tools framework
                   8114: and automatic configuration file management. Lots of efforts are put into
                   8115: achieving a completely clean deinstallation of installed software components.
                   8116:
                   8117: Given that pkgsrc is NetBSD's official packaging system, the above also means
                   8118: that great efforts are put into making GNOME work under this operating system.
                   8119: Recently, DragonFly BSD also adopted pkgsrc as its preferred packaging system,
                   8120: contributing lots of portability fixes to make GNOME build and install under
                   8121: it.
                   8122:
                   8123: This chapter is aimed at pkgsrc developers and other people interested in
                   8124: helping our GNOME porting and packaging efforts. It provides instructions on
                   8125: how to manage the existing packages and some important information regarding
                   8126: their internals.
                   8127:
                   8128: We need your help!
                   8129:
                   8130: Should you have some spare cycles to devote to NetBSD, pkgsrc and GNOME and are
                   8131: willing to learn new exciting stuff, please jump straight to the pending work
                   8132: list! There is still a long way to go to get a fully-functional GNOME desktop
                   8133: under NetBSD and we need your help to achieve it!
                   8134:
1.107     rillig   8135: 23.1. Meta packages
1.85      jmmv     8136:
                   8137: pkgsrc includes three GNOME-related meta packages:
                   8138:
                   8139:   * meta-pkgs/gnome-base: Provides the core GNOME desktop environment. It only
                   8140:     includes the necessary bits to get it to boot correctly, although it may
                   8141:     lack important functionality for daily operation. The idea behind this
                   8142:     package is to let end users build their own configurations on top of this
                   8143:     one, first installing this meta package to achieve a functional setup and
                   8144:     then adding individual applications.
                   8145:
                   8146:   * meta-pkgs/gnome: Provides a complete installation of the GNOME platform and
                   8147:     desktop as defined by the GNOME project; this is based on the components
                   8148:     distributed in the platform/x.y/x.y.z/sources and desktop/x.y/x.y.z/sources
                   8149:     directories of the official FTP server. Developer-only tools found in those
                   8150:     directories are not installed unless required by some other component to
                   8151:     work properly. Similarly, packages from the bindings set (bindings/x.y/
                   8152:     x.y.z/sources) are not pulled in unless required as a dependency for an
                   8153:     end-user component. This package "extends" meta-pkgs/gnome-base.
                   8154:
                   8155:   * meta-pkgs/gnome-devel: Installs all the tools required to build a GNOME
                   8156:     component when fetched from the CVS repository. These are required to let
                   8157:     the autogen.sh scripts work appropriately.
                   8158:
                   8159: In all these packages, the DEPENDS lines are sorted in a way that eases
                   8160: updates: a package may depend on other packages listed before it but not on any
1.132     wiz      8161: listed after it. It is very important to keep this order to ease updates so...
1.85      jmmv     8162: do not change it to alphabetical sorting!
                   8163:
1.107     rillig   8164: 23.2. Packaging a GNOME application
1.85      jmmv     8165:
                   8166: Almost all GNOME applications are written in C and use a common set of tools as
                   8167: their build system. Things get different with the new bindings to other
                   8168: languages (such as Python), but the following will give you a general idea on
                   8169: the minimum required tools:
                   8170:
                   8171:   * Almost all GNOME applications use the GNU Autotools as their build system.
                   8172:     As a general rule you will need to tell this to your package:
                   8173:
                   8174:     GNU_CONFIGURE=yes
                   8175:     USE_LIBTOOL=yes
                   8176:     USE_TOOLS+=gmake
                   8177:
                   8178:   * If the package uses pkg-config to detect dependencies, add this tool to the
                   8179:     list of required utilities:
                   8180:
                   8181:     USE_TOOLS+=pkg-config
                   8182:
                   8183:     Also use pkgtools/verifypc at the end of the build process to ensure that
                   8184:     you did not miss to specify any dependency in your package and that the
                   8185:     version requirements are all correct.
                   8186:
1.93      rillig   8187:   * If the package uses intltool, be sure to add intltool to the USE_TOOLS to
                   8188:     handle dependencies and to force the package to use the latest available
                   8189:     version.
1.85      jmmv     8190:
                   8191:   * If the package uses gtk-doc (a documentation generation utility), do not
                   8192:     add a dependency on it. The tool is rather big and the distfile should come
                   8193:     with pregenerated documentation anyway; if it does not, it is a bug that
                   8194:     you ought to report. For such packages you should disable gtk-doc (unless
1.89      rillig   8195:     it is the default):
1.85      jmmv     8196:
                   8197:     CONFIGURE_ARGS+=--disable-gtk-doc
1.89      rillig   8198:
                   8199:     The default location of installed HTML files (share/gtk-doc/<package-name>)
                   8200:     is correct and should not be changed unless the package insists on
                   8201:     installing them somewhere else. Otherwise programs as devhelp will not be
                   8202:     able to open them. You can do that with an entry similar to:
                   8203:
                   8204:     CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
1.85      jmmv     8205:
                   8206: GNOME uses multiple shared directories and files under the installation prefix
                   8207: to maintain databases. In this context, shared means that those exact same
                   8208: directories and files are used among several different packages, leading to
                   8209: conflicts in the PLIST. pkgsrc currently includes functionality to handle the
                   8210: most common cases, so you have to forget about using @unexec ${RMDIR} lines in
                   8211: your file lists and omitting shared files from them. If you find yourself doing
                   8212: those, your package is most likely incorrect.
                   8213:
                   8214: The following table lists the common situations that result in using shared
                   8215: directories or files. For each of them, the appropriate solution is given.
1.132     wiz      8216: After applying the solution be sure to regenerate the package's file list with
1.85      jmmv     8217: make print-PLIST and ensure it is correct.
                   8218:
1.107     rillig   8219: Table 23.1. PLIST handling for GNOME packages
1.85      jmmv     8220:
                   8221: +-----------------------------------------------------------------------------+
                   8222: |             If the package...             |             Then...             |
                   8223: |-------------------------------------------+---------------------------------|
1.107     rillig   8224: |                                           |See Section 19.6.10, "Packages   |
1.120     mishka   8225: |Installs OMF files under share/omf.        |installing scrollkeeper/rarian   |
                   8226: |                                           |data files".                     |
1.85      jmmv     8227: |-------------------------------------------+---------------------------------|
1.107     rillig   8228: |Installs icons under the share/icons/      |See Section 19.6.19, "Packages   |
1.85      jmmv     8229: |hicolor hierarchy or updates share/icons/  |installing hicolor theme icons". |
                   8230: |hicolor/icon-theme.cache.                  |                                 |
                   8231: |-------------------------------------------+---------------------------------|
1.107     rillig   8232: |                                           |See Section 19.6.14, "Packages   |
1.85      jmmv     8233: |Installs files under share/mime/packages.  |installing extensions to the MIME|
                   8234: |                                           |database".                       |
                   8235: |-------------------------------------------+---------------------------------|
1.107     rillig   8236: |Installs .desktop files under share/       |See Section 19.6.20, "Packages   |
1.85      jmmv     8237: |applications and these include MIME        |installing desktop files".       |
                   8238: |information.                               |                                 |
                   8239: +-----------------------------------------------------------------------------+
                   8240:
1.91      rillig   8241:
1.107     rillig   8242: 23.3. Updating GNOME to a newer version
1.85      jmmv     8243:
                   8244: When seeing GNOME as a whole, there are two kinds of updates:
                   8245:
                   8246: Major update
                   8247:
                   8248:     Given that there is still a very long way for GNOME 3 (if it ever appears),
                   8249:     we consider a major update one that goes from a 2.X version to a 2.Y one,
                   8250:     where Y is even and greater than X. These are hard to achieve because they
                   8251:     introduce lots of changes in the components' code and almost all GNOME
                   8252:     distfiles are updated to newer versions. Some of them can even break API
                   8253:     and ABI compatibility with the previous major version series. As a result,
                   8254:     the update needs to be done all at once to minimize breakage.
                   8255:
                   8256:     A major update typically consists of around 80 package updates and the
                   8257:     addition of some new ones.
                   8258:
                   8259: Minor update
                   8260:
                   8261:     We consider a minor update one that goes from a 2.A.X version to a 2.A.Y
                   8262:     one where Y is greater than X. These are easy to achieve because they do
                   8263:     not update all GNOME components, can be done in an incremental way and do
                   8264:     not break API nor ABI compatibility.
                   8265:
                   8266:     A minor update typically consists of around 50 package updates, although
                   8267:     the numbers here may vary a lot.
                   8268:
                   8269: In order to update the GNOME components in pkgsrc to a new stable release
                   8270: (either major or minor), the following steps should be followed:
                   8271:
                   8272:  1. Get a list of all the tarballs that form the new release by using the
1.121     snj      8273:     following commands. These will leave the full list of the components'
1.85      jmmv     8274:     distfiles into the list.txt file:
                   8275:
1.88      wiz      8276:     % echo ls "*.tar.bz2" | \
1.85      jmmv     8277:         ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
                   8278:         awk '{ print $9 }' >list.txt
1.88      wiz      8279:     % echo ls "*.tar.bz2" | \
1.85      jmmv     8280:         ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
                   8281:         awk '{ print $9 }' >>list.txt
                   8282:
                   8283:  2. Open each meta package's Makefile and bump their version to the release you
                   8284:     are updating them to. The three meta packages should be always consistent
                   8285:     with versioning. Obviously remove any PKGREVISIONs that might be in them.
                   8286:
                   8287:  3. For each meta package, update all its DEPENDS lines to match the latest
                   8288:     versions as shown by the above commands. Do not list any newer version
                   8289:     (even if found in the FTP) because the meta packages are supposed to list
                   8290:     the exact versions that form a specific GNOME release. Exceptions are
                   8291:     permitted here if a newer version solves a serious issue in the overall
                   8292:     desktop experience; these typically come in the form of a revision bump in
                   8293:     pkgsrc, not in newer versions from the developers.
                   8294:
                   8295:     Packages not listed in the list.txt file should be updated to the latest
                   8296:     version available (if found in pkgsrc). This is the case, for example, of
                   8297:     the dependencies on the GNU Autotools in the meta-pkgs/gnome-devel meta
                   8298:     package.
                   8299:
                   8300:  4. Generate a patch from the modified meta packages and extract the list of
                   8301:     "new" lines. This will provide you an outline on what packages need to be
                   8302:     updated in pkgsrc and in what order:
                   8303:
1.93      rillig   8304:     % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt
1.85      jmmv     8305:
                   8306:  5. For major desktop updates it is recommended to zap all your installed
                   8307:     packages and start over from scratch at this point.
                   8308:
                   8309:  6. Now comes the longest step by far: iterate over the contents of todo.txt
                   8310:     and update the packages listed in it in order. For major desktop updates
1.93      rillig   8311:     none of these should be committed until the entire set is completed because
1.85      jmmv     8312:     there are chances of breaking not-yet-updated packages.
                   8313:
                   8314:  7. Once the packages are up to date and working, commit them to the tree one
                   8315:     by one with appropriate log messages. At the end, commit the three meta
                   8316:     package updates and all the corresponding changes to the doc/CHANGES-<YEAR>
                   8317:     and pkgsrc/doc/TODO files.
                   8318:
1.107     rillig   8319: 23.4. Patching guidelines
1.85      jmmv     8320:
                   8321: GNOME is a very big component in pkgsrc which approaches 100 packages. Please,
                   8322: it is very important that you always, always, always feed back any portability
                   8323: fixes you do to a GNOME package to the mainstream developers (see
1.107     rillig   8324: Section 11.3.5, "Feedback to the author"). This is the only way to get their
1.85      jmmv     8325: attention on portability issues and to ensure that future versions can be built
                   8326: out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further
                   8327: updates are. Those developers in charge of issuing major GNOME updates will be
                   8328: grateful if you do that.
                   8329:
                   8330: The most common places to report bugs are the GNOME's Bugzilla and the
                   8331: freedesktop.org's Bugzilla. Not all components use these to track bugs, but
                   8332: most of them do. Do not be short on your reports: always provide detailed
                   8333: explanations of the current failure, how it can be improved to achieve maximum
                   8334: portability and, if at all possible, provide a patch against CVS head. The more
                   8335: verbose you are, the higher chances of your patch being accepted.
                   8336:
                   8337: Also, please avoid using preprocessor magic to fix portability issues. While
                   8338: the FreeBSD GNOME people are doing a great job in porting GNOME to their
                   8339: operating system, the official GNOME sources are now plagued by conditionals
                   8340: that check for __FreeBSD__ and similar macros. This hurts portability. Please
1.107     rillig   8341: see our patching guidelines (Section 11.3.4, "Patching guidelines") for more
1.85      jmmv     8342: details.
                   8343:
1.73      rillig   8344: Part III. The pkgsrc infrastructure internals
                   8345:
                   8346: This part of the guide deals with everything from the infrastructure that is
                   8347: behind the interfaces described in the developer's guide. A casual package
                   8348: maintainer should not need anything from this part.
1.72      rillig   8349:
                   8350: Table of Contents
                   8351:
1.107     rillig   8352: 24. Design of the pkgsrc infrastructure
1.73      rillig   8353:
1.107     rillig   8354:     24.1. The meaning of variable definitions
                   8355:     24.2. Avoiding problems before they arise
                   8356:     24.3. Variable evaluation
1.81      rillig   8357:
1.107     rillig   8358:         24.3.1. At load time
                   8359:         24.3.2. At runtime
1.73      rillig   8360:
1.107     rillig   8361:     24.4. How can variables be specified?
                   8362:     24.5. Designing interfaces for Makefile fragments
1.73      rillig   8363:
1.107     rillig   8364:         24.5.1. Procedures with parameters
                   8365:         24.5.2. Actions taken on behalf of parameters
1.73      rillig   8366:
1.107     rillig   8367:     24.6. The order in which files are loaded
1.81      rillig   8368:
1.107     rillig   8369:         24.6.1. The order in bsd.prefs.mk
                   8370:         24.6.2. The order in bsd.pkg.mk
1.73      rillig   8371:
1.107     rillig   8372: 25. Regression tests
1.73      rillig   8373:
1.107     rillig   8374:     25.1. The regression tests framework
                   8375:     25.2. Running the regression tests
                   8376:     25.3. Adding a new regression test
1.73      rillig   8377:
1.107     rillig   8378:         25.3.1. Overridable functions
                   8379:         25.3.2. Helper functions
1.73      rillig   8380:
1.107     rillig   8381: 26. Porting pkgsrc
1.73      rillig   8382:
1.107     rillig   8383:     26.1. Porting pkgsrc to a new operating system
                   8384:     26.2. Adding support for a new compiler
1.73      rillig   8385:
1.107     rillig   8386: Chapter 24. Design of the pkgsrc infrastructure
1.73      rillig   8387:
                   8388: Table of Contents
                   8389:
1.107     rillig   8390: 24.1. The meaning of variable definitions
                   8391: 24.2. Avoiding problems before they arise
                   8392: 24.3. Variable evaluation
1.81      rillig   8393:
1.107     rillig   8394:     24.3.1. At load time
                   8395:     24.3.2. At runtime
1.81      rillig   8396:
1.107     rillig   8397: 24.4. How can variables be specified?
                   8398: 24.5. Designing interfaces for Makefile fragments
1.73      rillig   8399:
1.107     rillig   8400:     24.5.1. Procedures with parameters
                   8401:     24.5.2. Actions taken on behalf of parameters
1.73      rillig   8402:
1.107     rillig   8403: 24.6. The order in which files are loaded
1.73      rillig   8404:
1.107     rillig   8405:     24.6.1. The order in bsd.prefs.mk
                   8406:     24.6.2. The order in bsd.pkg.mk
1.73      rillig   8407:
                   8408: The pkgsrc infrastructure consists of many small Makefile fragments. Each such
                   8409: fragment needs a properly specified interface. This chapter explains how such
                   8410: an interface looks like.
                   8411:
1.107     rillig   8412: 24.1. The meaning of variable definitions
1.81      rillig   8413:
                   8414: Whenever a variable is defined in the pkgsrc infrastructure, the location and
                   8415: the way of definition provide much information about the intended use of that
                   8416: variable. Additionally, more documentation may be found in a header comment or
                   8417: in this pkgsrc guide.
                   8418:
                   8419: A special file is mk/defaults/mk.conf, which lists all variables that are
                   8420: intended to be user-defined. They are either defined using the ?= operator or
                   8421: they are left undefined because defining them to anything would effectively
                   8422: mean "yes". All these variables may be overridden by the pkgsrc user in the
                   8423: MAKECONF file.
                   8424:
                   8425: Outside this file, the following conventions apply: Variables that are defined
                   8426: using the ?= operator may be overridden by a package.
                   8427:
                   8428: Variables that are defined using the = operator may be used read-only at
                   8429: run-time.
                   8430:
                   8431: Variables whose name starts with an underscore must not be accessed outside the
                   8432: pkgsrc infrastructure at all. They may change without further notice.
                   8433:
                   8434: Note
1.73      rillig   8435:
1.81      rillig   8436: These conventions are currently not applied consistently to the complete pkgsrc
                   8437: infrastructure.
                   8438:
1.107     rillig   8439: 24.2. Avoiding problems before they arise
1.81      rillig   8440:
                   8441: All variables that contain lists of things should default to being empty. Two
                   8442: examples that do not follow this rule are USE_LANGUAGES and DISTFILES. These
                   8443: variables cannot simply be modified using the += operator in package Makefiles
                   8444: (or other files included by them), since there is no guarantee whether the
                   8445: variable is already set or not, and what its value is. In the case of
                   8446: DISTFILES, the packages "know" the default value and just define it as in the
                   8447: following example.
                   8448:
1.101     rillig   8449: DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
1.81      rillig   8450:
                   8451: Because of the selection of this default value, the same value appears in many
                   8452: package Makefiles. Similarly for USE_LANGUAGES, but in this case the default
                   8453: value ("c") is so short that it doesn't stand out. Nevertheless it is mentioned
                   8454: in many files.
                   8455:
1.107     rillig   8456: 24.3. Variable evaluation
1.81      rillig   8457:
1.107     rillig   8458: 24.3.1. At load time
1.73      rillig   8459:
                   8460: Variable evaluation takes place either at load time or at runtime, depending on
                   8461: the context in which they occur. The contexts where variables are evaluated at
                   8462: load time are:
                   8463:
                   8464:   * The right hand side of the := and != operators,
                   8465:
                   8466:   * Make directives like .if or .for,
                   8467:
                   8468:   * Dependency lines.
                   8469:
                   8470: A special exception are references to the iteration variables of .for loops,
                   8471: which are expanded inline, no matter in which context they appear.
                   8472:
                   8473: As the values of variables may change during load time, care must be taken not
                   8474: to evaluate them by accident. Typical examples for variables that should not be
                   8475: evaluated at load time are DEPENDS and CONFIGURE_ARGS. To make the effect more
                   8476: clear, here is an example:
                   8477:
1.101     rillig   8478: CONFIGURE_ARGS=         # none
                   8479: CFLAGS=                 -O
                   8480: CONFIGURE_ARGS+=        CFLAGS=${CFLAGS:Q}
1.73      rillig   8481:
1.101     rillig   8482: CONFIGURE_ARGS:=        ${CONFIGURE_ARGS}
1.73      rillig   8483:
1.101     rillig   8484: CFLAGS+=                -Wall
1.73      rillig   8485:
                   8486:
                   8487: This code shows how the use of the := operator can quickly lead to unexpected
                   8488: results. The first paragraph is fairly common code. The second paragraph
                   8489: evaluates the CONFIGURE_ARGS variable, which results in CFLAGS=-O. In the third
                   8490: paragraph, the -Wall is appended to the CFLAGS, but this addition will not
                   8491: appear in CONFIGURE_ARGS. In actual code, the three paragraphs from above
                   8492: typically occur in completely unrelated files.
                   8493:
1.107     rillig   8494: 24.3.2. At runtime
1.73      rillig   8495:
                   8496: After all the files have been loaded, the values of the variables cannot be
                   8497: changed anymore. Variables that are used in the shell commands are expanded at
                   8498: this point.
                   8499:
1.107     rillig   8500: 24.4. How can variables be specified?
1.78      rillig   8501:
                   8502: There are many ways in which the definition and use of a variable can be
                   8503: restricted in order to detect bugs and violations of the (mostly unwritten)
                   8504: policies. See the pkglint developer's documentation for further details.
                   8505:
1.107     rillig   8506: 24.5. Designing interfaces for Makefile fragments
1.73      rillig   8507:
                   8508: Most of the .mk files fall into one of the following classes. Cases where a
                   8509: file falls into more than one class should be avoided as it often leads to
                   8510: subtle bugs.
                   8511:
1.107     rillig   8512: 24.5.1. Procedures with parameters
1.73      rillig   8513:
                   8514: In a traditional imperative programming language some of the .mk files could be
1.128     jakllsch 8515: described as procedures. They take some input parameters and?after
                   8516: inclusion?provide a result in output parameters. Since all variables in
                   8517: Makefiles have global scope care must be taken not to use parameter names that
                   8518: have already another meaning. For example, PKGNAME is a bad choice for a
                   8519: parameter name.
1.73      rillig   8520:
                   8521: Procedures are completely evaluated at preprocessing time. That is, when
                   8522: calling a procedure all input parameters must be completely resolvable. For
                   8523: example, CONFIGURE_ARGS should never be an input parameter since it is very
                   8524: likely that further text will be added after calling the procedure, which would
                   8525: effectively apply the procedure to only a part of the variable. Also,
                   8526: references to other variables wit will be modified after calling the procedure.
                   8527:
                   8528: A procedure can declare its output parameters either as suitable for use in
                   8529: preprocessing directives or as only available at runtime. The latter
                   8530: alternative is for variables that contain references to other runtime
                   8531: variables.
                   8532:
                   8533: Procedures shall be written such that it is possible to call the procedure more
                   8534: than once. That is, the file must not contain multiple-inclusion guards.
1.72      rillig   8535:
1.73      rillig   8536: Examples for procedures are mk/bsd.options.mk and mk/buildlink3/bsd.builtin.mk.
                   8537: To express that the parameters are evaluated at load time, they should be
                   8538: assigned using the := operator, which should be used only for this purpose.
1.72      rillig   8539:
1.107     rillig   8540: 24.5.2. Actions taken on behalf of parameters
1.72      rillig   8541:
1.73      rillig   8542: Action files take some input parameters and may define runtime variables. They
                   8543: shall not define loadtime variables. There are action files that are included
                   8544: implicitly by the pkgsrc infrastructure, while other must be included
                   8545: explicitly.
1.72      rillig   8546:
1.73      rillig   8547: An example for action files is mk/subst.mk.
1.72      rillig   8548:
1.107     rillig   8549: 24.6. The order in which files are loaded
1.81      rillig   8550:
                   8551: Package Makefiles usually consist of a set of variable definitions, and include
                   8552: the file ../../mk/bsd.pkg.mk in the very last line. Before that, they may also
                   8553: include various other *.mk files if they need to query the availability of
                   8554: certain features like the type of compiler or the X11 implementation. Due to
                   8555: the heavy use of preprocessor directives like .if and .for, the order in which
                   8556: the files are loaded matters.
                   8557:
                   8558: This section describes at which point the various files are loaded and gives
                   8559: reasons for that order.
                   8560:
1.107     rillig   8561: 24.6.1. The order in bsd.prefs.mk
1.81      rillig   8562:
1.93      rillig   8563: The very first action in bsd.prefs.mk is to define some essential variables
                   8564: like OPSYS, OS_VERSION and MACHINE_ARCH.
1.81      rillig   8565:
1.105     rillig   8566: Then, the user settings are loaded from the file specified in MAKECONF, which
                   8567: is usually mk.conf. After that, those variables that have not been overridden
                   8568: by the user are loaded from mk/defaults/mk.conf.
1.81      rillig   8569:
                   8570: After the user settings, the system settings and platform settings are loaded,
                   8571: which may override the user settings.
                   8572:
                   8573: Then, the tool definitions are loaded. The tool wrappers are not yet in effect.
                   8574: This only happens when building a package, so the proper variables must be used
                   8575: instead of the direct tool names.
                   8576:
                   8577: As the last steps, some essential variables from the wrapper and the package
                   8578: system flavor are loaded, as well as the variables that have been cached in
                   8579: earlier phases of a package build.
                   8580:
1.107     rillig   8581: 24.6.2. The order in bsd.pkg.mk
1.81      rillig   8582:
                   8583: First, bsd.prefs.mk is loaded.
                   8584:
                   8585: Then, the various *-vars.mk files are loaded, which fill default values for
1.93      rillig   8586: those variables that have not been defined by the package. These variables may
                   8587: later be used even in unrelated files.
1.81      rillig   8588:
                   8589: Then, the file bsd.pkg.error.mk provides the target error-check that is added
                   8590: as a special dependency to all other targets that use DELAYED_ERROR_MSG or
                   8591: DELAYED_WARNING_MSG.
                   8592:
                   8593: Then, the package-specific hacks from hacks.mk are included.
                   8594:
                   8595: Then, various other files follow. Most of them don't have any dependencies on
                   8596: what they need to have included before or after them, though some do.
                   8597:
                   8598: The code to check PKG_FAIL_REASON and PKG_SKIP_REASON is then executed, which
                   8599: restricts the use of these variables to all the files that have been included
                   8600: before. Appearances in later files will be silently ignored.
                   8601:
                   8602: Then, the files for the main targets are included, in the order of later
                   8603: execution, though the actual order should not matter.
                   8604:
                   8605: At last, some more files are included that don't set any interesting variables
                   8606: but rather just define make targets to be executed.
                   8607:
1.107     rillig   8608: Chapter 25. Regression tests
1.72      rillig   8609:
                   8610: Table of Contents
                   8611:
1.107     rillig   8612: 25.1. The regression tests framework
                   8613: 25.2. Running the regression tests
                   8614: 25.3. Adding a new regression test
1.72      rillig   8615:
1.107     rillig   8616:     25.3.1. Overridable functions
                   8617:     25.3.2. Helper functions
1.72      rillig   8618:
                   8619: The pkgsrc infrastructure consists of a large codebase, and there are many
                   8620: corners where every little bit of a file is well thought out, making pkgsrc
                   8621: likely to fail as soon as anything is changed near those parts. To prevent most
                   8622: changes from breaking anything, a suite of regression tests should go along
                   8623: with every important part of the pkgsrc infrastructure. This chapter describes
                   8624: how regression tests work in pkgsrc and how you can add new tests.
                   8625:
1.107     rillig   8626: 25.1. The regression tests framework
1.72      rillig   8627:
1.107     rillig   8628: 25.2. Running the regression tests
1.72      rillig   8629:
1.132     wiz      8630: You first need to install the pkgtools/pkg_regress package, which provides the
1.72      rillig   8631: pkg_regress command. Then you can simply run that command, which will run all
                   8632: tests in the regress category.
                   8633:
1.107     rillig   8634: 25.3. Adding a new regression test
1.72      rillig   8635:
                   8636: Every directory in the regress category that contains a file called spec is
                   8637: considered a regression test. This file is a shell program that is included by
                   8638: the pkg_regress command. The following functions can be overridden to suit your
                   8639: needs.
                   8640:
1.107     rillig   8641: 25.3.1. Overridable functions
1.72      rillig   8642:
                   8643: These functions do not take any parameters. They are all called in "set -e"
                   8644: mode, so you should be careful to check the exitcodes of any commands you run
                   8645: in the test.
                   8646:
                   8647: do_setup()
                   8648:
                   8649:     This function prepares the environment for the test. By default it does
                   8650:     nothing.
                   8651:
                   8652: do_test()
                   8653:
                   8654:     This function runs the actual test. By default, it calls TEST_MAKE with the
                   8655:     arguments MAKEARGS_TEST and writes its output including error messages into
                   8656:     the file TEST_OUTFILE.
                   8657:
                   8658: check_result()
                   8659:
                   8660:     This function is run after the test and is typically used to compare the
                   8661:     actual output from the one that is expected. It can make use of the various
                   8662:     helper functions from the next section.
                   8663:
                   8664: do_cleanup()
                   8665:
                   8666:     This function cleans everything up after the test has been run. By default
                   8667:     it does nothing.
                   8668:
1.107     rillig   8669: 25.3.2. Helper functions
1.72      rillig   8670:
                   8671: exit_status(expected)
                   8672:
                   8673:     This function compares the exitcode of the do_test() function with its
                   8674:     first parameter. If they differ, the test will fail.
                   8675:
                   8676: output_require(regex...)
                   8677:
                   8678:     This function checks for each of its parameters if the output from do_test
                   8679:     () matches the extended regular expression. If it does not, the test will
                   8680:     fail.
                   8681:
                   8682: output_prohibit(regex...)
                   8683:
                   8684:     This function checks for each of its parameters if the output from do_test
                   8685:     () does not match the extended regular expression. If any of the regular
                   8686:     expressions matches, the test will fail.
                   8687:
1.107     rillig   8688: Chapter 26. Porting pkgsrc
1.79      rillig   8689:
                   8690: Table of Contents
                   8691:
1.107     rillig   8692: 26.1. Porting pkgsrc to a new operating system
                   8693: 26.2. Adding support for a new compiler
1.69      rillig   8694:
                   8695: The pkgsrc system has already been ported to many operating systems, hardware
                   8696: architectures and compilers. This chapter explains the necessary steps to make
                   8697: pkgsrc even more portable.
                   8698:
1.107     rillig   8699: 26.1. Porting pkgsrc to a new operating system
1.69      rillig   8700:
                   8701: To port pkgsrc to a new operating system (called MyOS in this example), you
                   8702: need to touch the following files:
                   8703:
1.93      rillig   8704: pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk
1.69      rillig   8705:
                   8706:     This file contains some basic definitions, for example the name of the C
                   8707:     compiler.
                   8708:
                   8709: mk/bsd.prefs.mk
                   8710:
                   8711:     Insert code that defines the variables OPSYS, OS_VERSION, LOWER_OS_VERSION,
                   8712:     LOWER_VENDOR, MACHINE_ARCH, OBJECT_FMT, APPEND_ELF, and the other variables
                   8713:     that appear in this file.
                   8714:
                   8715: mk/platform/MyOS.mk
                   8716:
                   8717:     This file contains the platform-specific definitions that are used by
                   8718:     pkgsrc. Start by copying one of the other files and edit it to your needs.
                   8719:
                   8720: mk/platform/MyOS.pkg.dist
                   8721:
                   8722:     This file contains a list of directories, together with their permission
                   8723:     bits and ownership. These directories will be created automatically with
1.99      wiz      8724:     every package that explicitly sets USE_MTREE. This feature will be removed.
1.69      rillig   8725:
                   8726: mk/platform/MyOS.x11.dist
                   8727:
                   8728:     Just copy one of the pre-existing x11.dist files to your MyOS.x11.dist.
                   8729:
                   8730: mk/tools/bootstrap.mk
                   8731:
                   8732:     On some operating systems, the tools that are provided with the base system
                   8733:     are not good enough for pkgsrc. For example, there are many versions of sed
                   8734:     (1) that have a narrow limit on the line length they can process. Therefore
                   8735:     pkgsrc brings its own tools, which can be enabled here.
                   8736:
1.93      rillig   8737: mk/tools/tools.MyOS.mk
1.69      rillig   8738:
                   8739:     This file defines the paths to all the tools that are needed by one or the
                   8740:     other package in pkgsrc, as well as by pkgsrc itself. Find out where these
                   8741:     tools are on your platform and add them.
                   8742:
                   8743: Now, you should be able to build some basic packages, like lang/perl5, shells/
                   8744: bash.
                   8745:
1.107     rillig   8746: 26.2. Adding support for a new compiler
1.69      rillig   8747:
                   8748: TODO
                   8749:
1.46      gdt      8750: Appendix A. A simple example package: bison
1.1       grant    8751:
                   8752: Table of Contents
                   8753:
1.46      gdt      8754: A.1. files
1.20      ben      8755:
1.46      gdt      8756:     A.1.1. Makefile
                   8757:     A.1.2. DESCR
                   8758:     A.1.3. PLIST
                   8759:     A.1.4. Checking a package with pkglint
1.20      ben      8760:
1.46      gdt      8761: A.2. Steps for building, installing, packaging
1.1       grant    8762:
                   8763: We checked to find a piece of software that wasn't in the packages collection,
1.132     wiz      8764: and picked GNU bison. Quite why someone would want to have bison when Berkeley
1.1       grant    8765: yacc is already present in the tree is beyond us, but it's useful for the
                   8766: purposes of this exercise.
                   8767:
1.46      gdt      8768: A.1. files
1.1       grant    8769:
1.46      gdt      8770: A.1.1. Makefile
1.1       grant    8771:
1.101     rillig   8772: # $NetBSD$
                   8773: #
1.51      rillig   8774:
1.101     rillig   8775: DISTNAME=       bison-1.25
                   8776: CATEGORIES=     devel
                   8777: MASTER_SITES=   ${MASTER_SITE_GNU}
                   8778:
                   8779: MAINTAINER=     thorpej@NetBSD.org
                   8780: HOMEPAGE=       http://www.gnu.org/software/bison/bison.html
                   8781: COMMENT=        GNU yacc clone
1.1       grant    8782:
1.101     rillig   8783: GNU_CONFIGURE=  yes
                   8784: INFO_FILES=     bison.info
1.1       grant    8785:
1.101     rillig   8786: .include "../../mk/bsd.pkg.mk"
1.1       grant    8787:
1.46      gdt      8788: A.1.2. DESCR
1.1       grant    8789:
1.101     rillig   8790: GNU version of yacc.  Can make re-entrant parsers, and numerous other
                   8791: improvements.  Why you would want this when Berkeley yacc(1) is part
                   8792: of the NetBSD source tree is beyond me.
1.1       grant    8793:
1.46      gdt      8794: A.1.3. PLIST
1.1       grant    8795:
1.101     rillig   8796: @comment $NetBSD$
                   8797: bin/bison
                   8798: man/man1/bison.1.gz
                   8799: share/bison.simple
                   8800: share/bison.hairy
1.1       grant    8801:
1.46      gdt      8802: A.1.4. Checking a package with pkglint
1.1       grant    8803:
                   8804: The NetBSD package system comes with pkgtools/pkglint which helps to check the
                   8805: contents of these files. After installation it is quite easy to use, just
                   8806: change to the directory of the package you wish to examine and execute pkglint:
                   8807:
                   8808: $ pkglint
                   8809: looks fine.
                   8810:
1.60      rillig   8811: Depending on the supplied command line arguments (see pkglint(1)), more checks
                   8812: will be performed. Use e.g. pkglint -Call -Wall for a very thorough check.
1.1       grant    8813:
1.46      gdt      8814: A.2. Steps for building, installing, packaging
1.1       grant    8815:
                   8816: Create the directory where the package lives, plus any auxiliary directories:
                   8817:
                   8818: # cd /usr/pkgsrc/lang
                   8819: # mkdir bison
                   8820: # cd bison
                   8821: # mkdir patches
                   8822:
1.107     rillig   8823: Create Makefile, DESCR and PLIST (see Chapter 11, Package components - files,
1.1       grant    8824: directories and contents) then continue with fetching the distfile:
                   8825:
                   8826: # make fetch
                   8827: >> bison-1.25.tar.gz doesn't seem to exist on this system.
                   8828: >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
                   8829: Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
                   8830: ftp: Error retrieving file: 500 Internal error
                   8831:
                   8832: >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
                   8833: Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
                   8834: ftp: Error retrieving file: 500 Internal error
                   8835:
                   8836: >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
                   8837: Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
                   8838: Successfully retrieved file.
                   8839:
                   8840: Generate the checksum of the distfile into distinfo:
                   8841:
1.88      wiz      8842: # make makedistinfo
1.1       grant    8843:
                   8844: Now compile:
                   8845:
                   8846: # make
                   8847: >> Checksum OK for bison-1.25.tar.gz.
                   8848: ===>  Extracting for bison-1.25
                   8849: ===>  Patching for bison-1.25
                   8850: ===>   Ignoring empty patch directory
                   8851: ===>  Configuring for bison-1.25
                   8852: creating cache ./config.cache
                   8853: checking for gcc... cc
                   8854: checking whether we are using GNU C... yes
                   8855: checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
                   8856: checking how to run the C preprocessor... cc -E
                   8857: checking for minix/config.h... no
                   8858: checking for POSIXized ISC... no
                   8859: checking whether cross-compiling... no
                   8860: checking for ANSI C header files... yes
                   8861: checking for string.h... yes
                   8862: checking for stdlib.h... yes
                   8863: checking for memory.h... yes
                   8864: checking for working const... yes
                   8865: checking for working alloca.h... no
                   8866: checking for alloca... yes
                   8867: checking for strerror... yes
                   8868: updating cache ./config.cache
                   8869: creating ./config.status
                   8870: creating Makefile
                   8871: ===>  Building for bison-1.25
                   8872: 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
                   8873: 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
                   8874: 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
                   8875: 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
                   8876: 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      8877: 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    8878: 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
                   8879: 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
                   8880: 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
                   8881: 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
                   8882: 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
                   8883: 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
                   8884: 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
                   8885: 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
                   8886: 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
                   8887: 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
                   8888: 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
                   8889: 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
                   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 version.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 getopt.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 getopt1.c
                   8893: 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
                   8894: ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
                   8895: rm -f bison.s1
                   8896: sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
                   8897:
                   8898: Everything seems OK, so install the files:
                   8899:
                   8900: # make install
                   8901: >> Checksum OK for bison-1.25.tar.gz.
                   8902: ===>  Installing for bison-1.25
                   8903: sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
                   8904: rm -f /usr/pkg/bin/bison
                   8905: cd /usr/pkg/share; rm -f bison.simple bison.hairy
                   8906: rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
                   8907: install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
                   8908: /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
                   8909: /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
                   8910: cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
                   8911: /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
                   8912: ===>  Registering installation for bison-1.25
                   8913:
                   8914: You can now use bison, and also - if you decide so - remove it with pkg_delete
                   8915: bison. Should you decide that you want a binary package, do this now:
                   8916:
                   8917: # make package
                   8918: >> Checksum OK for bison-1.25.tar.gz.
                   8919: ===>  Building package for bison-1.25
                   8920: Creating package bison-1.25.tgz
                   8921: Registering depends:.
                   8922: Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
                   8923:
                   8924: Now that you don't need the source and object files any more, clean up:
                   8925:
                   8926: # make clean
                   8927: ===>  Cleaning for bison-1.25
                   8928:
1.46      gdt      8929: Appendix B. Build logs
1.1       grant    8930:
                   8931: Table of Contents
                   8932:
1.46      gdt      8933: B.1. Building figlet
                   8934: B.2. Packaging figlet
1.1       grant    8935:
1.46      gdt      8936: B.1. Building figlet
1.1       grant    8937:
                   8938: # make
                   8939: ===> Checking for vulnerabilities in figlet-2.2.1nb2
                   8940: => figlet221.tar.gz doesn't seem to exist on this system.
                   8941: => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
                   8942: => [172219 bytes]
                   8943: Connected to ftp.plig.net.
                   8944: 220 ftp.plig.org NcFTPd Server (licensed copy) ready.
                   8945: 331 Guest login ok, send your complete e-mail address as password.
                   8946: 230-You are user #5 of 500 simultaneous users allowed.
                   8947: 230-
1.20      ben      8948: 230-  ___ _             _ _
                   8949: 230- |  _| |_ ___   ___| |_|___   ___ ___ ___
1.1       grant    8950: 230- |  _|  _| . |_| . | | | . |_| . |  _| . |
                   8951: 230- |_| |_| |  _|_|  _|_|_|_  |_|___|_| |_  |
                   8952: 230-         |_|   |_|     |___|         |___|
                   8953: 230-
                   8954: 230-** Welcome to ftp.plig.org **
                   8955: 230-
                   8956: 230-Please note that all transfers from this FTP site are logged. If you
                   8957: 230-do not like this, please disconnect now.
                   8958: 230-
1.121     snj      8959: 230-This archive is available via
1.1       grant    8960: 230-
                   8961: 230-HTTP:  http://ftp.plig.org/
                   8962: 230-FTP:   ftp://ftp.plig.org/     (max 500 connections)
                   8963: 230-RSYNC: rsync://ftp.plig.org/   (max  30 connections)
                   8964: 230-
                   8965: 230-Please email comments, bug reports and requests for packages to be
1.20      ben      8966: 230-mirrored to ftp-admin@plig.org.
1.1       grant    8967: 230-
                   8968: 230-
                   8969: 230 Logged in anonymously.
                   8970: Remote system type is UNIX.
                   8971: Using binary mode to transfer files.
                   8972: 200 Type okay.
                   8973: 250 "/pub" is new cwd.
                   8974: 250-"/pub/figlet" is new cwd.
                   8975: 250-
                   8976: 250-Welcome to the figlet archive at ftp.figlet.org
1.20      ben      8977: 250-
1.1       grant    8978: 250-    ftp://ftp.figlet.org/pub/figlet/
                   8979: 250-
                   8980: 250-The official FIGlet web page is:
                   8981: 250-    http://www.figlet.org/
                   8982: 250-
                   8983: 250-If you have questions, please mailto:info@figlet.org. If you want to
                   8984: 250-contribute a font or something else, you can email us.
1.20      ben      8985: 250
1.1       grant    8986: 250 "/pub/figlet/program" is new cwd.
                   8987: 250 "/pub/figlet/program/unix" is new cwd.
                   8988: local: figlet221.tar.gz remote: figlet221.tar.gz
                   8989: 502 Unimplemented command.
                   8990: 227 Entering Passive Mode (195,40,6,41,246,104)
                   8991: 150 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
                   8992: 38% |**************                       | 65800      64.16 KB/s    00:01 ETA
                   8993: 226 Transfer completed.
                   8994: 172219 bytes received in 00:02 (75.99 KB/s)
                   8995: 221 Goodbye.
                   8996: => Checksum OK for figlet221.tar.gz.
                   8997: ===> Extracting for figlet-2.2.1nb2
                   8998: ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found
                   8999: ===> Patching for figlet-2.2.1nb2
                   9000: ===> Applying pkgsrc patches for figlet-2.2.1nb2
                   9001: ===> Overriding tools for figlet-2.2.1nb2
                   9002: ===> Creating toolchain wrappers for figlet-2.2.1nb2
                   9003: ===> Configuring for figlet-2.2.1nb2
                   9004: ===> Building for figlet-2.2.1nb2
                   9005: gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\"  -DDEFAULTFONTFILE=\"standard.flf\"  figlet.c zipio.c crc.c inflate.c -o figlet
                   9006: chmod a+x figlet
                   9007: gcc -O2 -o chkfont chkfont.c
                   9008: => Unwrapping files-to-be-installed.
                   9009: #
                   9010: # make install
                   9011: ===> Checking for vulnerabilities in figlet-2.2.1nb2
                   9012: ===> Installing for figlet-2.2.1nb2
                   9013: install -d -o root -g wheel -m 755 /usr/pkg/bin
                   9014: install -d -o root -g wheel -m 755 /usr/pkg/man/man6
                   9015: mkdir -p /usr/pkg/share/figlet
                   9016: cp figlet /usr/pkg/bin
                   9017: cp chkfont /usr/pkg/bin
                   9018: chmod 555 figlist showfigfonts
                   9019: cp figlist /usr/pkg/bin
                   9020: cp showfigfonts /usr/pkg/bin
                   9021: cp fonts/*.flf /usr/pkg/share/figlet
                   9022: cp fonts/*.flc /usr/pkg/share/figlet
                   9023: cp figlet.6 /usr/pkg/man/man6
                   9024: ===> Registering installation for figlet-2.2.1nb2
                   9025: #
                   9026:
1.46      gdt      9027: B.2. Packaging figlet
1.1       grant    9028:
                   9029: # make package
                   9030: ===> Checking for vulnerabilities in figlet-2.2.1nb2
                   9031: ===> Packaging figlet-2.2.1nb2
                   9032: ===> Building binary package for figlet-2.2.1nb2
                   9033: Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
                   9034: Using SrcDir value of /usr/pkg
1.20      ben      9035: Registering depends:.
1.1       grant    9036: #
                   9037:
1.76      rillig   9038: Appendix C. Directory layout of the pkgsrc FTP server
                   9039:
                   9040: Table of Contents
                   9041:
1.128     jakllsch 9042: C.1. distfiles: The distributed source files
                   9043: C.2. misc: Miscellaneous things
                   9044: C.3. packages: Binary packages
                   9045: C.4. reports: Bulk build reports
                   9046: C.5. current, pkgsrc-20xxQy: source packages
1.76      rillig   9047:
                   9048: As in other big projects, the directory layout of pkgsrc is quite complex for
                   9049: newbies. This chapter explains where you find things on the FTP server. The
1.89      rillig   9050: base directory on ftp.NetBSD.org is /pub/pkgsrc/. On other servers it may be
                   9051: different, but inside this directory, everything should look the same, no
                   9052: matter on which server you are. This directory contains some subdirectories,
                   9053: which are explained below.
1.76      rillig   9054:
1.128     jakllsch 9055: C.1. distfiles: The distributed source files
1.76      rillig   9056:
                   9057: The directory distfiles contains lots of archive files from all pkgsrc
                   9058: packages, which are mirrored here. The subdirectories are called after their
                   9059: package names and are used when the distributed files have names that don't
                   9060: explicitly contain a version number or are otherwise too generic (for example
                   9061: release.tar.gz).
                   9062:
1.128     jakllsch 9063: C.2. misc: Miscellaneous things
1.76      rillig   9064:
                   9065: This directory contains things that individual pkgsrc developers find worth
                   9066: publishing.
                   9067:
1.128     jakllsch 9068: C.3. packages: Binary packages
1.76      rillig   9069:
1.103     rillig   9070: This directory contains binary packages for the various platforms that are
                   9071: supported by pkgsrc. Each subdirectory is of the form OPSYS/ARCH/OSVERSION_TAG.
                   9072: The meaning of these variables is:
                   9073:
                   9074:   * OPSYS is the name of the operating system for which the packages have been