pkgsrc/doc/pkgsrc.txt - annotate

Return to pkgsrc.txt CVS log

Up to [cvs.NetBSD.org] / pkgsrc / doc

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

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

CVSweb <webmaster@jp.NetBSD.org>