Annotation of pkgsrc/doc/pkgsrc.txt, Revision 1.51
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.48 dillo 15: Copyright (C) 1994-2005 The NetBSD Foundation, Inc
1.1 grant 16:
1.48 dillo 17: $NetBSD: pkgsrc.xml,v 1.10 2005/10/05 13:59:56 dillo Exp $
1.1 grant 18:
19: Abstract
20:
21: Information about using the NetBSD package system (pkgsrc) from both a user
22: view for installing packages as well as from a pkgsrc developers' view for
23: creating new packages.
24:
25: -------------------------------------------------------------------------------
26:
27: Table of Contents
28:
1.51 ! rillig 29: 1. What is pkgsrc?
1.20 ben 30:
1.1 grant 31: 1.1. Introduction
32: 1.2. Overview
33: 1.3. Terminology
34: 1.4. Typography
1.20 ben 35:
1.46 gdt 36: I. The pkgsrc user's guide
1.20 ben 37:
1.1 grant 38: 2. Where to get pkgsrc
1.20 ben 39:
1.1 grant 40: 2.1. As tar file
41: 2.2. Via SUP
42: 2.3. Via CVS
1.20 ben 43:
1.1 grant 44: 3. Using pkgsrc on systems other than NetBSD
1.20 ben 45:
1.1 grant 46: 3.1. Bootstrapping pkgsrc
1.47 reed 47: 3.2. Platform-specific notes
1.20 ben 48:
1.1 grant 49: 3.2.1. Darwin (Mac OS X)
50: 3.2.2. FreeBSD
51: 3.2.3. Interix
52: 3.2.4. IRIX
1.22 tv 53: 3.2.5. Linux
54: 3.2.6. OpenBSD
55: 3.2.7. Solaris
1.20 ben 56:
1.1 grant 57: 4. Using pkgsrc
1.20 ben 58:
1.1 grant 59: 4.1. Working with binary packages
1.20 ben 60:
1.1 grant 61: 4.1.1. Where to get binary packages
62: 4.1.2. How to use binary packages
63: 4.1.3. A word of warning
1.20 ben 64:
1.1 grant 65: 4.2. Building packages from source
1.20 ben 66:
1.1 grant 67: 4.2.1. Requirements
68: 4.2.2. Fetching distfiles
69: 4.2.3. How to build and install
70: 4.2.4. Selecting the compiler
1.20 ben 71:
1.38 dillo 72: 5. Configuring pkgsrc
1.20 ben 73:
1.45 wiz 74: 5.1. General configuration
75: 5.2. Variables affecting the build process
76: 5.3. Developer/advanced settings
77: 5.4. Selecting Build Options
1.38 dillo 78:
79: 6. Creating binary packages
80:
81: 6.1. Building a single binary package
82: 6.2. Settings for creation of binary packages
83: 6.3. Doing a bulk build of all packages
84:
85: 6.3.1. Configuration
86: 6.3.2. Other environmental considerations
87: 6.3.3. Operation
88: 6.3.4. What it does
89: 6.3.5. Disk space requirements
1.47 reed 90: 6.3.6. Setting up a sandbox for chrooted builds
1.38 dillo 91: 6.3.7. Building a partial set of packages
92: 6.3.8. Uploading results of a bulk build
93:
94: 6.4. Creating a multiple CD-ROM packages collection
95:
96: 6.4.1. Example of cdpack
97:
98: 7. Frequently Asked Questions
99:
100: 7.1. Are there any mailing lists for pkg-related discussion?
101: 7.2. Where's the pkgviews documentation?
102: 7.3. Utilities for package management (pkgtools)
103: 7.4. How to use pkgsrc as non-root
104: 7.5. How to resume transfers when fetching distfiles?
105: 7.6. How can I install/use XFree86 from pkgsrc?
106: 7.7. How can I install/use X.org from pkgsrc?
107: 7.8. How to fetch files from behind a firewall
108: 7.9. How do I tell make fetch to do passive FTP?
109: 7.10. How to fetch all distfiles at once
110: 7.11. What does "Don't know how to make /usr/share/tmac/tmac.andoc"
1.14 xtraeme 111: mean?
1.38 dillo 112: 7.12. What does "Could not find bsd.own.mk" mean?
113: 7.13. Using 'sudo' with pkgsrc
114: 7.14. How do I change the location of configuration files?
115: 7.15. Automated security checks
1.20 ben 116:
1.46 gdt 117: II. The pkgsrc developer's guide
1.20 ben 118:
1.38 dillo 119: 8. Package components - files, directories and contents
1.20 ben 120:
1.38 dillo 121: 8.1. Makefile
122: 8.2. distinfo
123: 8.3. patches/*
124: 8.4. Other mandatory files
125: 8.5. Optional files
126: 8.6. work*
127: 8.7. files/*
1.20 ben 128:
1.38 dillo 129: 9. Programming in Makefiles
1.27 rillig 130:
1.38 dillo 131: 9.1. Makefile variables
1.27 rillig 132:
1.38 dillo 133: 9.1.1. Naming conventions
1.27 rillig 134:
1.38 dillo 135: 9.2. Code snippets
1.27 rillig 136:
1.38 dillo 137: 9.2.1. Adding things to a list
138: 9.2.2. Converting an internal list into an external list
139: 9.2.3. Passing variables to a shell command
140: 9.2.4. Quoting guideline
141: 9.2.5. Workaround for a bug in BSD Make
1.20 ben 142:
1.38 dillo 143: 10. PLIST issues
1.20 ben 144:
1.38 dillo 145: 10.1. RCS ID
146: 10.2. Semi-automatic PLIST generation
147: 10.3. Tweaking output of make print-PLIST
148: 10.4. Variable substitution in PLIST
1.48 dillo 149: 10.5. Man page compression
1.38 dillo 150: 10.6. Changing PLIST source with PLIST_SRC
1.47 reed 151: 10.7. Platform-specific and differing PLISTs
1.38 dillo 152: 10.8. Sharing directories between packages
1.20 ben 153:
1.38 dillo 154: 11. Buildlink methodology
1.20 ben 155:
1.38 dillo 156: 11.1. Converting packages to use buildlink3
157: 11.2. Writing buildlink3.mk files
1.20 ben 158:
1.38 dillo 159: 11.2.1. Anatomy of a buildlink3.mk file
160: 11.2.2. Updating BUILDLINK_DEPENDS.pkg in buildlink3.mk files
1.20 ben 161:
1.38 dillo 162: 11.3. Writing builtin.mk files
1.20 ben 163:
1.38 dillo 164: 11.3.1. Anatomy of a builtin.mk file
165: 11.3.2. Global preferences for native or pkgsrc software
1.20 ben 166:
1.38 dillo 167: 12. The pkginstall framework
1.20 ben 168:
1.38 dillo 169: 12.1. Files and directories outside the installation prefix
1.20 ben 170:
1.38 dillo 171: 12.1.1. Directory manipulation
172: 12.1.2. File manipulation
1.20 ben 173:
1.38 dillo 174: 12.2. Configuration files
1.35 jmmv 175:
1.38 dillo 176: 12.2.1. How PKG_SYSCONFDIR is set
1.47 reed 177: 12.2.2. Telling the software where configuration files are
1.38 dillo 178: 12.2.3. Patching installations
179: 12.2.4. Disabling handling of configuration files
1.35 jmmv 180:
1.38 dillo 181: 12.3. System startup scripts
1.35 jmmv 182:
1.38 dillo 183: 12.3.1. Disabling handling of system startup scripts
1.35 jmmv 184:
1.38 dillo 185: 12.4. System users and groups
186: 12.5. System shells
1.35 jmmv 187:
1.38 dillo 188: 12.5.1. Disabling handling of configuration files
1.35 jmmv 189:
1.38 dillo 190: 13. Options handling
1.35 jmmv 191:
1.38 dillo 192: 13.1. Global default options
193: 13.2. Converting packages to use bsd.options.mk
1.48 dillo 194: 13.3. Option Names
1.35 jmmv 195:
1.38 dillo 196: 14. The build process
1.35 jmmv 197:
1.38 dillo 198: 14.1. Program location
199: 14.2. Main targets
200: 14.3. Other helpful targets
1.35 jmmv 201:
1.38 dillo 202: 15. Notes on fixes for packages
1.35 jmmv 203:
1.38 dillo 204: 15.1. General operation
1.35 jmmv 205:
1.38 dillo 206: 15.1.1. How to pull in variables from /etc/mk.conf
207: 15.1.2. Where to install documentation
208: 15.1.3. Restricted packages
209: 15.1.4. Handling dependencies
210: 15.1.5. Handling conflicts with other packages
211: 15.1.6. Packages that cannot or should not be built
212: 15.1.7. Packages which should not be deleted, once installed
213: 15.1.8. Handling packages with security problems
214: 15.1.9. How to handle compiler bugs
215: 15.1.10. How to handle incrementing versions when fixing an
1.31 wiz 216: existing package
1.38 dillo 217: 15.1.11. Portability of packages
1.20 ben 218:
1.38 dillo 219: 15.2. Possible downloading issues
1.20 ben 220:
1.38 dillo 221: 15.2.1. Packages whose distfiles aren't available for plain
1.1 grant 222: downloading
1.38 dillo 223: 15.2.2. How to handle modified distfiles with the 'old' name
1.20 ben 224:
1.38 dillo 225: 15.3. Configuration gotchas
1.20 ben 226:
1.38 dillo 227: 15.3.1. Shared libraries - libtool
228: 15.3.2. Using libtool on GNU packages that already support libtool
229: 15.3.3. GNU Autoconf/Automake
230:
231: 15.4. Building considerations
232:
233: 15.4.1. CPP defines
1.51 ! rillig 234: 15.4.2. Getting a list of CPP defines
1.38 dillo 235:
236: 15.5. Package specific actions
237:
238: 15.5.1. User interaction
239: 15.5.2. Handling licenses
240: 15.5.3. Installing score files
241: 15.5.4. Packages containing perl scripts
242: 15.5.5. Packages with hardcoded paths to other interpreters
243: 15.5.6. Packages installing perl modules
244: 15.5.7. Packages installing info files
245: 15.5.8. Packages installing GConf2 data files
246: 15.5.9. Packages installing scrollkeeper data files
247: 15.5.10. Packages installing X11 fonts
248: 15.5.11. Packages installing GTK2 modules
249: 15.5.12. Packages installing SGML or XML data
250: 15.5.13. Packages installing extensions to the MIME database
251: 15.5.14. Packages using intltool
252: 15.5.15. Packages installing startup scripts
253:
254: 15.6. Feedback to the author
255:
256: 16. Debugging
257: 17. Submitting and Committing
258:
259: 17.1. Submitting your packages
1.41 wiz 260: 17.2. General notes when adding, updating, or removing packages
261: 17.3. Committing: Importing a package into CVS
262: 17.4. Updating a package to a newer version
263: 17.5. Moving a package in pkgsrc
1.20 ben 264:
1.46 gdt 265: A. A simple example package: bison
1.20 ben 266:
1.46 gdt 267: A.1. files
1.20 ben 268:
1.46 gdt 269: A.1.1. Makefile
270: A.1.2. DESCR
271: A.1.3. PLIST
272: A.1.4. Checking a package with pkglint
1.20 ben 273:
1.46 gdt 274: A.2. Steps for building, installing, packaging
1.20 ben 275:
1.46 gdt 276: B. Build logs
1.20 ben 277:
1.46 gdt 278: B.1. Building figlet
279: B.2. Packaging figlet
1.20 ben 280:
1.46 gdt 281: C. Layout of the FTP server's package archive
282: D. Editing guidelines for the pkgsrc guide
1.20 ben 283:
1.46 gdt 284: D.1. Targets
285: D.2. Procedure
1.20 ben 286:
1.51 ! rillig 287: Chapter 1. What is pkgsrc?
1.1 grant 288:
289: Table of Contents
290:
291: 1.1. Introduction
292: 1.2. Overview
293: 1.3. Terminology
294: 1.4. Typography
295:
296: 1.1. Introduction
297:
1.47 reed 298: There is a lot of software freely available for Unix-based systems, which
1.1 grant 299: usually runs on NetBSD and other Unix-flavoured systems, too, sometimes with
300: some modifications. The NetBSD Packages Collection (pkgsrc) incorporates any
301: such changes necessary to make that software run, and makes the installation
302: (and de-installation) of the software package easy by means of a single
303: command.
304:
305: Once the software has been built, it is manipulated with the pkg_* tools so
306: that installation and de-installation, printing of an inventory of all
307: installed packages and retrieval of one-line comments or more verbose
308: descriptions are all simple.
309:
310: pkgsrc currently contains several thousand packages, including:
311:
312: * www/apache - The Apache web server
1.20 ben 313:
1.1 grant 314: * www/mozilla - The Mozilla web browser
1.20 ben 315:
1.1 grant 316: * meta-pkgs/gnome - The GNOME Desktop Environment
1.20 ben 317:
1.1 grant 318: * meta-pkgs/kde3 - The K Desktop Environment
1.20 ben 319:
1.1 grant 320: ...just to name a few.
321:
322: pkgsrc has built-in support for handling varying dependencies, such as pthreads
323: and X11, and extended features such as IPv6 support on a range of platforms.
324:
325: pkgsrc was derived from FreeBSD's ports system, and initially developed for
326: NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
327: platforms:
328:
329: * Darwin (Mac OS X)
1.20 ben 330:
1.3 hubertf 331: * DragonFlyBSD
1.20 ben 332:
1.1 grant 333: * FreeBSD
1.20 ben 334:
1.3 hubertf 335: * Microsoft Windows, via Interix
1.20 ben 336:
1.1 grant 337: * IRIX
1.20 ben 338:
1.1 grant 339: * Linux
1.20 ben 340:
1.1 grant 341: * NetBSD (of course)
1.20 ben 342:
1.17 sketch 343: * Tru64 (Digital UNIX, OSF1)
1.20 ben 344:
1.1 grant 345: * OpenBSD
1.20 ben 346:
1.1 grant 347: * Solaris
1.20 ben 348:
1.1 grant 349: 1.2. Overview
350:
1.2 hubertf 351: This document is divided into two parts. The first, The pkgsrc user's guide,
1.1 grant 352: describes how one can use one of the packages in the Package Collection, either
353: by installing a precompiled binary package, or by building one's own copy using
1.2 hubertf 354: the NetBSD package system. The second part, The pkgsrc developer's guide,
355: explains how to prepare a package so it can be easily built by other NetBSD
356: users without knowing about the package's building details.
1.1 grant 357:
358: This document is available in various formats:
359:
360: * HTML
1.20 ben 361:
1.1 grant 362: * PDF
1.20 ben 363:
1.1 grant 364: * PS
1.20 ben 365:
1.1 grant 366: * TXT
1.20 ben 367:
1.1 grant 368: 1.3. Terminology
369:
370: There has been a lot of talk about "ports", "packages", etc. so far. Here is a
371: description of all the terminology used within this document.
372:
373: Package
1.20 ben 374:
1.1 grant 375: A set of files and building instructions that describe what's necessary to
376: build a certain piece of software using pkgsrc. Packages are traditionally
377: stored under /usr/pkgsrc.
1.20 ben 378:
1.1 grant 379: The NetBSD package system
1.20 ben 380:
1.1 grant 381: This is the former name of "pkgsrc". It is part of the NetBSD operating
1.27 rillig 382: system and can be bootstrapped to run on non-NetBSD operating systems as
383: well. It handles building (compiling), installing, and removing of
384: packages.
1.20 ben 385:
1.1 grant 386: Distfile
1.20 ben 387:
1.1 grant 388: This term describes the file or files that are provided by the author of
389: the piece of software to distribute his work. All the changes necessary to
390: build on NetBSD are reflected in the corresponding package. Usually the
391: distfile is in the form of a compressed tar-archive, but other types are
392: possible, too. Distfiles are usually stored below /usr/pkgsrc/distfiles.
1.20 ben 393:
1.1 grant 394: Port
1.20 ben 395:
1.1 grant 396: This is the term used by FreeBSD and OpenBSD people for what we call a
397: package. In NetBSD terminology, "port" refers to a different architecture.
1.20 ben 398:
1.1 grant 399: Precompiled/binary package
1.20 ben 400:
1.1 grant 401: A set of binaries built with pkgsrc from a distfile and stuffed together in
402: a single .tgz file so it can be installed on machines of the same machine
403: architecture without the need to recompile. Packages are usually generated
404: in /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.
1.20 ben 405:
1.1 grant 406: Sometimes, this is referred to by the term "package" too, especially in the
407: context of precompiled packages.
1.20 ben 408:
1.1 grant 409: Program
1.20 ben 410:
1.1 grant 411: The piece of software to be installed which will be constructed from all
1.47 reed 412: the files in the distfile by the actions defined in the corresponding
1.1 grant 413: package.
1.20 ben 414:
1.1 grant 415: 1.4. Typography
416:
417: When giving examples for commands, shell prompts are used to show if the
418: command should/can be issued as root, or if "normal" user privileges are
1.27 rillig 419: sufficient. We use a # for root's shell prompt, and a % for users' shell
1.1 grant 420: prompt, assuming they use the C-shell or tcsh.
421:
1.48 dillo 422: Part I. The pkgsrc user's guide
1.1 grant 423:
424: Table of Contents
425:
426: 2. Where to get pkgsrc
1.20 ben 427:
1.1 grant 428: 2.1. As tar file
429: 2.2. Via SUP
430: 2.3. Via CVS
1.20 ben 431:
1.1 grant 432: 3. Using pkgsrc on systems other than NetBSD
1.20 ben 433:
1.1 grant 434: 3.1. Bootstrapping pkgsrc
1.47 reed 435: 3.2. Platform-specific notes
1.20 ben 436:
1.1 grant 437: 3.2.1. Darwin (Mac OS X)
438: 3.2.2. FreeBSD
439: 3.2.3. Interix
440: 3.2.4. IRIX
1.22 tv 441: 3.2.5. Linux
442: 3.2.6. OpenBSD
443: 3.2.7. Solaris
1.20 ben 444:
1.1 grant 445: 4. Using pkgsrc
1.20 ben 446:
1.1 grant 447: 4.1. Working with binary packages
1.20 ben 448:
1.1 grant 449: 4.1.1. Where to get binary packages
450: 4.1.2. How to use binary packages
451: 4.1.3. A word of warning
1.20 ben 452:
1.1 grant 453: 4.2. Building packages from source
1.20 ben 454:
1.1 grant 455: 4.2.1. Requirements
456: 4.2.2. Fetching distfiles
457: 4.2.3. How to build and install
458: 4.2.4. Selecting the compiler
1.20 ben 459:
1.38 dillo 460: 5. Configuring pkgsrc
461:
1.45 wiz 462: 5.1. General configuration
463: 5.2. Variables affecting the build process
464: 5.3. Developer/advanced settings
465: 5.4. Selecting Build Options
1.20 ben 466:
1.38 dillo 467: 6. Creating binary packages
468:
469: 6.1. Building a single binary package
470: 6.2. Settings for creation of binary packages
471: 6.3. Doing a bulk build of all packages
472:
473: 6.3.1. Configuration
474: 6.3.2. Other environmental considerations
475: 6.3.3. Operation
476: 6.3.4. What it does
477: 6.3.5. Disk space requirements
1.47 reed 478: 6.3.6. Setting up a sandbox for chrooted builds
1.38 dillo 479: 6.3.7. Building a partial set of packages
480: 6.3.8. Uploading results of a bulk build
481:
482: 6.4. Creating a multiple CD-ROM packages collection
483:
484: 6.4.1. Example of cdpack
485:
486: 7. Frequently Asked Questions
487:
488: 7.1. Are there any mailing lists for pkg-related discussion?
489: 7.2. Where's the pkgviews documentation?
490: 7.3. Utilities for package management (pkgtools)
491: 7.4. How to use pkgsrc as non-root
492: 7.5. How to resume transfers when fetching distfiles?
493: 7.6. How can I install/use XFree86 from pkgsrc?
494: 7.7. How can I install/use X.org from pkgsrc?
495: 7.8. How to fetch files from behind a firewall
496: 7.9. How do I tell make fetch to do passive FTP?
497: 7.10. How to fetch all distfiles at once
498: 7.11. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
499: 7.12. What does "Could not find bsd.own.mk" mean?
500: 7.13. Using 'sudo' with pkgsrc
501: 7.14. How do I change the location of configuration files?
502: 7.15. Automated security checks
1.20 ben 503:
1.1 grant 504: Chapter 2. Where to get pkgsrc
505:
506: Table of Contents
507:
508: 2.1. As tar file
509: 2.2. Via SUP
510: 2.3. Via CVS
511:
512: There are three ways to get pkgsrc. Either as a tar file, via SUP, or via CVS.
513: All three ways are described here.
514:
515: 2.1. As tar file
516:
517: To get pkgsrc going, you need to get the pkgsrc.tar.gz file from ftp.NetBSD.org
518: and unpack it into /usr/pkgsrc.
519:
520: 2.2. Via SUP
521:
522: As an alternative to the tar file, you can get pkgsrc via the Software Update
523: Protocol, SUP. To do so, make sure your supfile has a line
524:
1.51 ! rillig 525: release=pkgsrc
1.1 grant 526:
527: in it, see the examples in /usr/share/examples/supfiles, and that the /usr/
528: pkgsrc directory exists. Then, simply run sup -v /path/to/your/supfile.
529:
530: 2.3. Via CVS
531:
1.27 rillig 532: To get pkgsrc via CVS, make sure you have "cvs" installed. To do an initial
533: (full) checkout of pkgsrc, do the following steps:
1.1 grant 534:
535: % setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot
536: % setenv CVS_RSH ssh
537: % cd /usr
538: % cvs checkout -P pkgsrc
539:
540: This will create the pkgsrc directory in your /usr, and all the package source
541: will be stored under /usr/pkgsrc. To update pkgsrc after the initial checkout,
542: make sure you have CVS_RSH set as above, then do:
543:
544: % cd /usr/pkgsrc
545: % cvs -q update -dP
546:
547: Please also note that it is possible to have multiple copies of the pkgsrc
548: hierarchy in use at any one time - all work is done relatively within the
549: pkgsrc tree.
550:
551: Chapter 3. Using pkgsrc on systems other than NetBSD
552:
553: Table of Contents
554:
555: 3.1. Bootstrapping pkgsrc
1.47 reed 556: 3.2. Platform-specific notes
1.20 ben 557:
1.1 grant 558: 3.2.1. Darwin (Mac OS X)
559: 3.2.2. FreeBSD
560: 3.2.3. Interix
561: 3.2.4. IRIX
1.22 tv 562: 3.2.5. Linux
563: 3.2.6. OpenBSD
564: 3.2.7. Solaris
1.20 ben 565:
1.1 grant 566: 3.1. Bootstrapping pkgsrc
567:
1.27 rillig 568: For operating systems other than NetBSD, we provide a bootstrap kit to build
1.1 grant 569: the required tools to use pkgsrc on your platform. Besides support for native
570: NetBSD, pkgsrc and the bootstrap kit have support for the following operating
571: systems:
572:
573: * Darwin (Mac OS X)
1.20 ben 574:
1.16 grant 575: * DragonFlyBSD
1.20 ben 576:
1.1 grant 577: * FreeBSD
1.20 ben 578:
1.1 grant 579: * Interix (Windows 2000, XP, 2003)
1.20 ben 580:
1.1 grant 581: * IRIX
1.20 ben 582:
1.1 grant 583: * Linux
1.20 ben 584:
1.1 grant 585: * OpenBSD
1.20 ben 586:
1.1 grant 587: * Solaris
1.20 ben 588:
1.16 grant 589: * Tru64 (Digital UNIX/OSF1)
1.20 ben 590:
1.1 grant 591: Support for other platforms is under development.
592:
593: Installing the bootstrap kit should be as simple as:
594:
595: # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
596: # cd pkgsrc/bootstrap
597: # ./bootstrap
598:
599: See Chapter 2, Where to get pkgsrc for other ways to get pkgsrc before
600: bootstrapping. The given bootstrap command will use the defaults of /usr/pkg
601: for the prefix where programs will be installed in, and /var/db/pkg for the
1.27 rillig 602: package database directory where pkgsrc will do its internal bookkeeping.
603: However, these can also be set using command-line arguments.
1.1 grant 604:
605: Binary packages for the pkgsrc tools and an initial set of packages is
1.20 ben 606: available for supported platforms. An up-to-date list of these can be found on
1.1 grant 607: www.pkgsrc.org.
608:
1.47 reed 609: Note
610:
611: The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
612: For examples in this guide, use bmake instead of "make".
613:
614: 3.2. Platform-specific notes
1.1 grant 615:
616: Here are some platform-specific notes you should be aware of.
617:
618: 3.2.1. Darwin (Mac OS X)
619:
620: Darwin 5.x and 6.x are supported. There are two methods of using pkgsrc on Mac
621: OS X, by using a disk image, or a UFS partition.
622:
623: Before you start, you will need to download and install the Mac OS X Developer
624: Tools from Apple's Developer Connection. See http://developer.apple.com/macosx/
1.20 ben 625: for details. Also, make sure you install X11 for Mac OS X and the X11 SDK from
1.1 grant 626: http://www.apple.com/macosx/x11/download/ if you intend to build packages that
627: use the X11 Window System.
628:
629: If you already have a UFS partition, or have a spare partition that you can
630: format as UFS, it is recommended to use that instead of the disk image. It'll
631: be somewhat faster and will mount automatically at boot time, where you must
632: manually mount a disk image.
633:
634: Note
635:
636: You cannot use a HFS+ file system for pkgsrc, because pkgsrc currently requires
1.47 reed 637: the file system to be case-sensitive, and HFS+ is not.
1.1 grant 638:
639: 3.2.1.1. Using a disk image
640:
641: Create the disk image:
642:
643: # cd pkgsrc/bootstrap
644: # ./ufsdiskimage create ~/Documents/NetBSD 512 # megabytes - season to taste
645: # ./ufsdiskimage mount ~/Documents/NetBSD
646: # sudo chown `id -u`:`id -g` /Volumes/NetBSD
647:
648: That's it!
649:
650: 3.2.1.2. Using a UFS partition
651:
652: By default, /usr will be on your root file system, normally HFS+. It is
653: possible to use the default prefix of /usr/pkg by symlinking /usr/pkg to a
654: directory on a UFS file system. Obviously, another symlink is required if you
655: want to place the package database directory outside the prefix. e.g.
656:
1.22 tv 657: # ./bootstrap --pkgdbdir /usr/pkg/pkgdb --pkgsrcdir /Volumes/ufs/pkgsrc
1.1 grant 658:
659: If you created your partitions at the time of installing Mac OS X and formatted
660: the target partition as UFS, it should automatically mount on /Volumes/<volume
661: name> when the machine boots. If you are (re)formatting a partition as UFS, you
662: need to ensure that the partition map correctly reflects "Apple_UFS" and not
663: "Apple_HFS".
664:
665: The problem is that none of the disk tools will let you touch a disk that is
666: booted from. You can unmount the partition, but even if you newfs it, the
667: partition type will be incorrect and the automounter won't mount it. It can be
668: mounted manually, but it won't appear in Finder.
669:
670: You'll need to boot off of the OS X Installation (User) CD. When the
671: Installation program starts, go up to the menu and select Disk Utility. Now,
672: you will be able to select the partition you want to be UFS, and Format it
673: Apple UFS. Quit the Disk Utility, quit the installer which will reboot your
674: machine. The new UFS file system will appear in Finder.
675:
676: Be aware that the permissions on the new file system will be writable by root
677: only.
678:
679: This note is as of 10.2 (Jaguar) and applies to earlier versions. Hopefully
680: Apple will fix Disk Utility in 10.3 (Panther).
681:
682: 3.2.2. FreeBSD
683:
684: FreeBSD 4.7 and 5.0 have been tested and are supported, other versions may
685: work.
686:
687: Care should be taken so that the tools that this kit installs do not conflict
688: with the FreeBSD userland tools. There are several steps:
689:
690: 1. FreeBSD stores its ports pkg database in /var/db/pkg. It is therefore
691: recommended that you choose a different location (e.g. /usr/pkgdb) by using
692: the --pkgdbdir option to the bootstrap script.
1.20 ben 693:
1.1 grant 694: 2. If you do not intend to use the FreeBSD ports tools, it's probably a good
695: idea to move them out of the way to avoid confusion, e.g.
1.20 ben 696:
1.1 grant 697: # cd /usr/sbin
698: # mv pkg_add pkg_add.orig
699: # mv pkg_create pkg_create.orig
700: # mv pkg_delete pkg_delete.orig
701: # mv pkg_info pkg_info.orig
1.20 ben 702:
1.1 grant 703: 3. An example /etc/mk.conf file will be placed in /etc/mk.conf.example file
704: when you use the bootstrap script.
1.20 ben 705:
1.1 grant 706: 3.2.3. Interix
707:
1.47 reed 708: Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a
1.1 grant 709: Unix-like environment with a tighter kernel integration than available with
710: Cygwin. It is part of the Windows Services for Unix package, available for free
1.22 tv 711: for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU
712: can be downloaded from http://www.microsoft.com/windows/sfu/.
1.1 grant 713:
714: Services for Unix 3.5, current as of this writing, has been tested. 3.0 or 3.1
715: may work, but are not officially supported. (The main difference in 3.0/3.1 is
716: lack of pthreads.)
717:
1.2 hubertf 718: 3.2.3.1. When installing Interix/SFU
1.1 grant 719:
720: At an absolute minimum, the following packages must be installed from the
721: Windows Services for Unix 3.5 distribution in order to use pkgsrc:
722:
723: * Utilities -> Base Utilities
1.20 ben 724:
1.1 grant 725: * Interix GNU Components -> (all)
1.20 ben 726:
1.1 grant 727: * Remote Connectivity
1.20 ben 728:
1.1 grant 729: * Interix SDK
1.20 ben 730:
1.1 grant 731: When using pkgsrc on Interix, DO NOT install the Utilities subcomponent "UNIX
732: Perl". That is Perl 5.6 without shared module support, installed to /usr/local,
733: and will only cause confusion. Instead, install Perl 5.8 from pkgsrc (or from a
734: binary package).
735:
736: The Remote Connectivity subcomponent "Windows Remote Shell Service" does not
737: need to be installed, but Remote Connectivity itself should be installed in
738: order to have a working inetd.
739:
740: Finally, during installation you may be asked whether to enable setuid behavior
741: for Interix programs, and whether to make pathnames default to case-sensitive.
742: Setuid should be enabled, and case-sensitivity MUST be enabled. (Without
743: case-sensitivity, a large number of packages including perl will not build.)
744:
745: 3.2.3.2. What to do if Interix/SFU is already installed
746:
747: If SFU is already installed and you wish to alter these settings to work with
748: pkgsrc, note the following things.
749:
750: * To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft Windows
751: Services for UNIX, then click Change. In the installer, choose Add or
752: Remove, then uncheck Utilities->UNIX Perl.
1.20 ben 753:
1.47 reed 754: * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change
1.1 grant 755: the following registry key:
1.20 ben 756:
1.1 grant 757: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
1.20 ben 758:
1.1 grant 759: Set the DWORD value "obcaseinsensitive" to 0; then reboot.
1.20 ben 760:
1.1 grant 761: * To enable setuid binaries (optional), run REGEDIT.EXE, and change the
762: following registry key:
1.20 ben 763:
1.1 grant 764: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX
1.20 ben 765:
1.1 grant 766: Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.
1.20 ben 767:
1.1 grant 768: 3.2.3.3. Important notes for using pkgsrc
769:
770: The package imanager (either the pkgsrc "su" user, or the user running
771: "pkg_add") must be a member of the local Administrators group. Such a user must
772: also be used to run the bootstrap. This is slightly relaxed from the normal
773: pkgsrc requirement of "root".
774:
775: The package manager should use a umask of 002. "make install" will
776: automatically complain if this is not the case. This ensures that directories
777: written in /var/db/pkg are Administrators-group writeable.
778:
779: The popular Interix binary packages from http://www.interopsystems.com/ use an
780: older version of pkgsrc's pkg_* tools. Ideally, these should NOT be used in
781: conjunction with pkgsrc. If you choose to use them at the same time as the
782: pkgsrc packages, ensure that you use the proper pkg_* tools for each type of
783: binary package.
784:
1.22 tv 785: The TERM setting used for DOS-type console windows (including those invoked by
786: the csh and ksh startup shortcuts) is "interix". Most systems don't have a
787: termcap/terminfo entry for it, but the following .termcap entry provides
788: adequate emulation in most cases:
789:
1.51 ! rillig 790: interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
1.22 tv 791:
1.1 grant 792: 3.2.4. IRIX
793:
794: You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro
795: compiler (cc/c89). Please set the CC environment variable according to your
796: preference. If you do not have a license for the MIPSpro compiler suite, you
797: can download a gcc tardist file from http://freeware.sgi.com/.
798:
799: Please note that you will need IRIX 6.5.17 or higher, as this is the earliest
800: version of IRIX providing support for if_indextoname(3), if_nametoindex(3),
801: etc.
802:
1.27 rillig 803: At this point in time, pkgsrc only supports one ABI at a time. That is, you can
804: not switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit ABI.
805: If you start out using "abi=n32", that's what all your packages will be built
1.1 grant 806: with.
807:
808: Therefore, please make sure that you have no conflicting CFLAGS in your
809: environment or the /etc/mk.conf. Particularly, make sure that you do not try to
810: link n32 object files with lib64 or vice versa. Check your /etc/
811: compiler.defaults!
812:
813: If you have the actual pkgsrc tree mounted via NFS from a different host,
814: please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX
1.47 reed 815: linker occasionally runs into issues when trying to link over a network-mounted
816: file system.
1.1 grant 817:
818: The bootstrapping process should set all the right options for programs such as
819: imake(1), but you may want to set some options depending on your local setup.
1.27 rillig 820: Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages
1.11 ben 821: for details.
1.1 grant 822:
1.22 tv 823: If you are using SGI's MIPSPro compiler, please set
824:
1.51 ! rillig 825: PKGSRC_COMPILER= mipspro
1.22 tv 826:
827: in /etc/mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up
828: passing invalid flags to the compiler. Note that bootstrap should create an
829: appropriate mk.conf.example by default.
830:
831: If you have both the MIPSPro compiler chain installed as well as gcc, but want
832: to make sure that MIPRPro is used, please set your PATH to not include the
833: location of gcc (often /usr/freeware/bin), and (important) pass the
834: '--preserve-path' flag.
835:
836: 3.2.5. Linux
837:
838: Some versions of Linux (for example Debian GNU/Linux) need either libtermcap or
839: libcurses (libncurses). Installing the distributions libncurses-dev package (or
840: equivalent) should fix the problem.
841:
842: pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++
843: Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested.
844:
845: To bootstrap using icc, assuming the default icc installation directory:
846:
1.51 ! rillig 847: env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \
! 848: ac_cv___attribute__=yes ./bootstrap
1.22 tv 849:
850: Note
851:
852: icc 8.1 needs the `-i-static' argument instead of -static-libcxa.
853:
854: icc supports __attribute__, but the GNU configure test uses a nested function,
855: which icc does not support. #undef'ing __attribute__ has the unfortunate
856: side-effect of breaking many of the Linux header files, which cannot be
857: compiled properly without __attribute__. The test must be overridden so that
858: __attribute__ is assumed supported by the compiler.
859:
860: After bootstrapping, you should set PKGSRC_COMPILER in /etc/mk.conf:
861:
1.51 ! rillig 862: PKGSRC_COMPILER= icc
1.22 tv 863:
864: The default installation directory for icc is /opt/intel_cc_80, which is also
865: the pkgsrc default. If you have installed it into a different directory, set
866: ICCBASE in /etc/mk.conf:
867:
1.51 ! rillig 868: ICCBASE= /opt/icc
1.22 tv 869:
870: pkgsrc uses the static linking method of the runtime libraries provided by icc,
871: so binaries can be run on other systems which do not have the shared libraries
872: installed.
873:
874: Libtool, however, extracts a list of libraries from the ld(1) command run when
875: linking a C++ shared library and records it, throwing away the -Bstatic and
876: -Bdynamic options interspersed between the libraries. This means that
877: libtool-linked C++ shared libraries will have a runtime dependency on the icc
878: libraries until this is fixed in libtool.
879:
880: 3.2.6. OpenBSD
1.1 grant 881:
882: OpenBSD 3.0 and 3.2 are tested and supported.
883:
884: Care should be taken so that the tools that this kit installs do not conflict
885: with the OpenBSD userland tools. There are several steps:
886:
887: 1. OpenBSD stores its ports pkg database in /var/db/pkg. It is therefore
888: recommended that you choose a different location (e.g. /usr/pkgdb) by using
889: the --pkgdbdir option to the bootstrap script.
1.20 ben 890:
1.1 grant 891: 2. If you do not intend to use the OpenBSD ports tools, it's probably a good
892: idea to move them out of the way to avoid confusion, e.g.
1.20 ben 893:
1.1 grant 894: # cd /usr/sbin
895: # mv pkg_add pkg_add.orig
896: # mv pkg_create pkg_create.orig
897: # mv pkg_delete pkg_delete.orig
898: # mv pkg_info pkg_info.orig
1.20 ben 899:
1.1 grant 900: 3. An example /etc/mk.conf file will be placed in /etc/mk.conf.example file
901: when you use the bootstrap script. OpenBSD's make program uses /etc/mk.conf
1.47 reed 902: as well. You can work around this by enclosing all the pkgsrc-specific
1.1 grant 903: parts of the file with:
1.20 ben 904:
1.51 ! rillig 905: .ifdef BSD_PKG_MK
! 906: # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
! 907: .else
! 908: # OpenBSD stuff
! 909: .endif
1.20 ben 910:
1.1 grant 911:
1.22 tv 912: 3.2.7. Solaris
1.1 grant 913:
914: Solaris 2.6 through 9 are supported on both x86 and sparc. You will need a
915: working C compiler. Both gcc 2.95.3 and Sun WorkShop 5 have been tested.
916:
917: The following packages are required on Solaris 8 for the bootstrap process and
918: to build packages.
919:
920: * SUNWsprot
1.20 ben 921:
1.1 grant 922: * SUNWarc
1.20 ben 923:
1.1 grant 924: * SUNWbtool
1.20 ben 925:
1.1 grant 926: * SUNWtoo
1.20 ben 927:
1.1 grant 928: * SUNWlibm
1.20 ben 929:
1.1 grant 930: Please note the use of GNU binutils on Solaris is not supported.
931:
1.22 tv 932: 3.2.7.1. If you are using gcc
1.1 grant 933:
934: It makes life much simpler if you only use the same gcc consistently for
935: building all packages.
936:
937: It is recommended that an external gcc be used only for bootstrapping, then
938: either build gcc from lang/gcc or install a binary gcc package, then remove gcc
939: used during bootstrapping.
940:
941: Binary packages of gcc can be found through http://www.sun.com/bigadmin/common/
942: freewareSearch.html.
943:
1.22 tv 944: 3.2.7.2. If you are using Sun WorkShop
1.1 grant 945:
946: You will need at least the following packages installed (from WorkShop 5.0)
947:
948: * SPROcc - Sun WorkShop Compiler C 5.0
1.20 ben 949:
1.1 grant 950: * SPROcpl - Sun WorkShop Compiler C++ 5.0
1.20 ben 951:
1.1 grant 952: * SPROild - Sun WorkShop Incremental Linker
1.20 ben 953:
1.1 grant 954: * SPROlang - Sun WorkShop Compilers common components
1.20 ben 955:
1.47 reed 956: You should set CC, CXX and optionally, CPP in /etc/mk.conf, e.g.:
1.1 grant 957:
1.51 ! rillig 958: CC= cc
! 959: CXX= CC
! 960: CPP= /usr/ccs/lib/cpp
1.1 grant 961:
1.47 reed 962: You may also want to build 64-bit binaries, e.g.:
1.1 grant 963:
1.51 ! rillig 964: CFLAGS= -xtarget=ultra -xarch=v9
1.1 grant 965:
966: Whichever compiler you use, please ensure the compiler tools and your $prefix
1.47 reed 967: are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/
968: {bin,sbin}.
1.1 grant 969:
970: Chapter 4. Using pkgsrc
971:
972: Table of Contents
973:
974: 4.1. Working with binary packages
1.20 ben 975:
1.1 grant 976: 4.1.1. Where to get binary packages
977: 4.1.2. How to use binary packages
978: 4.1.3. A word of warning
1.20 ben 979:
1.1 grant 980: 4.2. Building packages from source
1.20 ben 981:
1.1 grant 982: 4.2.1. Requirements
983: 4.2.2. Fetching distfiles
984: 4.2.3. How to build and install
985: 4.2.4. Selecting the compiler
1.20 ben 986:
1.1 grant 987: 4.1. Working with binary packages
988:
989: This section describes how to find, retrieve and install a precompiled binary
990: package that someone else already prepared for your type of machine.
991:
992: 4.1.1. Where to get binary packages
993:
994: Precompiled packages are stored on ftp.NetBSD.org and its mirrors in the
1.27 rillig 995: directory /pub/NetBSD/packages/<OSVERSION>/<ARCH>/ for anonymous FTP access.
996: OSVERSION is the NetBSD version (uname -r), ARCH is the architecture (uname -p
997: ). In that directory, there is a subdirectory for each category plus a
998: subdirectory All which includes the actual binaries in .tgz files. The category
999: subdirectories use symbolic links to those files (this is the same directory
1000: layout as in /usr/pkgsrc/packages).
1.1 grant 1001:
1.47 reed 1002: This same directory layout applies for CD-ROM distributions, only that the
1.1 grant 1003: directory may be rooted somewhere else, probably somewhere below /cdrom. Please
1.47 reed 1004: consult your CD-ROMs documentation for the exact location.
1.1 grant 1005:
1006: 4.1.2. How to use binary packages
1007:
1.47 reed 1008: If you have the files on a CD-ROM or downloaded them to your hard disk, you can
1.27 rillig 1009: install them with the following command (be sure to su to root first):
1.1 grant 1010:
1011: # pkg_add /path/to/package.tgz
1012:
1013: If you have FTP access and you don't want to download the packages via FTP
1014: prior to installation, you can do this automatically by giving pkg_add an FTP
1015: URL:
1016:
1.27 rillig 1017: # pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All/package.tgz
1.1 grant 1018:
1.27 rillig 1019: Note that any prerequisite packages needed to run the package in question will
1020: be installed, too, assuming they are present where you install from.
1.1 grant 1021:
1.23 wiz 1022: To save some typing, you can set the PKG_PATH environment variable to a
1.47 reed 1023: semicolon-separated list of paths (including remote URLs); trailing slashes are
1.23 wiz 1024: not allowed.
1025:
1026: Additionally to the All directory there exists a vulnerable directory to which
1027: binary packages with known vulnerabilities are moved, since removing them could
1028: cause missing dependencies. To use these packages, add the vulnerable directory
1029: to your PKG_PATH. However, you should run security/audit-packages regularly,
1.47 reed 1030: especially after installing new packages, and verify that the vulnerabilities
1031: are acceptable for your configuration. An example PKG_PATH would be: ftp://
1032: ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All;ftp://ftp.NetBSD.org/
1033: pub/NetBSD/packages/<OSVERSION>/<ARCH>/vulnerable Please note that semicolon
1034: (';') is a shell meta-character, so you'll probably have to quote it.
1.23 wiz 1035:
1.27 rillig 1036: After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
1037: in your PATH so you can actually start the just installed program.
1.1 grant 1038:
1039: 4.1.3. A word of warning
1040:
1041: Please pay very careful attention to the warnings expressed in the pkg_add(1)
1042: manual page about the inherent dangers of installing binary packages which you
1043: did not create yourself, and the security holes that can be introduced onto
1044: your system by indiscriminate adding of such files.
1045:
1046: 4.2. Building packages from source
1047:
1.46 gdt 1048: This assumes that the package is already in pkgsrc. If it is not, see Part II,
1.27 rillig 1049: "The pkgsrc developer's guide" for instructions how to create your own
1050: packages.
1.1 grant 1051:
1052: 4.2.1. Requirements
1053:
1054: To build packages from source on a NetBSD system the "comp" and the "text"
1.47 reed 1055: distribution sets must be installed. If you want to build X11-related packages
1.1 grant 1056: the "xbase" and "xcomp" distribution sets are required, too.
1057:
1058: 4.2.2. Fetching distfiles
1059:
1.27 rillig 1060: The first step for building a package is downloading the distfiles (i.e. the
1061: unmodified source). If they have not yet been downloaded, pkgsrc will fetch
1062: them automatically.
1.1 grant 1063:
1064: You can overwrite some of the major distribution sites to fit to sites that are
1.11 ben 1065: close to your own. Have a look at pkgsrc/mk/defaults/mk.conf to find some
1.27 rillig 1066: examples ? in particular, look for the MASTER_SORT, MASTER_SORT_REGEX and
1.1 grant 1067: INET_COUNTRY definitions. This may save some of your bandwidth and time.
1068:
1069: You can change these settings either in your shell's environment, or, if you
1070: want to keep the settings, by editing the /etc/mk.conf file, and adding the
1071: definitions there.
1072:
1073: If you don't have a permanent Internet connection and you want to know which
1074: files to download, make fetch-list will tell you what you'll need. Put these
1075: distfiles into /usr/pkgsrc/distfiles.
1076:
1077: 4.2.3. How to build and install
1078:
1079: Assuming that the distfile has been fetched (see previous section), become root
1.47 reed 1080: and change into the relevant directory and run make.
1081:
1082: Note
1083:
1084: If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
1085: command instead of "make" in the examples in this guide.
1086:
1087: For example, type
1.1 grant 1088:
1089: % cd misc/figlet
1090: % make
1091:
1092: at the shell prompt to build the various components of the package, and
1093:
1094: # make install
1095:
1096: to install the various components into the correct places on your system.
1097: Installing the package on your system requires you to be root. However, pkgsrc
1098: has a just-in-time-su feature, which allows you to only become root for the
1099: actual installation step
1100:
1101: Taking the figlet utility as an example, we can install it on our system by
1.46 gdt 1102: building as shown in Appendix B, Build logs.
1.1 grant 1103:
1104: The program is installed under the default root of the packages tree - /usr/
1105: pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
1106: environment, and it will use that value as the root of your packages tree. So,
1107: to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
1108: that you should use a directory which is dedicated to packages and not shared
1.47 reed 1109: with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
1.1 grant 1110: not try to add any of your own files or directories (such as src/, obj/, or
1111: pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
1112: between programs and other files installed by the package system and whatever
1113: else may have been installed there.
1114:
1115: Some packages look in /etc/mk.conf to alter some configuration options at build
1.11 ben 1116: time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will
1117: be set there by default. Environment variables such as LOCALBASE can be set in
1118: /etc/mk.conf to save having to remember to set them each time you want to use
1119: pkgsrc.
1.1 grant 1120:
1121: Occasionally, people want to "look under the covers" to see what is going on
1122: when a package is building or being installed. This may be for debugging
1123: purposes, or out of simple curiosity. A number of utility values have been
1124: added to help with this.
1125:
1126: 1. If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a huge
1127: amount of information will be displayed. For example,
1.20 ben 1128:
1.1 grant 1129: make patch PKG_DEBUG_LEVEL=2
1.20 ben 1130:
1.1 grant 1131: will show all the commands that are invoked, up to and including the
1132: "patch" stage.
1.20 ben 1133:
1.1 grant 1134: 2. If you want to know the value of a certain make(1) definition, then the
1135: VARNAME definition should be used, in conjunction with the show-var target.
1.22 tv 1136: e.g. to show the expansion of the make(1) variable LOCALBASE:
1.20 ben 1137:
1.1 grant 1138: % make show-var VARNAME=LOCALBASE
1139: /usr/pkg
1140: %
1.20 ben 1141:
1142:
1.1 grant 1143:
1144: If you want to install a binary package that you've either created yourself
1145: (see next section), that you put into pkgsrc/packages manually or that is
1.8 wiz 1146: located on a remote FTP server, you can use the "bin-install" target. This
1.1 grant 1147: target will install a binary package - if available - via pkg_add(1), else do a
1148: make package. The list of remote FTP sites searched is kept in the variable
1.11 ben 1149: BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
1150: to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
1151: for more details.
1.1 grant 1152:
1.47 reed 1153: A final word of warning: If you set up a system that has a non-standard setting
1.1 grant 1154: for LOCALBASE, be sure to set that before any packages are installed, as you
1155: can not use several directories for the same purpose. Doing so will result in
1156: pkgsrc not being able to properly detect your installed packages, and fail
1157: miserably. Note also that precompiled binary packages are usually built with
1158: the default LOCALBASE of /usr/pkg, and that you should not install any if you
1159: use a non-standard LOCALBASE.
1160:
1161: 4.2.4. Selecting the compiler
1162:
1163: By default, pkgsrc will use GCC to build packages. This may be overridden by
1164: setting the following variables in /etc/mk.conf:
1165:
1166: PKGSRC_COMPILER:
1.20 ben 1167:
1.1 grant 1168: This is a list of values specifying the chain of compilers to invoke when
1169: building packages. Valid values are:
1.20 ben 1170:
1.1 grant 1171: * distcc: distributed C/C++ (chainable)
1.20 ben 1172:
1.1 grant 1173: * ccache: compiler cache (chainable)
1.20 ben 1174:
1.1 grant 1175: * gcc: GNU C/C++ Compiler
1.20 ben 1176:
1.1 grant 1177: * mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)
1.20 ben 1178:
1.1 grant 1179: * mipspro: Silicon Graphics, Inc. MIPSpro (o32)
1.20 ben 1180:
1.1 grant 1181: * sunpro: Microsystems, Inc. WorkShip/Forte/Sun ONE Studio
1.20 ben 1182:
1.1 grant 1183: The default is "gcc". You can use ccache and/or distcc with an appropriate
1184: PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
1185: terminated with a value for a real compiler.
1.20 ben 1186:
1.1 grant 1187: GCC_REQD:
1.20 ben 1188:
1.1 grant 1189: This specifies the minimum version of GCC to use when building packages. If
1190: the system GCC doesn't satisfy this requirement, then pkgsrc will build and
1191: install one of the GCC packages to use instead.
1.20 ben 1192:
1.38 dillo 1193: Chapter 5. Configuring pkgsrc
1194:
1195: Table of Contents
1196:
1.45 wiz 1197: 5.1. General configuration
1198: 5.2. Variables affecting the build process
1199: 5.3. Developer/advanced settings
1200: 5.4. Selecting Build Options
1.38 dillo 1201:
1.45 wiz 1202: 5.1. General configuration
1203:
1.47 reed 1204: In this section, you can find some variables that apply to all pkgsrc packages.
1205: The preferred method of setting these variables is by setting them in /etc/
1206: mk.conf.
1.45 wiz 1207:
1208: * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
1209: not mix binary packages with different LOCALBASEs!
1210:
1211: * CROSSBASE: Where "cross" category packages will be installed. The default
1212: is ${LOCALBASE}/cross.
1213:
1214: * X11BASE: Where X11 is installed on the system. The default is /usr/X11R6.
1215:
1216: * DISTDIR: Where to store the downloaded copies of the original source
1217: distributions used for building pkgsrc packages. The default is $
1218: {PKGSRCDIR}/distfiles.
1219:
1220: * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
1221: value.
1222:
1223: * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
1224: files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
1225: respectively. The defaults are ftp://ftp.NetBSD.org/pub/NetBSD/packages/
1226: distfiles/${DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$
1227: {DIST_SUBDIR}/.
1228:
1229: * BINPKG_SITES: List of sites carrying binary pkgs.
1230:
1231: 5.2. Variables affecting the build process
1232:
1233: XXX
1234:
1235: * PACKAGES: The top level directory for the binary packages. The default is $
1236: {PKGSRCDIR}/packages.
1237:
1238: * WRKOBJDIR: The top level directory where, if defined, the separate working
1239: directories will get created, and symbolically linked to from ${WRKDIR}
1240: (see below). This is useful for building packages on several architectures,
1241: then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
1242: architecture. (It should be noted that PKGSRCDIR should not be set by the
1243: user ? it is an internal definition which refers to the root of the pkgsrc
1244: tree. It is possible to have many pkgsrc tree instances.)
1245:
1246: * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
1247: Section 8.3, "patches/*" for more information. rel and arch are replaced
1248: with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
1249:
1250: * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
1251: Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
1252: up settings used by builds in /usr/src.
1253:
1254: 5.3. Developer/advanced settings
1255:
1256: XXX
1257:
1258: * PKG_DEVELOPER: Run some sanity checks that package developers want:
1259:
1260: o make sure patches apply with zero fuzz
1261:
1262: o run check-shlibs to see that all binaries will find their shared libs.
1263:
1264: * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst
1265: making and installing the package. The default value for this is 0, which
1266: will not display the commands as they are executed (normal, default, quiet
1267: operation); the value 1 will display all shell commands before their
1268: invocation, and the value 2 will display both the shell commands before
1269: their invocation, and their actual execution progress with set -x will be
1270: displayed.
1271:
1272: 5.4. Selecting Build Options
1.38 dillo 1273:
1274: Some packages have build time options, usually to select between different
1275: dependencies, enable optional support for big dependencies or enable
1276: experimental features.
1277:
1278: To see which options, if any, a package supports, and which options are
1279: mutually exclusive, run make show-options, for example:
1280:
1.51 ! rillig 1281: The following options are supported by this package:
! 1282: ssl Enable SSL support.
! 1283: Exactly one of the following gecko options is required:
! 1284: firefox Use firefox as gecko rendering engine.
! 1285: mozilla Use mozilla as gecko rendering engine.
! 1286: At most one of the following database options may be selected:
! 1287: mysql Enable support for MySQL database.
! 1288: pgsql Enable support for PostgreSQL database.
1.38 dillo 1289:
1.51 ! rillig 1290: These options are enabled by default: firefox
! 1291: These options are currently enabled: mozilla ssl
1.38 dillo 1292:
1293: The following variables can be defined in /etc/mk.conf to select which options
1294: to enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
1295: disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
1296: which can be used to select or disable options specifically for package pkgbase
1297: . Options listed in these variables are selected, options preceded by "-" are
1298: disabled.
1299:
1.39 dillo 1300: The following settings are consulted in the order given, and the last setting
1301: that selects or disables an option is used:
1.38 dillo 1302:
1303: 1. the default options as suggested by the package maintainer
1304:
1305: 2. the options implied by the settings of legacy variables (see below)
1306:
1307: 3. PKG_DEFAULT_OPTIONS
1308:
1309: 4. PKG_OPTIONS.pkgbase
1310:
1311: For groups of mutually exclusive options, the last option selected is used, all
1312: others are automatically disabled. If an option of the group is explicitly
1313: disabled, the previously selected option, if any, is used. It is an error if no
1314: option from a required group of options is selected, and building the package
1315: will fail.
1316:
1317: Before the options framework was introduced, build options were selected by
1318: setting a variable in /etc/mk.conf for each option. To ease transition to the
1319: options framework for the user, these legacy variables are converted to the
1320: appropriate options setting automatically. A warning is issued to prompt the
1321: user to update /etc/mk.conf to use the options framework directly. Support for
1322: these legacy variables will be removed eventually.
1323:
1324: Chapter 6. Creating binary packages
1.1 grant 1325:
1326: Table of Contents
1327:
1.38 dillo 1328: 6.1. Building a single binary package
1329: 6.2. Settings for creation of binary packages
1330: 6.3. Doing a bulk build of all packages
1331:
1332: 6.3.1. Configuration
1333: 6.3.2. Other environmental considerations
1334: 6.3.3. Operation
1335: 6.3.4. What it does
1336: 6.3.5. Disk space requirements
1.47 reed 1337: 6.3.6. Setting up a sandbox for chrooted builds
1.38 dillo 1338: 6.3.7. Building a partial set of packages
1339: 6.3.8. Uploading results of a bulk build
1.20 ben 1340:
1.38 dillo 1341: 6.4. Creating a multiple CD-ROM packages collection
1.20 ben 1342:
1.38 dillo 1343: 6.4.1. Example of cdpack
1.20 ben 1344:
1.38 dillo 1345: 6.1. Building a single binary package
1.1 grant 1346:
1347: Once you have built and installed a package, you can create a binary package
1.47 reed 1348: which can be installed on another system with pkg_add(1). This saves having to
1.1 grant 1349: build the same package on a group of hosts and wasting CPU time. It also
1350: provides a simple means for others to install your package, should you
1351: distribute it.
1352:
1353: To create a binary package, change into the appropriate directory in pkgsrc,
1354: and run make package:
1355:
1356: # cd misc/figlet
1357: # make package
1358:
1359: This will build and install your package (if not already done), and then build
1360: a binary package from what was installed. You can then use the pkg_* tools to
1361: manipulate it. Binary packages are created by default in /usr/pkgsrc/packages,
1.46 gdt 1362: in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a
1.1 grant 1363: continuation of the above misc/figlet example.
1364:
1.38 dillo 1365: See Chapter 17, Submitting and Committing for information on how to submit such
1.1 grant 1366: a binary package.
1367:
1.38 dillo 1368: 6.2. Settings for creation of binary packages
1.1 grant 1369:
1.38 dillo 1370: See Section 14.3, "Other helpful targets".
1.1 grant 1371:
1.38 dillo 1372: 6.3. Doing a bulk build of all packages
1.1 grant 1373:
1374: If you want to get a full set of precompiled binary packages, this section
1375: describes how to get them. Beware that the bulk build will remove all currently
1.23 wiz 1376: installed packages from your system! Having an FTP server configured either on
1.1 grant 1377: the machine doing the bulk builds or on a nearby NFS server can help to make
1378: the packages available to everyone. See ftpd(8) for more information. If you
1379: use a remote NFS server's storage, be sure to not actually compile on NFS
1380: storage, as this slows things down a lot.
1381:
1.38 dillo 1382: 6.3.1. Configuration
1.1 grant 1383:
1.38 dillo 1384: 6.3.1.1. /etc/mk.conf
1.1 grant 1385:
1.23 wiz 1386: You may want to set variables in /etc/mk.conf. Look at pkgsrc/mk/defaults/
1387: mk.conf for details of the default settings. You will want to ensure that
1.11 ben 1388: ACCEPTABLE_LICENSES meet your local policy. As used in this example,
1389: _ACCEPTABLE=yes accepts all licenses.
1.1 grant 1390:
1.51 ! rillig 1391: PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
! 1392: WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
! 1393: BSDSRCDIR= /usr/src
! 1394: BSDXSRCDIR= /usr/xsrc # for x11/xservers
! 1395: OBJHOSTNAME?= yes # use work.`hostname`
! 1396: FAILOVER_FETCH= yes # insist on the correct checksum
! 1397: PKG_DEVELOPER?= yes
! 1398: _ACCEPTABLE= yes
1.1 grant 1399:
1.38 dillo 1400: 6.3.1.2. build.conf
1.1 grant 1401:
1402: In pkgsrc/mk/bulk, copy build.conf-example to build.conf and edit it, following
1403: the comments in that file. This is the config file that determines where log
1404: files are generated after the build, where to mail the build report to, where
1.23 wiz 1405: your pkgsrc tree is located and the user to which user to su(8) to do a cvs
1406: update.
1.1 grant 1407:
1.45 wiz 1408: 6.3.1.3. pre-build.local
1.1 grant 1409:
1.47 reed 1410: It is possible to configure the bulk build to perform certain site-specific
1.1 grant 1411: tasks at the end of the pre-build stage. If the file pre-build.local exists in
1.23 wiz 1412: /usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the
1.1 grant 1413: usual pre-build stage. An example use of pre-build.local is to have the line:
1414:
1415: # echo "I do not have enough disk space to build this pig." \
1.23 wiz 1416: > pkgsrc/misc/openoffice/$BROKENF
1.1 grant 1417:
1418: to prevent the system from trying to build a particular package which requires
1419: nearly 3 GB of disk space.
1420:
1.38 dillo 1421: 6.3.2. Other environmental considerations
1.1 grant 1422:
1423: As /usr/pkg will be completely deleted at the start of bulk builds, make sure
1424: your login shell is placed somewhere else. Either drop it into /usr/local/bin
1.20 ben 1425: (and adjust your login shell in the passwd file), or (re-)install it via
1.1 grant 1426: pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that
1427: your current process won't die if the package is removed, you just can't start
1428: any new instances of the shell any more). Also, if you use NetBSD earlier than
1429: 1.5, or you still want to use the pkgsrc version of ssh for some reason, be
1430: sure to install ssh before starting it from rc.local:
1431:
1.51 ! rillig 1432: ( cd /usr/pkgsrc/security/ssh ; make bulk-install )
! 1433: if [ -f /usr/pkg/etc/rc.d/sshd ]; then
! 1434: /usr/pkg/etc/rc.d/sshd
! 1435: fi
1.1 grant 1436:
1437: Not doing so will result in you being not able to log in via ssh after the bulk
1438: build is finished or if the machine gets rebooted or crashes. You have been
1439: warned! :)
1440:
1.38 dillo 1441: 6.3.3. Operation
1.1 grant 1442:
1443: Make sure you don't need any of the packages still installed.
1444:
1445: Warning
1446:
1447: During the bulk build, all packages will be removed!
1448:
1449: Be sure to remove all other things that might interfere with builds, like some
1450: libs installed in /usr/local, etc. then become root and type:
1451:
1452: # cd /usr/pkgsrc
1453: # sh mk/bulk/build
1454:
1455: If for some reason your last build didn't complete (power failure, system
1456: panic, ...), you can continue it by running:
1457:
1458: # sh mk/bulk/build restart
1459:
1460: At the end of the bulk build, you will get a summary via mail, and find build
1461: logs in the directory specified by FTP in the build.conf file.
1462:
1.38 dillo 1463: 6.3.4. What it does
1.1 grant 1464:
1465: The bulk builds consist of three steps:
1466:
1467: 1. pre-build
1.20 ben 1468:
1.1 grant 1469: The script updates your pkgsrc tree via (anon)cvs, then cleans out any
1470: broken distfiles, and removes all packages installed.
1.20 ben 1471:
1.1 grant 1472: 2. the bulk build
1.20 ben 1473:
1.1 grant 1474: This is basically "make bulk-package" with an optimised order in which
1475: packages will be built. Packages that don't require other packages will be
1476: built first, and packages with many dependencies will be built later.
1.20 ben 1477:
1.1 grant 1478: 3. post-build
1.20 ben 1479:
1.1 grant 1480: Generates a report that's placed in the directory specified in the
1481: build.conf file named broken.html, a short version of that report will also
1482: be mailed to the build's admin.
1.20 ben 1483:
1.1 grant 1484: During the build, a list of broken packages will be compiled in /usr/pkgsrc
1485: /.broken (or .../.broken.${MACHINE} if OBJMACHINE is set), individual build
1486: logs of broken builds can be found in the package's directory. These files are
1487: used by the bulk-targets to mark broken builds to not waste time trying to
1488: rebuild them, and they can be used to debug these broken package builds later.
1489:
1.38 dillo 1490: 6.3.5. Disk space requirements
1.1 grant 1491:
1492: Currently, roughly the following requirements are valid for NetBSD 2.0/i386:
1493:
1494: * 10 GB - distfiles (NFS ok)
1.20 ben 1495:
1.1 grant 1496: * 8 GB - full set of all binaries (NFS ok)
1.20 ben 1497:
1.1 grant 1498: * 5 GB - temp space for compiling (local disk recommended)
1.20 ben 1499:
1.1 grant 1500: Note that all pkgs will be de-installed as soon as they are turned into a
1501: binary package, and that sources are removed, so there is no excessively huge
1502: demand to disk space. Afterwards, if the package is needed again, it will be
1503: installed via pkg_add(1) instead of building again, so there are no cycles
1504: wasted by recompiling.
1505:
1.47 reed 1506: 6.3.6. Setting up a sandbox for chrooted builds
1.1 grant 1507:
1.12 agc 1508: If you don't want all the packages nuked from a machine (rendering it useless
1.23 wiz 1509: for anything but pkg compiling), there is the possibility of doing the package
1510: bulk build inside a chroot environment.
1.1 grant 1511:
1.12 agc 1512: The first step is to set up a chroot sandbox, e.g. /usr/sandbox. This can be
1513: done by using null mounts, or manually.
1514:
1515: There is a shell script called pkgsrc/mk/bulk/mksandbox which will set up the
1516: sandbox environment using null mounts. It will also create a script called
1517: sandbox in the root of the sandbox environment, which will allow the null
1518: mounts to be activated using the sandbox mount command and deactivated using
1519: the sandbox umount command.
1520:
1521: To set up a sandbox environment by hand, after extracting all the sets from a
1522: NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in /usr/
1523: src/etc, be sure the following items are present and properly configured:
1.1 grant 1524:
1525: 1. Kernel
1.20 ben 1526:
1.1 grant 1527: # cp /netbsd /usr/sandbox
1.20 ben 1528:
1.1 grant 1529: 2. /dev/*
1.20 ben 1530:
1.1 grant 1531: # cd /usr/sandbox/dev ; sh MAKEDEV all
1.20 ben 1532:
1.1 grant 1533: 3. /etc/resolv.conf (for security/smtpd and mail):
1.20 ben 1534:
1.1 grant 1535: # cp /etc/resolv.conf /usr/sandbox/etc
1.20 ben 1536:
1.1 grant 1537: 4. Working(!) mail config (hostname, sendmail.cf):
1.20 ben 1538:
1.1 grant 1539: # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
1.20 ben 1540:
1.1 grant 1541: 5. /etc/localtime (for security/smtpd):
1.20 ben 1542:
1.1 grant 1543: # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
1.20 ben 1544:
1.1 grant 1545: 6. /usr/src (system sources, for sysutils/aperture, net/ppp-mppe):
1.20 ben 1546:
1.1 grant 1547: # ln -s ../disk1/cvs .
1.23 wiz 1548: # ln -s cvs/src-2.0 src
1.20 ben 1549:
1.1 grant 1550: 7. Create /var/db/pkg (not part of default install):
1.20 ben 1551:
1.1 grant 1552: # mkdir /usr/sandbox/var/db/pkg
1.20 ben 1553:
1.1 grant 1554: 8. Create /usr/pkg (not part of default install):
1.20 ben 1555:
1.1 grant 1556: # mkdir /usr/sandbox/usr/pkg
1.20 ben 1557:
1.1 grant 1558: 9. Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:
1.20 ben 1559:
1.1 grant 1560: # cd /usr/sandbox/usr
1561: # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
1.20 ben 1562:
1.1 grant 1563: Do not mount/link this to the copy of your pkgsrc tree you do development
1564: in, as this will likely cause problems!
1.20 ben 1565:
1.1 grant 1566: 10. Make /usr/sandbox/usr/pkgsrc/packages and .../distfiles point somewhere
1567: appropriate. NFS- and/or nullfs-mounts may come in handy!
1.20 ben 1568:
1.38 dillo 1569: 11. Edit /etc/mk.conf, see Section 6.3.1.1, "/etc/mk.conf".
1.20 ben 1570:
1.1 grant 1571: 12. Adjust mk/bulk/build.conf to suit your needs.
1.20 ben 1572:
1.1 grant 1573: 13. If you have set CVS_USER in build.conf, make sure that account exists and
1574: can do a cvs ${CVS_FLAGS} update properly!
1.20 ben 1575:
1.47 reed 1576: When the chroot sandbox is set up, you can start the build with the following
1.1 grant 1577: steps:
1578:
1579: # cd /usr/sandbox/usr/pkgsrc
1580: # sh mk/bulk/do-sandbox-build
1581:
1582: This will just jump inside the sandbox and start building. At the end of the
1583: build, mail will be sent with the results of the build. Created binary pkgs
1584: will be in /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/
1585: from).
1586:
1.38 dillo 1587: 6.3.7. Building a partial set of packages
1.1 grant 1588:
1589: In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk
1590: /bulk/build script may be used to build a subset of the packages contained in
1.47 reed 1591: pkgsrc. By setting SPECIFIC_PKGS in /etc/mk.conf, the variables
1.1 grant 1592:
1593: * SITE_SPECIFIC_PKGS
1.20 ben 1594:
1.1 grant 1595: * HOST_SPECIFIC_PKGS
1.20 ben 1596:
1.1 grant 1597: * GROUP_SPECIFIC_PKGS
1.20 ben 1598:
1.1 grant 1599: * USER_SPECIFIC_PKGS
1.20 ben 1600:
1.1 grant 1601: will define the set of packages which should be built. The bulk build code will
1602: also include any packages which are needed as dependencies for the explicitly
1603: listed packages.
1604:
1605: One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
1606: periodically to have a complete set of the binary packages needed for your site
1607: available without the overhead of building extra packages that are not needed.
1608:
1.38 dillo 1609: 6.3.8. Uploading results of a bulk build
1.13 hubertf 1610:
1611: This section describes how pkgsrc developers can upload binary pkgs built by
1612: bulk builds to ftp.NetBSD.org.
1613:
1.17 sketch 1614: If you would like to automatically create checksum files for the binary
1615: packages you intend to upload, remember to set MKSUMS=yes in your mk/bulk/
1616: build.conf.
1617:
1618: If you would like to PGP sign the checksum files (highly recommended!),
1619: remember to set SIGN_AS=username@NetBSD.org in your mk/bulk/build.conf. This
1.23 wiz 1620: will prompt you for your GPG password to sign the files before uploading
1.17 sketch 1621: everything.
1622:
1623: Then, make sure that you have RSYNC_DST set properly in your mk/bulk/build.conf
1624: file, i.e. adjust it to something like one of the following:
1.13 hubertf 1625:
1.20 ben 1626: RSYNC_DST=$CVS_USER@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
1.13 hubertf 1627:
1.47 reed 1628: Please use appropriate values for "pkgsrc-200xQy", "NetBSD-a.b.c" and "arch"
1.13 hubertf 1629: here. If your login on ftp.NetBSD.org is different from CVS_USER, write your
1630: login directly into the variable, e.g. my local account is "feyrer", but for my
1631: login "hubertf", I use:
1632:
1.20 ben 1633: RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
1.13 hubertf 1634:
1635: A separate upload directory is used here to allow "closing" the directory
1636: during upload. To do so, run the following command on ftp.NetBSD.org next:
1637:
1638: nbftp% mkdir -p -m 750 /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
1639:
1640: Please note that /pub/NetBSD/packages is only appropriate for packages for the
1641: NetBSD operating system. Binary packages for other operating systems should go
1642: into /pub/pkgsrc.
1643:
1.23 wiz 1644: Before uploading the binary pkgs, ssh authentication needs to be set up. This
1.47 reed 1645: example shows how to set up temporary keys for the root account inside the
1.13 hubertf 1646: sandbox (assuming that no keys should be present there usually):
1647:
1.20 ben 1648: # chroot /usr/sandbox
1649: chroot-# rm $HOME/.ssh/id-dsa*
1650: chroot-# ssh-keygen -t dsa
1651: chroot-# cat $HOME/.ssh/id-dsa.pub
1.13 hubertf 1652:
1653: Now take the output of id-dsa.pub and append it to your ~/.ssh/authorized_keys
1.17 sketch 1654: file on ftp.NetBSD.org. You can remove the key after the upload is done!
1.13 hubertf 1655:
1656: Next, test if your ssh connection really works:
1657:
1.20 ben 1658: chroot-# ssh ftp.NetBSD.org date
1.13 hubertf 1659:
1660: Use "-l yourNetBSDlogin" here as appropriate!
1661:
1662: Now after all this works, you can exit the sandbox and start the upload:
1663:
1.20 ben 1664: chroot-# exit
1665: # cd /usr/sandbox/usr/pkgsrc
1666: # sh mk/bulk/do-sandbox-upload
1.13 hubertf 1667:
1.24 wiz 1668: The upload process may take quite some time. Use ls(1) or du(1) on the FTP
1669: server to monitor progress of the upload. The upload script will take care of
1670: not uploading restricted packages and putting vulnerable packages into the
1671: vulnerable subdirectory.
1.13 hubertf 1672:
1673: After the upload has ended, first thing is to revoke ssh access:
1674:
1675: nbftp% vi ~/.ssh/authorized_keys
1.20 ben 1676: Gdd:x!
1.13 hubertf 1677:
1678: Use whatever is needed to remove the key you've entered before! Last, move the
1679: uploaded packages out of the upload directory to have them accessible to
1680: everyone:
1681:
1682: nbftp% cd /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch
1683: nbftp% mv upload/* .
1684: nbftp% rmdir upload
1.20 ben 1685: nbftp% chmod 755 .
1.13 hubertf 1686:
1.38 dillo 1687: 6.4. Creating a multiple CD-ROM packages collection
1.1 grant 1688:
1689: After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
1690: of the resulting binary packages to assist in installing packages on other
1691: machines. The pkgtools/cdpack package provides a simple tool for creating the
1692: ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
1.47 reed 1693: keeps all the dependencies for a given package on the same CD as that package.
1.1 grant 1694:
1.38 dillo 1695: 6.4.1. Example of cdpack
1.1 grant 1696:
1.47 reed 1697: Complete documentation for cdpack is found in the cdpack(1) man page. The
1.1 grant 1698: following short example assumes that the binary packages are left in /usr/
1699: pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
1700: ISO 9660 images.
1701:
1702: # mkdir /u2/images
1703: # pkg_add /usr/pkgsrc/packages/All/cdpack
1704: # cdpack /usr/pkgsrc/packages/All /u2/images
1705:
1706: If you wish to include a common set of files (COPYRIGHT, README, etc.) on each
1707: CD in the collection, then you need to create a directory which contains these
1708: files. e.g.
1709:
1710: # mkdir /tmp/common
1711: # echo "This is a README" > /tmp/common/README
1712: # echo "Another file" > /tmp/common/COPYING
1713: # mkdir /tmp/common/bin
1714: # echo "#!/bin/sh" > /tmp/common/bin/myscript
1715: # echo "echo Hello world" >> /tmp/common/bin/myscript
1716: # chmod 755 /tmp/common/bin/myscript
1717:
1718: Now create the images:
1719:
1720: # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
1721:
1722: Each image will contain README, COPYING, and bin/myscript in their root
1723: directories.
1724:
1.38 dillo 1725: Chapter 7. Frequently Asked Questions
1.1 grant 1726:
1727: Table of Contents
1728:
1.38 dillo 1729: 7.1. Are there any mailing lists for pkg-related discussion?
1730: 7.2. Where's the pkgviews documentation?
1731: 7.3. Utilities for package management (pkgtools)
1732: 7.4. How to use pkgsrc as non-root
1733: 7.5. How to resume transfers when fetching distfiles?
1734: 7.6. How can I install/use XFree86 from pkgsrc?
1735: 7.7. How can I install/use X.org from pkgsrc?
1736: 7.8. How to fetch files from behind a firewall
1737: 7.9. How do I tell make fetch to do passive FTP?
1738: 7.10. How to fetch all distfiles at once
1739: 7.11. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
1740: 7.12. What does "Could not find bsd.own.mk" mean?
1741: 7.13. Using 'sudo' with pkgsrc
1742: 7.14. How do I change the location of configuration files?
1743: 7.15. Automated security checks
1.1 grant 1744:
1745: This section contains hints, tips & tricks on special things in pkgsrc that we
1746: didn't find a better place for in the previous chapters, and it contains items
1747: for both pkgsrc users and developers.
1748:
1.38 dillo 1749: 7.1. Are there any mailing lists for pkg-related discussion?
1.1 grant 1750:
1.18 xtraeme 1751: The following mailing lists may be of interest to pkgsrc users:
1.1 grant 1752:
1.34 wiz 1753: * pkgsrc-bugs: A list where problem reports related to pkgsrc are sent and
1754: discussed.
1.20 ben 1755:
1.34 wiz 1756: * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and
1757: discussed.
1.20 ben 1758:
1.34 wiz 1759: * pkgsrc-changes: A list where all commit messages to pkgsrc are sent.
1.20 ben 1760:
1.34 wiz 1761: * tech-pkg: A general discussion list for all things related to pkgsrc.
1.20 ben 1762:
1.18 xtraeme 1763: To subscribe, do:
1764:
1.51 ! rillig 1765: % echo subscribe listname | mail majordomo@NetBSD.org
1.18 xtraeme 1766:
1767: Archives for all these mailing lists are available from http://
1768: mail-index.NetBSD.org/.
1.1 grant 1769:
1.38 dillo 1770: 7.2. Where's the pkgviews documentation?
1.1 grant 1771:
1772: Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's
1773: guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.
1774:
1.38 dillo 1775: 7.3. Utilities for package management (pkgtools)
1.1 grant 1776:
1777: The pkgsrc/pkgtools directory pkgtools contains a number of useful utilities
1778: for both users and developers of pkgsrc. This section attempts only to make the
1779: reader aware of the utilities and when they might be useful, and not to
1780: duplicate the documentation that comes with each package.
1781:
1782: Utilities used by pkgsrc (automatically installed when needed):
1783:
1.34 wiz 1784: * pkgtools/x11-links: Symlinks for use by buildlink.
1.20 ben 1785:
1.1 grant 1786: OS tool augmentation (automatically installed when needed):
1787:
1.34 wiz 1788: * pkgtools/digest: Calculates various kinds of checksums (including SHA1).
1.20 ben 1789:
1.34 wiz 1790: * pkgtools/libnbcompat: Compatibility library for pkgsrc tools.
1.20 ben 1791:
1.34 wiz 1792: * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree.
1.20 ben 1793:
1.34 wiz 1794: * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or
1795: for use on operating systems where pkg_install is not present.
1.20 ben 1796:
1.1 grant 1797: Utilities used by pkgsrc (not automatically installed):
1798:
1.34 wiz 1799: * pkgtools/pkg_tarup: Create a binary package from an already-installed
1800: package. Used by make replace to save the old package.
1.20 ben 1801:
1.34 wiz 1802: * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch
1.5 hubertf 1803: distfiles from multiple locations. It currently supports the following
1804: methods: multiple CD-ROMs and network FTP/HTTP connections.
1.20 ben 1805:
1.34 wiz 1806: * pkgtools/xpkgwedge: Put X11 packages someplace else (enabled by default).
1.20 ben 1807:
1.34 wiz 1808: * devel/cpuflags: Determine the best compiler flags to optimise code for your
1809: current CPU and compiler.
1.20 ben 1810:
1.1 grant 1811: Utilities for keeping track of installed packages, being up to date, etc:
1812:
1.34 wiz 1813: * pkgtools/pkg_chk: Reports on packages whose installed versions do not match
1814: the latest pkgsrc entries.
1.20 ben 1815:
1.34 wiz 1816: * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a
1817: strategy for updating.
1.20 ben 1818:
1.34 wiz 1819: * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses
1820: graphviz).
1.20 ben 1821:
1.34 wiz 1822: * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors,
1.27 rillig 1823: lintpkgsrc(1) does various checks on the complete pkgsrc system.
1.20 ben 1824:
1.34 wiz 1825: * pkgtools/pkgsurvey: Report what packages you have installed.
1.20 ben 1826:
1.1 grant 1827: Utilities for people maintaining or creating individual packages:
1828:
1.34 wiz 1829: * pkgtools/pkgdiff: Automate making and maintaining patches for a package
1830: (includes pkgdiff, pkgvi, mkpatches, etc.).
1.20 ben 1831:
1.34 wiz 1832: * pkgtools/rpm2pkg, pkgtools/url2pkg: Aids in converting to pkgsrc.
1.20 ben 1833:
1.34 wiz 1834: * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package.
1.20 ben 1835:
1.47 reed 1836: Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
1.20 ben 1837:
1.34 wiz 1838: * pkgtools/pkg_comp: Build packages in a chrooted area.
1.20 ben 1839:
1.34 wiz 1840: * pkgtools/libkver: Spoof kernel version for chrooted cross builds.
1.20 ben 1841:
1.38 dillo 1842: 7.4. How to use pkgsrc as non-root
1.1 grant 1843:
1844: If you want to use pkgsrc as non-root user, you can set some variables to make
1.33 jmmv 1845: pkgsrc work under these conditions. At the very least, you need to set
1846: UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple
1847: related variables to allow installation of packages as non-root.
1848:
1849: In case the defaults are not enough, you may want to tune some other variables
1850: used. For example, if the automatic user/group detection leads to incorrect
1851: values (or not the ones you would like to use), you can change them by setting
1852: UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively.
1853:
1854: As regards bootstrapping, please note that the bootstrap script will ease
1855: non-root configuration when given the "--ignore-user-check" flag, as it will
1856: choose and use multiple default directories under ~/pkg as the installation
1857: targets. These directories can be overriden by the "--prefix" flag provided by
1858: the script, as well as some others that allow finer tuning of the tree layout.
1.1 grant 1859:
1.38 dillo 1860: 7.5. How to resume transfers when fetching distfiles?
1.14 xtraeme 1861:
1.47 reed 1862: By default, resuming transfers in pkgsrc is disabled, but you can enable this
1.15 xtraeme 1863: feature by adding the option PKG_RESUME_TRANSFERS=YES into /etc/mk.conf. If,
1864: during a fetch step, an incomplete distfile is found, pkgsrc will try to resume
1865: it.
1866:
1867: You can also use a different program than the default ftp(1) by changing the
1868: FETCH_CMD variable. Don't forget to set FETCH_RESUME_ARGS and FETCH_OUTPUT_ARGS
1869: if you are not using default values.
1.14 xtraeme 1870:
1871: For example, if you want to use wget to resume downloads, you'll have to use
1872: something like:
1873:
1.51 ! rillig 1874: FETCH_CMD= wget
! 1875: FETCH_BEFORE_ARGS= --passive-ftp
! 1876: FETCH_RESUME_ARGS= -c
! 1877: FETCH_OUTPUT_ARGS= -O
1.14 xtraeme 1878:
1.38 dillo 1879: 7.6. How can I install/use XFree86 from pkgsrc?
1.1 grant 1880:
1881: If you want to use XFree86 from pkgsrc instead of your system's own X11 (/usr/
1.15 xtraeme 1882: X11R6, /usr/openwin, ...), you will have to add the following line into /etc/
1.1 grant 1883: mk.conf:
1884:
1.51 ! rillig 1885: X11_TYPE=XFree86
1.14 xtraeme 1886:
1.38 dillo 1887: 7.7. How can I install/use X.org from pkgsrc?
1.1 grant 1888:
1889: If you want to use X.org from pkgsrc instead of your system's own X11 (/usr/
1.15 xtraeme 1890: X11R6, /usr/openwin, ...) you will have to add the following line into /etc/
1891: mk.conf:
1.1 grant 1892:
1.51 ! rillig 1893: X11_TYPE=xorg
1.14 xtraeme 1894:
1.38 dillo 1895: 7.8. How to fetch files from behind a firewall
1.1 grant 1896:
1897: If you are sitting behind a firewall which does not allow direct connections to
1898: Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
1.47 reed 1899: is done using an environment variable in the form of a URL, e.g. in Amdahl, the
1.1 grant 1900: machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
1901: the proxy port number. So the proxy environment variables are:
1902:
1.51 ! rillig 1903: ftp_proxy=ftp://orpheus.amdahl.com:80/
! 1904: http_proxy=http://orpheus.amdahl.com:80/
1.1 grant 1905:
1.38 dillo 1906: 7.9. How do I tell make fetch to do passive FTP?
1.1 grant 1907:
1908: This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
1909: FETCH_CMD is assigned the first available command from the following list:
1910:
1.34 wiz 1911: * ${LOCALBASE}/bin/ftp
1912:
1913: * /usr/bin/ftp
1.1 grant 1914:
1915: On a default NetBSD installation, this will be /usr/bin/ftp, which
1916: automatically tries passive connections first, and falls back to active
1917: connections if the server refuses to do passive. For the other tools, add the
1918: following to your /etc/mk.conf file: PASSIVE_FETCH=1.
1919:
1920: Having that option present will prevent /usr/bin/ftp from falling back to
1921: active transfers.
1922:
1.38 dillo 1923: 7.10. How to fetch all distfiles at once
1.1 grant 1924:
1925: You would like to download all the distfiles in a single batch from work or
1926: university, where you can't run a make fetch. There is an archive of distfiles
1927: on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
1928:
1.47 reed 1929: The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
1.1 grant 1930: subdirectories, carry the resulting list to your machine at work/school and use
1.23 wiz 1931: it there. If you don't have a NetBSD-compatible ftp(1) (like lukemftp) at work,
1.1 grant 1932: don't forget to set FETCH_CMD to something that fetches a URL:
1933:
1934: At home:
1935:
1936: % cd /usr/pkgsrc
1937: % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
1938: % scp /tmp/fetch.sh work:/tmp
1939:
1940: At work:
1941:
1942: % sh /tmp/fetch.sh
1943:
1944: then tar up /tmp/distfiles and take it home.
1945:
1946: If you have a machine running NetBSD, and you want to get all distfiles (even
1947: ones that aren't for your machine architecture), you can do so by using the
1948: above-mentioned make fetch-list approach, or fetch the distfiles directly by
1949: running:
1950:
1951: % make mirror-distfiles
1952:
1953: If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can get
1954: everything by running:
1955:
1956: % make fetch NO_SKIP=yes
1957:
1.38 dillo 1958: 7.11. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
1.1 grant 1959:
1960: When compiling the pkgtools/pkg_install package, you get the error from make
1961: that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
1.23 wiz 1962: that you don't have installed the "text" set (nroff, ...) from the NetBSD base
1.47 reed 1963: distribution on your machine. It is recommended to do that to format man pages.
1.1 grant 1964:
1965: In the case of the pkgtools/pkg_install package, you can get away with setting
1966: NOMAN=YES either in the environment or in /etc/mk.conf.
1967:
1.38 dillo 1968: 7.12. What does "Could not find bsd.own.mk" mean?
1.1 grant 1969:
1970: You didn't install the compiler set, comp.tgz, when you installed your NetBSD
1.47 reed 1971: machine. Please get and install it, by extracting it in /:
1.1 grant 1972:
1973: # cd /
1974: # tar --unlink -zxvpf .../comp.tgz
1975:
1976: comp.tgz is part of every NetBSD release. Get the one that corresponds to your
1977: release (determine via uname -r).
1978:
1.38 dillo 1979: 7.13. Using 'sudo' with pkgsrc
1.1 grant 1980:
1981: When installing packages as non-root user and using the just-in-time su(1)
1982: feature of pkgsrc, it can become annoying to type in the root password for each
1983: required package installed. To avoid this, the sudo package can be used, which
1984: does password caching over a limited time. To use it, install sudo (either as
1985: binary package or from security/sudo) and then put the following into your /etc
1986: /mk.conf:
1987:
1.51 ! rillig 1988: .if exists(${LOCALBASE}/bin/sudo)
! 1989: SU_CMD= ${LOCALBASE}/bin/sudo /bin/sh -c
! 1990: .endif
1.14 xtraeme 1991:
1.38 dillo 1992: 7.14. How do I change the location of configuration files?
1.1 grant 1993:
1.35 jmmv 1994: As the system administrator, you can choose where configuration files are
1995: installed. The default settings make all these files go into ${PREFIX}/etc or
1996: some of its subdirectories; this may be suboptimal depending on your
1997: expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine
1998: configuration of the provided packages).
1999:
2000: In order to change the defaults, you can modify the PKG_SYSCONFBASE variable
2001: (in /etc/mk.conf) to point to your preferred configuration directory; some
2002: common examples include /etc or /etc/pkg.
2003:
2004: Furthermore, you can change this value on a per-package basis by setting the
2005: PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
2006: matches the name of the package you would like to modify, that is, the contents
2007: of PKGBASE.
1.1 grant 2008:
1.47 reed 2009: Note that after changing these settings, you must rebuild and reinstall any
1.35 jmmv 2010: affected packages.
1.1 grant 2011:
1.38 dillo 2012: 7.15. Automated security checks
1.1 grant 2013:
2014: Please be aware that there can often be bugs in third-party software, and some
2015: of these bugs can leave a machine vulnerable to exploitation by attackers. In
2016: an effort to lessen the exposure, the NetBSD packages team maintains a database
2017: of known-exploits to packages which have at one time been included in pkgsrc.
2018: The database can be downloaded automatically, and a security audit of all
2019: packages installed on a system can take place. To do this, install the security
2020: /audit-packages package. It has two components:
2021:
1.34 wiz 2022: 1. download-vulnerability-list, an easy way to download a list of the security
2023: vulnerabilities information. This list is kept up to date by the NetBSD
2024: security officer and the NetBSD packages team, and is distributed from the
2025: NetBSD ftp server:
1.20 ben 2026:
1.1 grant 2027: ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities
1.20 ben 2028:
1.34 wiz 2029: 2. audit-packages, an easy way to audit the current machine, checking each
1.1 grant 2030: vulnerability which is known. If a vulnerable package is installed, it will
2031: be shown by output to stdout, including a description of the type of
2032: vulnerability, and a URL containing more information.
1.20 ben 2033:
1.23 wiz 2034: Use of the security/audit-packages package is strongly recommended! After
2035: "audit-packages" is installed, please read the package's message, which you can
2036: get by running pkg_info -D audit-package.
1.1 grant 2037:
1.48 dillo 2038: Part II. The pkgsrc developer's guide
1.1 grant 2039:
2040: Table of Contents
2041:
1.38 dillo 2042: 8. Package components - files, directories and contents
1.27 rillig 2043:
1.38 dillo 2044: 8.1. Makefile
2045: 8.2. distinfo
2046: 8.3. patches/*
2047: 8.4. Other mandatory files
2048: 8.5. Optional files
2049: 8.6. work*
2050: 8.7. files/*
1.27 rillig 2051:
1.38 dillo 2052: 9. Programming in Makefiles
1.25 rillig 2053:
1.38 dillo 2054: 9.1. Makefile variables
1.25 rillig 2055:
1.38 dillo 2056: 9.1.1. Naming conventions
1.27 rillig 2057:
1.38 dillo 2058: 9.2. Code snippets
1.27 rillig 2059:
1.38 dillo 2060: 9.2.1. Adding things to a list
2061: 9.2.2. Converting an internal list into an external list
2062: 9.2.3. Passing variables to a shell command
2063: 9.2.4. Quoting guideline
2064: 9.2.5. Workaround for a bug in BSD Make
1.20 ben 2065:
1.38 dillo 2066: 10. PLIST issues
1.20 ben 2067:
1.38 dillo 2068: 10.1. RCS ID
2069: 10.2. Semi-automatic PLIST generation
2070: 10.3. Tweaking output of make print-PLIST
2071: 10.4. Variable substitution in PLIST
1.48 dillo 2072: 10.5. Man page compression
1.38 dillo 2073: 10.6. Changing PLIST source with PLIST_SRC
1.47 reed 2074: 10.7. Platform-specific and differing PLISTs
1.38 dillo 2075: 10.8. Sharing directories between packages
1.20 ben 2076:
1.38 dillo 2077: 11. Buildlink methodology
1.20 ben 2078:
1.38 dillo 2079: 11.1. Converting packages to use buildlink3
2080: 11.2. Writing buildlink3.mk files
1.20 ben 2081:
1.38 dillo 2082: 11.2.1. Anatomy of a buildlink3.mk file
2083: 11.2.2. Updating BUILDLINK_DEPENDS. pkg in buildlink3.mk files
1.20 ben 2084:
1.38 dillo 2085: 11.3. Writing builtin.mk files
1.20 ben 2086:
1.38 dillo 2087: 11.3.1. Anatomy of a builtin.mk file
2088: 11.3.2. Global preferences for native or pkgsrc software
1.20 ben 2089:
1.38 dillo 2090: 12. The pkginstall framework
1.35 jmmv 2091:
1.38 dillo 2092: 12.1. Files and directories outside the installation prefix
1.20 ben 2093:
1.38 dillo 2094: 12.1.1. Directory manipulation
2095: 12.1.2. File manipulation
1.20 ben 2096:
1.38 dillo 2097: 12.2. Configuration files
1.20 ben 2098:
1.38 dillo 2099: 12.2.1. How PKG_SYSCONFDIR is set
1.47 reed 2100: 12.2.2. Telling the software where configuration files are
1.38 dillo 2101: 12.2.3. Patching installations
2102: 12.2.4. Disabling handling of configuration files
1.35 jmmv 2103:
1.38 dillo 2104: 12.3. System startup scripts
1.35 jmmv 2105:
1.38 dillo 2106: 12.3.1. Disabling handling of system startup scripts
1.35 jmmv 2107:
1.38 dillo 2108: 12.4. System users and groups
2109: 12.5. System shells
1.35 jmmv 2110:
1.38 dillo 2111: 12.5.1. Disabling handling of configuration files
1.35 jmmv 2112:
1.38 dillo 2113: 13. Options handling
1.35 jmmv 2114:
1.38 dillo 2115: 13.1. Global default options
2116: 13.2. Converting packages to use bsd.options.mk
1.48 dillo 2117: 13.3. Option Names
1.35 jmmv 2118:
1.38 dillo 2119: 14. The build process
1.35 jmmv 2120:
1.38 dillo 2121: 14.1. Program location
2122: 14.2. Main targets
2123: 14.3. Other helpful targets
1.35 jmmv 2124:
1.38 dillo 2125: 15. Notes on fixes for packages
1.35 jmmv 2126:
1.38 dillo 2127: 15.1. General operation
1.35 jmmv 2128:
1.38 dillo 2129: 15.1.1. How to pull in variables from /etc/mk.conf
2130: 15.1.2. Where to install documentation
2131: 15.1.3. Restricted packages
2132: 15.1.4. Handling dependencies
2133: 15.1.5. Handling conflicts with other packages
2134: 15.1.6. Packages that cannot or should not be built
2135: 15.1.7. Packages which should not be deleted, once installed
2136: 15.1.8. Handling packages with security problems
2137: 15.1.9. How to handle compiler bugs
2138: 15.1.10. How to handle incrementing versions when fixing an existing
1.1 grant 2139: package
1.38 dillo 2140: 15.1.11. Portability of packages
1.25 rillig 2141:
1.38 dillo 2142: 15.2. Possible downloading issues
1.25 rillig 2143:
1.38 dillo 2144: 15.2.1. Packages whose distfiles aren't available for plain downloading
2145: 15.2.2. How to handle modified distfiles with the 'old' name
1.25 rillig 2146:
1.38 dillo 2147: 15.3. Configuration gotchas
1.25 rillig 2148:
1.38 dillo 2149: 15.3.1. Shared libraries - libtool
2150: 15.3.2. Using libtool on GNU packages that already support libtool
2151: 15.3.3. GNU Autoconf/Automake
1.35 jmmv 2152:
1.38 dillo 2153: 15.4. Building considerations
1.35 jmmv 2154:
1.38 dillo 2155: 15.4.1. CPP defines
1.51 ! rillig 2156: 15.4.2. Getting a list of CPP defines
1.35 jmmv 2157:
1.38 dillo 2158: 15.5. Package specific actions
1.35 jmmv 2159:
1.38 dillo 2160: 15.5.1. User interaction
2161: 15.5.2. Handling licenses
2162: 15.5.3. Installing score files
2163: 15.5.4. Packages containing perl scripts
2164: 15.5.5. Packages with hardcoded paths to other interpreters
2165: 15.5.6. Packages installing perl modules
2166: 15.5.7. Packages installing info files
2167: 15.5.8. Packages installing GConf2 data files
2168: 15.5.9. Packages installing scrollkeeper data files
2169: 15.5.10. Packages installing X11 fonts
2170: 15.5.11. Packages installing GTK2 modules
2171: 15.5.12. Packages installing SGML or XML data
2172: 15.5.13. Packages installing extensions to the MIME database
2173: 15.5.14. Packages using intltool
2174: 15.5.15. Packages installing startup scripts
1.35 jmmv 2175:
1.38 dillo 2176: 15.6. Feedback to the author
1.35 jmmv 2177:
1.38 dillo 2178: 16. Debugging
2179: 17. Submitting and Committing
1.35 jmmv 2180:
1.38 dillo 2181: 17.1. Submitting your packages
1.41 wiz 2182: 17.2. General notes when adding, updating, or removing packages
2183: 17.3. Committing: Importing a package into CVS
2184: 17.4. Updating a package to a newer version
2185: 17.5. Moving a package in pkgsrc
1.25 rillig 2186:
1.38 dillo 2187: Chapter 8. Package components - files, directories and contents
1.1 grant 2188:
2189: Table of Contents
2190:
1.38 dillo 2191: 8.1. Makefile
2192: 8.2. distinfo
2193: 8.3. patches/*
2194: 8.4. Other mandatory files
2195: 8.5. Optional files
2196: 8.6. work*
2197: 8.7. files/*
1.1 grant 2198:
2199: Whenever you're preparing a package, there are a number of files involved which
2200: are described in the following sections.
2201:
1.38 dillo 2202: 8.1. Makefile
1.1 grant 2203:
2204: Building, installation and creation of a binary package are all controlled by
1.23 wiz 2205: the package's Makefile. The Makefile describes various things about a package,
2206: for example from where to get it, how to configure, build, and install it.
2207:
2208: A package Makefile contains several sections that describe the package.
2209:
2210: In the first section there are the following variables, which should appear
2211: exactly in the order given here.
2212:
2213: * DISTNAME is the basename of the distribution file to be downloaded from the
2214: package's website.
2215:
2216: * PKGNAME is the name of the package, as used by pkgsrc. You only need to
2217: provide it if it differs from DISTNAME. Usually it is the directory name
1.27 rillig 2218: together with the version number. It must match the regular expression ^
2219: [A-Za-z0-9][A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit,
2220: and contains only letters, digits, dashes, underscores, dots and plus
2221: signs.
1.23 wiz 2222:
2223: * CATEGORIES is a list of categories which the package fits in. You can
2224: choose any of the top-level directories of pkgsrc for it.
2225:
1.45 wiz 2226: Currently the following values are available for CATEGORIES. If more than
2227: one is used, they need to be separated by spaces:
2228:
1.51 ! rillig 2229: archivers cross geography meta-pkgs security
! 2230: audio databases graphics misc shells
! 2231: benchmarks devel ham multimedia sysutils
! 2232: biology editors inputmethod net textproc
! 2233: cad emulators lang news time
! 2234: chat finance mail parallel wm
! 2235: comms fonts math pkgtools www
! 2236: converters games mbone print x11
1.45 wiz 2237:
1.23 wiz 2238: * MASTER_SITES is a list of URLs where the distribution files can be
2239: downloaded. Each URL must end with a slash.
2240:
1.45 wiz 2241: The MASTER_SITES may make use of the following predefined sites:
1.23 wiz 2242:
1.51 ! rillig 2243: ${MASTER_SITE_APACHE}
! 2244: ${MASTER_SITE_BACKUP}
! 2245: ${MASTER_SITE_CYGWIN}
! 2246: ${MASTER_SITE_DEBIAN}
! 2247: ${MASTER_SITE_FREEBSD}
! 2248: ${MASTER_SITE_FREEBSD_LOCAL}
! 2249: ${MASTER_SITE_GNOME}
! 2250: ${MASTER_SITE_GNU}
! 2251: ${MASTER_SITE_GNUSTEP}
! 2252: ${MASTER_SITE_IFARCHIVE}
! 2253: ${MASTER_SITE_MOZILLA}
! 2254: ${MASTER_SITE_OPENOFFICE}
! 2255: ${MASTER_SITE_PERL_CPAN}
! 2256: ${MASTER_SITE_R_CRAN}
! 2257: ${MASTER_SITE_SOURCEFORGE}
! 2258: ${MASTER_SITE_SUNSITE}
! 2259: ${MASTER_SITE_SUSE}
! 2260: ${MASTER_SITE_TEX_CTAN}
! 2261: ${MASTER_SITE_XCONTRIB}
! 2262: ${MASTER_SITE_XEMACS}
1.45 wiz 2263:
2264: If one of these predefined sites is chosen, you may want to specify a
2265: subdirectory of that site. Since these macros may expand to more than one
2266: actual site, you must use the following construct to specify a
2267: subdirectory:
2268:
1.51 ! rillig 2269: ${MASTER_SITE_GNU:=subdirectory/name/}
! 2270: ${MASTER_SITE_SOURCEFORGE:=project_name/}
1.45 wiz 2271:
2272: Note the trailing slash after the subdirectory name.
2273:
2274: If the package has multiple DISTFILES or multiple PATCHFILES from different
1.47 reed 2275: sites, set SITES_foo to a list of URIs where file "foo" may be found. "foo"
2276: includes the suffix, e.g.:
1.45 wiz 2277:
1.51 ! rillig 2278: DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
! 2279: DISTFILES+= foo-file.tar.gz
! 2280: SITES_foo-file.tar.gz=http://www.somewhere.com/somehow/ \
! 2281: http://www.somewhereelse.com/mirror/somehow/
1.45 wiz 2282:
2283: * DISTFILES: Name(s) of archive file(s) containing distribution. The default
2284: is ${DISTNAME}${EXTRACT_SUFX}. Should only be set if you have more than one
2285: distfile.
2286:
2287: Note that the normal default setting of DISTFILES must be made explicit if
2288: you want to add to it (rather than replace it), as you usually would.
2289:
2290: * EXTRACT_SUFX: Suffix of the distribution file, will be appended to
2291: DISTNAME. Defaults to .tar.gz.
2292:
2293: The second section contains information about separately downloaded patches, if
2294: any.
2295:
1.47 reed 2296: * PATCHFILES: Name(s) of additional files that contain distribution patches.
1.45 wiz 2297: There is no default. pkgsrc will look for them at PATCH_SITES. They will
2298: automatically be uncompressed before patching if the names end with .gz or
2299: .Z.
2300:
2301: * PATCH_SITES: Primary location(s) for distribution patch files (see
2302: PATCHFILES below) if not found locally.
2303:
2304: The third section contains the following variables.
2305:
1.50 rillig 2306: * MAINTAINER is the email address of the person who feels responsible for
2307: this package, and who is most likely to look at problems or questions
2308: regarding this package which have been reported with send-pr(1). Other
2309: developers should contact the MAINTAINER before making major changes to the
2310: package. When packaging a new program, set MAINTAINER to yourself. If you
2311: really can't maintain the package for future updates, set it to <
2312: tech-pkg@NetBSD.org>.
1.23 wiz 2313:
2314: * HOMEPAGE is a URL where users can find more information about the package.
1.1 grant 2315:
1.45 wiz 2316: * COMMENT is a one-line description of the package (should not include the
2317: package name).
1.1 grant 2318:
1.45 wiz 2319: Other variables that affect the build:
1.1 grant 2320:
1.50 rillig 2321: * WRKSRC: The directory where the interesting distribution files of the
2322: package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
2323: most packages.
2324:
2325: If a package doesn't create a subdirectory for itself (most GNU software
2326: does, for instance), but extracts itself in the current directory, you
2327: should set WRKSRC= ${WRKDIR}.
2328:
2329: If a package doesn't create a subdirectory with the name of DISTNAME but
2330: some different name, set WRKSRC to point to the proper name in ${WRKDIR},
2331: for example WRKSRC= ${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
2332: other examples.
2333:
2334: The name of the working directory created by pkgsrc is taken from the
2335: WRKDIR_BASENAME variable. By default, its value is work. If you want to use
2336: the same pkgsrc tree for building different kinds of binary packages, you
2337: can change the variable according to your needs. Two other variables handle
2338: common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
2339: defined in /etc/mk.conf, the first component of the host's name is attached
2340: to the directory name. If OBJMACHINE is defined, the platform name is
2341: attached, which might look like work.i386 or work.sparc.
1.1 grant 2342:
2343: Please pay attention to the following gotchas:
2344:
1.47 reed 2345: * Add MANCOMPRESSED if man pages are installed in compressed form by the
1.1 grant 2346: package; see comment in bsd.pkg.mk.
1.20 ben 2347:
1.1 grant 2348: * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
1.20 ben 2349:
1.38 dillo 2350: * If the package installs any info files, see Section 15.5.7, "Packages
1.1 grant 2351: installing info files".
1.20 ben 2352:
1.38 dillo 2353: 8.2. distinfo
1.1 grant 2354:
1.50 rillig 2355: The distinfo file contains the message digest, or checksum, of each distfile
2356: needed for the package. This ensures that the distfiles retrieved from the
2357: Internet have not been corrupted during transfer or altered by a malign force
2358: to introduce a security hole. Due to recent rumor about weaknesses of digest
2359: algorithms, all distfiles are protected using both SHA1 and RMD160 message
2360: digests, as well as the file size.
1.1 grant 2361:
1.50 rillig 2362: The distinfo file also contains the checksums for all the patches found in the
2363: patches directory (see Section 8.3, "patches/*").
2364:
2365: To regenerate the distinfo file, use the make makedistinfo or make mdi command.
2366:
2367: Some packages have different sets of distfiles depending on the platform, for
1.1 grant 2368: example www/navigator). These are kept in the same distinfo file and care
2369: should be taken when upgrading such a package to ensure distfile information is
2370: not lost.
2371:
1.38 dillo 2372: 8.3. patches/*
1.1 grant 2373:
2374: This directory contains files that are used by the patch(1) command to modify
2375: the sources as distributed in the distribution file into a form that will
2376: compile and run perfectly on NetBSD. The files are applied successively in
2377: alphabetic order (as returned by a shell "patches/patch-*" glob expansion), so
2378: patch-aa is applied before patch-ab, etc.
2379:
2380: The patch-* files should be in diff -bu format, and apply without a fuzz to
2381: avoid problems. (To force patches to apply with fuzz you can set
2382: PATCH_FUZZ_FACTOR=-F2). Furthermore, do not put changes for more than one file
1.47 reed 2383: into a single patch file, as this will make future modifications more
1.1 grant 2384: difficult.
2385:
2386: Similar, a file should be patched at most once, not several times by several
2387: different patches. If a file needs several patches, they should be combined
2388: into one file.
2389:
2390: One important thing to mention is to pay attention that no RCS IDs get stored
2391: in the patch files, as these will cause problems when later checked into the
2392: NetBSD CVS tree. Use the pkgdiff from the pkgtools/pkgdiff package to avoid
2393: these problems.
2394:
2395: For even more automation, we recommend using mkpatches from the same package to
2396: make a whole set of patches. You just have to backup files before you edit them
1.20 ben 2397: to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using
1.1 grant 2398: pkgvi again from the same package. If you upgrade a package this way, you can
1.20 ben 2399: easily compare the new set of patches with the previously existing one with
1.1 grant 2400: patchdiff.
2401:
2402: When you have finished a package, remember to generate the checksums for the
1.38 dillo 2403: patch files by using the make makepatchsum command, see Section 8.2, "distinfo"
1.1 grant 2404: .
2405:
1.46 gdt 2406: When adding a patch that corrects a problem in the distfile (rather than e.g.
2407: enforcing pkgsrc's view of where man pages should go), send the patch as a bug
2408: report to the maintainer. This benefits non-pkgsrc users of the package, and
2409: usually enables removing the patch in future version.
2410:
1.1 grant 2411: Patch files that are distributed by the author or other maintainers can be
2412: listed in $PATCHFILES.
2413:
2414: If it is desired to store any patches that should not be committed into pkgsrc,
2415: they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
2416: directory tree there is expected to have the same "category/package" structure
2417: as pkgsrc, and patches are expected to be stored inside these dirs (also known
1.47 reed 2418: as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
2419: for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
2420: files in the named directory are expected to be patch files, and they are
2421: applied after pkgsrc patches are applied.
1.1 grant 2422:
1.38 dillo 2423: 8.4. Other mandatory files
1.1 grant 2424:
2425: DESCR
1.20 ben 2426:
1.1 grant 2427: A multi-line description of the piece of software. This should include any
2428: credits where they are due. Please bear in mind that others do not share
2429: your sense of humour (or spelling idiosyncrasies), and that others will
2430: read everything that you write here.
1.20 ben 2431:
1.1 grant 2432: PLIST
1.20 ben 2433:
1.1 grant 2434: This file governs the files that are installed on your system: all the
2435: binaries, manual pages, etc. There are other directives which may be
2436: entered in this file, to control the creation and deletion of directories,
1.38 dillo 2437: and the location of inserted files. See Chapter 10, PLIST issues for more
1.1 grant 2438: information.
1.20 ben 2439:
1.38 dillo 2440: 8.5. Optional files
1.1 grant 2441:
2442: INSTALL
1.20 ben 2443:
1.1 grant 2444: This shell script is invoked twice by pkg_add(1). First time after package
2445: extraction and before files are moved in place, the second time after the
2446: files to install are moved in place. This can be used to do any custom
1.20 ben 2447: procedures not possible with @exec commands in PLIST. See pkg_add(1) and
1.1 grant 2448: pkg_create(1) for more information.
1.20 ben 2449:
1.1 grant 2450: DEINSTALL
1.20 ben 2451:
1.1 grant 2452: This script is executed before and after any files are removed. It is this
2453: script's responsibility to clean up any additional messy details around the
2454: package's installation, since all pkg_delete knows is how to delete the
1.20 ben 2455: files created in the original distribution. See pkg_delete(1) and
1.1 grant 2456: pkg_create(1) for more information.
1.20 ben 2457:
1.1 grant 2458: MESSAGE
1.20 ben 2459:
1.50 rillig 2460: This file is displayed after installation of the package. Useful for things
2461: like legal notices on almost-free software and hints for updating config
2462: files after installing modules for apache, PHP etc. Please note that you
2463: can modify variables in it easily by using MESSAGE_SUBST in the package's
1.1 grant 2464: Makefile:
1.20 ben 2465:
1.51 ! rillig 2466: MESSAGE_SUBST+= SOMEVAR="somevalue"
1.20 ben 2467:
1.1 grant 2468: replaces "${SOMEVAR}" with "somevalue" in MESSAGE.
1.20 ben 2469:
1.38 dillo 2470: 8.6. work*
1.1 grant 2471:
1.47 reed 2472: When you type make, the distribution files are unpacked into the directory
1.45 wiz 2473: denoted by WRKDIR. It can be removed by running make clean. Besides the
2474: sources, this directory is also used to keep various timestamp files. The
2475: directory gets removed completely on clean. The default is ${.CURDIR}/work or $
2476: {.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
1.1 grant 2477:
1.38 dillo 2478: 8.7. files/*
1.1 grant 2479:
2480: If you have any files that you wish to be placed in the package prior to
2481: configuration or building, you could place these files here and use a "${CP}"
2482: command in the "pre-configure" target to achieve this. Alternatively, you could
2483: simply diff the file against /dev/null and use the patch mechanism to manage
2484: the creation of this file.
2485:
1.38 dillo 2486: Chapter 9. Programming in Makefiles
1.27 rillig 2487:
2488: Table of Contents
2489:
1.38 dillo 2490: 9.1. Makefile variables
1.27 rillig 2491:
1.38 dillo 2492: 9.1.1. Naming conventions
1.27 rillig 2493:
1.38 dillo 2494: 9.2. Code snippets
1.27 rillig 2495:
1.38 dillo 2496: 9.2.1. Adding things to a list
2497: 9.2.2. Converting an internal list into an external list
2498: 9.2.3. Passing variables to a shell command
2499: 9.2.4. Quoting guideline
2500: 9.2.5. Workaround for a bug in BSD Make
1.27 rillig 2501:
2502: Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
2503: part of the pkgsrc system. Using the make(1) system as a programming language
2504: for a big system like pkgsrc requires some discipline to keep the code correct
2505: and understandable.
2506:
2507: The basic ingredients for Makefile programming are variables (which are
2508: actually macros) and shell commands. Among these shell commands may even be
2509: more complex ones like awk(1) programs. To make sure that every shell command
2510: runs as intended it is necessary to quote all variables correctly when they are
2511: used.
2512:
2513: This chapter describes some patterns, that appear quite often in Makefiles,
2514: including the pitfalls that come along with them.
2515:
1.38 dillo 2516: 9.1. Makefile variables
1.27 rillig 2517:
2518: Makefile variables contain strings that can be processed using the five
2519: operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
2520: make(1) man page.
2521:
2522: When a variable's value is parsed from a Makefile, the hash character ``#'' and
2523: the backslash character ``\'' are handled specially. If a backslash is followed
2524: by a newline, any whitespace immediately in front of the backslash, the
2525: backslash, the newline, and any whitespace immediately behind the newline are
2526: replaced with a single space. A backspace character and an immediately
1.47 reed 2527: following hash character are replaced with a single hash character. Otherwise,
1.27 rillig 2528: the backslash is passed as is. In a variable assignment, any hash character
2529: that is not preceded by a backslash starts a comment that continues upto the
2530: end of the logical line.
2531:
2532: Note: Because of this parsing algorithm the only way to create a variable
2533: consisting of a single backslash is using the ``!='' operator, for example:
2534: BACKSLASH!=echo "\\".
2535:
2536: So far for defining variables. The other thing you can do with variables is
2537: evaluating them. A variable is evaluated when it is part of the right side of
2538: the ``:='' or the ``!='' operator, or directly before executing a shell command
1.47 reed 2539: which the variable is part of. In all other cases, make(1) performs lazy
1.27 rillig 2540: evaluation, that is, variables are not evaluated until there's no other way.
2541: The ``modifiers'' mentioned in the man page also evaluate the variable.
2542:
2543: Some of the modifiers split the string into words and then operate on the
1.47 reed 2544: words, others operate on the string as a whole. When a string is split into
2545: words, it is split as you would expect it from sh(1).
1.27 rillig 2546:
2547: No rule without exception?the .for loop does not follow the shell quoting rules
2548: but splits at sequences of whitespace.
2549:
2550: There are several types of variables that should be handled differently.
2551: Strings and two types of lists.
2552:
1.47 reed 2553: * Strings can contain arbitrary characters. Nevertheless, you should restrict
1.27 rillig 2554: yourself to only using printable characters. Examples are PREFIX and
2555: COMMENT.
2556:
2557: * Internal lists are lists that are never exported to any shell command.
1.47 reed 2558: Their elements are separated by whitespace. Therefore, the elements
1.27 rillig 2559: themselves cannot have embedded whitespace. Any other characters are
2560: allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
2561: BUILD_DEPENDS.
2562:
2563: * External lists are lists that may be exported to a shell command. Their
2564: elements can contain any characters, including whitespace. That's why they
2565: cannot be used in .for loops. Examples are DISTFILES and MASTER_SITES.
2566:
1.38 dillo 2567: 9.1.1. Naming conventions
1.27 rillig 2568:
2569: * All variable names starting with an underscore are reserved for use by the
2570: pkgsrc infrastructure. They shall not be used by package Makefiles.
2571:
2572: * In .for loops you should use lowercase variable names for the iteration
2573: variables.
2574:
2575: * All list variables should have a ``plural'' name, e.g. PKG_OPTIONS or
2576: DISTFILES.
2577:
1.38 dillo 2578: 9.2. Code snippets
1.27 rillig 2579:
2580: This section presents you with some code snippets you should use in your own
2581: code. If you don't find anything appropriate here, you should test your code
2582: and add it here.
2583:
1.38 dillo 2584: 9.2.1. Adding things to a list
1.27 rillig 2585:
1.51 ! rillig 2586: STRING= foo * bar `date`
! 2587: INT_LIST= # empty
! 2588: ANOTHER_INT_LIST= apache-[0-9]*:../../www/apache
! 2589: EXT_LIST= # empty
! 2590: ANOTHER_EXT_LIST= a=b c=d
! 2591:
! 2592: INT_LIST+= ${STRING} # 1
! 2593: INT_LIST+= ${ANOTHER_INT_LIST} # 2
! 2594: EXT_LIST+= ${STRING:Q} # 3
! 2595: EXT_LIST+= ${ANOTHER_EXT_LIST} # 4
1.27 rillig 2596:
2597: When you add a string to an external list (example 3), it must be quoted. In
2598: all other cases, you must not add a quoting level. You must not merge internal
2599: and external lists, unless you are sure that all entries are correctly
2600: interpreted in both lists.
2601:
1.38 dillo 2602: 9.2.2. Converting an internal list into an external list
1.27 rillig 2603:
1.51 ! rillig 2604: EXT_LIST= # empty
! 2605: .for i in ${INT_LIST}
! 2606: EXT_LIST+= ${i:Q}""
! 2607: .endfor
1.27 rillig 2608:
2609: This code converts the internal list INT_LIST into the external list EXT_LIST.
2610: As the elements of an internal list are unquoted they must be quoted here. The
2611: reason for appending "" is explained below.
2612:
1.38 dillo 2613: 9.2.3. Passing variables to a shell command
1.27 rillig 2614:
1.51 ! rillig 2615: STRING= foo bar < > * `date` $$HOME ' "
! 2616: EXT_LIST= string=${STRING:Q} x=second\ item
1.27 rillig 2617:
1.51 ! rillig 2618: all:
! 2619: echo ${STRING} # 1
! 2620: echo "${STRING}" # 2
! 2621: echo "${STRING:Q}" # 3
! 2622: echo ${STRING:Q} # 4
! 2623: echo x${STRING:Q} | sed 1s,.,, # 5
! 2624: env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
1.27 rillig 2625:
2626: Example 1 leads to a syntax error in the shell, as the characters are just
2627: copied.
2628:
2629: Example 2 leads to a syntax error too, and if you leave out the last "
2630: character from ${STRING}, date(1) will be executed. The $HOME shell variable
2631: would be evaluated, too.
2632:
2633: Example 3 outputs each space character preceded by a backslash (or not),
2634: depending on the implementation of the echo(1) command.
2635:
2636: Example 4 handles correctly every string that does not start with a dash. In
2637: that case, the result depends on the implementation of the echo(1) command. As
1.47 reed 2638: long as you can guarantee that your input does not start with a dash, this form
1.27 rillig 2639: is appropriate.
2640:
2641: Example 5 handles even the case of a leading dash correctly.
2642:
1.47 reed 2643: The EXT_LIST does not need to be quoted because the quoting has already been
2644: done when adding elements to the list.
1.27 rillig 2645:
2646: As internal lists shall not be passed to the shell, there is no example for it.
2647:
1.38 dillo 2648: 9.2.4. Quoting guideline
1.27 rillig 2649:
2650: There are many possible sources of wrongly quoted variables. This section lists
2651: some of the commonly known ones.
2652:
2653: * Whenever you use the value of a list, think about what happens to leading
1.47 reed 2654: or trailing whitespace. If the list is a well-formed shell expression, you
1.27 rillig 2655: can apply the :M* modifier to strip leading and trailing whitespace from
2656: each word. The :M operator first splits its argument according to the rules
2657: of the shell, and then creates a new list consisting of all words that
2658: match the shell glob expression *, that is: all. One class of situations
2659: where this is needed is when adding a variable like CPPFLAGS to
1.47 reed 2660: CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
1.27 rillig 2661: strips the leading and trailing whitespace from the variable and then
2662: passes it to the other configure scripts. But these configure scripts
2663: expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
2664: That's why we better pass the CPPFLAGS value properly trimmed. And here is
2665: how we do it:
2666:
1.51 ! rillig 2667: CPPFLAGS= # empty
! 2668: CPPFLAGS+= -Wundef -DPREFIX=\"${PREFIX:Q}\"
! 2669: CPPFLAGS+= ${MY_CPPFLAGS}
! 2670:
! 2671: CONFIGURE_ARGS+= CPPFLAGS=${CPPFLAGS:M*:Q}
! 2672:
! 2673: all:
! 2674: echo x${CPPFLAGS:Q}x # leading and trailing whitespace
! 2675: echo x${CONFIGURE_ARGS}x # properly trimmed
1.27 rillig 2676:
2677: * The example above contains one bug: The ${PREFIX} is a properly quoted
2678: shell expression, but there is the C compiler after it, which also expects
2679: a properly quoted string (this time in C syntax). The version above is
2680: therefore only correct if ${PREFIX} does not have embedded backslashes or
2681: double quotes. If you want to allow these, you have to add another layer of
2682: quoting to each variable that is used as a C string literal. You cannot use
2683: the :Q operator for it, as this operator only works for the shell.
2684:
1.47 reed 2685: * Whenever a variable can be empty, the :Q operator can have surprising
1.27 rillig 2686: results. Here are two completely different cases which can be solved with
2687: the same trick.
2688:
1.51 ! rillig 2689: EMPTY= # empty
! 2690: empty_test:
! 2691: for i in a ${EMPTY:Q} c; do \
! 2692: echo "$$i"; \
! 2693: done
! 2694:
! 2695: for_test:
! 2696: .for i in a:\ a:\test.txt
! 2697: echo ${i:Q}
! 2698: echo "foo"
! 2699: .endfor
1.27 rillig 2700:
2701: The first example will only print two of the three lines we might have
2702: expected. This is because ${EMPTY:Q} expands to the empty string, which the
2703: shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
2704: be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
2705: these are wrong).
2706:
2707: The second example will only print three lines instead of four. The first
2708: line looks like a:\ echo foo. This is because the backslash of the value a:
2709: \ is interpreted as a line-continuation by make(1), which makes the second
2710: line the arguments of the echo(1) command from the first line. To avoid
2711: this, write ${i:Q}"".
2712:
1.38 dillo 2713: 9.2.5. Workaround for a bug in BSD Make
1.27 rillig 2714:
2715: The pkgsrc bmake program does not handle the following assignment correctly. In
2716: case _othervar_ contains a ``-'' character, one of the closing braces is
2717: included in ${VAR} after this code executes.
2718:
1.51 ! rillig 2719: VAR:= ${VAR:N${_othervar_:C/-//}}
1.27 rillig 2720:
2721: For a more complex code snippet and a workaround, see the package regress/
2722: make-quoting, testcase bug1.
2723:
1.38 dillo 2724: Chapter 10. PLIST issues
1.1 grant 2725:
2726: Table of Contents
2727:
1.38 dillo 2728: 10.1. RCS ID
2729: 10.2. Semi-automatic PLIST generation
2730: 10.3. Tweaking output of make print-PLIST
2731: 10.4. Variable substitution in PLIST
1.48 dillo 2732: 10.5. Man page compression
1.38 dillo 2733: 10.6. Changing PLIST source with PLIST_SRC
1.47 reed 2734: 10.7. Platform-specific and differing PLISTs
1.38 dillo 2735: 10.8. Sharing directories between packages
1.1 grant 2736:
2737: The PLIST file contains a package's "packing list", i.e. a list of files that
2738: belong to the package (relative to the ${PREFIX} directory it's been installed
1.47 reed 2739: in) plus some additional statements - see the pkg_create(1) man page for a full
1.1 grant 2740: list. This chapter addresses some issues that need attention when dealing with
2741: the PLIST file (or files, see below!).
2742:
1.38 dillo 2743: 10.1. RCS ID
1.1 grant 2744:
2745: Be sure to add a RCS ID line as the first thing in any PLIST file you write:
2746:
1.51 ! rillig 2747: @comment $NetBSD$
1.1 grant 2748:
1.38 dillo 2749: 10.2. Semi-automatic PLIST generation
1.1 grant 2750:
2751: You can use the make print-PLIST command to output a PLIST that matches any new
1.38 dillo 2752: files since the package was extracted. See Section 14.3, "Other helpful
1.1 grant 2753: targets" for more information on this target.
2754:
1.38 dillo 2755: 10.3. Tweaking output of make print-PLIST
1.1 grant 2756:
1.38 dillo 2757: If you have used any of the *-dirs packages, as explained in Section 10.8,
1.1 grant 2758: "Sharing directories between packages", you may have noticed that make
2759: print-PLIST outputs a set of @comments instead of real @dirrm lines. You can
2760: also do this for specific directories and files, so that the results of that
2761: command are very close to reality. This helps a lot during the update of
2762: packages.
2763:
2764: The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
2765: used to filter the output of print-PLIST. You can append any chunk of AWK
2766: scripting you like to it, but be careful with quoting.
2767:
2768: For example, to get all files inside the libdata/foo directory removed from the
2769: resulting PLIST:
2770:
1.51 ! rillig 2771: PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }
1.1 grant 2772:
2773: And to get all the @dirrm lines referring to a specific (shared) directory
2774: converted to @comments:
2775:
1.51 ! rillig 2776: PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; }
1.1 grant 2777:
1.38 dillo 2778: 10.4. Variable substitution in PLIST
1.1 grant 2779:
2780: A number of variables are substituted automatically in PLISTs when a package is
2781: installed on a system. This includes the following variables:
2782:
2783: ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
1.20 ben 2784:
1.1 grant 2785: Some packages like emacs and perl embed information about which
2786: architecture they were built on into the pathnames where they install their
1.47 reed 2787: files. To handle this case, PLIST will be preprocessed before actually
2788: used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
2789: gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
2790: PLIST somewhere - use this on packages that have GNU autoconf-created
2791: configure scripts.
1.20 ben 2792:
1.1 grant 2793: Legacy note
1.20 ben 2794:
1.1 grant 2795: There used to be a symbol "$ARCH" that was replaced by the output of uname
2796: -m, but that's no longer supported and has been removed.
1.20 ben 2797:
1.1 grant 2798: ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
1.20 ben 2799:
1.1 grant 2800: Some packages want to embed the OS name and version into some paths. To do
2801: this, use these variables in the PLIST:
1.20 ben 2802:
1.1 grant 2803: * ${OPSYS} - output of "uname -s"
1.20 ben 2804:
1.1 grant 2805: * ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
1.20 ben 2806:
1.1 grant 2807: * ${OS_VERSION} - "uname -r"
1.20 ben 2808:
1.1 grant 2809: ${PKGLOCALEDIR}
1.20 ben 2810:
1.1 grant 2811: Packages that install locale files should list them in the PLIST as "$
2812: {PKGLOCALEDIR}/locale/de/LC_MESSAGES/..." instead of "share/locale/de/
2813: LC_MESSAGES/...". This properly handles the fact that different operating
2814: systems expect locale files to be either in share or lib by default.
1.20 ben 2815:
1.1 grant 2816: For a complete list of values which are replaced by default, please look in
2817: bsd.pkg.mk (and search for PLIST_SUBST).
2818:
2819: If you want to change other variables not listed above, you can add variables
2820: and their expansions to this variable in the following way, similar to
1.38 dillo 2821: MESSAGE_SUBST (see Section 8.5, "Optional files"):
1.1 grant 2822:
1.51 ! rillig 2823: PLIST_SUBST+= SOMEVAR="somevalue"
1.1 grant 2824:
2825: This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".
2826:
1.48 dillo 2827: 10.5. Man page compression
1.1 grant 2828:
1.47 reed 2829: Man pages should be installed in compressed form if MANZ is set (in
2830: bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
2831: suffix ".gz" is appended/removed automatically for man pages according to MANZ
2832: and MANCOMPRESSED being set or not, see above for details. This modification of
2833: the PLIST file is done on a copy of it, not PLIST itself.
1.1 grant 2834:
1.38 dillo 2835: 10.6. Changing PLIST source with PLIST_SRC
1.1 grant 2836:
2837: To use one or more files as source for the PLIST used in generating the binary
2838: package, set the variable PLIST_SRC to the names of that file(s). The files are
2839: later concatenated using cat(1), and order of things is important.
2840:
1.47 reed 2841: 10.7. Platform-specific and differing PLISTs
1.1 grant 2842:
2843: Some packages decide to install a different set of files based on the operating
2844: system being used. These differences can be automatically handled by using the
2845: following files:
2846:
2847: * PLIST.common
1.20 ben 2848:
1.1 grant 2849: * PLIST.${OPSYS}
1.20 ben 2850:
1.21 ben 2851: * PLIST.${MACHINE_ARCH}
2852:
2853: * PLIST.${OPSYS}-${MACHINE_ARCH}
2854:
1.1 grant 2855: * PLIST.common_end
2856:
1.38 dillo 2857: 10.8. Sharing directories between packages
1.1 grant 2858:
2859: A "shared directory" is a directory where multiple (and unrelated) packages
2860: install files. These directories are problematic because you have to add
2861: special tricks in the PLIST to conditionally remove them, or have some
2862: centralized package handle them.
2863:
2864: Within pkgsrc, you'll find both approaches. If a directory is shared by a few
2865: unrelated packages, it's often not worth to add an extra package to remove it.
2866: Therefore, one simply does:
2867:
1.51 ! rillig 2868: @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE}
1.1 grant 2869:
2870: in the PLISTs of all affected packages, instead of the regular "@dirrm" line.
2871:
2872: However, if the directory is shared across many packages, two different
2873: solutions are available:
2874:
2875: 1. If the packages have a common dependency, the directory can be removed in
2876: that. For example, see textproc/scrollkeeper, which removes the shared
2877: directory share/omf.
1.20 ben 2878:
1.1 grant 2879: 2. If the packages using the directory are not related at all (they have no
2880: common dependencies), a *-dirs package is used.
1.20 ben 2881:
1.1 grant 2882: From now on, we'll discuss the second solution. To get an idea of the *-dirs
2883: packages available, issue:
2884:
1.51 ! rillig 2885: % cd .../pkgsrc
! 2886: % ls -d */*-dirs
1.1 grant 2887:
2888: Their use from other packages is very simple. The USE_DIRS variable takes a
2889: list of package names (without the "-dirs" part) together with the required
1.34 wiz 2890: version number (always pick the latest one when writing new packages).
1.1 grant 2891:
2892: For example, if a package installs files under share/applications, it should
2893: have the following line in it:
2894:
1.51 ! rillig 2895: USE_DIRS+= xdg-1.1
1.1 grant 2896:
2897: After regenerating the PLIST using make print-PLIST, you should get the right
2898: (commented out) lines.
2899:
1.47 reed 2900: Note that even if your package is using $X11BASE, it must not depend on the
1.1 grant 2901: *-x11-dirs packages. Just specify the name without that part and pkgsrc (in
2902: particular, mk/dirs.mk) will take care of it.
2903:
1.38 dillo 2904: Chapter 11. Buildlink methodology
1.1 grant 2905:
2906: Table of Contents
2907:
1.38 dillo 2908: 11.1. Converting packages to use buildlink3
2909: 11.2. Writing buildlink3.mk files
1.20 ben 2910:
1.38 dillo 2911: 11.2.1. Anatomy of a buildlink3.mk file
2912: 11.2.2. Updating BUILDLINK_DEPENDS.pkg in buildlink3.mk files
1.20 ben 2913:
1.38 dillo 2914: 11.3. Writing builtin.mk files
1.20 ben 2915:
1.38 dillo 2916: 11.3.1. Anatomy of a builtin.mk file
2917: 11.3.2. Global preferences for native or pkgsrc software
1.20 ben 2918:
1.1 grant 2919: Buildlink is a framework in pkgsrc that controls what headers and libraries are
2920: seen by a package's configure and build processes. This is implemented in a two
2921: step process:
2922:
2923: 1. Symlink headers and libraries for dependencies into BUILDLINK_DIR, which by
2924: default is a subdirectory of WRKDIR.
1.20 ben 2925:
1.1 grant 2926: 2. Create wrapper scripts that are used in place of the normal compiler tools
2927: that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib into
2928: references to BUILDLINK_DIR. The wrapper scripts also make native compiler
2929: on some operating systems look like GCC, so that packages that expect GCC
2930: won't require modifications to build with those native compilers.
1.20 ben 2931:
1.1 grant 2932: This normalizes the environment in which a package is built so that the package
2933: may be built consistently despite what other software may be installed. Please
2934: note that the normal system header and library paths, e.g. /usr/include, /usr/
2935: lib, etc., are always searched -- buildlink3 is designed to insulate the
2936: package build from non-system-supplied software.
2937:
1.38 dillo 2938: 11.1. Converting packages to use buildlink3
1.1 grant 2939:
2940: The process of converting packages to use the buildlink3 framework
2941: ("bl3ifying") is fairly straightforward. The things to keep in mind are:
2942:
1.22 tv 2943: 1. Ensure that the build always calls the wrapper scripts instead of the
1.1 grant 2944: actual toolchain. Some packages are tricky, and the only way to know for
2945: sure is the check ${WRKDIR}/.work.log to see if the wrappers are being
2946: invoked.
1.20 ben 2947:
1.22 tv 2948: 2. Don't override PREFIX from within the package Makefile, e.g. Java VMs,
1.1 grant 2949: standalone shells, etc., because the code to symlink files into $
2950: {BUILDLINK_DIR} looks for files relative to "pkg_info -qp pkgname".
1.20 ben 2951:
1.22 tv 2952: 3. Remember that only the buildlink3.mk files that you list in a package's
1.1 grant 2953: Makefile are added as dependencies for that package.
1.20 ben 2954:
1.1 grant 2955: If a dependency on a particular package is required for its libraries and
2956: headers, then we replace:
2957:
1.51 ! rillig 2958: DEPENDS+= foo>=1.1.0:../../category/foo
1.1 grant 2959:
2960: with
2961:
1.51 ! rillig 2962: .include "../../category/foo/buildlink3.mk"
1.1 grant 2963:
1.47 reed 2964: The buildlink3.mk files usually define the required dependencies. If you need a
2965: newer version of the dependency when using buildlink3.mk files, then you can
2966: define it in your Makefile; for example:
2967:
1.51 ! rillig 2968: BUILDLINK_DEPENDS.foo+= foo>=1.1.0
! 2969: .include "../../category/foo/buildlink3.mk"
1.47 reed 2970:
1.1 grant 2971: There are several buildlink3.mk files in pkgsrc/mk that handle special package
2972: issues:
2973:
2974: * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
2975: implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.
1.20 ben 2976:
1.47 reed 2977: * curses.buildlink3.mk: If the system comes with neither Curses nor NCurses,
1.1 grant 2978: this will take care to install the devel/ncurses package.
1.20 ben 2979:
1.1 grant 2980: * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding
2981: a dependency on Heimdal or MIT-krb5 for packages that require a Kerberos 5
2982: implementation.
1.20 ben 2983:
1.1 grant 2984: * motif.buildlink3.mk checks for a system-provided Motif installation or adds
1.47 reed 2985: a dependency on x11/lesstif or x11/openmotif.
1.20 ben 2986:
1.1 grant 2987: * ossaudio.buildlink3.mk defines several variables that may be used by
1.47 reed 2988: packages that use the Open Sound System (OSS) API.
1.20 ben 2989:
1.1 grant 2990: * pgsql.buildlink3.mk will accept either Postgres 7.3 or 7.4, whichever is
2991: found installed. See the file for more information.
1.20 ben 2992:
1.1 grant 2993: * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native
1.47 reed 2994: pthreads or adds a dependency on devel/pth as needed.
1.20 ben 2995:
1.1 grant 2996: * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena
2997: widgets library.
1.20 ben 2998:
1.1 grant 2999: The comments in those buildlink3.mk files provide a more complete description
3000: of how to use them properly.
3001:
1.38 dillo 3002: 11.2. Writing buildlink3.mk files
1.1 grant 3003:
3004: A package's buildlink3.mk file is included by Makefiles to indicate the need to
3005: compile and link against header files and libraries provided by the package. A
3006: buildlink3.mk file should always provide enough information to add the correct
3007: type of dependency relationship and include any other buildlink3.mk files that
3008: it needs to find headers and libraries that it needs in turn.
3009:
1.20 ben 3010: To generate an initial buildlink3.mk file for further editing, Rene Hexel's
1.1 grant 3011: pkgtools/createbuildlink package is highly recommended. For most packages, the
3012: following command will generate a good starting point for buildlink3.mk files:
3013:
3014: % cd pkgsrc/category/pkgdir
1.49 rillig 3015: % createbuildlink >buildlink3.mk
1.1 grant 3016:
1.38 dillo 3017: 11.2.1. Anatomy of a buildlink3.mk file
1.1 grant 3018:
3019: The following real-life example buildlink3.mk is taken from pkgsrc/graphics/
3020: tiff:
3021:
1.51 ! rillig 3022: # $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $
1.1 grant 3023:
1.51 ! rillig 3024: BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH}+
! 3025: TIFF_BUILDLINK3_MK:= ${TIFF_BUILDLINK3_MK}+
1.1 grant 3026:
1.51 ! rillig 3027: .if !empty(BUILDLINK_DEPTH:M+)
! 3028: BUILDLINK_DEPENDS+= tiff
! 3029: .endif
1.1 grant 3030:
1.51 ! rillig 3031: BUILDLINK_PACKAGES:= ${BUILDLINK_PACKAGES:Ntiff}
! 3032: BUILDLINK_PACKAGES+= tiff
1.1 grant 3033:
1.51 ! rillig 3034: .if !empty(TIFF_BUILDLINK3_MK:M+)
! 3035: BUILDLINK_DEPENDS.tiff+= tiff>=3.6.1
! 3036: BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff
! 3037: .endif # TIFF_BUILDLINK3_MK
1.1 grant 3038:
1.51 ! rillig 3039: .include "../../devel/zlib/buildlink3.mk"
! 3040: .include "../../graphics/jpeg/buildlink3.mk"
1.1 grant 3041:
1.51 ! rillig 3042: BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//}
1.1 grant 3043:
3044: The header and footer manipulate BUILDLINK_DEPTH, which is common across all
3045: buildlink3.mk files and is used to track at what depth we are including
3046: buildlink3.mk files.
3047:
3048: The first section controls if the dependency on pkg is added. BUILDLINK_DEPENDS
3049: is the global list of packages for which dependencies are added by buildlink3.
3050:
3051: The second section advises pkgsrc that the buildlink3.mk file for pkg has been
3052: included at some point. BUILDLINK_PACKAGES is the global list of packages for
3053: which buildlink3.mk files have been included. It must always be appended to
3054: within a buildlink3.mk file.
3055:
3056: The third section is protected from multiple inclusion and controls how the
3057: dependency on pkg is added. Several important variables are set in the section:
3058:
1.14 xtraeme 3059: * BUILDLINK_DEPENDS.pkg is the actual dependency recorded in the installed
1.1 grant 3060: package; this should always be set using += to ensure that we're appending
3061: to any pre-existing list of values. This variable should be set to the
3062: first version of the package that had the last change in the major number
3063: of a shared library or that had a major API change.
1.20 ben 3064:
1.47 reed 3065: * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory.
1.20 ben 3066:
1.1 grant 3067: * BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
3068: BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
3069: is selected by setting BUILDLINK_DEPMETHOD.pkg to "build". By default, the
3070: full dependency is used.
1.20 ben 3071:
1.14 xtraeme 3072: * BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS. pkg (not shown above) are
1.1 grant 3073: lists of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and
3074: library search paths. These default to "include" and "lib" respectively.
1.20 ben 3075:
1.1 grant 3076: * BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags
3077: to add to CPPFLAGS, which are passed on to the configure and build phases.
3078: The "-I" option should be avoided and instead be handled using
3079: BUILDLINK_INCDIRS.pkg as above.
1.20 ben 3080:
1.1 grant 3081: The following variables are all optionally defined within this second section
3082: (protected against multiple inclusion) and control which package files are
3083: symlinked into ${BUILDLINK_DIR} and how their names are transformed during the
3084: symlinking:
3085:
3086: * BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to $
3087: {BUILDLINK_PREFIX.pkg} to be symlinked into ${BUILDLINK_DIR}, e.g. include/
3088: *.h.
1.20 ben 3089:
1.1 grant 3090: * BUILDLINK_FILES_CMD.pkg (not shown above) is a shell pipeline that outputs
3091: to stdout a list of files relative to ${BUILDLINK_PREFIX.pkg}. The
3092: resulting files are to be symlinked into ${BUILDLINK_DIR}. By default, this
3093: takes the +CONTENTS of a pkg and filters it through $
3094: {BUILDLINK_CONTENTS_FILTER.pkg}.
1.20 ben 3095:
1.1 grant 3096: * BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that
3097: filters +CONTENTS input into a list of files relative to $
3098: {BUILDLINK_PREFIX.pkg} on stdout. By default for overwrite packages,
3099: BUILDLINK_CONTENTS_FILTER.pkg outputs the contents of the include and lib
3100: directories in the package +CONTENTS, and for pkgviews packages, it outputs
3101: any libtool archives in lib directories.
1.20 ben 3102:
1.1 grant 3103: * BUILDLINK_TRANSFORM.pkg (not shown above) is a list of sed arguments used
3104: to transform the name of the source filename into a destination filename,
3105: e.g. -e "s|/curses.h|/ncurses.h|g".
1.20 ben 3106:
1.1 grant 3107: The last section includes any buildlink3.mk needed for pkg's library
3108: dependencies. Including these buildlink3.mk files means that the headers and
3109: libraries for these dependencies are also symlinked into ${BUILDLINK_DIR}
3110: whenever the pkg buildlink3.mk file is included.
3111:
1.38 dillo 3112: 11.2.2. Updating BUILDLINK_DEPENDS. pkg in buildlink3.mk files
1.1 grant 3113:
3114: There are two situations that require increasing the dependency listed in
3115: BUILDLINK_DEPENDS.pkg after a package update:
3116:
3117: 1. if the sonames (major number of the library version) of any installed
1.47 reed 3118: shared libraries change.
1.20 ben 3119:
1.1 grant 3120: 2. if the API or interface to the header files change.
1.20 ben 3121:
1.1 grant 3122: In these cases, BUILDLINK_DEPENDS.pkg should be adjusted to require at least
3123: the new package version. In some cases, the packages that depend on this new
3124: version may need their PKGREVISIONs increased and, if they have buildlink3.mk
1.45 wiz 3125: files, their BUILDLINK_DEPENDS.pkg adjusted, too. This is needed so that binary
3126: packages made using it will require the correct package dependency and not
3127: settle for an older one which will not contain the necessary shared libraries.
1.1 grant 3128:
3129: Please take careful consideration before adjusting BUILDLINK_DEPENDS.pkg as we
3130: don't want to cause unneeded package deletions and rebuilds. In many cases, new
3131: versions of packages work just fine with older dependencies. See Section
1.38 dillo 3132: 15.1.4, "Handling dependencies" for more information about dependencies on
1.36 wiz 3133: other packages, including the BUILDLINK_RECOMMENDED and RECOMMENDED
3134: definitions.
1.1 grant 3135:
1.38 dillo 3136: 11.3. Writing builtin.mk files
1.1 grant 3137:
3138: Some packages in pkgsrc install headers and libraries that coincide with
3139: headers and libraries present in the base system. Aside from a buildlink3.mk
3140: file, these packages should also include a builtin.mk file that includes the
3141: necessary checks to decide whether using the built-in software or the pkgsrc
3142: software is appropriate.
3143:
3144: The only requirements of a builtin.mk file for pkg are:
3145:
3146: 1. It should set USE_BUILTIN.pkg to either "yes" or "no" after it is included.
1.20 ben 3147:
1.1 grant 3148: 2. It should not override any USE_BUILTIN.pkg which is already set before the
3149: builtin.mk file is included.
1.20 ben 3150:
1.1 grant 3151: 3. It should be written to allow multiple inclusion. This is very important
3152: and takes careful attention to Makefile coding.
1.20 ben 3153:
1.38 dillo 3154: 11.3.1. Anatomy of a builtin.mk file
1.1 grant 3155:
3156: The following is the recommended template for builtin.mk files:
3157:
1.51 ! rillig 3158: .if !defined(IS_BUILTIN.foo)
! 3159: #
! 3160: # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
! 3161: # genuinely exists in the system or not.
! 3162: #
! 3163: IS_BUILTIN.foo?= no
! 3164:
! 3165: # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
! 3166: # version can be determined.
! 3167: #
! 3168: . if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
! 3169: BUILTIN_PKG.foo?= foo-1.0
! 3170: . endif
! 3171: .endif # IS_BUILTIN.foo
! 3172:
! 3173: .if !defined(USE_BUILTIN.foo)
! 3174: USE_BUILTIN.foo?= ${IS_BUILTIN.foo}
! 3175: . if defined(BUILTIN_PKG.foo)
! 3176: . for _depend_ in ${BUILDLINK_DEPENDS.foo}
! 3177: . if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
! 3178: USE_BUILTIN.foo!= \
! 3179: if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then \
! 3180: ${ECHO} "yes"; \
! 3181: else \
! 3182: ${ECHO} "no"; \
! 3183: fi
! 3184: . endif
! 3185: . endfor
! 3186: . endif
! 3187: .endif # USE_BUILTIN.foo
! 3188:
! 3189: CHECK_BUILTIN.foo?= no
! 3190: .if !empty(CHECK_BUILTIN.foo:M[nN][oO])
! 3191: #
! 3192: # Here we place code that depends on whether USE_BUILTIN.foo is set to
! 3193: # "yes" or "no".
! 3194: #
! 3195: .endif # CHECK_BUILTIN.foo
1.1 grant 3196:
3197: The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the
3198: base system. This should not be a base system software with similar
3199: functionality to pkg; it should only be "yes" if the actual package is included
3200: as part of the base system. This variable is only used internally within the
3201: builtin.mk file.
3202:
3203: The second section sets BUILTIN_PKG.pkg to the version of pkg in the base
3204: system if it exists (if IS_BUILTIN.pkg is "yes"). This variable is only used
3205: internally within the builtin.mk file.
3206:
3207: The third section sets USE_BUILTIN.pkg and is required in all builtin.mk files.
3208: The code in this section must make the determination whether the built-in
1.14 xtraeme 3209: software is adequate to satisfy the dependencies listed in BUILDLINK_DEPENDS.
3210: pkg. This is typically done by comparing BUILTIN_PKG.pkg against each of the
3211: dependencies in BUILDLINK_DEPENDS.pkg. USE_BUILTIN.pkg must be set to the
3212: correct value by the end of the builtin.mk file. Note that USE_BUILTIN.pkg may
3213: be "yes" even if IS_BUILTIN.pkg is "no" because we may make the determination
3214: that the built-in version of the software is similar enough to be used as a
3215: replacement.
1.1 grant 3216:
3217: The last section is guarded by CHECK_BUILTIN.pkg, and includes code that uses
3218: the value of USE_BUILTIN.pkg set in the previous section. This typically
3219: includes, e.g., adding additional dependency restrictions and listing
3220: additional files to symlink into ${BUILDLINK_DIR} (via BUILDLINK_FILES.pkg).
3221:
1.38 dillo 3222: 11.3.2. Global preferences for native or pkgsrc software
1.1 grant 3223:
3224: When building packages, it's possible to choose whether to set a global
3225: preference for using either the built-in (native) version or the pkgsrc version
3226: of software to satisfy a dependency. This is controlled by setting
3227: PREFER_PKGSRC and PREFER_NATIVE. These variables take values of either "yes",
3228: "no", or a list of packages. PREFER_PKGSRC tells pkgsrc to use the pkgsrc
3229: versions of software, while PREFER_NATIVE tells pkgsrc to use the built-in
3230: versions. Preferences are determined by the most specific instance of the
3231: package in either PREFER_PKGSRC or PREFER_NATIVE. If a package is specified in
3232: neither or in both variables, then PREFER_PKGSRC has precedence over
3233: PREFER_NATIVE. For example, to require using pkgsrc versions of software for
3234: all but the most basic bits on a NetBSD system, you can set:
3235:
1.51 ! rillig 3236: PREFER_PKGSRC= yes
! 3237: PREFER_NATIVE= getopt skey tcp_wrappers
1.1 grant 3238:
3239: A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise
3240: it is simply ignored in that list.
3241:
1.38 dillo 3242: Chapter 12. The pkginstall framework
1.35 jmmv 3243:
3244: Table of Contents
3245:
1.38 dillo 3246: 12.1. Files and directories outside the installation prefix
1.35 jmmv 3247:
1.38 dillo 3248: 12.1.1. Directory manipulation
3249: 12.1.2. File manipulation
1.35 jmmv 3250:
1.38 dillo 3251: 12.2. Configuration files
1.35 jmmv 3252:
1.38 dillo 3253: 12.2.1. How PKG_SYSCONFDIR is set
1.47 reed 3254: 12.2.2. Telling the software where configuration files are
1.38 dillo 3255: 12.2.3. Patching installations
3256: 12.2.4. Disabling handling of configuration files
1.35 jmmv 3257:
1.38 dillo 3258: 12.3. System startup scripts
1.35 jmmv 3259:
1.38 dillo 3260: 12.3.1. Disabling handling of system startup scripts
1.35 jmmv 3261:
1.38 dillo 3262: 12.4. System users and groups
3263: 12.5. System shells
1.35 jmmv 3264:
1.38 dillo 3265: 12.5.1. Disabling handling of configuration files
1.35 jmmv 3266:
3267: This chapter describes the framework known as pkginstall, whose key features
3268: are:
3269:
3270: * Generic installation and manipulation of directories and files outside the
3271: pkgsrc-handled tree, LOCALBASE.
3272:
3273: * Automatic handling of configuration files during installation, provided
3274: that packages are correctly designed.
3275:
3276: * Generation and installation of system startup scripts.
3277:
3278: * Registration of system users and groups.
3279:
3280: * Registration of system shells.
3281:
1.47 reed 3282: The following sections inspect each of the above points in detail. Note that in
3283: order to use any of the described functionalities, you must add the following
3284: to your package's Makefile:
1.35 jmmv 3285:
1.51 ! rillig 3286: USE_PKGINSTALL= YES
1.35 jmmv 3287:
3288: You may be thinking that many of the things described here could be easily done
3289: with simple code in the package's post-installation target (post-install). This
3290: is incorrect, as the code in them is only executed when building from source.
3291: Machines using binary packages could not benefit from it at all (as the code
3292: itself could be unavailable). Therefore, the only way to achieve any of the
3293: items described above is by means of the installation scripts, which are
3294: automatically generated by pkginstall.
3295:
1.38 dillo 3296: 12.1. Files and directories outside the installation prefix
1.35 jmmv 3297:
3298: As you already know, the PLIST file holds a list of files and directories that
3299: belong to a package. The names used in it are relative to the installation
3300: prefix (${PREFIX}), which means that it cannot register files outside this
3301: directory (absolute path names are not allowed). Despite this restriction, some
3302: packages need to install files outside this location; e.g., under ${VARBASE} or
3303: ${PKG_SYSCONFDIR}.
3304:
3305: The only way to achieve this is to create such files during installation time
3306: by using the installation scripts. These scripts can run arbitrary commands, so
1.47 reed 3307: they have the potential to create and manage files anywhere in the file system.
1.35 jmmv 3308: Here is where pkginstall comes into play: it provides generic scripts to
3309: abstract the manipulation of such files and directories based on variables set
1.47 reed 3310: in the package's Makefile. The rest of this section describes these variables.
1.35 jmmv 3311:
1.38 dillo 3312: 12.1.1. Directory manipulation
1.35 jmmv 3313:
3314: The following variables can be set to request the creation of directories
1.47 reed 3315: anywhere in the file system:
1.35 jmmv 3316:
3317: * MAKE_DIRS and OWN_DIRS contain a list of directories that should be created
3318: and should attempt to be destroyed by the installation scripts. The
3319: difference between the two is that the latter prompts the administrator to
3320: remove any directories that may be left after deinstallation (because they
3321: were not empty), while the former does not.
3322:
3323: * MAKE_DIRS_PERMS and OWN_DIRS_PERMS contain a list of tuples describing
3324: which directories should be created and should attempt to be destroyed by
3325: the installation scripts. Each tuple holds the following values, separated
3326: by spaces: the directory name, its owner, its group and its numerical mode.
3327: For example:
3328:
1.51 ! rillig 3329: MAKE_DIRS_PERMS+= ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
1.35 jmmv 3330:
3331: The difference between the two is exactly the same as their non-PERMS
3332: counterparts.
3333:
1.38 dillo 3334: 12.1.2. File manipulation
1.35 jmmv 3335:
3336: Creating non-empty files outside the installation prefix is tricky because the
3337: PLIST forces all files to be inside it. To overcome this problem, the only
3338: solution is to extract the file in the known place (i.e., inside the
3339: installation prefix) and copy it to the appropriate location during
3340: installation (done by the installation scripts generated by pkginstall). We
3341: will call the former the master file in the following paragraphs, which
3342: describe the variables that can be used to automatically and consistently
3343: handle files outside the installation prefix:
3344:
3345: * CONF_FILES and SUPPORT_FILES are pairs of master and target files. During
3346: installation time, the master file is copied to the target one if and only
3347: if the latter does not exist. Upon deinstallation, the target file is
3348: removed provided that it was not modified by the installation.
3349:
3350: The difference between the two is that the latter prompts the administrator
3351: to remove any files that may be left after deinstallation (because they
3352: were not empty), while the former does not.
3353:
3354: * CONF_FILES_PERMS and SUPPORT_FILES_PERMS contain tuples describing master
3355: files as well as their target locations. For each of them, it also
3356: specifies their owner, their group and their numeric permissions, in this
3357: order. For example:
3358:
1.51 ! rillig 3359: SUPPORT_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
1.35 jmmv 3360:
3361: The difference between the two is exactly the same as their non-PERMS
3362: counterparts.
3363:
1.38 dillo 3364: 12.2. Configuration files
1.35 jmmv 3365:
3366: Configuration files are special in the sense that they are installed in their
3367: own specific directory, PKG_SYSCONFDIR, and need special treatment during
3368: installation (most of which is automated by pkginstall). The main concept you
1.36 wiz 3369: must bear in mind is that files marked as configuration files are automatically
1.35 jmmv 3370: copied to the right place (somewhere inside PKG_SYSCONFDIR) during installation
3371: if and only if they didn't exist before. Similarly, they will not be removed if
1.36 wiz 3372: they have local modifications. This ensures that administrators never lose any
1.35 jmmv 3373: custom changes they may have made.
3374:
1.38 dillo 3375: 12.2.1. How PKG_SYSCONFDIR is set
1.35 jmmv 3376:
3377: As said before, the PKG_SYSCONFDIR variable specifies where configuration files
3378: shall be installed. Its contents are set based upon the following variables:
3379:
3380: * PKG_SYSCONFBASE: The configuration's root directory. Defaults to ${PREFIX}/
1.36 wiz 3381: etc although it may be overridden by the user to point to his preferred
1.35 jmmv 3382: location (e.g., /etc, /etc/pkg, etc.). Packages must not use it directly.
3383:
3384: * PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the
3385: configuration files for the package being built shall be installed. The
3386: definition of this variable only makes sense in the package's Makefile
1.47 reed 3387: (i.e., it is not user-customizable).
1.35 jmmv 3388:
3389: As an example, consider the Apache package, www/apache2, which places its
3390: configuration files under the httpd/ subdirectory of PKG_SYSCONFBASE. This
3391: should be set in the package Makefile.
3392:
3393: * PKG_SYSCONFVAR: Specifies the name of the variable that holds this
3394: package's configuration directory (if different from PKG_SYSCONFBASE). It
3395: defaults to PKGBASE's value, and is always prefixed with PKG_SYSCONFDIR.
3396:
3397: * PKG_SYSCONFDIR.${PKG_SYSCONFVAR}: Holds the directory where the
3398: configuration files for the package identified by PKG_SYSCONFVAR's shall be
3399: placed.
3400:
3401: Based on the above variables, pkginstall determines the value of
3402: PKG_SYSCONFDIR, which is the only variable that can be used within a package to
3403: refer to its configuration directory. The algorithm used to set its value is
3404: basically the following:
3405:
3406: 1. If PKG_SYSCONFDIR.${PKG_SYSCONFVAR} is set, its value is used.
3407:
3408: 2. If the previous variable is not defined but PKG_SYSCONFSUBDIR is set in the
3409: package's Makefile, the resulting value is ${PKG_SYSCONFBASE}/$
3410: {PKG_SYSCONFSUBDIR}.
3411:
3412: 3. Otherwise, it is set to ${PKG_SYSCONFBASE}.
3413:
3414: It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
1.38 dillo 3415: OWN_DIRS. See Section 12.1.1, "Directory manipulation" what this means.
1.35 jmmv 3416:
1.47 reed 3417: 12.2.2. Telling the software where configuration files are
1.35 jmmv 3418:
3419: Given that pkgsrc (and users!) expect configuration files to be in a known
1.36 wiz 3420: place, you need to teach each package where it shall install its files. In some
1.35 jmmv 3421: cases you will have to patch the package Makefiles to achieve it. If you are
3422: lucky, though, it may be as easy as passing an extra flag to the configuration
1.47 reed 3423: script; this is the case of GNU Autoconf- generated files:
1.35 jmmv 3424:
1.51 ! rillig 3425: CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
1.35 jmmv 3426:
3427: Note that this specifies where the package has to look for its configuration
3428: files, not where they will be originally installed (although the difference is
3429: never explicit, unfortunately).
3430:
1.38 dillo 3431: 12.2.3. Patching installations
1.35 jmmv 3432:
3433: As said before, pkginstall automatically handles configuration files. This
3434: means that the packages themselves must not touch the contents of $
1.36 wiz 3435: {PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts
3436: will, out of the box, mess with the contents of that directory. So what is the
3437: correct procedure to fix this issue?
1.35 jmmv 3438:
3439: You must teach the package (usually by manually patching it) to install any
3440: configuration files under the examples hierarchy, share/examples/${PKGBASE}/.
3441: This way, the PLIST registers them and the administrator always has the
3442: original copies available.
3443:
3444: Once the required configuration files are in place (i.e., under the examples
3445: hierarchy), the pkginstall framework can use them as master copies during the
3446: package installation to update what is in ${PKG_SYSCONFDIR}. To achieve this,
3447: the variables CONF_FILES and CONF_FILES_PERMS are used. Check out Section
1.38 dillo 3448: 12.1.2, "File manipulation" for information about their syntax and their
1.35 jmmv 3449: purpose. Here is an example, taken from the mail/mutt package:
3450:
1.51 ! rillig 3451: EGDIR= ${PREFIX}/share/doc/mutt/samples
! 3452: CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
1.35 jmmv 3453:
3454: Note that the EGDIR variable is specific to that package and has no meaning
3455: outside it.
3456:
1.38 dillo 3457: 12.2.4. Disabling handling of configuration files
1.35 jmmv 3458:
3459: The automatic copying of config files can be toggled by setting the environment
3460: variable PKG_CONFIG prior to package installation.
3461:
1.38 dillo 3462: 12.3. System startup scripts
1.35 jmmv 3463:
3464: System startup scripts are special files because they must be installed in a
3465: place known by the underlying OS, usually outside the installation prefix.
1.38 dillo 3466: Therefore, the same rules described in Section 12.1, "Files and directories
1.35 jmmv 3467: outside the installation prefix" apply, and the same solutions can be used.
1.36 wiz 3468: However, pkginstall provides a special mechanism to handle these files.
1.35 jmmv 3469:
3470: In order to provide system startup scripts, the package has to:
3471:
3472: 1. Store the script inside ${FILESDIR}, with the .sh suffix appended.
1.36 wiz 3473: Considering the print/cups package as an example, it has a cupsd.sh in its
3474: files directory.
1.35 jmmv 3475:
3476: 2. Tell pkginstall to handle it, appending the name of the script, without its
3477: extension, to the RCD_SCRIPTS variable. Continuing the previous example:
3478:
1.51 ! rillig 3479: RCD_SCRIPTS+= cupsd
1.35 jmmv 3480:
3481:
3482: Once this is done, pkginstall will do the following steps for each script in an
3483: automated fashion:
3484:
3485: 1. Process the file found in the files directory applying all the
3486: substitutions described in the FILES_SUBST variable.
3487:
3488: 2. Copy the script from the files directory to the examples hierarchy, $
1.36 wiz 3489: {PREFIX}/share/examples/rc.d/. Note that this master file must be
3490: explicitly registered in the PLIST.
1.35 jmmv 3491:
3492: 3. Add code to the installation scripts to copy the startup script from the
3493: examples hierarchy into the system-wide startup scripts directory.
3494:
1.38 dillo 3495: 12.3.1. Disabling handling of system startup scripts
1.35 jmmv 3496:
3497: The automatic copying of config files can be toggled by setting the environment
3498: variable PKG_RCD_SCRIPTS prior to package installation. Note that the scripts
3499: will be always copied inside the examples hierarchy, ${PREFIX}/share/examples/
3500: rc.d/, no matter what the value of this variable is.
3501:
1.38 dillo 3502: 12.4. System users and groups
1.35 jmmv 3503:
3504: If a package needs to create special users and/or groups during installation,
3505: it can do so by using the pkginstall framework.
3506:
3507: Users can be created by adding entries to the PKG_USERS variable. Each entry
3508: has the following syntax, which mimics /etc/passwd:
3509:
1.51 ! rillig 3510: user:group[:[userid][:[descr][:[home][:shell]]]]
1.35 jmmv 3511:
3512: Only the user and group are required; everything else is optional, but the
3513: colons must be in the right places when specifying optional bits. By default, a
3514: new user will have home directory /nonexistent, and login shell /sbin/nologin
3515: unless they are specified as part of the user element. Note that if the
1.51 ! rillig 3516: description contains spaces, then spaces should be backslash-escaped, as in:
1.35 jmmv 3517:
1.51 ! rillig 3518: foo:foogrp::The\ Foomister
1.35 jmmv 3519:
3520: Similarly, groups can be created using the PKG_GROUPS variable, whose syntax
3521: is:
3522:
1.51 ! rillig 3523: group[:groupid]
1.35 jmmv 3524:
3525: As before, only the group name is required; the numeric identifier is optional.
3526:
1.38 dillo 3527: 12.5. System shells
1.35 jmmv 3528:
3529: Packages that install system shells should register them in the shell database,
3530: /etc/shells, to make things easier to the administrator. This must be done from
3531: the installation scripts to keep binary packages working on any system.
3532: pkginstall provides an easy way to accomplish this task.
3533:
3534: When a package provides a shell interpreter, it has to set the PKG_SHELL
3535: variable to its absolute file name. This will add some hooks to the
3536: installation scripts to handle it. Consider the following example, taken from
3537: shells/zsh:
3538:
1.51 ! rillig 3539: USE_PKGINSTALL= YES
! 3540: PKG_SHELL= ${PREFIX}/bin/zsh
1.35 jmmv 3541:
1.38 dillo 3542: 12.5.1. Disabling handling of configuration files
1.35 jmmv 3543:
3544: The automatic registration of shell interpreters can be disabled by the
3545: administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.
3546:
1.38 dillo 3547: Chapter 13. Options handling
1.1 grant 3548:
3549: Table of Contents
3550:
1.38 dillo 3551: 13.1. Global default options
3552: 13.2. Converting packages to use bsd.options.mk
1.48 dillo 3553: 13.3. Option Names
1.1 grant 3554:
3555: Many packages have the ability to be built to support different sets of
3556: features. bsd.options.mk is a framework in pkgsrc that provides generic
3557: handling of those options that determine different ways in which the packages
3558: can be built. It's possible for the user to specify exactly which sets of
3559: options will be built into a package or to allow a set of global default
3560: options apply.
3561:
1.38 dillo 3562: 13.1. Global default options
1.1 grant 3563:
3564: Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of
3565: the options that should be built into every package if that option is
3566: supported. This variable should be set in /etc/mk.conf.
3567:
1.38 dillo 3568: 13.2. Converting packages to use bsd.options.mk
1.1 grant 3569:
1.27 rillig 3570: The following example shows how bsd.options.mk should be used by the
3571: hypothetical ``wibble'' package, either in the package Makefile, or in a file,
3572: e.g. options.mk, that is included by the main package Makefile.
1.1 grant 3573:
1.51 ! rillig 3574: PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
! 3575: PKG_SUPPORTED_OPTIONS= wibble-foo ldap
! 3576: PKG_OPTIONS_OPTIONAL_GROUPS= database
! 3577: PKG_OPTIONS_GROUP.database= mysql pgsql
! 3578: PKG_SUGGESTED_OPTIONS= wibble-foo
! 3579: PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
! 3580: PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo
! 3581:
! 3582: .include "../../mk/bsd.prefs.mk"
! 3583:
! 3584: # this package was previously named wibble2
! 3585: .if defined(PKG_OPTIONS.wibble2)
! 3586: PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
! 3587: PKG_OPTIONS_DEPRECATED_WARNINGS+= \
! 3588: "Deprecated variable PKG_OPTIONS.wibble2 used, use "${PKG_OPTIONS_VAR:Q}" instead."
! 3589: .endif
! 3590:
! 3591: .include "../../mk/bsd.options.mk"
! 3592:
! 3593: # Package-specific option-handling
! 3594:
! 3595: ###
! 3596: ### FOO support
! 3597: ###
! 3598: .if !empty(PKG_OPTIONS:Mwibble-foo)
! 3599: CONFIGURE_ARGS+= --enable-foo
! 3600: .endif
! 3601:
! 3602: ###
! 3603: ### LDAP support
! 3604: ###
! 3605: .if !empty(PKG_OPTIONS:Mldap)
! 3606: . include "../../databases/openldap/buildlink3.mk"
! 3607: CONFIGURE_ARGS+= --enable-ldap=${BUILDLINK_PREFIX.openldap}
! 3608: .endif
! 3609:
! 3610: ###
! 3611: ### database support
! 3612: ###
! 3613: .if !empty(PKG_OPTIONS:Mmysql)
! 3614: . include "../../mk/mysql.buildlink3.mk"
! 3615: .endif
! 3616: .if !empty(PKG_OPTIONS:Mpgsql)
! 3617: . include "../../mk/pgsql.buildlink3.mk"
! 3618: .endif
1.20 ben 3619:
1.28 rillig 3620: The first section contains the information about which build options are
1.1 grant 3621: supported by the package, and any default options settings if needed.
3622:
1.37 dillo 3623: 1. PKG_OPTIONS_VAR is the name of the make(1) variable that the user can set
1.38 dillo 3624: to override the default options. It should be set to "PKG_OPTIONS.pkgbase".
1.20 ben 3625:
1.1 grant 3626: 2. PKG_SUPPORTED_OPTIONS is a list of build options supported by the package.
1.20 ben 3627:
1.37 dillo 3628: 3. PKG_OPTIONS_OPTIONAL_GROUPS is a list of names of groups of mutually
3629: exclusive options. The options in each group are listed in
3630: PKG_OPTIONS_GROUP.groupname. The most specific setting of any option from
3631: the group takes precedence over all other options in the group. Options
3632: from the groups will be automatically added to PKG_SUPPORTED_OPTIONS.
3633:
3634: 4. PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, but
3635: building the packages will fail if no option from the group is selected.
3636:
1.44 gdt 3637: 5. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of options. At least
3638: one option from each set must be selected. The options in each set are
3639: listed in PKG_OPTIONS_SET.setname. Options from the sets will be
3640: automatically added to PKG_SUPPORTED_OPTIONS. Building the package will
3641: fail if no option from the set is selected.
3642:
3643: 6. PKG_SUGGESTED_OPTIONS is a list of build options which are enabled by
1.27 rillig 3644: default.
3645:
1.44 gdt 3646: 7. PKG_OPTIONS_LEGACY_VARS is a list of "USE_VARIABLE: option" pairs that map
1.37 dillo 3647: legacy /etc/mk.conf variables to their option counterparts. Pairs should be
3648: added with "+=" to keep the listing of global legacy variables. A warning
3649: will be issued if the user uses a legacy variable.
3650:
1.44 gdt 3651: 8. PKG_OPTIONS_LEGACY_OPTS is a list of "old-option: new-option" pairs that
1.37 dillo 3652: map options that have been renamed to their new counterparts. Pairs should
3653: be added with "+=" to keep the listing of global legacy options. A warning
3654: will be issued if the user uses a legacy option.
3655:
1.44 gdt 3656: 9. PKG_LEGACY_OPTIONS is a list of options implied by deprecated variables
1.37 dillo 3657: used. This can be used for cases that neither PKG_OPTIONS_LEGACY_VARS nor
3658: PKG_OPTIONS_LEGACY_OPTS can handle, e. g. when PKG_OPTIONS_VAR is renamed.
3659:
1.44 gdt 3660: 10. PKG_OPTIONS_DEPRECATED_WARNINGS is a list of warnings about deprecated
1.37 dillo 3661: variables or options used, and what to use instead.
3662:
3663: A package should never modify PKG_DEFAULT_OPTIONS or the variable named in
3664: PKG_OPTIONS_VAR. These are strictly user-settable. To suggest a default set of
3665: options, use PKG_SUGGESTED_OPTIONS.
3666:
1.42 dillo 3667: PKG_OPTIONS_VAR must be defined before including bsd.options.mk. If none of
3668: PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, and
1.47 reed 3669: PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform-specific
1.42 dillo 3670: options if none of them is supported on the current platform), PKG_OPTIONS is
3671: set to the empty list and the package is otherwise treated as not using the
3672: options framework.
1.28 rillig 3673:
3674: After the inclusion of bsd.options.mk, the variable PKG_OPTIONS contains the
1.37 dillo 3675: list of selected build options, properly filtered to remove unsupported and
1.28 rillig 3676: duplicate options.
1.20 ben 3677:
1.37 dillo 3678: The remaining sections contain the logic that is specific to each option. The
3679: correct way to check for an option is to check whether it is listed in
3680: PKG_OPTIONS:
3681:
1.51 ! rillig 3682: .if !empty(PKG_OPTIONS:Moption)
1.37 dillo 3683:
1.48 dillo 3684: 13.3. Option Names
3685:
3686: Options that enable similar features in different packages (like optional
3687: support for a library) should use a common name in all packages that support it
3688: (like the name of the library). If another package already has an option with
3689: the same meaning, use the same name.
3690:
3691: Options that enable features specific to one package, where it's unlikely that
3692: another (unrelated) package has the same (or a similar) optional feature,
3693: should use a name prefixed with pkgname-.
3694:
3695: If a group of related packages share an optional feature specific to that
3696: group, prefix it with the name of the "main" package (e. g.
3697: djbware-errno-hack).
3698:
3699: For new options, add a line to mk/defaults/options.description. Lines have two
3700: fields, separated by tab. The first field is the option name, the second its
3701: description. The description should be a whole sentence (starting with an
3702: uppercase letter and ending with a period) that describes what enabling the
3703: option does. E. g. "Enable ispell support." The file is sorted by option names.
1.1 grant 3704:
1.38 dillo 3705: Chapter 14. The build process
1.1 grant 3706:
3707: Table of Contents
3708:
1.38 dillo 3709: 14.1. Program location
3710: 14.2. Main targets
3711: 14.3. Other helpful targets
1.1 grant 3712:
3713: The basic steps for building a program are always the same. First the program's
3714: source (distfile) must be brought to the local system and then extracted. After
3715: any patches to compile properly on NetBSD are applied, the software can be
3716: configured, then built (usually by compiling), and finally the generated
3717: binaries, etc. can be put into place on the system. These are exactly the steps
3718: performed by the NetBSD package system, which is implemented as a series of
3719: targets in a central Makefile, pkgsrc/mk/bsd.pkg.mk.
3720:
1.38 dillo 3721: 14.1. Program location
1.1 grant 3722:
3723: Before outlining the process performed by the NetBSD package system in the next
3724: section, here's a brief discussion on where programs are installed, and which
3725: variables influence this.
3726:
3727: The automatic variable PREFIX indicates where all files of the final program
3728: shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
3729: pkgs in the "cross" category. The value of PREFIX needs to be put into the
3730: various places in the program's source where paths to these files are encoded.
1.38 dillo 3731: See Section 8.3, "patches/*" and Section 15.3.1, "Shared libraries - libtool"
1.1 grant 3732: for more details.
3733:
3734: When choosing which of these variables to use, follow the following rules:
3735:
3736: * PREFIX always points to the location where the current pkg will be
3737: installed. When referring to a pkg's own installation path, use "${PREFIX}
3738: ".
1.20 ben 3739:
1.1 grant 3740: * LOCALBASE is where all non-X11 pkgs are installed. If you need to construct
3741: a -I or -L argument to the compiler to find includes and libraries
3742: installed by another non-X11 pkg, use "${LOCALBASE}".
1.20 ben 3743:
1.1 grant 3744: * X11BASE is where the actual X11 distribution (from xsrc, etc.) is
3745: installed. When looking for standard X11 includes (not those installed by a
3746: pkg), use "${X11BASE}".
1.20 ben 3747:
1.47 reed 3748: * X11-based packages are special in that they may be installed in either
3749: X11BASE or LOCALBASE.
1.20 ben 3750:
1.1 grant 3751: Usually, X11 packages should be installed under LOCALBASE whenever
1.34 wiz 3752: possible. Note that you will need to include ../../mk/x11.buildlink3.mk in
3753: them to request the presence of X11 and to get the right compilation flags.
1.20 ben 3754:
1.1 grant 3755: Even though, there are some packages that cannot be installed under
3756: LOCALBASE: those that come with app-defaults files. These packages are
3757: special and they must be placed under X11BASE. To accomplish this, set
3758: either USE_X11BASE or USE_IMAKE in your package.
1.20 ben 3759:
1.34 wiz 3760: Some notes: If you need to find includes or libraries installed by a pkg
3761: that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in
3762: both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages
3763: in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default.
1.20 ben 3764:
1.1 grant 3765: * X11PREFIX should be used to refer to the installed location of an X11
3766: package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed,
3767: and to LOCALBASE if xpkgwedge is installed.
1.20 ben 3768:
1.1 grant 3769: * If xpkgwedge is installed, it is possible to have some packages installed
3770: in X11BASE and some in LOCALBASE. To determine the prefix of an installed
3771: package, the EVAL_PREFIX definition can be used. It takes pairs in the
3772: format "DIRNAME=<package>", and the make(1) variable DIRNAME will be set to
3773: the prefix of the installed package <package>, or "${X11PREFIX}" if the
3774: package is not installed.
1.20 ben 3775:
1.1 grant 3776: This is best illustrated by example.
1.20 ben 3777:
1.1 grant 3778: The following lines are taken from pkgsrc/wm/scwm/Makefile:
1.20 ben 3779:
1.51 ! rillig 3780: EVAL_PREFIX+= GTKDIR=gtk+
! 3781: CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \
! 3782: --with-gtk-prefix="${GTKDIR}" \
! 3783: --enable-multibyte
1.20 ben 3784:
1.1 grant 3785: Specific defaults can be defined for the packages evaluated using
3786: EVAL_PREFIX, by using a definition of the form:
1.20 ben 3787:
1.51 ! rillig 3788: GTKDIR_DEFAULT= ${LOCALBASE}
1.20 ben 3789:
1.1 grant 3790: where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair.
1.20 ben 3791:
1.1 grant 3792: * Within ${PREFIX}, packages should install files according to hier(7), with
3793: the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
3794: man.
1.20 ben 3795:
1.38 dillo 3796: 14.2. Main targets
1.1 grant 3797:
3798: The main targets used during the build process defined in bsd.pkg.mk are:
3799:
3800: fetch
1.20 ben 3801:
1.1 grant 3802: This will check if the file(s) given in the variables DISTFILES and
3803: PATCHFILES (as defined in the package's Makefile) are present on the local
3804: system in /usr/pkgsrc/distfiles. If they are not present, an attempt will
3805: be made to fetch them using commands of the form:
1.20 ben 3806:
1.51 ! rillig 3807: ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
1.20 ben 3808:
1.1 grant 3809: where ${site} varies through several possibilities in turn: first,
3810: MASTER_SITE_OVERRIDE is tried, then the sites specified in either
3811: SITES_file if defined, else MASTER_SITES or PATCH_SITES, as applies, then
3812: finally the value of MASTER_SITE_BACKUP. The order of all except the first
3813: can be optionally sorted by the user, via setting either MASTER_SORT_AWK or
3814: MASTER_SORT_REGEX.
1.20 ben 3815:
1.1 grant 3816: checksum
1.20 ben 3817:
1.1 grant 3818: After the distfile(s) are fetched, their checksum is generated and compared
3819: with the checksums stored in the distinfo file. If the checksums don't
3820: match, the build is aborted. This is to ensure the same distfile is used
3821: for building, and that the distfile wasn't changed, e.g. by some malign
3822: force, deliberately changed distfiles on the master distribution site or
3823: network lossage.
1.20 ben 3824:
1.1 grant 3825: extract
1.20 ben 3826:
1.1 grant 3827: When the distfiles are present on the local system, they need to be
3828: extracted, as they are usually in the form of some compressed archive
3829: format, most commonly .tar.gz.
1.20 ben 3830:
1.1 grant 3831: If only some of the distfiles need to be uncompressed, the files to be
3832: uncompressed should be put into EXTRACT_ONLY.
1.20 ben 3833:
1.1 grant 3834: If the distfiles are not in .tar.gz format, they can be extracted by
3835: setting either EXTRACT_SUFX, or EXTRACT_CMD, EXTRACT_BEFORE_ARGS and
3836: EXTRACT_AFTER_ARGS. In the former case, pkgsrc knows how to extract a
3837: number of suffixes (.tar.gz, .tgz, .tar.gz2, .tbz, .tar.Z, .tar, .shar.gz,
3838: .shar.bz2, .shar.Z, .shar, .Z, .bz2 and .gz; see the definition of the
1.47 reed 3839: various DECOMPRESS_CMD variables in bsd.pkg.extract.mk for a complete
3840: list). Here's an example on how to use the other variables for a program
3841: that comes with a compressed shell archive whose name ends in .msg.gz:
1.20 ben 3842:
1.51 ! rillig 3843: EXTRACT_SUFX= .msg.gz
! 3844: EXTRACT_CMD= zcat
! 3845: EXTRACT_BEFORE_ARGS=
! 3846: EXTRACT_AFTER_ARGS= |sh
1.20 ben 3847:
1.1 grant 3848: patch
1.20 ben 3849:
1.1 grant 3850: After extraction, all the patches named by the PATCHFILES, those present in
3851: the patches subdirectory of the package as well as in $LOCALPATCHES/
3852: $PKGPATH (e.g. /usr/local/patches/graphics/png) are applied. Patchfiles
3853: ending in .Z or .gz are uncompressed before they are applied, files ending
3854: in .orig or .rej are ignored. Any special options to patch(1) can be handed
1.38 dillo 3855: in PATCH_DIST_ARGS. See Section 8.3, "patches/*" for more details.
1.20 ben 3856:
1.1 grant 3857: By default patch(1) is given special args to make it fail if the patches
3858: apply with some lines of fuzz. Please fix (regen) the patches so that they
3859: apply cleanly. The rationale behind this is that patches that don't apply
3860: cleanly may end up being applied in the wrong place, and cause severe harm
3861: there.
1.20 ben 3862:
1.1 grant 3863: configure
1.20 ben 3864:
1.1 grant 3865: Most pieces of software need information on the header files, system calls,
3866: and library routines which are available in NetBSD. This is the process
3867: known as configuration, and is usually automated. In most cases, a script
3868: is supplied with the source, and its invocation results in generation of
3869: header files, Makefiles, etc.
1.20 ben 3870:
1.1 grant 3871: If the program's distfile contains its own configure script, this can be
3872: invoked by setting HAS_CONFIGURE. If the configure script is a GNU autoconf
3873: script, GNU_CONFIGURE should be specified instead. In either case, any
3874: arguments to the configure script can be specified in the CONFIGURE_ARGS
3875: variable, and the configure script's name can be set in CONFIGURE_SCRIPT if
1.20 ben 3876: it differs from the default "configure". Here's an example from the
1.1 grant 3877: sysutils/top package:
1.20 ben 3878:
1.51 ! rillig 3879: HAS_CONFIGURE= yes
! 3880: CONFIGURE_SCRIPT= Configure
! 3881: CONFIGURE_ARGS+= netbsd13
1.20 ben 3882:
1.1 grant 3883: If the program uses an Imakefile for configuration, the appropriate steps
3884: can be invoked by setting USE_IMAKE to "YES". (If you only want the package
3885: installed in $X11PREFIX but xmkmf not being run, set USE_X11BASE instead!)
1.20 ben 3886:
1.1 grant 3887: build
1.20 ben 3888:
1.1 grant 3889: Once configuration has taken place, the software will be built by invoking
1.10 wiz 3890: $MAKE_PROGRAM on $MAKEFILE with $BUILD_TARGET as the target to build. The
1.29 rillig 3891: default MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", "make"
1.10 wiz 3892: otherwise. MAKEFILE is set to "Makefile" by default, and BUILD_TARGET
1.7 wiz 3893: defaults to "all". Any of these variables can be set in the package's
3894: Makefile to change the default build process.
1.20 ben 3895:
1.1 grant 3896: install
1.20 ben 3897:
1.1 grant 3898: Once the build stage has completed, the final step is to install the
3899: software in public directories, so users can access the programs and files.
3900: As in the build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but
3901: with the $INSTALL_TARGET instead, the latter defaulting to "install" (plus
3902: "install.man", if USE_IMAKE is set).
1.20 ben 3903:
1.1 grant 3904: If no target is specified, the default is "build". If a subsequent stage is
3905: requested, all prior stages are made: e.g. make build will also perform the
3906: equivalent of:
3907:
1.51 ! rillig 3908: make fetch
! 3909: make checksum
! 3910: make extract
! 3911: make patch
! 3912: make configure
! 3913: make build
1.1 grant 3914:
1.38 dillo 3915: 14.3. Other helpful targets
1.1 grant 3916:
3917: pre/post-*
1.20 ben 3918:
1.1 grant 3919: For any of the main targets described in the previous section, two
3920: auxiliary targets exist with "pre-" and "post-" used as a prefix for the
3921: main target's name. These targets are invoked before and after the main
3922: target is called, allowing extra configuration or installation steps be
3923: performed from a package's Makefile, for example, which a program's
3924: configure script or install target omitted.
1.20 ben 3925:
1.1 grant 3926: do-*
1.20 ben 3927:
1.1 grant 3928: Should one of the main targets do the wrong thing, and should there be no
3929: variable to fix this, you can redefine it with the do-* target. (Note that
3930: redefining the target itself instead of the do-* target is a bad idea, as
3931: the pre-* and post-* targets won't be called anymore, etc.) You will not
3932: usually need to do this.
1.20 ben 3933:
1.1 grant 3934: reinstall
1.20 ben 3935:
1.1 grant 3936: If you did a make install and you noticed some file was not installed
3937: properly, you can repeat the installation with this target, which will
3938: ignore the "already installed" flag.
1.20 ben 3939:
1.1 grant 3940: deinstall
1.20 ben 3941:
1.1 grant 3942: This target does a pkg_delete(1) in the current directory, effectively
3943: de-installing the package. The following variables can be used to tune the
3944: behaviour:
1.20 ben 3945:
1.1 grant 3946: PKG_VERBOSE
1.20 ben 3947:
1.1 grant 3948: Add a "-v" to the pkg_delete(1) command.
1.20 ben 3949:
1.1 grant 3950: DEINSTALLDEPENDS
1.20 ben 3951:
1.1 grant 3952: Remove all packages that require (depend on) the given package. This
3953: can be used to remove any packages that may have been pulled in by a
3954: given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
3955: pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding
3956: "-R" to the pkg_delete(1) command line.
1.20 ben 3957:
1.1 grant 3958: update
1.20 ben 3959:
1.1 grant 3960: This target causes the current package to be updated to the latest version.
3961: The package and all depending packages first get de-installed, then current
3962: versions of the corresponding packages get compiled and installed. This is
3963: similar to manually noting which packages are currently installed, then
3964: performing a series of make deinstall and make install (or whatever
3965: UPDATE_TARGET is set to) for these packages.
1.20 ben 3966:
1.1 grant 3967: You can use the "update" target to resume package updating in case a
3968: previous make update was interrupted for some reason. However, in this
3969: case, make sure you don't call make clean or otherwise remove the list of
1.47 reed 3970: dependent packages in WRKDIR. Otherwise, you lose the ability to
1.1 grant 3971: automatically update the current package along with the dependent packages
3972: you have installed.
1.20 ben 3973:
1.1 grant 3974: Resuming an interrupted make update will only work as long as the package
3975: tree remains unchanged. If the source code for one of the packages to be
3976: updated has been changed, resuming make update will most certainly fail!
1.20 ben 3977:
1.1 grant 3978: The following variables can be used either on the command line or in /etc/
3979: mk.conf to alter the behaviour of make update:
1.20 ben 3980:
1.1 grant 3981: UPDATE_TARGET
1.20 ben 3982:
1.1 grant 3983: Install target to recursively use for the updated package and the
3984: dependent packages. Defaults to DEPENDS_TARGET if set, "install"
3985: otherwise for make update. e.g. make update UPDATE_TARGET=package
1.20 ben 3986:
1.1 grant 3987: NOCLEAN
1.20 ben 3988:
1.1 grant 3989: Don't clean up after updating. Useful if you want to leave the work
3990: sources of the updated packages around for inspection or other
3991: purposes. Be sure you eventually clean up the source tree (see the
3992: "clean-update" target below) or you may run into troubles with old
3993: source code still lying around on your next make or make update.
1.20 ben 3994:
1.1 grant 3995: REINSTALL
1.20 ben 3996:
1.1 grant 3997: Deinstall each package before installing (making DEPENDS_TARGET). This
3998: may be necessary if the "clean-update" target (see below) was called
3999: after interrupting a running make update.
1.20 ben 4000:
1.1 grant 4001: DEPENDS_TARGET
1.20 ben 4002:
1.1 grant 4003: Allows you to disable recursion and hardcode the target for packages.
4004: The default is "update" for the update target, facilitating a recursive
4005: update of prerequisite packages. Only set DEPENDS_TARGET if you want to
4006: disable recursive updates. Use UPDATE_TARGET instead to just set a
4007: specific target for each package to be installed during make update
4008: (see above).
1.20 ben 4009:
1.1 grant 4010: clean-update
1.20 ben 4011:
1.1 grant 4012: Clean the source tree for all packages that would get updated if make
4013: update was called from the current directory. This target should not be
4014: used if the current package (or any of its depending packages) have already
4015: been de-installed (e.g., after calling make update) or you may lose some
1.20 ben 4016: packages you intended to update. As a rule of thumb: only use this target
1.1 grant 4017: before the first time you run make update and only if you have a dirty
4018: package tree (e.g., if you used NOCLEAN).
1.20 ben 4019:
1.47 reed 4020: If you are unsure about whether your tree is clean, you can either perform
4021: a make clean at the top of the tree, or use the following sequence of
1.1 grant 4022: commands from the directory of the package you want to update (before
4023: running make update for the first time, otherwise you lose all the packages
4024: you wanted to update!):
1.20 ben 4025:
1.1 grant 4026: # make clean-update
4027: # make clean CLEANDEPENDS=YES
4028: # make update
1.20 ben 4029:
1.1 grant 4030: The following variables can be used either on the command line or in /etc/
4031: mk.conf to alter the behaviour of make clean-update:
1.20 ben 4032:
1.1 grant 4033: CLEAR_DIRLIST
1.20 ben 4034:
1.1 grant 4035: After make clean, do not reconstruct the list of directories to update
4036: for this package. Only use this if make update successfully installed
4037: all packages you wanted to update. Normally, this is done automatically
4038: on make update, but may have been suppressed by the NOCLEAN variable
4039: (see above).
1.20 ben 4040:
1.1 grant 4041: info
1.20 ben 4042:
1.1 grant 4043: This target invokes pkg_info(1) for the current package. You can use this
4044: to check which version of a package is installed.
1.20 ben 4045:
1.1 grant 4046: readme
1.20 ben 4047:
1.1 grant 4048: This target generates a README.html file, which can be viewed using a
4049: browser such as www/mozilla or www/links. The generated files contain
4050: references to any packages which are in the PACKAGES directory on the local
4051: host. The generated files can be made to refer to URLs based on
4052: FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate
4053: README.html files which pointed to binary packages on the local machine, in
4054: the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
4055: FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
4056: subdirectories will be searched for all the binary packages.
1.20 ben 4057:
1.1 grant 4058: readme-all
1.20 ben 4059:
1.1 grant 4060: Use this target to create a file README-all.html which contains a list of
4061: all packages currently available in the NetBSD Packages Collection,
4062: together with the category they belong to and a short description. This
4063: file is compiled from the pkgsrc/*/README.html files, so be sure to run
4064: this after a make readme.
1.20 ben 4065:
1.1 grant 4066: cdrom-readme
1.20 ben 4067:
1.1 grant 4068: This is very much the same as the "readme" target (see above), but is to be
4069: used when generating a pkgsrc tree to be written to a CD-ROM. This target
4070: also produces README.html files, and can be made to refer to URLs based on
4071: CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
1.20 ben 4072:
1.1 grant 4073: show-distfiles
1.20 ben 4074:
1.1 grant 4075: This target shows which distfiles and patchfiles are needed to build the
4076: package. (DISTFILES and PATCHFILES, but not patches/*)
1.20 ben 4077:
1.1 grant 4078: show-downlevel
1.20 ben 4079:
1.1 grant 4080: This target shows nothing if the package is not installed. If a version of
4081: this package is installed, but is not the version provided in this version
4082: of pkgsrc, then a warning message is displayed. This target can be used to
4083: show which of your installed packages are downlevel, and so the old
4084: versions can be deleted, and the current ones added.
1.20 ben 4085:
1.1 grant 4086: show-pkgsrc-dir
1.20 ben 4087:
1.1 grant 4088: This target shows the directory in the pkgsrc hierarchy from which the
4089: package can be built and installed. This may not be the same directory as
4090: the one from which the package was installed. This target is intended to be
4091: used by people who may wish to upgrade many packages on a single host, and
4092: can be invoked from the top-level pkgsrc Makefile by using the
4093: "show-host-specific-pkgs" target.
1.20 ben 4094:
1.1 grant 4095: show-installed-depends
1.20 ben 4096:
1.1 grant 4097: This target shows which installed packages match the current package's
4098: DEPENDS. Useful if out of date dependencies are causing build problems.
1.20 ben 4099:
1.1 grant 4100: check-shlibs
1.20 ben 4101:
1.1 grant 4102: After a package is installed, check all its binaries and (on ELF platforms)
4103: shared libraries to see if they find the shared libs they need. Run by
4104: default if PKG_DEVELOPER is set in /etc/mk.conf.
1.20 ben 4105:
1.1 grant 4106: print-PLIST
1.20 ben 4107:
1.1 grant 4108: After a "make install" from a new or upgraded pkg, this prints out an
4109: attempt to generate a new PLIST from a find -newer work/.extract_done. An
4110: attempt is made to care for shared libs etc., but it is strongly
4111: recommended to review the result before putting it into PLIST. On upgrades,
4112: it's useful to diff the output of this command against an already existing
4113: PLIST file.
1.20 ben 4114:
1.1 grant 4115: If the package installs files via tar(1) or other methods that don't update
4116: file access times, be sure to add these files manually to your PLIST, as
4117: the "find -newer" command used by this target won't catch them!
1.20 ben 4118:
1.38 dillo 4119: See Section 10.3, "Tweaking output of make print-PLIST" for more
4120: information on this target.
1.20 ben 4121:
1.1 grant 4122: bulk-package
1.20 ben 4123:
1.1 grant 4124: Used to do bulk builds. If an appropriate binary package already exists, no
4125: action is taken. If not, this target will compile, install and package it
1.47 reed 4126: (and its depends, if PKG_DEPENDS is set properly. See Section 6.3.1,
4127: "Configuration"). After creating the binary package, the sources, the
4128: just-installed package and its required packages are removed, preserving
1.1 grant 4129: free disk space.
1.20 ben 4130:
1.1 grant 4131: Beware that this target may deinstall all packages installed on a system!
1.20 ben 4132:
1.1 grant 4133: bulk-install
1.20 ben 4134:
1.47 reed 4135: Used during bulk-installs to install required packages. If an up-to-date
1.20 ben 4136: binary package is available, it will be installed via pkg_add(1). If not,
1.47 reed 4137: make bulk-package will be executed, but the installed binary won't be
1.1 grant 4138: removed.
1.20 ben 4139:
1.47 reed 4140: A binary package is considered "up-to-date" to be installed via pkg_add(1)
1.1 grant 4141: if:
1.20 ben 4142:
1.1 grant 4143: * None of the package's files (Makefile, ...) were modified since it was
4144: built.
1.20 ben 4145:
1.1 grant 4146: * None of the package's required (binary) packages were modified since it
4147: was built.
1.20 ben 4148:
1.1 grant 4149: Beware that this target may deinstall all packages installed on a system!
1.20 ben 4150:
1.38 dillo 4151: Chapter 15. Notes on fixes for packages
1.1 grant 4152:
4153: Table of Contents
4154:
1.38 dillo 4155: 15.1. General operation
1.20 ben 4156:
1.38 dillo 4157: 15.1.1. How to pull in variables from /etc/mk.conf
4158: 15.1.2. Where to install documentation
4159: 15.1.3. Restricted packages
4160: 15.1.4. Handling dependencies
4161: 15.1.5. Handling conflicts with other packages
4162: 15.1.6. Packages that cannot or should not be built
4163: 15.1.7. Packages which should not be deleted, once installed
4164: 15.1.8. Handling packages with security problems
4165: 15.1.9. How to handle compiler bugs
4166: 15.1.10. How to handle incrementing versions when fixing an existing
1.31 wiz 4167: package
1.38 dillo 4168: 15.1.11. Portability of packages
1.25 rillig 4169:
1.38 dillo 4170: 15.2. Possible downloading issues
1.25 rillig 4171:
1.38 dillo 4172: 15.2.1. Packages whose distfiles aren't available for plain downloading
4173: 15.2.2. How to handle modified distfiles with the 'old' name
1.25 rillig 4174:
1.38 dillo 4175: 15.3. Configuration gotchas
1.25 rillig 4176:
1.38 dillo 4177: 15.3.1. Shared libraries - libtool
4178: 15.3.2. Using libtool on GNU packages that already support libtool
4179: 15.3.3. GNU Autoconf/Automake
1.25 rillig 4180:
1.38 dillo 4181: 15.4. Building considerations
1.25 rillig 4182:
1.38 dillo 4183: 15.4.1. CPP defines
1.51 ! rillig 4184: 15.4.2. Getting a list of CPP defines
1.25 rillig 4185:
1.38 dillo 4186: 15.5. Package specific actions
1.25 rillig 4187:
1.38 dillo 4188: 15.5.1. User interaction
4189: 15.5.2. Handling licenses
4190: 15.5.3. Installing score files
4191: 15.5.4. Packages containing perl scripts
4192: 15.5.5. Packages with hardcoded paths to other interpreters
4193: 15.5.6. Packages installing perl modules
4194: 15.5.7. Packages installing info files
4195: 15.5.8. Packages installing GConf2 data files
4196: 15.5.9. Packages installing scrollkeeper data files
4197: 15.5.10. Packages installing X11 fonts
4198: 15.5.11. Packages installing GTK2 modules
4199: 15.5.12. Packages installing SGML or XML data
4200: 15.5.13. Packages installing extensions to the MIME database
4201: 15.5.14. Packages using intltool
4202: 15.5.15. Packages installing startup scripts
1.20 ben 4203:
1.38 dillo 4204: 15.6. Feedback to the author
1.1 grant 4205:
1.38 dillo 4206: 15.1. General operation
1.1 grant 4207:
1.38 dillo 4208: 15.1.1. How to pull in variables from /etc/mk.conf
1.1 grant 4209:
4210: The problem with package-defined variables that can be overridden via MAKECONF
4211: or /etc/mk.conf is that make(1) expands a variable as it is used, but evaluates
1.47 reed 4212: preprocessor-like statements (.if, .ifdef and .ifndef) as they are read. So, to
1.1 grant 4213: use any variable (which may be set in /etc/mk.conf) in one of the .if*
4214: statements, the file /etc/mk.conf must be included before that .if* statement.
4215:
1.47 reed 4216: Rather than having a number of ad-hoc ways of including /etc/mk.conf, should it
1.1 grant 4217: exist, or MAKECONF, should it exist, include the pkgsrc/mk/bsd.prefs.mk file in
4218: the package Makefile before any preprocessor-like .if, .ifdef, or .ifndef
4219: statements:
4220:
1.51 ! rillig 4221: .include "../../mk/bsd.prefs.mk"
1.20 ben 4222:
1.1 grant 4223: .if defined(USE_MENUS)
1.51 ! rillig 4224: # ...
1.1 grant 4225: .endif
4226:
1.47 reed 4227: If you wish to set the CFLAGS variable in /etc/mk.conf, please make sure to
4228: use:
1.1 grant 4229:
1.51 ! rillig 4230: CFLAGS+= -your -flags
1.1 grant 4231:
4232: Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
4233: need to add their own flags. Also, you may want to take a look at the devel/
4234: cpuflags package if you're interested in optimization for the current CPU.
4235:
1.38 dillo 4236: 15.1.2. Where to install documentation
1.31 wiz 4237:
4238: Documentation should be installed into ${PREFIX}/share/doc/${PKGBASE} or $
4239: {PREFIX}/share/doc/${PKGNAME} (the latter includes the version number of the
4240: package).
4241:
1.38 dillo 4242: 15.1.3. Restricted packages
1.1 grant 4243:
4244: Some licenses restrict how software may be re-distributed. In order to satisfy
4245: these restrictions, the package system defines five make variables that can be
4246: set to note these restrictions:
4247:
4248: * RESTRICTED
1.20 ben 4249:
1.1 grant 4250: This variable should be set whenever a restriction exists (regardless of
4251: its kind). Set this variable to a string containing the reason for the
4252: restriction.
1.20 ben 4253:
1.1 grant 4254: * NO_BIN_ON_CDROM
1.20 ben 4255:
1.1 grant 4256: Binaries may not be placed on CD-ROM. Set this variable to ${RESTRICTED}
4257: whenever a binary package may not be included on a CD-ROM.
1.20 ben 4258:
1.1 grant 4259: * NO_BIN_ON_FTP
1.20 ben 4260:
1.1 grant 4261: Binaries may not be placed on an FTP server. Set this variable to $
4262: {RESTRICTED} whenever a binary package may not not be made available on the
4263: Internet.
1.20 ben 4264:
1.1 grant 4265: * NO_SRC_ON_CDROM
1.20 ben 4266:
1.1 grant 4267: Distfiles may not be placed on CD-ROM. Set this variable to ${RESTRICTED}
4268: if re-distribution of the source code or other distfile(s) is not allowed
4269: on CD-ROMs.
1.20 ben 4270:
1.1 grant 4271: * NO_SRC_ON_FTP
1.20 ben 4272:
1.1 grant 4273: Distfiles may not be placed on FTP. Set this variable to ${RESTRICTED} if
4274: re-distribution of the source code or other distfile(s) via the Internet is
4275: not allowed.
1.20 ben 4276:
1.1 grant 4277: Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic make
4278: variables to denote restrictions is deprecated, because they unconditionally
4279: prevent users from generating binary packages!
4280:
1.38 dillo 4281: 15.1.4. Handling dependencies
1.1 grant 4282:
4283: Your package may depend on some other package being present - and there are
4284: various ways of expressing this dependency. pkgsrc supports the BUILD_DEPENDS
1.47 reed 4285: and DEPENDS definitions, the USE_TOOLS definition, as well as dependencies via
4286: buildlink3.mk, which is the preferred way to handle dependencies, and which
4287: uses the variables named above. See Chapter 11, Buildlink methodology for more
4288: information.
1.1 grant 4289:
4290: The basic difference between the two variables is as follows: The DEPENDS
4291: definition registers that pre-requisite in the binary package so it will be
4292: pulled in when the binary package is later installed, whilst the BUILD_DEPENDS
4293: definition does not, marking a dependency that is only needed for building the
4294: package.
4295:
4296: This means that if you only need a package present whilst you are building, it
4297: should be noted as a BUILD_DEPENDS.
4298:
4299: The format for a BUILD_DEPENDS and a DEPENDS definition is:
4300:
1.51 ! rillig 4301: <pre-req-package-name>:../../<category>/<pre-req-package>
1.1 grant 4302:
4303: Please note that the "pre-req-package-name" may include any of the wildcard
1.18 xtraeme 4304: version numbers recognized by pkg_info(1).
1.1 grant 4305:
4306: 1. If your package needs another package's binaries or libraries to build or
4307: run, and if that package has a buildlink3.mk file available, use it:
1.20 ben 4308:
1.1 grant 4309: .include "../../graphics/jpeg/buildlink3.mk"
1.20 ben 4310:
1.1 grant 4311: 2. If your package needs to use another package to build itself and there is
4312: no buildlink3.mk file available, use the BUILD_DEPENDS definition:
1.20 ben 4313:
1.51 ! rillig 4314: BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
1.20 ben 4315:
1.1 grant 4316: 3. If your package needs a library with which to link and again there is no
4317: buildlink3.mk file available, this is specified using the DEPENDS
4318: definition. An example of this is the print/lyx package, which uses the xpm
4319: library, version 3.4j to build:
1.20 ben 4320:
1.51 ! rillig 4321: DEPENDS+= xpm-3.4j:../../graphics/xpm
1.20 ben 4322:
1.1 grant 4323: You can also use wildcards in package dependences:
1.20 ben 4324:
1.51 ! rillig 4325: DEPENDS+= xpm-[0-9]*:../../graphics/xpm
1.20 ben 4326:
1.1 grant 4327: Note that such wildcard dependencies are retained when creating binary
4328: packages. The dependency is checked when installing the binary package and
4329: any package which matches the pattern will be used. Wildcard dependencies
4330: should be used with care.
1.20 ben 4331:
1.1 grant 4332: The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
4333: matches such as "tk-postgresql" matching a "tk-*" DEPENDS.
1.20 ben 4334:
1.1 grant 4335: Wildcards can also be used to specify that a package will only build
4336: against a certain minimum version of a pre-requisite:
1.20 ben 4337:
1.51 ! rillig 4338: DEPENDS+= tiff>=3.5.4:../../graphics/tiff
1.20 ben 4339:
1.1 grant 4340: This means that the package will build against version 3.5.4 of the tiff
4341: library or newer. Such a dependency may be warranted if, for example, the
4342: API of the library has changed with version 3.5.4 and a package would not
4343: compile against an earlier version of tiff.
1.20 ben 4344:
1.1 grant 4345: Please note that such dependencies should only be updated if a package
4346: requires a newer pre-requisite, but not to denote recommendations such as
4347: security updates or ABI changes that do not prevent a package from building
4348: correctly. Such recommendations can be expressed using RECOMMENDED:
1.20 ben 4349:
1.51 ! rillig 4350: RECOMMENDED+= tiff>=3.6.1:../../graphics/tiff
1.20 ben 4351:
1.1 grant 4352: In addition to the above DEPENDS line, this denotes that while a package
4353: will build against tiff>=3.5.4, at least version 3.6.1 is recommended.
4354: RECOMMENDED entries will be turned into dependencies unless explicitly
1.36 wiz 4355: ignored (in which case a warning will be printed).
4356:
4357: To ignore these dependency recommendations and just use the required
4358: DEPENDS, set IGNORE_RECOMMENDED=YES. This may make it easier and faster to
4359: update packages built using pkgsrc, since older compatible dependencies can
4360: continue to be used. This is useful for people who watch their rebuilds
4361: very carefully; it is not very good as a general-purpose hammer. If you use
4362: it, you need to be mindful of possible ABI changes, including those from
4363: the underlying OS.
4364:
4365: Packages that are built with recommendations ignored may not be uploaded to
4366: ftp.NetBSD.org by developers and should not be used across different
4367: systems that may have different versions of binary packages installed.
1.20 ben 4368:
1.1 grant 4369: For security fixes, please update the package vulnerabilities file as well
1.38 dillo 4370: as setting RECOMMENDED, see Section 15.1.8, "Handling packages with
1.1 grant 4371: security problems" for more information.
1.20 ben 4372:
1.1 grant 4373: 4. If your package needs some executable to be able to run correctly and if
1.17 sketch 4374: there's no buildlink3.mk file, this is specified using the DEPENDS
1.1 grant 4375: variable. The print/lyx package needs to be able to execute the latex
4376: binary from the teTeX package when it runs, and that is specified:
1.20 ben 4377:
1.51 ! rillig 4378: DEPENDS+= teTeX-[0-9]*:../../print/teTeX
1.20 ben 4379:
1.1 grant 4380: The comment about wildcard dependencies from previous paragraph applies
4381: here, too.
1.20 ben 4382:
1.1 grant 4383: If your package needs files from another package to build, see the first part
4384: of the "do-configure" target print/ghostscript5 package (it relies on the jpeg
4385: sources being present in source form during the build):
4386:
1.51 ! rillig 4387: if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
! 4388: cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract; \
1.1 grant 4389: fi
4390:
4391: If you build any other packages that way, please make sure the working files
4392: are deleted too when this package's working files are cleaned up. The easiest
4393: way to do so is by adding a pre-clean target:
4394:
1.51 ! rillig 4395: pre-clean:
! 4396: cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean
1.1 grant 4397:
4398: Please also note the BUILD_USES_MSGFMT and BUILD_USES_GETTEXT_M4 definitions,
4399: which are provided as convenience definitions. The former works out whether
4400: msgfmt(1) is part of the base system, and, if it isn't, installs the devel/
4401: gettext package. The latter adds a build dependency on either an installed
4402: version of an older gettext package, or if it isn't, installs the devel/
4403: gettext-m4 package.
4404:
1.38 dillo 4405: 15.1.5. Handling conflicts with other packages
1.1 grant 4406:
4407: Your package may conflict with other packages a user might already have
4408: installed on his system, e.g. if your package installs the same set of files
4409: like another package in our pkgsrc tree.
4410:
1.47 reed 4411: In this case you can set CONFLICTS to a space-separated list of packages
1.1 grant 4412: (including version string) your package conflicts with.
4413:
1.47 reed 4414: For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus
4415: you set in pkgsrc/x11/Xaw3d/Makefile:
1.1 grant 4416:
1.51 ! rillig 4417: CONFLICTS= Xaw-Xpm-[0-9]*
1.1 grant 4418:
4419: and in pkgsrc/x11/Xaw-Xpm/Makefile:
4420:
1.51 ! rillig 4421: CONFLICTS= Xaw3d-[0-9]*
1.1 grant 4422:
4423: Packages will automatically conflict with other packages with the name prefix
4424: and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
4425: with the older version "Xaw3d-1.3".
4426:
1.38 dillo 4427: 15.1.6. Packages that cannot or should not be built
1.1 grant 4428:
4429: There are several reasons why a package might be instructed to not build under
4430: certain circumstances. If the package builds and runs on most platforms, the
4431: exceptions should be noted with NOT_FOR_PLATFORM. If the package builds and
1.45 wiz 4432: runs on a small handful of platforms, set ONLY_FOR_PLATFORM instead. Both
4433: ONLY_FOR_PLATFORM and NOT_FOR_PLATFORM are OS triples (OS-version-platform)
4434: that can use glob-style wildcards.
4435:
4436: If the package should be skipped (for example, because it provides
4437: functionality already provided by the system), set PKG_SKIP_REASON to a
4438: descriptive message. If the package should fail because some preconditions are
4439: not met, set PKG_FAIL_REASON to a descriptive message.
1.1 grant 4440:
1.38 dillo 4441: 15.1.7. Packages which should not be deleted, once installed
1.1 grant 4442:
4443: To ensure that a package may not be deleted, once it has been installed, the
4444: PKG_PRESERVE definition should be set in the package Makefile. This will be
4445: carried into any binary package that is made from this pkgsrc entry. A
4446: "preserved" package will not be deleted using pkg_delete(1) unless the "-f"
4447: option is used.
4448:
1.38 dillo 4449: 15.1.8. Handling packages with security problems
1.1 grant 4450:
4451: When a vulnerability is found, this should be noted in localsrc/security/
1.43 wiz 4452: advisories/pkg-vulnerabilities, and after committing that file, use make upload
4453: in the same directory to update the file on ftp.NetBSD.org.
4454:
4455: After fixing the vulnerability by a patch, its PKGREVISION should be increased
4456: (this is of course not necessary if the problem is fixed by using a newer
4457: release of the software). In addition, if a buildlink3.mk file exists for an
4458: affected package, a corresponding BUILDLINK_RECOMMENDED.pkg entry should be
4459: added or updated in it.
1.1 grant 4460:
4461: Also, if the fix should be applied to the stable pkgsrc branch, be sure to
4462: submit a pullup request!
4463:
1.43 wiz 4464: Binary packages already on ftp.NetBSD.org will be handled semi-automatically by
4465: a weekly cron job.
4466:
1.38 dillo 4467: 15.1.9. How to handle compiler bugs
1.1 grant 4468:
4469: Some source files trigger bugs in the compiler, based on combinations of
4470: compiler version and architecture and almost always relation to optimisation
4471: being enabled. Common symptoms are gcc internal errors or never finishing
4472: compiling a file.
4473:
1.47 reed 4474: Typically, a workaround involves testing the MACHINE_ARCH and compiler version,
1.1 grant 4475: disabling optimisation for that file/MACHINE_ARCH/compiler combination, and
4476: documenting it in pkgsrc/doc/HACKS. See that file for a number of examples!
4477:
1.38 dillo 4478: 15.1.10. How to handle incrementing versions when fixing an existing package
1.1 grant 4479:
4480: When making fixes to an existing package it can be useful to change the version
4481: number in PKGNAME. To avoid conflicting with future versions by the original
4482: author, a "nb1", "nb2", ... suffix can be used on package versions by setting
4483: PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the pkg tools. e.g.
4484:
1.51 ! rillig 4485: DISTNAME= foo-17.42
! 4486: PKGREVISION= 9
1.1 grant 4487:
4488: will result in a PKGNAME of "foo-17.42nb9".
4489:
4490: When a new release of the package is released, the PKGREVISION should be
1.47 reed 4491: removed, e.g. on a new minor release of the above package, things should be
1.1 grant 4492: like:
4493:
1.51 ! rillig 4494: DISTNAME= foo-17.43
1.1 grant 4495:
1.38 dillo 4496: 15.1.11. Portability of packages
1.1 grant 4497:
4498: One appealing feature of pkgsrc is that it runs on many different platforms. As
4499: a result, it is important to ensure, where possible, that packages in pkgsrc
4500: are portable. There are some particular details you should pay attention to
4501: while working on pkgsrc.
4502:
1.38 dillo 4503: 15.1.11.1. ${INSTALL}, ${INSTALL_DATA_DIR}, ...
1.1 grant 4504:
4505: The BSD-compatible install supplied with some operating systems will not
4506: perform more than one operation at a time. As such, you should call "${INSTALL}
4507: ", etc. like this:
4508:
1.51 ! rillig 4509: ${INSTALL_DATA_DIR} ${PREFIX}/dir1
! 4510: ${INSTALL_DATA_DIR} ${PREFIX}/dir2
1.1 grant 4511:
1.38 dillo 4512: 15.2. Possible downloading issues
1.1 grant 4513:
1.38 dillo 4514: 15.2.1. Packages whose distfiles aren't available for plain downloading
1.1 grant 4515:
4516: If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
4517: a make fetch will call files/getsite.sh with the name of each file to download
4518: as an argument, expecting it to output the URL of the directory from which to
4519: download it. graphics/ns-cult3d is an example of this usage.
4520:
4521: If the download can't be automated, because the user must submit personal
4522: information to apply for a password, or must pay for the source, or whatever,
4523: you can set _FETCH_MESSAGE to a macro which displays a message explaining the
4524: situation. _FETCH_MESSAGE must be executable shell commands, not just a
4525: message. (Generally, it executes ${ECHO}). As of this writing, the following
1.43 wiz 4526: packages use this: cad/simian, devel/ipv6socket, emulators/vmware-module, fonts
4527: /acroread-jpnfont, multimedia/realplayer, sysutils/storage-manager, www/
1.1 grant 4528: ap-aolserver, www/openacs. Try to be consistent with them.
4529:
1.38 dillo 4530: 15.2.2. How to handle modified distfiles with the 'old' name
1.1 grant 4531:
4532: Sometimes authors of a software package make some modifications after the
4533: software was released, and they put up a new distfile without changing the
4534: package's version number. If a package is already in pkgsrc at that time, the
1.32 wiz 4535: checksum will no longer match. The contents of the new distfile should be
4536: compared against the old one before changing anything, to make sure the
1.1 grant 4537: distfile was really updated on purpose, and that no trojan horse or so crept
1.32 wiz 4538: in. Then, the correct way to work around this is to set DIST_SUBDIR to a unique
4539: directory name, usually based on PKGNAME_NOREV. In case this happens more
4540: often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can
4541: be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget regenerating the
4542: distinfo file after that, since it contains the DIST_SUBDIR path in the
4543: filenames. Furthermore, a mail to the package's authors seems appropriate
4544: telling them that changing distfiles after releases without changing the file
4545: names is not good practice.
1.1 grant 4546:
1.38 dillo 4547: 15.3. Configuration gotchas
1.1 grant 4548:
1.38 dillo 4549: 15.3.1. Shared libraries - libtool
1.1 grant 4550:
4551: pkgsrc supports many different machines, with different object formats like
4552: a.out and ELF, and varying abilities to do shared library and dynamic loading
4553: at all. To accompany this, varying commands and options have to be passed to
4554: the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
1.20 ben 4555: especially if you don't have all the machines at your hand to test things. The
1.1 grant 4556: devel/libtool pkg can help here, as it just "knows" how to build both static
1.47 reed 4557: and dynamic libraries from a set of source files, thus being
4558: platform-independent.
1.1 grant 4559:
4560: Here's how to use libtool in a pkg in seven simple steps:
4561:
4562: 1. Add USE_LIBTOOL=yes to the package Makefile.
1.20 ben 4563:
1.1 grant 4564: 2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
4565: {CC}". You could even add it to the definition of CC, if only libraries are
4566: being built in a given Makefile. This one command will build both PIC and
4567: non-PIC library objects, so you need not have separate shared and
4568: non-shared library rules.
1.20 ben 4569:
1.1 grant 4570: 3. For the linking of the library, remove any "ar", "ranlib", and "ld
4571: -Bshareable" commands, and instead use:
1.20 ben 4572:
1.51 ! rillig 4573: ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} \
! 4574: -rpath ${PREFIX}/lib -version-info major:minor
1.20 ben 4575:
1.1 grant 4576: Note that the library is changed to have a .la extension, and the objects
4577: are changed to have a .lo extension. Change OBJS as necessary. This
4578: automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
4579: necessary) in the build directory. Be sure to include "-version-info",
4580: especially when major and minor are zero, as libtool will otherwise strip
4581: off the shared library version.
1.20 ben 4582:
1.1 grant 4583: From the libtool manual:
1.20 ben 4584:
1.51 ! rillig 4585: So, libtool library versions are described by three integers:
1.20 ben 4586:
1.51 ! rillig 4587: CURRENT
! 4588: The most recent interface number that this library implements.
1.20 ben 4589:
1.51 ! rillig 4590: REVISION
! 4591: The implementation number of the CURRENT interface.
1.20 ben 4592:
1.51 ! rillig 4593: AGE
! 4594: The difference between the newest and oldest interfaces that
! 4595: this library implements. In other words, the library implements
! 4596: all the interface numbers in the range from number `CURRENT -
! 4597: AGE' to `CURRENT'.
1.20 ben 4598:
1.51 ! rillig 4599: If two libraries have identical CURRENT and AGE numbers, then the
! 4600: dynamic linker chooses the library with the greater REVISION number.
1.20 ben 4601:
1.1 grant 4602: The "-release" option will produce different results for a.out and ELF
4603: (excluding symlinks) in only one case. An ELF library of the form
4604: "libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
4605: platform. This is handled automatically.
1.20 ben 4606:
1.1 grant 4607: The "-rpath argument" is the install directory of the library being built.
1.20 ben 4608:
1.19 hubertf 4609: In the PLIST, include only the .la file, the other files will be added
4610: automatically.
1.20 ben 4611:
1.1 grant 4612: 4. When linking shared object (.so) files, i.e. files that are loaded via
4613: dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
4614: them getting version tacked on.
1.20 ben 4615:
1.1 grant 4616: The PLIST file gets the foo.so entry.
1.20 ben 4617:
1.1 grant 4618: 5. When linking programs that depend on these libraries before they are
4619: installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
4620: and it will find the correct libraries (static or shared), but please be
4621: aware that libtool will not allow you to specify a relative path in -L
4622: (such as "-L../somelib"), because it expects you to change that argument to
4623: be the .la file. e.g.
1.20 ben 4624:
1.51 ! rillig 4625: ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
1.20 ben 4626:
1.1 grant 4627: should be changed to:
1.20 ben 4628:
1.51 ! rillig 4629: ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
1.20 ben 4630:
1.1 grant 4631: and it will do the right thing with the libraries.
1.20 ben 4632:
1.1 grant 4633: 6. When installing libraries, preface the install(1) or cp(1) command with "$
4634: {LIBTOOL} --mode=install", and change the library name to .la. e.g.
1.20 ben 4635:
1.51 ! rillig 4636: ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
1.20 ben 4637:
1.1 grant 4638: This will install the static .a, shared library, any needed symlinks, and
4639: run ldconfig(8).
1.20 ben 4640:
1.23 wiz 4641: 7. In your PLIST, include only the .la file (this is a change from previous
4642: behaviour).
1.20 ben 4643:
1.38 dillo 4644: 15.3.2. Using libtool on GNU packages that already support libtool
1.1 grant 4645:
4646: Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
4647: own libtool in most cases. For older libtool using packages, libtool is made by
4648: ltconfig script during the do-configure step; you can check the libtool script
4649: location by doing make configure; find work*/ -name libtool.
4650:
4651: LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
4652: override. By default, it is set to "libtool */libtool */*/libtool". If this
4653: does not match the location of the package's libtool script(s), set it as
4654: appropriate.
4655:
4656: If you do not need *.a static libraries built and installed, then use
4657: SHLIBTOOL_OVERRIDE instead.
4658:
1.47 reed 4659: If your package makes use of the platform-independent library for loading
1.1 grant 4660: dynamic shared objects, that comes with libtool (libltdl), you should include
1.22 tv 4661: devel/libltdl/buildlink3.mk.
1.1 grant 4662:
4663: Some packages use libtool incorrectly so that the package may not work or build
4664: in some circumstances. Some of the more common errors are:
4665:
4666: * The inclusion of a shared object (-module) as a dependent library in an
4667: executable or library. This in itself isn't a problem if one of two things
4668: has been done:
1.20 ben 4669:
1.1 grant 4670: 1. The shared object is named correctly, i.e. libfoo.la, not foo.la
1.20 ben 4671:
1.1 grant 4672: 2. The -dlopen option is used when linking an executable.
1.20 ben 4673:
1.1 grant 4674: * The use of libltdl without the correct calls to initialisation routines.
4675: The function lt_dlinit() should be called and the macro
4676: LTDL_SET_PRELOADED_SYMBOLS included in executables.
1.20 ben 4677:
1.38 dillo 4678: 15.3.3. GNU Autoconf/Automake
1.1 grant 4679:
4680: If a package needs GNU autoconf or automake to be executed to regenerate the
4681: configure script and Makefile.in makefile templates, then they should be
1.35 jmmv 4682: executed in a pre-configure target.
1.1 grant 4683:
4684: For packages that need only autoconf:
4685:
1.51 ! rillig 4686: AUTOCONF_REQD= 2.50 # if default version is not good enough
! 4687: USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13
! 4688: ...
1.1 grant 4689:
1.51 ! rillig 4690: pre-configure:
! 4691: cd ${WRKSRC}; autoconf
1.1 grant 4692:
1.51 ! rillig 4693: ...
1.1 grant 4694:
4695: and for packages that need automake and autoconf:
4696:
1.51 ! rillig 4697: AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
! 4698: USE_TOOLS+= automake # use "automake14" for automake-1.4
! 4699: ...
1.1 grant 4700:
1.51 ! rillig 4701: pre-configure:
! 4702: cd ${WRKSRC}; \
! 4703: aclocal; autoheader; \
! 4704: automake -a --foreign -i; autoconf
! 4705:
! 4706: ...
1.1 grant 4707:
1.35 jmmv 4708: Packages which use GNU Automake will almost certainly require GNU Make.
1.1 grant 4709:
4710: There are times when the configure process makes additional changes to the
4711: generated files, which then causes the build process to try to re-execute the
4712: automake sequence. This is prevented by touching various files in the configure
4713: stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
4714: NO in the package Makefile.
4715:
1.38 dillo 4716: 15.4. Building considerations
1.1 grant 4717:
1.38 dillo 4718: 15.4.1. CPP defines
1.1 grant 4719:
4720: To port an application to NetBSD, it's usually necessary for the compiler to be
4721: able to judge the system on which it's compiling, and we use definitions so
4722: that the C pre-processor can do this.
4723:
4724: To test whether you are working on a 4.4 BSD-derived system, you should use the
4725: BSD definition, which is defined in <sys/param.h> on said systems.
4726:
1.51 ! rillig 4727: #include <sys/param.h>
1.1 grant 4728:
4729: and then you can surround the BSD-specific parts of your package's C/C++ code
4730: using this conditional:
4731:
1.51 ! rillig 4732: #if (defined(BSD) && BSD >= 199306)
1.1 grant 4733: ...
1.51 ! rillig 4734: #endif
1.1 grant 4735:
4736: Please use the "__NetBSD__" definition sparingly - it should only apply to
1.47 reed 4737: features of NetBSD that are not present in other 4.4-lite-derived BSDs.
1.1 grant 4738:
1.51 ! rillig 4739: 15.4.2. Getting a list of CPP defines
! 4740:
! 4741: When your system uses the GNU C Compiler, you can get a list of symbols that
! 4742: are defined by default, e.g. to identify the platform, with the following
! 4743: command:
! 4744:
! 4745: gcc -E -dM - < /dev/null
! 4746:
1.38 dillo 4747: 15.5. Package specific actions
1.1 grant 4748:
1.38 dillo 4749: 15.5.1. User interaction
1.1 grant 4750:
4751: Occasionally, packages require interaction from the user, and this can be in a
4752: number of ways:
4753:
4754: * help in fetching the distfiles
1.20 ben 4755:
1.1 grant 4756: * help to configure the package before it is built
1.20 ben 4757:
1.1 grant 4758: * help during the build process
1.20 ben 4759:
1.1 grant 4760: * help during the installation of a package
1.20 ben 4761:
1.1 grant 4762: The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of
4763: an interactive stage which will be needed, and this should be set in the
1.47 reed 4764: package's Makefile, e.g.:
1.1 grant 4765:
1.51 ! rillig 4766: INTERACTIVE_STAGE= build
1.1 grant 4767:
4768: Multiple interactive stages can be specified:
4769:
1.51 ! rillig 4770: INTERACTIVE_STAGE= configure install
1.1 grant 4771:
1.38 dillo 4772: 15.5.2. Handling licenses
1.1 grant 4773:
1.44 gdt 4774: A package may be covered by a license which the user has or has not agreed to
4775: accept. For these cases, pkgsrc contains a mechanism to note that a package is
4776: covered by a particular license, and the package cannot be built unless the
4777: user has accepted the license. (Installation of binary packages are not
4778: currently subject to this mechanism.) Packages with licenses that are either
4779: Open Source according to the Open Source Initiative or Free according to the
4780: Free Software Foundation will not be marked with a license tag. Packages with
4781: licenses that have not been determined to meet either definition will be marked
4782: with a license tag referring to the license. This will prevent building unless
4783: pkgsrc is informed that the license is acceptable, and enables displaying the
4784: license.
4785:
4786: The license tag mechanism is intended to address copyright-related issues
4787: surrounding building, installing and using a package, and not to address
4788: redistribution issues (see RESTRICTED and NO_SRC_ON_FTP, etc.). However, the
4789: above definition of licenses for which tags are not needed implies that
4790: packages with redistribution restrictions should have tags.
4791:
4792: Denoting that a package is covered by a particular license is done by placing
4793: the license in pkgsrc/licenses and setting the LICENSE variable to a string
4794: identifying the license, e.g. in graphics/xv:
1.1 grant 4795:
1.51 ! rillig 4796: LICENSE= xv-license
1.1 grant 4797:
1.44 gdt 4798: When trying to build, the user will get a notice that the package is covered by
4799: a license which has not been accepted:
1.1 grant 4800:
1.51 ! rillig 4801: % make
! 4802: ===> xv-3.10anb9 has an unacceptable license: xv-license.
! 4803: ===> To view the license, enter "/usr/bin/make show-license".
! 4804: ===> To indicate acceptance, add this line to your /etc/mk.conf:
! 4805: ===> ACCEPTABLE_LICENSES+=xv-license
! 4806: *** Error code 1
1.1 grant 4807:
4808: The license can be viewed with make show-license, and if it is considered
4809: appropriate, the line printed above can be added to /etc/mk.conf to indicate
4810: acceptance of the particular license:
4811:
1.51 ! rillig 4812: ACCEPTABLE_LICENSES+=xv-license
1.1 grant 4813:
4814: When adding a package with a new license, the license text should be added to
4815: pkgsrc/licenses for displaying. A list of known licenses can be seen in this
4816: directory as well as by looking at the list of (commented out)
1.11 ben 4817: ACCEPTABLE_LICENSES variable settings in pkgsrc/mk/defaults/mk.conf.
1.1 grant 4818:
1.44 gdt 4819: The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar language
4820: is deprecated because it does not crisply refer to a particular license text.
4821: Another problem with such usage is that it does not enable a user to denote
4822: acceptance of the license for a single package without accepting the same
4823: license text for another package. In particular, this can be inappropriate when
4824: e.g. one accepts a particular license to indicate to pkgsrc that a fee has been
4825: paid.
1.1 grant 4826:
1.38 dillo 4827: 15.5.3. Installing score files
1.1 grant 4828:
4829: Certain packages, most of them in the games category, install a score file that
4830: allows all users on the system to record their highscores. In order for this to
4831: work, the binaries need to be installed setgid and the score files owned by the
4832: appropriate group and/or owner (traditionally the "games" user/group). The
1.11 ben 4833: following variables, documented in more detail in mk/defaults/mk.conf, control
4834: this behaviour: SETGIDGAME, GAMEDATAMODE, GAMEGRP, GAMEMODE, GAMEOWN.
1.1 grant 4835:
4836: Note that per default, setgid installation of games is disabled; setting
4837: SETGIDGAME=YES will set all the other variables accordingly.
4838:
4839: A package should therefor never hard code file ownership or access permissions
4840: but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly.
4841:
1.38 dillo 4842: 15.5.4. Packages containing perl scripts
1.1 grant 4843:
4844: If your package contains interpreted perl scripts, set REPLACE_PERL to ensure
4845: that the proper interpreter path is set. REPLACE_PERL should contain a list of
4846: scripts, relative to WRKSRC, that you want adjusted.
4847:
1.38 dillo 4848: 15.5.5. Packages with hardcoded paths to other interpreters
1.1 grant 4849:
4850: Your package may also contain scripts with hardcoded paths to other
4851: interpreters besides (or as well as) perl. To correct the full pathname to the
4852: script interpreter, you need to set the following definitions in your Makefile
4853: (we shall use tclsh in this example):
4854:
1.51 ! rillig 4855: REPLACE_INTERPRETER+= tcl
! 4856: _REPLACE.tcl.old= .*/bin/tclsh
! 4857: _REPLACE.tcl.new= ${PREFIX}/bin/tclsh
! 4858: _REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed,
! 4859: # relative to ${WRKSRC}, just as in REPLACE_PERL
1.1 grant 4860:
1.38 dillo 4861: 15.5.6. Packages installing perl modules
1.1 grant 4862:
4863: Makefiles of packages providing perl5 modules should include the Makefile
4864: fragment ../../lang/perl5/module.mk. It provides a do-configure target for the
4865: standard perl configuration for such modules as well as various hooks to tune
4866: this configuration. See comments in this file for details.
4867:
4868: Perl5 modules will install into different places depending on the version of
4869: perl used during the build process. To address this, pkgsrc will append lines
4870: to the PLIST corresponding to the files listed in the installed .packlist file
4871: generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to
4872: a space-separated list of paths to packlist files, e.g.:
4873:
1.51 ! rillig 4874: PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
1.1 grant 4875:
4876: The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent the
4877: three locations in which perl5 modules may be installed, and may be used by
4878: perl5 packages that don't have a packlist. These three variables are also
4879: substituted for in the PLIST.
4880:
1.38 dillo 4881: 15.5.7. Packages installing info files
1.1 grant 4882:
4883: Some packages install info files or use the "makeinfo" or "install-info"
4884: commands. Each of the info files:
4885:
4886: * is considered to be installed in the directory ${PREFIX}/${INFO_DIR},
1.20 ben 4887:
1.1 grant 4888: * is registered in the Info directory file ${PREFIX}/${INFO_DIR}/dir,
1.20 ben 4889:
1.1 grant 4890: * and must be listed as a filename in the INFO_FILES variable in the package
4891: Makefile.
1.20 ben 4892:
1.1 grant 4893: INFO_DIR defaults to "info" and can be overridden in the package Makefile.
4894: INSTALL and DEINSTALL scripts will be generated to handle registration of the
4895: info files in the Info directory file. The "install-info" command used for the
4896: info files registration is either provided by the system, or by a special
4897: purpose package automatically added as dependency if needed.
4898:
4899: A package which needs the "makeinfo" command at build time must define the
4900: variable USE_MAKEINFO in its Makefile. If a minimum version of the "makeinfo"
4901: command is needed it should be noted with the TEXINFO_REQD variable in the
4902: package Makefile. By default, a minimum version of 3.12 is required. If the
4903: system does not provide a makeinfo command or if it does not match the required
4904: minimum, a build dependency on the devel/gtexinfo package will be added
4905: automatically.
4906:
4907: The build and installation process of the software provided by the package
4908: should not use the install-info command as the registration of info files is
1.20 ben 4909: the task of the package INSTALL script, and it must use the appropriate
1.1 grant 4910: makeinfo command.
4911:
1.47 reed 4912: To achieve this goal, the pkgsrc infrastructure creates overriding scripts for
1.1 grant 4913: the install-info and makeinfo commands in a directory listed early in PATH.
4914:
4915: The script overriding install-info has no effect except the logging of a
4916: message. The script overriding makeinfo logs a message and according to the
4917: value of USE_MAKEINFO and TEXINFO_REQD either run the appropriate makeinfo
4918: command or exit on error.
4919:
1.38 dillo 4920: 15.5.8. Packages installing GConf2 data files
1.1 grant 4921:
4922: If a package installs .schemas or .entries files, used by GConf2, you need to
4923: take some extra steps to make sure they get registered in the database:
4924:
4925: 1. Include ../../devel/GConf2/schemas.mk instead of its buildlink3.mk file.
4926: This takes care of rebuilding the GConf2 database at installation and
4927: deinstallation time, and tells the package where to install GConf2 data
4928: files using some standard configure arguments. It also disallows any access
4929: to the database directly from the package.
1.20 ben 4930:
1.1 grant 4931: 2. Ensure that the package installs its .schemas files under ${PREFIX}/share/
4932: gconf/schemas. If they get installed under ${PREFIX}/etc, you will need to
4933: manually patch the package.
1.20 ben 4934:
1.1 grant 4935: 3. Check the PLIST and remove any entries under the etc/gconf directory, as
1.38 dillo 4936: they will be handled automatically. See Section 7.14, "How do I change the
1.35 jmmv 4937: location of configuration files?" for more information.
1.20 ben 4938:
1.1 grant 4939: 4. Define the GCONF2_SCHEMAS variable in your Makefile with a list of all
4940: .schemas files installed by the package, if any. Names must not contain any
4941: directories in them.
1.20 ben 4942:
1.1 grant 4943: 5. Define the GCONF2_ENTRIES variable in your Makefile with a list of all
4944: .entries files installed by the package, if any. Names must not contain any
4945: directories in them.
1.20 ben 4946:
1.38 dillo 4947: 15.5.9. Packages installing scrollkeeper data files
1.1 grant 4948:
4949: If a package installs .omf files, used by scrollkeeper, you need to take some
4950: extra steps to make sure they get registered in the database:
4951:
4952: 1. Include ../../textproc/scrollkeeper/omf.mk instead of its buildlink3.mk
4953: file. This takes care of rebuilding the scrollkeeper database at
4954: installation and deinstallation time, and disallows any access to it
4955: directly from the package.
1.20 ben 4956:
1.1 grant 4957: 2. Check the PLIST and remove any entries under the libdata/scrollkeeper
4958: directory, as they will be handled automatically.
1.20 ben 4959:
1.1 grant 4960: 3. Remove the share/omf directory from the PLIST. It will be handled by
4961: scrollkeeper.
1.20 ben 4962:
1.38 dillo 4963: 15.5.10. Packages installing X11 fonts
1.1 grant 4964:
4965: If a package installs font files, you will need to rebuild the fonts database
4966: in the directory where they get installed at installation and deinstallation
4967: time. This can be automatically done by using mk/fonts.mk, which you need to
4968: include in your Makefile.
4969:
4970: When the file is included, you can list the directories where fonts are
4971: installed in the FONTS_type_DIRS variables, where type can be one of "TTF",
4972: "TYPE1" or "X11". Also make sure that the database file fonts.dir is not listed
4973: in the PLIST.
4974:
4975: Note that you should not create new directories for fonts; instead use the
4976: standard ones to avoid that the user needs to manually configure his X server
4977: to find them.
4978:
1.38 dillo 4979: 15.5.11. Packages installing GTK2 modules
1.1 grant 4980:
1.47 reed 4981: If a package installs GTK2 immodules or loaders, you need to take some extra
1.1 grant 4982: steps to get them registered in the GTK2 database properly:
4983:
4984: 1. Include ../../x11/gtk2/modules.mk instead of its buildlink3.mk file. This
4985: takes care of rebuilding the database at installation and deinstallation
4986: time.
1.20 ben 4987:
1.1 grant 4988: 2. Set GTK2_IMMODULES=YES if your package installs GTK2 immodules.
1.20 ben 4989:
1.1 grant 4990: 3. Set GTK2_LOADERS=YES if your package installs GTK2 loaders.
1.20 ben 4991:
1.47 reed 4992: 4. Patch the package to not touch any of the GTK2 databases directly. These
1.1 grant 4993: are:
1.20 ben 4994:
1.1 grant 4995: * libdata/gtk-2.0/gdk-pixbuf.loaders
1.20 ben 4996:
1.1 grant 4997: * libdata/gtk-2.0/gtk.immodules
1.20 ben 4998:
1.1 grant 4999: 5. Check the PLIST and remove any entries under the libdata/gtk-2.0 directory,
5000: as they will be handled automatically.
1.20 ben 5001:
1.38 dillo 5002: 15.5.12. Packages installing SGML or XML data
1.1 grant 5003:
5004: If a package installs SGML or XML data files that need to be registered in
5005: system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
5006: extra steps:
5007:
5008: 1. Include ../../textproc/xmlcatmgr/catalogs.mk in your Makefile, which takes
5009: care of registering those files in system-wide catalogs at installation and
5010: deinstallation time.
1.20 ben 5011:
1.1 grant 5012: 2. Set SGML_CATALOGS to the full path of any SGML catalogs installed by the
5013: package.
1.20 ben 5014:
1.1 grant 5015: 3. Set XML_CATALOGS to the full path of any XML catalogs installed by the
5016: package.
1.20 ben 5017:
1.1 grant 5018: 4. Set SGML_ENTRIES to individual entries to be added to the SGML catalog.
5019: These come in groups of three strings; see xmlcatmgr(1) for more
5020: information (specifically, arguments recognized by the 'add' action). Note
5021: that you will normally not use this variable.
1.20 ben 5022:
1.1 grant 5023: 5. Set XML_ENTRIES to individual entries to be added to the XML catalog. These
5024: come in groups of three strings; see xmlcatmgr(1) for more information
5025: (specifically, arguments recognized by the 'add' action). Note that you
5026: will normally not use this variable.
1.20 ben 5027:
1.38 dillo 5028: 15.5.13. Packages installing extensions to the MIME database
1.1 grant 5029:
5030: If a package provides extensions to the MIME database by installing .xml files
5031: inside ${PREFIX}/share/mime/packages, you need to take some extra steps to
5032: ensure that the database is kept consistent with respect to these new files:
5033:
5034: 1. Include ../../databases/shared-mime-info/mimedb.mk (avoid using the
5035: buildlink3.mk file from this same directory, which is reserved for
5036: inclusion from other buildlink3.mk files). It takes care of rebuilding the
5037: MIME database at installation and deinstallation time, and disallows any
5038: access to it directly from the package.
1.20 ben 5039:
5040: 2. Check the PLIST and remove any entries under the share/mime directory,
1.1 grant 5041: except for files saved under share/mime/packages. The former are handled
1.47 reed 5042: automatically by the update-mime-database program, but the latter are
1.1 grant 5043: package-dependent and must be removed by the package that installed them in
5044: the first place.
1.20 ben 5045:
1.1 grant 5046: 3. Remove any share/mime/* directories from the PLIST. They will be handled by
5047: the shared-mime-info package.
1.20 ben 5048:
1.38 dillo 5049: 15.5.14. Packages using intltool
1.1 grant 5050:
5051: If a package uses intltool during its build, include the ../../textproc/
5052: intltool/buildlink3.mk file, which forces it to use the intltool package
5053: provided by pkgsrc, instead of the one bundled with the distribution file.
5054:
5055: This tracks intltool's build-time dependencies and uses the latest available
5056: version; this way, the package benefits of any bug fixes that may have appeared
5057: since it was released.
5058:
1.38 dillo 5059: 15.5.15. Packages installing startup scripts
1.18 xtraeme 5060:
5061: If a package contains a rc.d script, it won't be copied into the startup
5062: directory by default, but you can enable it, by adding the option
5063: PKG_RCD_SCRIPTS=YES in /etc/mk.conf. This option will copy the scripts into /
5064: etc/rc.d when a package is installed, and it will automatically remove the
5065: scripts when the package is deinstalled.
5066:
1.38 dillo 5067: 15.6. Feedback to the author
1.1 grant 5068:
5069: If you have found any bugs in the package you make available, if you had to do
5070: special steps to make it run under NetBSD or if you enhanced the software in
5071: various other ways, be sure to report these changes back to the original author
5072: of the program! With that kind of support, the next release of the program can
5073: incorporate these fixes, and people not using the NetBSD packages system can
5074: win from your efforts.
5075:
5076: Support the idea of free software!
5077:
1.38 dillo 5078: Chapter 16. Debugging
1.1 grant 5079:
5080: To check out all the gotchas when building a package, here are the steps that I
5081: do in order to get a package working. Please note this is basically the same as
5082: what was explained in the previous sections, only with some debugging aids.
5083:
5084: * Be sure to set PKG_DEVELOPER=1 in /etc/mk.conf
1.20 ben 5085:
1.1 grant 5086: * Install pkgtools/url2pkg, create a directory for a new package, change into
5087: it, then run url2pkg:
1.20 ben 5088:
1.1 grant 5089: % mkdir /usr/pkgsrc/category/examplepkg
5090: % cd /usr/pkgsrc/category/examplepkg
5091: % url2pkg http://www.example.com/path/to/distfile.tar.gz
1.20 ben 5092:
1.1 grant 5093: * Edit the Makefile as requested.
1.20 ben 5094:
1.1 grant 5095: * Fill in the DESCR file
1.20 ben 5096:
1.1 grant 5097: * Run make configure
1.20 ben 5098:
1.1 grant 5099: * Add any dependencies glimpsed from documentation and the configure step to
5100: the package's Makefile.
1.20 ben 5101:
1.1 grant 5102: * Make the package compile, doing multiple rounds of
1.20 ben 5103:
1.1 grant 5104: % make
5105: % pkgvi ${WRKSRC}/some/file/that/does/not/compile
5106: % mkpatches
5107: % patchdiff
5108: % mv ${WRKDIR}/.newpatches/* patches
5109: % make mps
5110: % make clean
1.20 ben 5111:
1.1 grant 5112: Doing as non-root user will ensure that no files are modified that
1.20 ben 5113: shouldn't be, especially during the build phase. mkpatches, patchdiff and
1.1 grant 5114: pkgvi are from the pkgtools/pkgdiff package.
1.20 ben 5115:
1.38 dillo 5116: * Look at the Makefile, fix if necessary; see Section 8.1, "Makefile".
1.20 ben 5117:
1.1 grant 5118: * Generate a PLIST:
1.20 ben 5119:
1.1 grant 5120: # make install
5121: # make print-PLIST >PLIST
5122: # make deinstall
5123: # make install
5124: # make deinstall
1.20 ben 5125:
1.1 grant 5126: You usually need to be root to do this. Look if there are any files left:
1.20 ben 5127:
1.1 grant 5128: # make print-PLIST
1.20 ben 5129:
1.1 grant 5130: If this reveals any files that are missing in PLIST, add them.
1.20 ben 5131:
1.1 grant 5132: * Now that the PLIST is OK, install the package again and make a binary
5133: package:
1.20 ben 5134:
1.1 grant 5135: # make reinstall
5136: # make package
1.20 ben 5137:
1.1 grant 5138: * Delete the installed package:
1.20 ben 5139:
1.1 grant 5140: # pkg_delete blub
1.20 ben 5141:
1.1 grant 5142: * Repeat the above make print-PLIST command, which shouldn't find anything
5143: now:
1.20 ben 5144:
1.1 grant 5145: # make print-PLIST
1.20 ben 5146:
1.1 grant 5147: * Reinstall the binary package:
1.20 ben 5148:
1.1 grant 5149: # pkgadd .../blub.tgz
1.20 ben 5150:
1.1 grant 5151: * Play with it. Make sure everything works.
1.20 ben 5152:
1.1 grant 5153: * Run pkglint from pkgtools/pkglint, and fix the problems it reports:
1.20 ben 5154:
1.1 grant 5155: # pkglint
1.20 ben 5156:
1.38 dillo 5157: * Submit (or commit, if you have cvs access); see Chapter 17, Submitting and
1.1 grant 5158: Committing.
1.20 ben 5159:
1.38 dillo 5160: Chapter 17. Submitting and Committing
1.1 grant 5161:
5162: Table of Contents
5163:
1.38 dillo 5164: 17.1. Submitting your packages
1.41 wiz 5165: 17.2. General notes when adding, updating, or removing packages
5166: 17.3. Committing: Importing a package into CVS
5167: 17.4. Updating a package to a newer version
5168: 17.5. Moving a package in pkgsrc
1.1 grant 5169:
1.38 dillo 5170: 17.1. Submitting your packages
1.1 grant 5171:
5172: You have to separate between binary and "normal" (source) packages here:
5173:
5174: * precompiled binary packages
1.20 ben 5175:
1.1 grant 5176: Our policy is that we accept binaries only from pkgsrc developers to
5177: guarantee that the packages don't contain any trojan horses etc. This is
1.13 hubertf 5178: not to annoy anyone but rather to protect our users! You're still free to
5179: put up your home-made binary packages and tell the world where to get them.
1.20 ben 5180: NetBSD developers doing bulk builds and wanting to upload them please see
1.38 dillo 5181: Section 6.3.8, "Uploading results of a bulk build".
1.20 ben 5182:
1.1 grant 5183: * packages
1.20 ben 5184:
5185: First, check that your package is complete, compiles and runs well; see
1.38 dillo 5186: Chapter 16, Debugging and the rest of this document. Next, generate an
1.1 grant 5187: uuencoded gzipped tar(1) archive, preferably with all files in a single
5188: directory. Finally, send-pr with category "pkg", a synopsis which includes
5189: the package name and version number, a short description of your package
5190: (contents of the COMMENT variable or DESCR file are OK) and attach the
5191: archive to your PR.
1.20 ben 5192:
1.1 grant 5193: If you want to submit several packages, please send a separate PR for each
5194: one, it's easier for us to track things that way.
1.20 ben 5195:
1.1 grant 5196: Alternatively, you can also import new packages into pkgsrc-wip ("pkgsrc
5197: work-in-progress"); see the homepage at http://pkgsrc-wip.sourceforge.net/
5198: for details.
1.20 ben 5199:
1.41 wiz 5200: 17.2. General notes when adding, updating, or removing packages
5201:
5202: Please note all package additions, updates, moves, and removals in pkgsrc/doc/
5203: CHANGES. It's very important to keep this file up to date and conforming to the
5204: existing format, because it will be used by scripts to automatically update
5205: pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/doc/
5206: TODO file and remove the entry for the package you updated or removed, in case
5207: it was mentioned there.
5208:
5209: There is a make target that helps in creating proper CHANGES entries: make
5210: changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The
5211: general usage is to first make sure that your CHANGES file is up-to-date (to
5212: avoid having to resolve conflicts later-on) and then to cd to the package
5213: directory. For package updates, make changes-entry is enough. For new packages,
5214: or package moves or removals, set the CTYPE variable on the command line to
5215: "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in /etc/mk.conf
5216: if your local login name is not the same as your NetBSD login name. Don't
5217: forget to commit the changes to pkgsrc/doc/CHANGES!
5218:
5219: 17.3. Committing: Importing a package into CVS
1.1 grant 5220:
5221: This section is only of interest for pkgsrc developers with write access to the
5222: pkgsrc repository. Please remember that cvs imports files relative to the
5223: current working directory, and that the pathname that you give the cvs import
5224: command is so that it knows where to place the files in the repository. Newly
5225: created packages should be imported with a vendor tag of "TNF" and a release
5226: tag of "pkgsrc-base", e.g:
5227:
1.51 ! rillig 5228: $ cd .../pkgsrc/category/pkgname
! 5229: $ cvs import pkgsrc/category/pkgname TNF pkgsrc-base
1.1 grant 5230:
5231: Remember to move the directory from which you imported out of the way, or cvs
5232: will complain the next time you "cvs update" your source tree. Also don't
5233: forget to add the new package to the category's Makefile.
5234:
5235: The commit message of the initial import should include part of the DESCR file,
5236: so people reading the mailing lists know what the package is/does.
5237:
5238: For new packages, "cvs import" is preferred to "cvs add" because the former
5239: gets everything with a single command, and provides a consistent tag.
5240:
1.41 wiz 5241: 17.4. Updating a package to a newer version
1.1 grant 5242:
5243: Please always put a concise, appropriate and relevant summary of the changes
5244: between old and new versions into the commit log when updating a package. There
5245: are various reasons for this:
5246:
5247: * A URL is volatile, and can change over time. It may go away completely or
5248: its information may be overwritten by newer information.
1.20 ben 5249:
1.1 grant 5250: * Having the change information between old and new versions in our CVS
5251: repository is very useful for people who use either cvs or anoncvs.
1.20 ben 5252:
1.1 grant 5253: * Having the change information between old and new versions in our CVS
5254: repository is very useful for people who read the pkgsrc-changes mailing
5255: list, so that they can make tactical decisions about when to upgrade the
5256: package.
1.20 ben 5257:
1.18 xtraeme 5258: Please also recognize that, just because a new version of a package has been
1.1 grant 5259: released, it should not automatically be upgraded in the CVS repository. We
5260: prefer to be conservative in the packages that are included in pkgsrc -
5261: development or beta packages are not really the best thing for most places in
5262: which pkgsrc is used. Please use your judgement about what should go into
5263: pkgsrc, and bear in mind that stability is to be preferred above new and
5264: possibly untested features.
5265:
1.41 wiz 5266: 17.5. Moving a package in pkgsrc
1.1 grant 5267:
5268: 1. Make a copy of the directory somewhere else.
1.20 ben 5269:
1.1 grant 5270: 2. Remove all CVS dirs.
1.20 ben 5271:
1.1 grant 5272: Alternatively to the first two steps you can also do:
1.20 ben 5273:
1.1 grant 5274: % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
1.20 ben 5275:
1.1 grant 5276: and use that for further work.
1.20 ben 5277:
1.1 grant 5278: 3. Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of
5279: "../../category/package".
1.20 ben 5280:
1.1 grant 5281: 4. cvs import the modified package in the new place.
1.20 ben 5282:
1.1 grant 5283: 5. Check if any package depends on it:
1.20 ben 5284:
1.1 grant 5285: % cd /usr/pkgsrc
5286: % grep /package */*/Makefile* */*/buildlink*
1.20 ben 5287:
1.1 grant 5288: 6. Fix paths in packages from step 5 to point to new location.
1.20 ben 5289:
1.1 grant 5290: 7. cvs rm (-f) the package at the old location.
1.20 ben 5291:
1.1 grant 5292: 8. Remove from oldcategory/Makefile.
1.20 ben 5293:
1.1 grant 5294: 9. Add to newcategory/Makefile.
1.20 ben 5295:
1.1 grant 5296: 10. Commit the changed and removed files:
1.20 ben 5297:
1.1 grant 5298: % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
1.20 ben 5299:
1.1 grant 5300: (and any packages from step 5, of course).
1.20 ben 5301:
1.46 gdt 5302: Appendix A. A simple example package: bison
1.1 grant 5303:
5304: Table of Contents
5305:
1.46 gdt 5306: A.1. files
1.20 ben 5307:
1.46 gdt 5308: A.1.1. Makefile
5309: A.1.2. DESCR
5310: A.1.3. PLIST
5311: A.1.4. Checking a package with pkglint
1.20 ben 5312:
1.46 gdt 5313: A.2. Steps for building, installing, packaging
1.1 grant 5314:
5315: We checked to find a piece of software that wasn't in the packages collection,
1.20 ben 5316: and picked GNU bison. Quite why someone would want to have bison when Berkeley
1.1 grant 5317: yacc is already present in the tree is beyond us, but it's useful for the
5318: purposes of this exercise.
5319:
1.46 gdt 5320: A.1. files
1.1 grant 5321:
1.46 gdt 5322: A.1.1. Makefile
1.1 grant 5323:
1.51 ! rillig 5324: # $NetBSD$
! 5325: #
! 5326:
! 5327: DISTNAME= bison-1.25
! 5328: CATEGORIES= devel
! 5329: MASTER_SITES= ${MASTER_SITE_GNU}
1.1 grant 5330:
1.51 ! rillig 5331: MAINTAINER= thorpej@NetBSD.org
! 5332: HOMEPAGE= http://www.gnu.org/software/bison/bison.html
! 5333: COMMENT= GNU yacc clone
1.1 grant 5334:
1.51 ! rillig 5335: GNU_CONFIGURE= yes
! 5336: INFO_FILES= bison.info
1.1 grant 5337:
1.51 ! rillig 5338: .include "../../mk/bsd.pkg.mk"
1.1 grant 5339:
1.46 gdt 5340: A.1.2. DESCR
1.1 grant 5341:
1.51 ! rillig 5342: GNU version of yacc. Can make re-entrant parsers, and numerous other
! 5343: improvements. Why you would want this when Berkeley yacc(1) is part
! 5344: of the NetBSD source tree is beyond me.
1.1 grant 5345:
1.46 gdt 5346: A.1.3. PLIST
1.1 grant 5347:
1.51 ! rillig 5348: @comment $NetBSD$
! 5349: bin/bison
! 5350: man/man1/bison.1.gz
! 5351: share/bison.simple
! 5352: share/bison.hairy
1.1 grant 5353:
1.46 gdt 5354: A.1.4. Checking a package with pkglint
1.1 grant 5355:
5356: The NetBSD package system comes with pkgtools/pkglint which helps to check the
5357: contents of these files. After installation it is quite easy to use, just
5358: change to the directory of the package you wish to examine and execute pkglint:
5359:
5360: $ pkglint
5361: looks fine.
5362:
1.47 reed 5363: Depending on the supplied command line arguments (see pkglint(1)), more verbose
1.1 grant 5364: checks will be performed. Use e.g. pkglint -v for a very verbose check.
5365:
1.46 gdt 5366: A.2. Steps for building, installing, packaging
1.1 grant 5367:
5368: Create the directory where the package lives, plus any auxiliary directories:
5369:
5370: # cd /usr/pkgsrc/lang
5371: # mkdir bison
5372: # cd bison
5373: # mkdir patches
5374:
1.38 dillo 5375: Create Makefile, DESCR and PLIST (see Chapter 8, Package components - files,
1.1 grant 5376: directories and contents) then continue with fetching the distfile:
5377:
5378: # make fetch
5379: >> bison-1.25.tar.gz doesn't seem to exist on this system.
5380: >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
5381: Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
5382: ftp: Error retrieving file: 500 Internal error
5383:
5384: >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
5385: Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
5386: ftp: Error retrieving file: 500 Internal error
5387:
5388: >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
5389: Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
5390: Successfully retrieved file.
5391:
5392: Generate the checksum of the distfile into distinfo:
5393:
5394: # make makesum
5395:
5396: Now compile:
5397:
5398: # make
5399: >> Checksum OK for bison-1.25.tar.gz.
5400: ===> Extracting for bison-1.25
5401: ===> Patching for bison-1.25
5402: ===> Ignoring empty patch directory
5403: ===> Configuring for bison-1.25
5404: creating cache ./config.cache
5405: checking for gcc... cc
5406: checking whether we are using GNU C... yes
5407: checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
5408: checking how to run the C preprocessor... cc -E
5409: checking for minix/config.h... no
5410: checking for POSIXized ISC... no
5411: checking whether cross-compiling... no
5412: checking for ANSI C header files... yes
5413: checking for string.h... yes
5414: checking for stdlib.h... yes
5415: checking for memory.h... yes
5416: checking for working const... yes
5417: checking for working alloca.h... no
5418: checking for alloca... yes
5419: checking for strerror... yes
5420: updating cache ./config.cache
5421: creating ./config.status
5422: creating Makefile
5423: ===> Building for bison-1.25
5424: 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
5425: 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
5426: 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
5427: 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
5428: 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 5429: 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 5430: 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
5431: 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
5432: 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
5433: 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
5434: 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
5435: 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
5436: 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
5437: 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
5438: 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
5439: 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
5440: 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
5441: 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
5442: 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
5443: 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
5444: 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
5445: 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
5446: ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
5447: rm -f bison.s1
5448: sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
5449:
5450: Everything seems OK, so install the files:
5451:
5452: # make install
5453: >> Checksum OK for bison-1.25.tar.gz.
5454: ===> Installing for bison-1.25
5455: sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
5456: rm -f /usr/pkg/bin/bison
5457: cd /usr/pkg/share; rm -f bison.simple bison.hairy
5458: rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
5459: install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison
5460: /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
5461: /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
5462: cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
5463: /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
5464: ===> Registering installation for bison-1.25
5465:
5466: You can now use bison, and also - if you decide so - remove it with pkg_delete
5467: bison. Should you decide that you want a binary package, do this now:
5468:
5469: # make package
5470: >> Checksum OK for bison-1.25.tar.gz.
5471: ===> Building package for bison-1.25
5472: Creating package bison-1.25.tgz
5473: Registering depends:.
5474: Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
5475:
5476: Now that you don't need the source and object files any more, clean up:
5477:
5478: # make clean
5479: ===> Cleaning for bison-1.25
5480:
1.46 gdt 5481: Appendix B. Build logs
1.1 grant 5482:
5483: Table of Contents
5484:
1.46 gdt 5485: B.1. Building figlet
5486: B.2. Packaging figlet
1.1 grant 5487:
1.46 gdt 5488: B.1. Building figlet
1.1 grant 5489:
5490: # make
5491: ===> Checking for vulnerabilities in figlet-2.2.1nb2
5492: => figlet221.tar.gz doesn't seem to exist on this system.
5493: => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
5494: => [172219 bytes]
5495: Connected to ftp.plig.net.
5496: 220 ftp.plig.org NcFTPd Server (licensed copy) ready.
5497: 331 Guest login ok, send your complete e-mail address as password.
5498: 230-You are user #5 of 500 simultaneous users allowed.
5499: 230-
1.20 ben 5500: 230- ___ _ _ _
5501: 230- | _| |_ ___ ___| |_|___ ___ ___ ___
1.1 grant 5502: 230- | _| _| . |_| . | | | . |_| . | _| . |
5503: 230- |_| |_| | _|_| _|_|_|_ |_|___|_| |_ |
5504: 230- |_| |_| |___| |___|
5505: 230-
5506: 230-** Welcome to ftp.plig.org **
5507: 230-
5508: 230-Please note that all transfers from this FTP site are logged. If you
5509: 230-do not like this, please disconnect now.
5510: 230-
5511: 230-This arhive is available via
5512: 230-
5513: 230-HTTP: http://ftp.plig.org/
5514: 230-FTP: ftp://ftp.plig.org/ (max 500 connections)
5515: 230-RSYNC: rsync://ftp.plig.org/ (max 30 connections)
5516: 230-
5517: 230-Please email comments, bug reports and requests for packages to be
1.20 ben 5518: 230-mirrored to ftp-admin@plig.org.
1.1 grant 5519: 230-
5520: 230-
5521: 230 Logged in anonymously.
5522: Remote system type is UNIX.
5523: Using binary mode to transfer files.
5524: 200 Type okay.
5525: 250 "/pub" is new cwd.
5526: 250-"/pub/figlet" is new cwd.
5527: 250-
5528: 250-Welcome to the figlet archive at ftp.figlet.org
1.20 ben 5529: 250-
1.1 grant 5530: 250- ftp://ftp.figlet.org/pub/figlet/
5531: 250-
5532: 250-The official FIGlet web page is:
5533: 250- http://www.figlet.org/
5534: 250-
5535: 250-If you have questions, please mailto:info@figlet.org. If you want to
5536: 250-contribute a font or something else, you can email us.
1.20 ben 5537: 250
1.1 grant 5538: 250 "/pub/figlet/program" is new cwd.
5539: 250 "/pub/figlet/program/unix" is new cwd.
5540: local: figlet221.tar.gz remote: figlet221.tar.gz
5541: 502 Unimplemented command.
5542: 227 Entering Passive Mode (195,40,6,41,246,104)
5543: 150 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
5544: 38% |************** | 65800 64.16 KB/s 00:01 ETA
5545: 226 Transfer completed.
5546: 172219 bytes received in 00:02 (75.99 KB/s)
5547: 221 Goodbye.
5548: => Checksum OK for figlet221.tar.gz.
5549: ===> Extracting for figlet-2.2.1nb2
5550: ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found
5551: ===> Patching for figlet-2.2.1nb2
5552: ===> Applying pkgsrc patches for figlet-2.2.1nb2
5553: ===> Overriding tools for figlet-2.2.1nb2
5554: ===> Creating toolchain wrappers for figlet-2.2.1nb2
5555: ===> Configuring for figlet-2.2.1nb2
5556: ===> Building for figlet-2.2.1nb2
5557: gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\" -DDEFAULTFONTFILE=\"standard.flf\" figlet.c zipio.c crc.c inflate.c -o figlet
5558: chmod a+x figlet
5559: gcc -O2 -o chkfont chkfont.c
5560: => Unwrapping files-to-be-installed.
5561: #
5562: # make install
5563: ===> Checking for vulnerabilities in figlet-2.2.1nb2
5564: ===> Installing for figlet-2.2.1nb2
5565: install -d -o root -g wheel -m 755 /usr/pkg/bin
5566: install -d -o root -g wheel -m 755 /usr/pkg/man/man6
5567: mkdir -p /usr/pkg/share/figlet
5568: cp figlet /usr/pkg/bin
5569: cp chkfont /usr/pkg/bin
5570: chmod 555 figlist showfigfonts
5571: cp figlist /usr/pkg/bin
5572: cp showfigfonts /usr/pkg/bin
5573: cp fonts/*.flf /usr/pkg/share/figlet
5574: cp fonts/*.flc /usr/pkg/share/figlet
5575: cp figlet.6 /usr/pkg/man/man6
5576: ===> Registering installation for figlet-2.2.1nb2
5577: #
5578:
1.46 gdt 5579: B.2. Packaging figlet
1.1 grant 5580:
5581: # make package
5582: ===> Checking for vulnerabilities in figlet-2.2.1nb2
5583: ===> Packaging figlet-2.2.1nb2
5584: ===> Building binary package for figlet-2.2.1nb2
5585: Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
5586: Using SrcDir value of /usr/pkg
1.20 ben 5587: Registering depends:.
1.1 grant 5588: #
5589:
1.46 gdt 5590: Appendix C. Layout of the FTP server's package archive
1.1 grant 5591:
5592: Layout for precompiled binary packages on ftp.NetBSD.org:
5593:
1.51 ! rillig 5594: /pub/NetBSD/packages/
! 5595: distfiles/
1.20 ben 5596:
1.51 ! rillig 5597: # Unpacked pkgsrc trees
! 5598: pkgsrc-current -> /pub/NetBSD/NetBSD-current/pkgsrc
! 5599: pkgsrc-2003Q4 -> N/A
! 5600: pkgsrc-2004Q1/pkgsrc
! 5601:
! 5602: # pkgsrc archives
! 5603: pkgsrc-current.tar.gz -> ../NetBSD-current/tar_files/pkgsrc.tar.gz
! 5604: pkgsrc-2003Q4.tar.gz -> N/A
! 5605: pkgsrc-2004Q1.tar.gz -> N/A
! 5606:
! 5607: # Per pkgsrc-release/OS-release/arch package archives
! 5608: pkgsrc-2003Q4/
! 5609: NetBSD-1.6.2/
! 5610: i386/
! 5611: All/
! 5612: archivers/
! 5613: foo -> ../All/foo
! 5614: ...
! 5615: pkgsrc-2004Q1/
! 5616: NetBSD-1.6.2/
! 5617: i386/
! 5618: All/
! 5619: ...
! 5620: NetBSD-2.0/
! 5621: i386/
! 5622: All/
! 5623: ...
! 5624: SunOS-5.9/
! 5625: sparc/
! 5626: All/
! 5627: ...
! 5628: x86/
! 5629: All/
! 5630: ...
! 5631:
! 5632: # Per os-release package archive convenience links
! 5633: NetBSD-1.6.2 -> 1.6.2
! 5634: 1.6.2/
! 5635: i386 -> ../pkgsrc-2004Q1/NetBSD-1.6.2/i386
! 5636: m68k/
! 5637: All/
! 5638: archivers/
! 5639: foo -> ../All/foo
! 5640: ...
! 5641: amiga -> m68k
! 5642: atari -> m68k
! 5643: ...
! 5644:
! 5645: 2.0 -> NetBSD-2.0 # backward compat, historic
! 5646: NetBSD-2.0/
! 5647: i386 -> ../pkgsrc-2004Q1/NetBSD-2.0/i386
! 5648: SunOS-5.9/
! 5649: sparc -> ../pkgsrc-2004Q1/SunOS-5.9/sparc
! 5650: x86 -> ../pkgsrc-2004Q1/SunOS-5.9/x86
1.1 grant 5651:
5652: To create:
5653:
1.38 dillo 5654: 1. Run bulk build, see Section 6.3, "Doing a bulk build of all packages"
1.20 ben 5655:
1.1 grant 5656: 2. Upload /usr/pkgsrc/packages to
1.20 ben 5657:
1.1 grant 5658: ftp://ftp.NetBSD.org/pub/NetBSD/packages/\
1.51 ! rillig 5659: pkgsrc-2004Q4/\ # pkgsrc-branch
! 5660: `uname -s`-`uname -r`/\ # OS & version
! 5661: `uname -p` # architecture
1.20 ben 5662:
1.2 hubertf 5663: 3. If necessary, create a symlink ln -s `uname -m` `uname -p` (amiga -> m68k,
5664: ...)
1.20 ben 5665:
1.46 gdt 5666: Appendix D. Editing guidelines for the pkgsrc guide
1.2 hubertf 5667:
5668: Table of Contents
5669:
1.46 gdt 5670: D.1. Targets
5671: D.2. Procedure
1.1 grant 5672:
1.2 hubertf 5673: This section contains information on editing the pkgsrc guide itself.
1.1 grant 5674:
1.46 gdt 5675: D.1. Targets
1.1 grant 5676:
1.2 hubertf 5677: The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several
5678: files are created from it:
5679:
1.23 wiz 5680: * pkgsrc/doc/pkgsrc.txt
1.20 ben 5681:
1.2 hubertf 5682: * pkgsrc/doc/pkgsrc.html
1.20 ben 5683:
1.2 hubertf 5684: * http://www.NetBSD.org/Documentation/pkgsrc/: the documentation on the
5685: NetBSD website will be built from pkgsrc and kept up to date on the web
5686: server itself. This means you must make sure that your changes haven't
5687: broken the build!
1.20 ben 5688:
1.6 hubertf 5689: * http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.pdf: PDF version of the
5690: pkgsrc guide.
1.20 ben 5691:
1.6 hubertf 5692: * http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.ps: PostScript version of
5693: the pkgsrc guide.
1.20 ben 5694:
1.46 gdt 5695: D.2. Procedure
1.2 hubertf 5696:
5697: The procedure to edit the pkgsrc guide is:
5698:
1.6 hubertf 5699: * Make sure you have the packages needed to re-generate the pkgsrc guide (and
1.11 ben 5700: other XML-based NetBSD documentation) installed. These are "netbsd-doc" for
1.47 reed 5701: creating the ASCII and HTML versions, and "netbsd-doc-print" for the
5702: PostScript and PDF versions. You will need both packages installed, to make
1.6 hubertf 5703: sure documentation is consistent across all formats. The packages can be
5704: found in pkgsrc/meta-pkgs/netbsd-doc and pkgsrc/meta-pkgs/netbsd-doc-print.
1.20 ben 5705:
1.6 hubertf 5706: * Edit the XML file(s) in pkgsrc/doc/guide/files.
1.20 ben 5707:
1.6 hubertf 5708: * Run make extract && make do-lint in pkgsrc/doc/guide to check the XML
5709: syntax, and fix it if needed.
1.20 ben 5710:
1.6 hubertf 5711: * Run make in pkgsrc/doc/guide to build the HTML and ASCII version.
1.20 ben 5712:
1.4 hubertf 5713: * If all is well, run make install-doc to put the generated files into pkgsrc
5714: /doc.
1.20 ben 5715:
1.2 hubertf 5716: * cvs commit pkgsrc/doc/guide/files
1.20 ben 5717:
1.6 hubertf 5718: * cvs commit -m re-generate pkgsrc/doc/pkgsrc.{html,txt}
1.20 ben 5719:
1.4 hubertf 5720: * Until the webserver on www.NetBSD.org is really updated automatically to
5721: pick up changes to the pkgsrc guide automatically, also run make
1.18 xtraeme 5722: install-htdocs HTDOCSDIR=../../../htdocs (or similar, adjust HTDOCSDIR!).
1.20 ben 5723:
1.4 hubertf 5724: * cvs commit htdocs/Documentation/pkgsrc
1.20 ben 5725:
CVSweb <webmaster@jp.NetBSD.org>
![[BACK]](/icons/back.gif){kind=icon}
Return to pkgsrc.txt CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [cvs.NetBSD.org] / pkgsrc / doc