1 # $NetBSD: Packages.txt,v 1.259 2002/07/29 21:10:18 wiz Exp $
2 ###########################################################################
4 ==========================
7 ==========================
9 Hubert Feyrer, Alistair Crooks
15 Run this command to produce a table of contents:
16 sed '/^.====/{g;p;};h;d' Packages.txt
22 There is a lot of software freely available for Unix based systems, which
23 usually runs on NetBSD, too, sometimes with some modifications. The NetBSD
24 packages collection incorporates any such changes necessary to make that
25 software run on NetBSD, and makes the installation (and re-installation) of
26 the software package easy by means of a single command.
28 The NetBSD package system is used to enable such freely available
29 third-party software to be built easily on NetBSD hosts. Once the software
30 has been built, it is manipulated with the pkg_* tools so that installation
31 and de-installation, printing of an inventory of all installed packages and
32 retrieval of one-line comments or more verbose descriptions are all simple.
34 Both the NetBSD packages collection and the NetBSD package system are
41 This document is divided into two parts. The first, "User's Guide",
42 describes how one can use one of the packages in the Package
43 Collection, either by installing a precompiled binary package, or
44 by building your own copy using the NetBSD package system. The
45 second part, "Package Constructor's Guide", explains how to prepare
46 a package so it can be easily built by other NetBSD users without
47 knowing about the package's building details.
53 There has been a lot of talk about "ports", "packages", etc. so far. Here
54 is a description of all the terminology used within this document:
57 A set of files and building instructions that describe what's necessary
58 to build a certain piece of software using the NetBSD package
59 system. Packages are traditionally stored under /usr/pkgsrc.
61 * The NetBSD package system:
62 This is the part of the NetBSD operating system handling building
63 (compiling), installing, and removing of packages.
66 This term describes the file or files that are provided by the author
67 of the piece of freely available software to distribute his work. All
68 the changes necessary to build on NetBSD are reflected in the
69 corresponding package. Usually the distfile is in the form of a
70 compressed tar-archive, but other types are possible, too. Distfiles
71 are stored below /usr/pkgsrc/distfiles.
74 This is the term used by FreeBSD people for what we call a package.
75 In NetBSD terminology, "port" refers to a different architecture.
77 * Precompiled (binary) package:
78 A set of binaries built by the NetBSD package system from a distfile
79 using the NetBSD package system and stuffed together in a single .tgz
80 file so it can be installed on machines of the same machine architecture
81 without the need to recompile. Packages are generated in
82 /usr/pkgsrc/packages by the NetBSD package system; there is also an
83 archive on ftp.netbsd.org.
85 Sometimes, this is referred to by the term "package" too,
86 especially in the context of precompiled packages.
89 The piece of software to be installed which will be constructed from
90 all the files in the Distfile by the actions defined in the
91 corresponding package.
94 Some files in a package contain RCS IDs to reflect which version of
95 that file this is (inserted automatically by cvs). These IDs are used
96 in several examples within this document, but as this document itself
97 is managed by CVS, it can't list the RCS IDs in plaintext. Instead, the
98 $s are written as <$>, resulting in <$>NetBSD<$> and <$>Id<$>.
104 Right now this document is written in plain ASCII text, and there's not
105 much typography applied here. Future versions may move to something like
106 HTML or DocBook, which have better ways theres.
108 When giving examples for commands, shell prompts are used to show if the
109 command should/can be issued as root, or if "normal" user privileges are
110 sufficient. We use a "#" for root's shell prompt, and a "%" for users'
111 shell prompt, assuming they use the C-shell or tcsh.
118 1 Installing a precompiled binary package
119 =========================================
121 This section describes how to find, retrieve and install a precompiled
122 binary package that someone else already prepared for your type of machine.
128 Precompiled packages are stored on ftp.netbsd.org and its mirrors in the
129 directory /pub/NetBSD/packages for anon FTP access. Please pick the right
130 subdirectory there as indicated by "uname -p". In that directory, there
131 is a subdirectory for each category plus a subdirectory "All" which includes
132 the actual binaries in .tgz-files. The category subdirectories use symbolic
133 links to those files. (This is the same directory layout as in
134 /usr/pkgsrc/packages).
136 This same directory layout applies for CDROM distributions, only that the
137 directory may be rooted somewhere else, probably somewhere below /cdrom.
138 Please consult your CDROM's documentation for the exact location!
144 If you have the files on a CDROM or downloaded them to your hard disk, you
145 can install them with the following command (be sure to su to root first):
147 # pkg_add /path/to/package.tgz
149 If you have FTP access and you don't want to download the packages via FTP
150 prior to installation, you can do this automatically by giving pkg_add an
153 # pkg_add ftp://ftp.netbsd.org/pub/NetBSD/packages/<OS Ver>/<arch>/All/package.tgz
155 If there is any doubt, the uname utility can be used to determine the
156 <OS Ver>, and <arch> by running "uname -rp".
158 Also note that any prerequisite packages needed to run the package in
159 question will be installed, too, assuming they are present where you install
162 After you've installed packages, be sure to have /usr/pkg/bin in your $PATH
163 so you can actually start the just installed program.
166 1.3 A word of warning
167 =====================
169 Please pay very careful attention to the warnings expressed in that manual
170 page about the inherent dangers of installing binary packages which you did
171 not create yourself, and the security holes that can be introduced onto
172 your system by indiscriminate adding of such files.
175 2 Installing by Building
176 ========================
178 This assumes that the package is already part of the NetBSD package system.
179 If it is not, then you are advised to read part II of this document,
180 "Package Constructor's Guide".
186 To build packages from source on a NetBSD system the "comp" and the "text"
187 distribution sets must be installed. If you want to build X11 related
188 packages the "xbase" and "xcomp" distribution sets are required, too.
191 2.2 Where to get pkgsrc
192 =======================
194 There are three ways to get pkgsrc. Either as a tar file, via SUP, or
195 via CVS. All three ways are described here.
197 To get the package source going, you need to get the pkgsrc.tar.gz file
198 from ftp://ftp.netbsd.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz and
199 unpack it into /usr/pkgsrc.
201 As an alternative, you can get pkgsrc via the Software Update Protocol,
202 SUP. To do so, make sure your supfile has a line saying "release=pkgsrc" in
203 it, see the examples in /usr/share/examples/supfiles, and that the
204 directory /usr/pkgsrc does exist. Then, simply start "sup -v
205 /path/to/your/supfile".
207 To get pkgsrc via CVS, make sure you have cvs installed. If not present on
208 your system, it can be found as precompiled binary on ftp.netbsd.org.
209 To do an initial (full) checkout of pkgsrc, do the following steps:
211 % setenv CVSROOT anoncvs@anoncvs.netbsd.org:/cvsroot
214 % cvs checkout -P pkgsrc
216 This will create the "pkgsrc" directory in your /usr, and all the
217 package source will be stored under /usr/pkgsrc. To update pkgsrc
218 after the initial checkout, make sure you have CVS_RSH set as above,
224 Please also note that it is possible to have multiple copies of the
225 pkgsrc hierarchy in use at any one time - all work is done relatively
226 within the pkgsrc tree.
229 2.3 Fetching distfiles
230 ======================
232 There is one gotcha: The distribution file (i.e. the unmodified source)
233 must exist on your system for the packages system to be able to build it.
234 If it does not, then ftp(1) is used to fetch the distribution files
237 You can overwrite some of the major distribution sites to fit to sites
238 that are close to your own. Have a look at
239 pkgsrc/mk/bsd.pkg.defaults.mk to find some examples - in particular,
240 look for the MASTER_SORT, MASTER_SORT_REGEX and INET_COUNTRY
241 definitions. This may save some of your bandwidth and time.
243 You can change these settings either in your shell's environment, or,
244 if you want to keep the settings, by editing the /etc/mk.conf file,
245 and adding the definitions there.
247 If you don't have a permanent Internet connection and you want to know
248 which files to download, "make fetch-list" will tell you what you'll need.
249 Put these distfiles into /usr/pkgsrc/distfiles.
252 2.4 How to build and install
253 ============================
255 Assuming that the distfile has been fetched (see previous section), become
256 root and change into the relevant directory. Then you can type
260 at the shell prompt to build the various components of the package, and
264 at the shell prompt to install the various components into the correct
265 places on your system.
267 Taking the top system utility as an example, we can install it on our
268 system by building as shown in appendix A.1.
270 The program is installed under the default root of the packages tree -
271 /usr/pkg. Should this not conform to your tastes, simply set the LOCALBASE
272 variable in your environment, and it will use that value as the root of
273 your packages tree. So, to use /usr/local, set
277 in your environment. Please note that you should use a root which is
278 dedicated to packages and not shared with other programs (ie, do not try
279 and use LOCALBASE=/usr). Also, you should not try to add any of your
280 own files or directories (such as, for example, src, obj, or pkgsrc) below
281 the LOCALBASE tree. This is to prevent possible conflicts between programs
282 and other files installed by the package system and whatever else may have
283 been installed there.
285 There is, of course, one exception to this - X11 packages are traditionally
286 installed in the X11 tree. The definition used to identify the root of the
287 X11 tree is the X11BASE definition.
289 It is possible to install X11 packages in the LOCALBASE tree, for
290 which you must install the xpkgwedge package
291 (pkgsrc/pkgtools/xpkgwedge) - see section 7.1 for further details.
293 Some packages look in /etc/mk.conf to alter some configuration options
294 at build time. Have a look at pkgsrc/mk/bsd.pkg.defaults.mk to
295 get an overview of what will be set there by default. Environment
296 variables such as LOCALBASE, and X11BASE can be set in /etc/mk.conf to
297 save having to remember to set them each time you want to use pkgsrc.
299 Occasionally, people want to "look under the covers" to see what is
300 going on when a package is building or being installed. This may be
301 for debugging purposes, or out of simple curiosity. A number of utility
302 values have been added to help with this.
304 (1) If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a
305 huge amount of information will be displayed. As a worked example,
307 make patch PKG_DEBUG_LEVEL=2
309 will show all the commands that are invoked, up to and including the
312 (2) If you want to know the value of a certain make(1) definition, then
313 the VARNAME definition should be used, in conjunction with the show-var
316 make show-var VARNAME=DISTFILES
318 will show the expansion of the make(1) variable "DISTFILES".
320 If you want to de-install and re-install a binary package that you've
321 created (see next section), that you put into pkgsrc/packages manually or
322 that's located on a remote FTP server, you can use the the "bin-install"
323 target. This target will install a binary package - if available - via
324 pkg_add, and do a "make package" else. The list of remote FTP sites
325 searched is kept in the variable BINPKG_SITE, which defaults to
326 ftp.netbsd.org. Any flags that should be added to pkg_add(8) can be put
327 into BIN_INSTALL_FLAGS. See pkgsrc/mk/bsd.pkg.defaults.mk for more details.
329 A final word of warning: If you setup a system that has a non-standard
330 setting for LOCALBASE (or X11BASE, for that matter), be sure to set that
331 before any packages are installed, as you can not use several directories
332 for the same purpose. Doing so will result in pkgsrc not being able to
333 properly detect your installed packages, and fail miserably. Note also that
334 precompiled binary packages are usually built with the default LOCALBASE of
335 /usr/pkg, and that you should *not* install any if you use a non-standard
339 3 Making precompiled packages
340 =============================
343 3.1 Packaging a single package
344 ==============================
346 Once you have built and installed the package as mentioned above, you can
347 build it into a "binary package" - you might want to do this so that you
348 can use the binaries you have just built on another NetBSD system, or to
349 provide a simple means for others to use your binary package instead of
350 wasting CPU time - this is done by changing to the appropriate directory in
351 the pkgsrc tree, and typing the command
355 at the shell prompt. This will build and install your package (if not
356 already done), and then construct a binary package out of the results so
357 that you can use the pkg_* tools to manipulate this. The binary package is
358 stored under /usr/pkgsrc/packages, it's in the form of a gzipped file at
359 the present time. See appendix A.2 for a continuation of the above top
362 Please see the "submitting" section later in this document on how to submit
363 such a binary package.
366 3.2 Doing a bulk build of all packages
367 ======================================
369 If you want to get a full set of precompiled binary packages, this section
370 describes how to get them. Beware that the bulk build will remove all
371 currently installed packages from your your system! Having a FTP server
372 configured either on the machine doing the bulk builds or on a nearby NFS
373 server can help to make the packages available to everyone. See ftpd(8) for
374 more information. If you use a remote NFS server's storage, be sure to not
375 actually compile on NFS storage, as this slows things down a lot.
384 You may want to set things in /etc/mk.conf. Look at
385 pkgsrc/mk/bsd.pkg.defaults.mk for details of the default settings.
386 You will want to make sure that ACCEPTABLE_LICENSES meet your local
389 PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
390 WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
392 BSDXSRCDIR= /usr/xsrc # for x11/xervers
393 OBJHOSTNAME?= yes # use work.`hostname`
394 FAILOVER_FETCH= yes # insist on the correct checksum
398 If you wish to use xpkgwedge for the entire build, then add:
400 BULK_PREREQ+= pkgtools/xpkgwedge
402 Other packages which must be installed during the bulk build to modify the
403 build behaviour may be added to the BULK_PREREQ variable. Note that currently
404 the only package for which BULK_PREREQ makes sense is xpkgwedge.
409 In pkgsrc/mk/bulk, copy ``build.conf-example'' to ``build.conf'' and
410 edit it, following the comments in that file. This is the config
411 file that determines where log files are generated after the build,
412 where to mail the build report, where your pkgsrc is located and
413 which user to su(8) to to do a 'cvs update'.
415 3.2.1.3 pre-build.local
416 =======================
418 It is possible to configure the bulk build to perform certain site
419 specific tasks at the end of the pre-build stage. If the file
420 ``pre-build.local'' exists in pkgsrc/mk/bulk it will be executed
421 (as a sh(1) script) at the end of the usual pre-build stage. An
422 example use of pre-build.local is to have the line:
424 # echo "I do not have enough disk space to build this pig." \
425 > pkgsrc/games/crafty-book-enormous/$BROKENF
427 to prevent the system from trying to build a particular package
428 which requires nearly 3 Gb of disk space.
430 3.2.2 Other environmental considerations
431 ========================================
433 As /usr/pkg will be completely deleted at the start of bulk builds,
434 make sure your login shell is placed somewhere else. Either drop it into
435 /usr/local/bin (and adjust your login shell in the password file), or
436 (re-)install it via pkg_add from /etc/rc.local, so you can login after a
437 reboot (remember that your current process won't die if the package is
438 removed, you just can't start any new instances of the shell any more).
439 Also, if you use a OS version below 1.5 or you still want to use the
440 pkgsrc version of ssh for some reason, be sure to install ssh before
441 starting it from rc.local:
443 ( cd /usr/pkgsrc/security/ssh ; make bulk-install )
444 if [ -f /usr/pkg/etc/rc.d/sshd ]; then
445 /usr/pkg/etc/rc.d/sshd
448 Not doing so will result in you being not able to log in via ssh
449 after the bulk build is finished or if the machine gets rebooted
450 or crashes. You have been warned! :)
456 Make sure you don't need any of the packages still installed.
457 BEWARE: During the bulk build, ALL packages will be removed!!!
458 Be sure to remove all other things that might interfere with builds, like
459 some libs installed in /usr/local, etc. then become root and type:
464 If for some reason your last build didn't complete (power failure,
465 system panic, ...), you can continue it by running:
467 # sh mk/bulk/build restart
469 At the end of the bulk run, you will get a summary via mail, and find
470 build logs in the directory specified by "FTP" in the "build.conf"
477 The bulk builds consist of three steps:
479 1. pre-build: The script updates your pkgsrc via (anon)cvs, then cleans
480 out any broken distfiles, and removes all packages installed.
482 2. the bulk build: This is basically 'make bulk-package' with an optimised
483 order in which packages will be built. Packages that don't require
484 other packages will be built first, and packages with many depends
487 3. post-build: Generates a report that's placed in the directory specified
488 in the build.conf file named ``broken.html'', a short version of
489 that report will also be mailed to the build's admin.
491 During the build, a list of broken packages will be compiled in
492 /usr/pkgsrc/.broken (or .../.broken.${MACHINE} if OBJMACHINE is set),
493 individual build logs of broken builds can be found in the package's
494 directory. These files are used by the bulk-targets to mark broken builds
495 to not waste time trying to rebuild them, and they can be used to debug
496 these broken package builds later.
499 3.2.5 Disk space requirements
500 =============================
502 Currently, roughly the following requirements are valid for
505 * Distfiles: 1500MB (NFS ok)
506 * Full set of all binaries: 1000MB (NFS ok)
507 * Temp space for compiling: 1500MB (local disk recommended)
511 * Full set of all binaries: 1300MB (NFS ok)
513 Note that all pkgs will be de-installed as soon as they are turned into a
514 binary package, and that work-sources are removed, so there is no huge
515 demand to disk space. Afterwards, if the package is needed again, it will
516 be installed via pkg_add instead of building again, so there are no cycles
517 wasted by recompiling.
520 3.2.6 Setting up a sandbox for chroot'ed builds
521 ===============================================
523 If you don't want all the pkgs nuked from a machine (rendering it useless
524 for anything but pkg compiling), there is the possibility of doing the pkg
525 bulk build inside a chroot environment.
527 The first step to do so is setting up a chroot sandbox, e.g. /usr/sandbox.
528 After extracting all the sets from a NetBSD installation or doing a
529 "make distribution DESTDIR=/usr/sandbox" in src/etc, make sure the following
530 items are present and properly configures:
533 cp /netbsd /usr/sandbox
535 cd /usr/sandbox/dev ; sh MAKEDEV all
536 * /etc/resolv.conf (for security/snmpd and mail):
537 cp /etc/resolv.conf /usr/sandbox/etc
538 * working(!) mail config (hostname, sendmail.cf):
539 cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
540 * /etc/localtime (for security/snmpd):
541 ln -sf /usr/share/zoneinfo/GMT /usr/sandbox/etc/localtime
542 * /usr/src (system sources, for sysutils/aperture, net/ppp-mppe):
544 ln -s cvs/src-1.6 src
546 * create /var/db/pkg (not part of default install):
547 mkdir /usr/sandbox/var/db/pkg
548 * create /usr/pkg (not part of default install)
549 mkdir /usr/sandbox/usr/pkg
550 * checkout pkgsrc from cvs, into /usr/sandbox/usr/pkgsrc
551 cvs -d cvs.netbsd.org:/cvsroot co pkgsrc
552 * /usr/pkgsrc/packages & .../distfiles (point outside of sandbox)
553 * /etc/mk.conf, see 3.2.1.1
554 * adjust .../mk/bulk/build.conf
556 !!! Don't forget to install X !!!
557 If you are a developer and want to upload the resulting binary packages
558 to ftp.netbsd.org, make sure you are using the default X version for your
559 architecture and release (up to 1.6, that is 3.3.6 for all architectures).
561 Next thing you will want to is make sure /usr/sandbox/usr/pkgsrc contains a
562 fresh checkout of pkgsrc (e.g. from anoncvs). Do not mount/link this to the
563 copy of your pkgsrc tree you do development in, as this will likely cause
564 problems! Adjust .../pkgsrc/packages and .../pkgsrc/distfiles to point to
565 some places outside the sandbox if you want to make the files public.
567 Then, configure .../pkgsrc/mk/bulk/build.conf to fit your needs!
569 When the chroot sandbox is setup, you can start the build with the following
572 # cd /usr/sandbox/usr/pkgsrc
573 # sh mk/bulk/do-sandbox-build
575 This will just jump inside the sandbox and start thrash^Wbuilding.
576 At the end of the build, mail will be sent with the results of the build.
577 Created binary pkgs will be in /usr/sandbox/usr/pkgsrc/packages (whereever
578 that points/mounts to/from).
581 3.3 Creating a multiple CD-ROM packages collection
582 ==================================================
584 After your bulk pkgsrc build has completed, you may wish to create a CD-ROM
585 set of the resulting binary packages to assist in installing packages on
586 other machines. The package pkgsrc/pkgtools/cdpack provides a simple tool for
587 creating the ISO 9660 images. `cdpack' arranges the packages on the CD-ROM's
588 in a way that keeps all the dependencies for given package on the same
592 3.3.1 Example of cdpack
593 =======================
595 Complete documentation for cdpack is found in cdpack(1). The following
596 short example assumes that the binary packages are left in
597 /usr/pkgsrc/packages/All and that sufficient disk space exists in /u2
598 to hold the ISO 9660 images.
601 # pkg_add /usr/pkgsrc/packages/All/cdpack
602 # cdpack /usr/pkgsrc/packages/All /u2/images
604 If you wish to include a common set of files (COPYRIGHT, README, etc)
605 on each CD in the collection, then you need to create a directory which
606 contains these files. For example
609 # echo "This is a README" > /tmp/commmon/README
610 # echo "Another file" > /tmp/common/COPYING
611 # mkdir /tmp/common/bin
612 # echo "#!/bin/sh" > /tmp/common/bin/myscript
613 # echo "echo Hello world" >> /tmp/common/bin/myscript
614 # chmod 755 /tmp/common/bin/myscript
616 Now create the images with
618 # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
620 and each image will contain "README", "COPYING", and "bin/myscript"
621 in their root directories.
624 ====================================
625 Part II: Package Constructor's Guide
626 ====================================
628 4 Package components - files, directories and contents
629 ======================================================
631 Whenever you're preparing a package, there are a number of files involved
632 which are described in the following sections.
638 Building, installation and creation of a binary package are all controlled
639 by the package's Makefile.
641 There is a Makefile for each package. This file includes the standard
642 bsd.pkg.mk file (referenced as "../../mk/bsd.pkg.mk"), which sets all the
643 definitions and actions necessary for the package to compile and install
644 itself. The mandatory fields are the DISTNAME which specifies the base name
645 of the distribution file to be downloaded from the site on the Internet,
646 MASTER_SITES which specifies that site, CATEGORIES which denotes the
647 categories into which the package falls, PKGNAME which is the name of the
648 package, the MAINTAINER name, and the COMMENT variable, which should
649 contain a one-line description of the package (the package name should not
650 appear, it will be added automatically). The maintainer variable is there
651 so that anyone who quibbles with the (always completely correct) decisions
652 taken by the guy who maintains the port can complain vigorously.
654 The MASTER_SITES may be set to one of the predefined sites:
656 ${MASTER_SITE_XCONTRIB}
658 ${MASTER_SITE_PERL_CPAN}
659 ${MASTER_SITE_TEX_CTAN}
660 ${MASTER_SITE_SUNSITE}
662 ${MASTER_SITE_SOURCEFORGE}
664 If one of these predefined sites is chosen, you may require the ability to
665 specify a subdirectory of that site. Since these macros may expand to
666 more than one actual site, you MUST use the following construct to specify
669 ${MASTER_SITE_GNU:=subdirectory/name/}
671 (Note the trailing slash after the subdirectory name.) Use of the deprecated
672 MASTER_SITE_SUBDIR will not work.
674 If the package has multiple DISTFILES or multiple PATCHFILES from different
675 sites, set SITES_foo to a list of URI's where file "foo" may be found. "foo"
676 includes the suffix, e.g.
678 DISTFILES=${DISTNAME}${EXTRACT_SUFX}
679 DISTFILES+=foo-file.tar.gz
680 SITES_foo-file.tar.gz=http://www.somewhere.com/somehow/ \
681 http://www.somewhereelse.com/mirror/somehow/
683 Note, that the normal default setting of DISTFILES must be made explicit
684 if you want to add to it (rather than replace it), as you usually would.
686 Currently the following values are available for CATEGORIES. If more than
687 one is used, they need to be separated by spaces:
689 archivers audio benchmarks biology cad
690 chat comms converters cross databases
691 devel editors emulators finance fonts
692 games graphics ham japanese lang
693 mail math mbone misc net
694 news parallel print security shells
695 sysutils textproc time wm www
698 See the NetBSD packages(7) manual page for a description of all available
699 options and variables.
701 Please pay attention to the following gotchas:
703 - Add MANCOMPRESSED (if not already there) if manpages are installed in
704 compressed form by the package; see comment in bsd.pkg.mk
705 - Replace /usr/local by ${PREFIX} in all files (see patches below)
706 - If the package installs any info files, see the section `Packages providing
707 info files' in this document.
708 - Adjust MAINTAINER to be either yourself, if you plan to maintain the
709 package for future updates, or set it to the default MAINTAINER
711 - If there exists a home page for the software in question, please
712 add the variable HOMEPAGE right after MAINTAINER. The value of this
713 variable should be the URL for the home page.
714 - Please also set the COMMENT variable to a short description of the
721 Most important, the mandatory message digest, or checksum, of all the
722 distfiles needed for the package to compile, confirming they match the
723 original file distributed by the author. This ensures that the
724 distfile retrieved from the Internet has not been corrupted during
725 transfer or altered by a malign force to introduce a security hole.
726 It is best generated using the "make makesum" command. The digest
727 algorithm used was, at one stage, md5, but that was felt lacking
728 compared to sha1, and so sha1 is now the default algorithm. The
729 distfile size is also generated and stored in new distinfo files.
730 The pkgsrc/pkgtools/digest utility calculates all of the digests
731 in the distinfo file, and it provides various different algorithms.
732 At the current time, the algorithms provided are:
734 md5, rmd160, sha1, sha256, sha384 and sha512
736 Some packages have different sets of distfiles on a per architecture
737 basis. (A good example is pkgsrc/www/navigator). These are kept in the
738 same distinfo file and care should be taken when upgrading such a
739 package to ensure distfile information is not lost.
741 The message digest/checksum for all the official patches found in the
742 patches/ directory (see section 4.3) for the package is also stored in
743 the distinfo file. This is a message digest/checksum of all lines in
744 the patch file except the NetBSD RCS Id. This file is generated by
745 invoking "make makepatchsum".
751 This directory contains files that are used by the patch(1) command to
752 modify the sources as distributed in the distribution file into a form that
753 will compile and run perfectly on NetBSD. The files are applied
754 successively in alphabetic order (as returned by a shell "patches/patch-*"
755 glob expansion), so patch-aa is applied before patch-ab etc.
757 The patch-?? files should be in "diff -bu" format, and apply without
758 a fuzz to avoid problems (To force patches to apply with fuzz you
759 can set PATCH_FUZZ_FACTOR=-F2). Furthermore, do not put changes
760 for more than one file into a single patch-file, as this will make
761 future modifications more difficult.
763 Similar, a file should be patched at most once, not several times by
764 several different patches. If a file needs several patches, they should
765 be combined into one file.
767 One important thing to mention is to pay attention that no RCS IDs
768 get stored in the patch files, as these will cause problems when
769 later checked into the NetBSD CVS tree. To avoid this, use either
770 the "-U 2" or "-U 1" option to diff, or let the 'pkgdiff' command
771 from pkgsrc/pkgtools/pkgdiff help you.
773 If you don't want to worry about the problems in the last two paragraphs
774 yourself, use pkgdiff from the pkgsrc/pkgtools/pkgdiff package, which takes
775 care of any RCS Ids by itself.
777 For even more automation, we recommend using mkpatches from the same
778 package to make a whole set of patches. You just have to backup files
779 before you edit them to "filename.orig", e.g. with "cp -p filename
780 filename.orig" or, easier, by using pkgvi from the same package. If you
781 upgrade a package this way, you can easily compare the new set of patches
782 with the previously existing one with patchdiff.
784 When you have finished a package, remember to generate the checksums
785 for the patch files by using the "make makepatchsum" command, see
788 If it is desired to store any patches that should not be committed into
789 pkgsrc, they can be kept outside the pkgsrc tree in the $LOCALPATCHES
790 directory. The directory tree there is expected to have the same
791 "category/package" structure as pkgsrc, and patches are expected to be
792 stored inside these dirs (also known as $LOCALPATCHES/$PKGPATH). For
793 example if you want to keep a private patch for pkgsrc/graphics/png, keep
794 it in $LOCALPATCHES/graphics/png/mypatch. All files in the named directory
795 are expected to be patch files, and they are applied after the "normal"
796 pkgsrc patches are applied.
799 4.4 Other mandatory files
800 =========================
803 A multi-line description of the piece of software. This should include
804 any credits where they are due. Please bear in mind that others do not
805 share your sense of humour (or spelling idiosyncrasies), and that others
806 will read everything that you write here.
809 This file governs the files that are installed on your system: all the
810 binaries, manual pages, etc. There are other directives which may be
811 entered in this file, to control the creation and deletion of
812 directories, and the location of inserted files.
819 Shell script invoked twice during pkg_add. First time after package
820 extraction and before files are moved in place, the second time after
821 the files to install are moved in place. This can be used to do any
822 custom procedures not possible with @exec commands in PLIST. See
823 pkg_add(1) and pkg_create(1) for more information.
826 This script is executed before and after any files are removed. It is
827 this script's responsibility to clean up any additional messy details
828 around the package's installation, since all pkg_delete knows is how to
829 delete the files created in the original distribution. See pkg_delete(1)
830 and pkg_create(1) for more information.
833 Display this file after installation of the package.
834 Useful for things like legal notices on almost-free software, etc.
835 Please note that you can modify variables in it easily by using
836 MESSAGE_SUBST in the package's Makefile:
838 MESSAGE_SUBST+= SOMEVAR="somevalue"
844 in MESSAGE with "somevalue" before displaying the message.
850 When you type "make" the distribution files are unpacked into this
851 directory. It can be removed by typing
855 at the shell prompt. Also, this directory is used to keep various
862 If you have any files that you wish to be placed in the package prior
863 to configuration or building, you could place these files here and use
864 a ${CP} command in the pre-configure target to achieve this.
865 Alternatively, you could simply diff the file against /dev/null and
866 use the patch mechanism to manage the creation of this file.
872 This section addresses some special issues that one needs to pay attention
873 to when dealing with the PLIST file (or files, see below!).
880 Be sure to add a RCS ID line as the first thing in any PLIST file you
883 @comment <$>NetBSD<$>
885 * ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}:
886 Some packages like emacs and perl embed information about which
887 architecture they were built on into the pathnames where they install
888 their file. To handle this case, PLIST will be preprocessed before
889 actually used, and the symbol "${MACHINE_ARCH}" will be replaced by
890 what "uname -p" gives. The same is done if the string ${MACHINE_GNU_ARCH}
891 is embedded in PLIST somewhere - use this on packages that have GNU
892 autoconf created configure scripts.
894 Legacy note: There used to be a symbol "<$ARCH>" that was replaced by
895 the output of "uname -m", but that's no longer supported and has been
898 * ${OPSYS}, ${OS_VERSION}:
899 Some packages want to embed the OS name and version into some paths.
900 to do this, use these two variables in PLIST. ${OPSYS} will be replaced
901 by output from "uname -s", ${OS_VERSION} will be set to what "uname -r"
905 Packages that install locale files should list them in the PLIST as
906 "${PKGLOCALEDIR}/locale/de/LC_MESSAGES/..." instead of
907 "share/locale/de/LC_MESSAGES/...". This properly handles the fact that
908 different OSes expect locale files to be either in "share" or "lib" by
911 * Manpage-compression:
912 Manpages should be installed in compressed form if MANZ is set (in
913 bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST
914 file, the suffix ".gz" is appended/removed automatically for manpages
915 according to MANZ and MANCOMPRESSED being set or not, see above for
916 details. This modification of the PLIST file is done on a copy of it,
919 * Semi-automatic PLIST generation:
920 You can use the "make print-PLIST" command to output a PLIST that matches
921 any new files since the package was extracted. See below for more
922 information on this target.
928 To use one or more files as source for the PLIST used in generating the
929 binary package, set the variable PLIST_SRC to the names of that file(s).
930 The files are later concatenated using cat(1), and order of things is
936 Similar to MESSAGE_SUBST (see above), you can add variables and their
937 expansions to this variable in the following way:
939 PLIST_SUBST+= SOMEVAR="somevalue"
941 which replaces all occurrences of ${SOMEVAR} in the PLIST with "somevalue".
942 For the values which are replaced by default, please look in bsd.pkg.mk
943 (and search for PLIST_SUBST).
948 Perl5 modules will install into different places depending on the version
949 of perl used during the build process. To address this, the NetBSD
950 packages system will append lines to the PLIST corresponding to the files
951 listed in the installed .packlist file generated by most perl5 modules.
952 This is invoked by defining PERL5_PACKLIST to a space-separated list of
953 paths to packlist files:
955 PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
957 The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent
958 the three locations in which perl5 modules may be installed, and may be
959 used by perl5 packages that don't have a packlist. These three variables
960 are also substituted for in the PLIST.
965 Occasionally, packages require interaction from the user, and this can be
968 + help in fetching the distfiles
969 + help to configure the package before it is built
970 + help during the build process
971 + help during the installation of a package
973 The INTERACTIVE_STAGE definition is provided, to notify the pkgsrc mechanism
974 of an interactive stage which will be needed, and this should be set in the
975 package's Makefile. e.g.
977 INTERACTIVE_STAGE= build
979 Multiple interactive stages can be specified:
981 INTERACTIVE_STAGE= configure install
984 6 Notes on fixes for packages
985 =============================
990 To port an application to NetBSD, it's usually necessary for the compiler
991 to be able to judge the system on which it's compiling, and we use
992 definitions so that the C pre-processor can do this.
994 To test whether you are working on a 4.4 BSD-derived system, you should use
995 the BSD definition, which is defined in <sys/param.h> on said systems.
997 #include <sys/param.h>
999 and then you can surround the BSD-specific parts of your port using the
1002 #if (defined(BSD) && BSD >= 199306)
1006 Please use the __NetBSD__ definition sparingly - it should only apply to
1007 features of NetBSD that are not present in other 4.4-lite derived BSDs.
1009 6.2 Shared libraries - libtool
1010 ==============================
1012 Pkgsrc supports many different machines, with different object formats
1013 like a.out and ELF, and varying abilities to do shared library and
1014 dynamic loading at all. To accompany this, varying commands and options
1015 have to be passed to the compiler, linker etc. to get the Right Thing,
1016 which can be pretty annoying especially if you don't have all the
1017 machines at your hand to test things. The "libtool" pkg can help
1018 here, as it just "knows" how to build both static and dynamic
1019 libraries from a set of source files, thus being platform
1022 Here's how to use libtool in a pkg in seven simple steps:
1024 1. Add USE_LIBTOOL= yes to the package Makefile.
1026 2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of
1027 ${CC}. You could even add it to the definition of CC, if only
1028 libraries are being built in a given Makefile. This one command will
1029 build both PIC and non-PIC library objects, so you need not have
1030 separate shared and non-shared library rules.
1032 3. For the linking of the library, remove any "ar", "ranlib", and "ld
1033 -Bshareable" commands, and use instead:
1035 ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor
1037 Note that the library is changed to have a .la extension, and the
1038 objects are changed to have a .lo extension. Change OBJS as necessary.
1039 This automatically creates all of the .a, .so.major.minor, and ELF
1040 symlinks (if necessary) in the build directory. Be sure to include
1041 the -version-info especially when major and minor are zero, as libtool
1042 will otherwise strip off the shared library version.
1044 The "-release" option will produce different results for a.out and ELF
1045 (excluding symlinks) in only one case. An ELF library of the form
1046 libfoo-release.so.x.y will have a symlink of libfoo.so.x.y on an a.out
1047 platform. This is handled automatically.
1049 The -rpath argument is the install directory of the library being built.
1051 PLIST should include all of the .a, .la and so, .so.major and
1052 .so.major.minor entries.
1054 4. When linking shared object (.so) files, i.e. files that are loaded via
1055 dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
1056 them getting version tacked on.
1058 PLIST gets the foo.so entry.
1060 5. When linking programs that depend on these libraries _before_ they are
1061 installed, preface the cc or ld line with "${LIBTOOL} --mode=link", and
1062 it will find the correct libraries (static or shared), but please be
1063 aware that libtool will not allow you to specify a relative path in -L
1064 (such as -L../somelib), because it expects you to change that argument
1065 to be the .la file. For example:
1067 ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
1069 should be changed to:
1071 ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
1073 and it will DTRT with the libraries.
1075 6. When installing libraries, preface the install or cp command with
1076 "${LIBTOOL} --mode=install", and change the library name to .la. For
1079 ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
1081 This will install the static .a, shared library, any needed symlinks,
1084 7. In your PLIST, include all of the .a, .la, and so, .so.major and
1085 .so.major.minor files (this is a change from the previous behaviour).
1088 6.3 Using libtool on GNU packages that already support libtool
1089 ==============================================================
1091 Add USE_LIBTOOL=yes and LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig to the package
1092 Makefile as the quick way to bypass the pkg's own libtool. The pkg's own
1093 libtool is made by ltconfig script at do-configure target. If USE_LIBTOOL
1094 and LTCONFIG_OVERRIDE are defined, the specified ltconfig is overridden,
1095 using the pkgsrc/devel/libtool instead of the pkg's own libtool. For newer
1096 versions of libtool (without ltconfig) it may be necessary to use
1097 LIBTOOL_OVERRIDE=${WRKSRC}/libtool instead.
1099 If your package makes use of the platform independent library for loading
1100 dynamic shared objects, that comes with libtool (libltdl), you should
1101 add USE_LTDL= yes to the Makefile.
1103 Some packages use libtool incorrectly so that the package may not work or
1104 build in some circumstances. Some common errors are
1106 * The inclusion of a shared object (-module) as a dependent library in an
1107 executable or library. This in itself isn't a problem if one of two things
1110 1. The shared object is named correctly, i.e. libfoo.la and not foo.la
1112 2. The -dlopen option is used when linking an executable.
1114 * The use of libltdl without the correct calls to initialisation routines.
1115 The function lt_dlinit() should be called and the macro
1116 LTDL_SET_PRELOADED_SYMBOLS included in executables.
1119 6.4 GNU Autoconf/Automake
1120 =========================
1122 If a package needs GNU autoconf or automake to be executed to regenerate
1123 the configure script and Makefile.in makefile templates, then they should
1124 be executed in a pre-configure target. For packages that need only
1128 cd ${WRKSRC}; ${LOCALBASE}/bin/autoconf
1130 and for packages that need automake and autoconf:
1134 ${LOCALBASE}/bin/aclocal; \
1135 ${LOCALBASE}/bin/autoheader; \
1136 ${LOCALBASE}/bin/automake -a --foreign -i; \
1137 ${LOCALBASE}/bin/autoconf
1139 There are times when the configure process makes additional changes to the
1140 generated files, which then causes the build process to try to re-execute
1141 the automake sequence. This is prevented by touching various files in
1142 the configure stage. If this causes problems with your package you can set
1143 AUTOMAKE_OVERRIDE to NO in the package Makefile.
1146 6.5 Package configuration files
1147 ===============================
1149 Packages should be taught to look for their configuration files in
1150 ${PKG_SYSCONFDIR}, which is passed through to the configure and build
1151 processes. PKG_SYSCONFDIR may be customized in various ways by setting
1152 other make variables:
1154 * PKG_SYSCONFBASE is the main config directory under which all package
1155 configuration files are to be found. This defaults to ${PREFIX}/etc, but
1156 may be overridden in /etc/mk.conf.
1158 * PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which the
1159 configuration files for a particular package may be found, e.g. the
1160 Apache configuration files may all be found under the "httpd" subdirectory
1161 of ${PKG_SYSCONFBASE}.
1163 * PKG_SYSCONFDIR.${PKGBASE} overrides the value of ${PKG_SYSCONFDIR} for a
1164 particular package. This is not meant to be set by a package Makefile, but
1165 is reserved for users who wish to override the PKG_SYSCONFDIR setting for
1166 a particular package with a special location.
1168 Users will typically want to set PKG_SYSCONFBASE to /etc, or to accept the
1169 default location of ${PREFIX}/etc.
1172 6.6 Feedback to the author
1173 ==========================
1175 If you have found any bugs in the package you make available, if you had to
1176 do special steps to make it run under NetBSD or if you enhanced the software
1177 in various other ways, be sure to report these changes back to the original
1178 author of the program! With that kind of support, the next release of the
1179 program can incorporate these fixes, and people not using the NetBSD packages
1180 system can win from your efforts.
1182 Support the idea of free software!
1188 The basic steps for building a program are always the same. First the
1189 program's source (distfile) must be brought to the local system and
1190 then extracted. After any patches to compile properly on NetBSD are
1191 applied, the software can be configured, then built (usually by
1192 compiling), and finally the generated binaries etc. can be put into
1193 place on the system. These are exactly the steps performed by the
1194 NetBSD package system, which is implemented as a series of targets in
1195 a central Makefile, pkgsrc/mk/bsd.pkg.mk.
1198 7.1 Program location
1199 ====================
1201 Before outlining the process performed by the NetBSD package system in the
1202 next section, here's a brief discussion on where programs are installed,
1203 and which variables influence this.
1205 The automatic variable PREFIX indicates where all files of the final
1206 program shall be installed. It is usually set to $LOCALBASE (/usr/pkg),
1207 or $CROSSBASE for pkgs in the "cross" category, though its value becomes
1208 that of $X11BASE if USE_IMAKE or USE_X11BASE is set. The value ${PREFIX}
1209 needs to be put into the various places in the program's source where paths
1210 to these files are encoded; see sections 4.3 and 6.2 for details on this.
1212 When choosing which of these variables to use, follow the following rules:
1214 * ${PREFIX} always points to the location where the current pkg will be
1215 installed. When referring to a pkg's own installation path, use ${PREFIX}.
1217 * ${LOCALBASE} is where all non-X11 pkgs are installed. If you need to
1218 construct a -I or -L argument to the compiler to find includes and
1219 libraries installed by another non-X11 pkg, use ${LOCALBASE}.
1221 * ${X11BASE} is where the actual X11 distribution (from xsrc etc.) is installed.
1222 When looking for _standard_ X11 includes (not those installed by a pkg), use
1225 * X11 based pkgs are special in that they may be installed in either
1226 X11BASE or LOCALBASE. To install X11 packages in LOCALBASE, simply
1227 install the xpkgwedge package (pkgsrc/pkgtools/xpkgwedge).
1228 If you need to find includes or libraries installed by a pkg that has
1229 USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to use _both_
1230 ${X11BASE} and ${LOCALBASE}.
1232 * ${X11PREFIX} should be used to refer to the installed location of an X11
1233 package. X11PREFIX will be set to ${X11BASE} if xpkgwedge is not installed,
1234 and to ${LOCALBASE} if xpkgwedge is installed.
1236 * If xpkgwedge is installed, it is possible to have some packages installed in
1237 X11BASE and some in LOCALBASE. To determine the prefix of an installed
1238 package, the EVAL_PREFIX definition can be used. It takes pairs in the
1239 format DIRNAME=<package>, and the make(1) variable DIRNAME will be set
1240 to the prefix of the installed package <package>, or ${X11PREFIX} if the
1241 package is not installed.
1243 This is best illustrated by example.
1245 The following lines are taken from pkgsrc/wm/scwm/Makefile:
1247 EVAL_PREFIX+= GTKDIR=gtk+
1248 CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \
1249 --with-gtk-prefix="${GTKDIR}" \
1252 Specific defaults can be defined for the packages evaluated using
1253 EVAL_PREFIX, by using a definition of the form:
1255 GTKDIR_DEFAULT= ${LOCALBASE}
1257 where "GTKDIR" corresponds to the first definition in the EVAL_PREFIX pair.
1262 The main targets used during the build process defined in bsd.pkg.mk are:
1265 This will check if the file(s) given in the variables DISTFILES and
1266 PATCHFILES (as defined in the package's Makefile) are present on the
1267 local system in /usr/pkgsrc/distfiles. If they are not present, an
1268 attempt will be made to fetch them using commands of the form
1270 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
1272 where ${site} varies through several possibilities in turn: first,
1273 ${MASTER_SITE_OVERRIDE} is tried, then the sites specified in either
1274 ${SITES_file}, if defined, else ${MASTER_SITES} or ${PATCH_SITES}, as
1275 applies, then finally the value of ${MASTER_SITE_BACKUP}. The order of
1276 all except the first can be optionally sorted by the user, via setting
1277 either ${MASTER_SORT_AWK} or ${MASTER_SORT_REGEX}.
1280 After the distfile(s) are fetched, their checksum is generated and
1281 compared with the checksums stored in the distinfo file. If the
1282 checksums don't match, the build is aborted. This is to ensure the same
1283 distfile is used for building, and that the distfile wasn't changed,
1284 e.g. by some malign force, deliberately changed distfiles on the master
1285 distribution site or network lossage.
1288 When the distfiles are present on the local system, they need to be
1289 extracted, as they are usually in the form of some compressed archive
1290 format, most commonly .tar.gz. If only some of the distfiles need to be
1291 uncompressed, the files to be uncompressed should be put into
1292 EXTRACT_ONLY. If the distfiles are not in .tar.gz format, they can be
1293 extracted by setting EXTRACT_CMD, EXTRACT_BEFORE_ARGS and/or
1297 After extraction, all the patches named by the PATCHFILES, those present
1298 in the patches subdirectory of the package as well as in
1299 $LOCALPATCHES/$PKGPATH (e.g. /usr/local/patches/graphics/png) are
1300 applied. Patchfiles ending in .Z or .gz are uncompressed before they are
1301 applied, files ending in .orig or .rej are ignored. Any special options
1302 to patch(1) can be handed in PATCH_DIST_ARGS. See section 4.3 for more
1305 By default patch is given special args to make it fail if the
1306 patches with some lines of fuzz. Please fix (regen) the patches
1307 so that they apply cleanly. The rationale behind this is that
1308 patches that apply cleanly may end up being applied in the wrong
1309 place, and cause severe harm there.
1312 Most pieces of software need information on the header files,
1313 system calls, and library routines which are available in NetBSD.
1314 This is the process known as configuration, and is usually
1315 automated. In most cases, a script is supplied with the source,
1316 and its invocation results in generation of header files,
1319 If the program's distfile contains its own configure script, this can
1320 be invoked by setting HAS_CONFIGURE. If the configure script is a GNU
1321 autoconf script, GNU_CONFIGURE should be specified instead. In either
1322 case, any arguments to the configure script can be specified in the
1323 CONFIGURE_ARGS variable, and the configure script's name can be set in
1324 CONFIGURE_SCRIPT if it differs from the default "configure".
1326 If the program uses an Imakefile for configuration, the appropriate
1327 steps can be invoked by setting USE_IMAKE to YES. (If you only want the
1328 package installed in $X11PREFIX but xmkmf not being run, set USE_X11BASE
1332 Once configuration has taken place, the software can be built on
1333 NetBSD by invoking $MAKE_PROGRAM on $MAKEFILE with $ALL_TARGET as
1334 the target to build. The default MAKE_PROGRAM is "gmake" if
1335 USE_GMAKE is set, "make" otherwise. MAKEFILE is set to "Makefile"
1336 by default, and ALL_TARGET defaults to "all". Any of these
1337 variables can be set to change the default build process.
1340 Once the build stage has completed, the final step is to install
1341 the software in public directories, for users. As in the
1342 build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but with
1343 the $INSTALL_TARGET instead, the latter defaulting to "install"
1344 (plus "install.man", if USE_IMAKE is set).
1346 If no target is specified, the default is "build". If a subsequent stage
1347 is requested, all prior stages are made: e.g. "make build" will also
1348 perform the equivalent of:
1358 7.3 Other helpful targets
1359 =========================
1362 For any of the main targets described in the previous section, two
1363 auxiliary targets exist with "pre-" and "post-" used as a prefix
1364 for the main target's name. These targets are invoked before and
1365 after the main target is called, allowing extra configuration or
1366 installation steps, for example, which program's configure script
1367 or install target omitted.
1370 Should one of the main targets do the wrong thing, and should there
1371 be no variable to fix this, you can redefine it with the do-*
1372 target. (Note that redefining the target itself instead of the
1373 do-* target is a bad idea, as the pre-* and post-* targets won't be
1374 called anymore, etc.) You will not usually need to do this.
1377 If you did a "make install" and you noticed some file was not installed
1378 properly, you can repeat the installation with this target, which will
1379 ignore the "already installed" flag.
1382 This target does a pkg_delete(1) in the current directory,
1383 effectively de-installing the package. The following variables can
1384 be used either on the command line or in /etc/mk.conf to tune the
1388 Add a "-v" to the pkg_delete(1) command.
1391 Remove all packages that require (depend on) the given package.
1392 This can be used to remove any packages that may have been pulled in
1393 by a given package, e.g. if "make deinstall DEINSTALLDEPENDS=1" is
1394 done in pkgsrc/x11/kde, this is likely to remove whole KDE. Works by
1395 adding a "-R" to the pkg_delete command line.
1398 This target causes the current package to be updated to the latest
1399 version. The package and all depending packages first get de-installed,
1400 then current versions of the corresponding packages get compiled and
1401 installed. This is similar to manually noting which packages are
1402 currently installed, then performing a series of "make deinstall" and
1403 "make install" (or whatever UPDATE_TARGET is set to) for these packages.
1405 You can use the "update" target to resume package updating in case a
1406 previous "make update" was interrupted for some reason. However, in
1407 this case, make sure you don't call "make clean" or otherwise remove
1408 the list of dependent packages in ${WRKDIR}. Otherwise you lose the
1409 ability to automatically update the current package along with the
1410 dependent packages you have installed.
1412 Resuming an interrupted "make update" will only work as long as the
1413 package tree remains unchanged. If the source code for one of the
1414 packages to be updated has been changed, resuming "make update" will
1415 most certainly fail!
1417 The following variables can be used either on the command line or in
1418 /etc/mk.conf to alter the behaviour of "make update":
1421 Install target to recursively use for the updated package and the
1422 dependent packages. Defaults to ${DEPENDS_TARGET} if set, "install"
1423 otherwise for "make update".
1424 E.g. "make update UPDATE_TARGET=package"
1427 Don't clean up after updating. Useful if you want to leave the
1428 work sources of the updated packages around for inspection or
1429 other purposes. Be sure you eventually clean up the source
1430 tree (see the "clean-update" target below) or you may run into
1431 troubles with old source code still lying around on your next
1432 "make" or "make update".
1435 Deinstall each package before installing (making ${DEPENDS_TARGET}).
1436 This may be necessary if the "clean-update" target (see below) was
1437 called after interrupting a running "make update".
1440 Allows you to disable recursion and hardcode the target for
1441 packages. The default is "update" for the update target,
1442 facilitating a recursive update of prerequisite packages.
1443 Only set DEPENDS_TARGET if you want to disable recursive updates.
1444 Use "UPDATE_TARGET" instead to just set a specific target for
1445 each package to be installed during "make update" (see above).
1448 Clean the source tree for all packages that would get updated if
1449 "make update" was called from the current directory. This target
1450 should not be used if the current package (or any of its depending
1451 packages) have already been de-installed (e.g., after calling "make
1452 update") or you may lose some packages you intended to update.
1453 As a rule of thumb: only use this target _before_ the first time
1454 you call "make update" and only if you have a dirty package tree
1455 (e.g., if you used NOCLEAN).
1457 If you unsure about whether your tree is clean you can either perform
1458 a "make clean" at the top of the tree, or use the following sequence
1459 of commands from the directory of the package you want to update
1460 (*before* running "make update" for the first time, otherwise you lose
1461 all the packages you wanted to update!):
1464 make clean CLEANDEPENDS=YES
1467 The following variables can be used either on the command line or in
1468 /etc/mk.conf to alter the behaviour of "make clean-update":
1471 After "make clean", do not reconstruct the list of directories to
1472 update for this package. Only use this if "make update" successfully
1473 installed all packages you wanted to update. Normally, this is done
1474 automatically on "make update", but may have been suppressed by the
1475 NOCLEAN variable (see above).
1478 This target invokes "pkg_info" for the current package. You can use this
1479 e.g. to check which version of a package is installed.
1482 This target generates a README.html file, which can be viewed using a
1483 browser such as navigator (pkgsrc/www/navigator) or lynx
1484 (pkgsrc/www/lynx). The generated files contain references to any
1485 packages which are in the ${PACKAGES} directory on the local host. The
1486 generated files can be made to refer to URLs based on FTP_PKG_URL_HOST
1487 and FTP_PKG_URL_DIR. For example, if I wanted to generate README.html
1488 files which pointed to binary packages on the local machine, in the
1489 directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
1490 FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
1491 subdirectories will be searched for all the binary packages.
1494 Use this target to create a file README-all.html which contains a
1495 list of all packages currently available in the NetBSD Packages
1496 Collection, together with the category they belong to and a short
1497 description. This file is compiled from the pkgsrc/*/README.html
1498 files, so be sure to run this _after_ a "make readme".
1501 This is very much the same as the readme: target (see above), but is
1502 to be used when generating a pkgsrc tree to be written to a CD-ROM.
1503 This target also produces README.html files, and can be made to refer
1504 to URLs based on CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
1507 This target shows which distfiles and patchfiles are needed to build
1508 the package. (DISTFILES and PATCHFILES, but not patches/*)
1511 This target shows nothing if the package is not installed. If a version
1512 of this package is installed, but is not the version provided in this
1513 version of pkgsrc, then a warning message is displayed. This target can
1514 be used to show which of your installed packages are downlevel, and so
1515 the old versions can be deleted, and the current ones added.
1518 This target shows the directory in the pkgsrc hierarchy from which the
1519 package can be built and installed. This may not be the same directory
1520 as the one from which the package was installed. This target is intended
1521 to be used by people who may wish to upgrade many packages on a single
1522 host, and can be invoked from the top-level pkgsrc Makefile by using the
1523 target "show-host-specific-pkgs"
1525 * show-installed-depends:
1526 This target shows which installed packages match the current package's
1527 DEPENDS. Useful if out of date DEPENDS are causing build problems.
1530 After a package is installed, check all it's binaries and (on ELF
1531 platforms) shared libraries if they find the shared libs they need.
1532 Run by default if PKG_DEVELOPER is set in /etc/mk.conf.
1535 After a 'make install' from a new or upgraded pkg, this prints out an
1536 attempt to generate a new PLIST from a 'find -newer work/.extract_done'.
1537 An attempt is made to care for shared libs etc., but it is STRONGLY
1538 recommended to review the result before putting it into PLIST. On
1539 upgrades, it's useful to diff the output of this command against an already
1540 existing PLIST file.
1542 If the package installs files via tar(1) or other methods that don't update
1543 file access times, be sure to add these files manually to your PLIST,
1544 as 'find -newer' won't catch them!
1547 Used to do bulk builds. If an appropriate binary package already exists,
1548 no action is taken. If not, this target will compile, install and
1549 package it (and it's depends, if PKG_DEPENDS is set properly, see
1550 section 3.2.1). After creating the binary package, the sources, the
1551 just-installed package and it's required packages are removed,
1552 preserving free disk space.
1555 Used during bulk-installs to install required packages. If an
1556 appropriate binary package is available, it will be installed via
1557 pkg_add. If not, "make bulk-package" will be executed, but the installed
1558 binary not be removed. A binary package is "appropriate" to be installed
1561 - None of the package's files (Makefile, ...) were modified since it
1563 - None of the package's required (binary) packages were modified since
1567 8 buildlink.mk methodology
1568 ==========================
1570 Many packages that install libraries and headers for use in other packages
1571 now have buildlink.mk files in their pkgsrc subdirectory. The purpose of
1572 these files is two-fold:
1574 (1) Cause all headers and libraries used by a particular package to be
1575 found in a known location during the configure and build process.
1576 These packages are said to be "weakly-buildlinked".
1578 (2) Cause _only_ those headers and libraries used by a particular package
1579 to be found during the configure and build process.
1580 These packages are said to be "strongly-buildlinked".
1583 8.1 Using buildlink.mk files
1584 ============================
1586 Goal (1) is accomplished by simply including the buildlink.mk file of a
1587 dependency in the package's Makefile, which does the following:
1589 (1a) Adds a DEPENDS or BUILD_DEPENDS line for the package;
1591 (1b) Creates a directory ${BUILDLINK_DIR}, by default set to a
1592 subdirectory of ${WRKDIR};
1594 (1c) Links all the headers and libraries for that dependency into
1595 ${BUILDLINK_DIR}/include and ${BUILDLINK_DIR}/lib, respectively;
1597 (1d) Prepends -I${BUILDLINK_DIR}/include to CPPFLAGS, CFLAGS, CXXFLAGS,
1598 and -L${BUILDLINK_DIR}/lib to LDFLAGS;
1600 (1e) Creates a wrapper script for GTK+-style config scripts, often found
1601 in GNOME software, that translates -I${LOCALBASE}/include and
1602 -L${LOCALBASE}/lib into references into ${BUILDLINK_DIR}.
1604 Some packages are for software libraries whose functionality is a part of
1605 recent released versions of NetBSD, e.g. readline, OpenSSL, and ncurses.
1606 For those packages, the buildlink.mk files link the appropriate system
1607 headers and libraries into ${BUILDLINK_DIR} so that goal (1) is still met.
1608 Where possible, the system headers and libraries are renamed when linked
1609 into ${BUILDLINK_DIR} to match the names of their pkgsrc counterparts so
1610 that the files may be referenced under a consistent name.
1612 Goal (2) requires some work on the part of the package builder. As all
1613 headers and libraries used by a package may be found in ${BUILDLINK_DIR},
1614 and -I${BUILDLINK_DIR}/include and -L${BUILDLINK_DIR}/lib are already passed
1615 to the compiler, it is no longer necessary to pass -I${LOCALBASE}/include or
1616 -L${LOCALBASE}/lib to the compiler. Therefore, those lines should be removed
1617 from package Makefiles, and where necessary, the package sources should be
1618 patched to do the same. Also, if a package uses X11, then by including
1619 mk/x11.buildlink.mk, -I${BUILDLINK_X11_DIR}/include and
1620 -L${BUILDLINK_X11_DIR}/lib are also passed to the compiler instead of the
1621 corresponding directories in ${X11BASE}. Also, if USE_BUILDLINK_ONLY is
1622 defined, then -L${LOCALBASE}/lib is not automatically added to LDFLAGS in
1626 8.2 Writing buildlink.mk files
1627 ==============================
1629 Most of the work done by buildlink.mk files is encapsulated and shared
1630 through bsd.buildlink.mk, which is included by packages' buildlink.mk files.
1631 Please see the comments at the top of bsd.buildlink.mk for complete
1632 documentation on how to use the file. A simple example of a buildlink.mk
1633 for a mythical package foo follows:
1635 .include "../../mk/bsd.buildlink.mk"
1637 BUILDLINK_DEPENDS.foo?= foo>=1.0
1638 DEPENDS+= ${BUILDLINK_DEPENDS.foo}:../../category/foo
1640 EVAL_PREFIX+= BUILDLINK_PREFIX.foo=foo
1641 BUILDLINK_FILES.foo= include/foo.h
1642 BUILDLINK_FILES.foo+= include/bar.h
1643 BUILDLINK_FILES.foo+= lib/libfoo.*
1645 # We need the libraries to be called "libbar.*".
1646 BUILDLINK_TRANSFORM.foo= -e "s|libfoo|libbar|g"
1648 BUILDLINK_TARGETS+= foo-buildlink
1650 pre-configure: foo-buildlink
1651 foo-buildlink: _BUILDLINK_USE
1654 8.3 Converting packages to use buildlink.mk files
1655 =================================================
1657 The process of converting existing packages to use the buildlink.mk
1658 infrastructure is fairly straightforward. If a dependency on a particular
1659 package is required for its libraries and headers, then rather than
1660 directly adding a dependency on that package, include that package's
1661 buildlink.mk instead. The following variables may also be replaced with
1664 USE_LIBINTL --> .include "../../devel/gettext-lib/buildlink.mk"
1665 USE_LTDL --> .include "../../devel/libtool/buildlink.mk"
1666 USE_MESA --> .include "../../graphics/Mesa/buildlink.mk"
1667 USE_MOTIF --> .include "../../mk/motif.buildlink.mk"
1668 USE_X11 --> .include "../../mk/x11.buildlink.mk"
1669 USE_XAW --> .include "../../mk/xaw.buildlink.mk"
1670 USE_XPM --> .include "../../graphics/xpm/buildlink.mk"
1672 Packages that have an explicit dependency on ncurses should set USE_NCURSES
1673 to the reason why the system curses is insufficient, and include
1674 "../../devel/ncurses/buildlink.mk" afterwards. This helps to identify
1675 where the system curses differs from ncurses, and when the development of
1676 the system curses catches up in functionality, the USE_NCURSES setting may
1679 Package that need a Motif-1.2-compatible installation should define
1680 USE_MOTIF12, otherwise assume the need for a Motif-2.0-compatible
1681 installation. If MOTIFBASE or MOTIF12BASE is set, then it is assumed that
1682 they point to valid 2.0-compatible or 1.2-compatible Motif, respectively.
1684 Packages that use OpenSSL that require a specific version of OpenSSL should
1685 define USE_OPENSSL_VERSION to the minimum version number required prior to
1686 including "../../security/openssl/buildlink.mk". The version number is the
1687 hexadecimal number found in <openssl/opensslv.h>, or the variables
1688 OPENSSL_VERSION_{095A,096,096A,096B} may be used.
1690 The use of EVAL_PREFIX to find the installation prefix for packages may be
1691 removed since references to package library and header files are found
1692 through ${BUILDLINK_DIR}. If the required dependency pattern for a package
1693 differs from the default specified in the package's buildlink.mk file, then
1694 it may be set by defining BUILDLINK_DEPENDS.<pkgname> in the Makefile to
1695 the dependency pattern required.
1697 Packages will still need LDFLAGS to be set to include the appropriate rpath
1698 settings in order for built packages to find libraries. LDFLAGS should
1699 still contain -Wl,-R${LOCALBASE}/lib, and -Wl,-R${X11BASE}/lib if the
1700 package requires the X11 libraries. -Wl,-R should never refer to a
1701 ${BUILDLINK_DIR} library directory, and all such references should be
1702 purged from the build.
1704 A package that builds correctly with USE_BUILDLINK_ONLY set should have
1705 that setting added to its Makefile to note that it doesn't use any
1706 libraries or headers in ${LOCALBASE} directly, but rather references them
1707 only through ${BUILDLINK_DIR}. Note that you MUST check the build output
1708 to verify that no references to ${LOCALBASE} directories occurred during
1709 the configure or build process, or else the package cannot be marked as
1716 To check out all the gotchas when building a package, here are the steps
1717 that I do in order to get a package working. Please note this is basically
1718 the same as what was explained in the previous sections, only with some
1721 * Make sure PKG_DEVELOPER=1 is in /etc/mk.conf
1722 * Create a new directory, and run
1724 # url2pkg http://www.example.com/path/to/distfile.tar.gz
1726 You'll need to have pkgsrc/pkgtools/url2pkg installed for that.
1727 * Edit the Makefile as requested.
1729 * ``make configure''
1730 * Add any dependancies glimpsed from the configure step to the package's
1732 * Make the package compile, doing multiple rounds of
1735 # pkgvi ${WRKSRC}/some/file/that/does/not/compile
1738 # mv ${WRKDIR}/.newpatches/* patches
1741 [ mkpatches, patchdiff and pkgvi are from pkgsrc/pkgtools/pkgdiff ]
1743 Doing as non-root user will assure that no files are modified that
1744 shouldn't, esp. not during the build phase.
1745 * Look at Makefile, fix if necessary; see section 4.1.
1749 # make print-PLIST > PLIST
1754 You usually need to be root to do this.
1755 * Look if there are any files left:
1759 If this brings up any files that are missing in PLIST, add them.
1760 * Now that the PLIST is ok, install the package again and make a binary
1763 # make reinstall && make package
1765 * Delete the installed package:
1769 * Repeat the above find command, which shouldn't find anything now:
1773 * Reinstall the binary package:
1775 # pkg_add ..../blub.tgz
1777 * Play with it. Make sure everything works.
1778 * Run pkglint from pkgsrc/pkgtools/pkglint, and fix the problems it reports.
1782 * Submit (or commit, if you have cvs access); see section 11.
1785 10 FAQs & features of the package system
1786 ========================================
1788 10.1 Packages using GNU autoconf
1789 ================================
1791 If your package uses GNU autoconf created configure scripts, add the following
1792 to your package's Makefile:
1796 Note that this appends --prefix=${PREFIX} to CONFIGURE_ARGS, so you don't
1797 have to do that yourself, and this may not be what you want.
1800 10.2 Other distrib methods than .tar.gz
1801 =======================================
1803 If your package uses a different distribution method from .tar.gz, take a
1804 look at the package for pkgsrc/editors/sam, which uses a gzipped shell archive
1805 (shar), but the quick solution is to set EXTRACT_SUFX to the name after the
1806 DISTNAME field, and add the following to your package's Makefile:
1808 EXTRACT_SUFX= .msg.gz
1810 EXTRACT_BEFORE_ARGS=
1811 EXTRACT_AFTER_ARGS= |sh
1814 10.3 Packages not creating their own subdirectory
1815 =================================================
1817 Your package doesn't create a subdirectory for itself (like GNU software
1818 does, for instance), but extracts itself in the current directory: see
1819 pkgsrc/editors/sam again, but the quick answer is:
1823 Please note that the old
1827 has been deprecated and should not be used.
1830 10.4 Custom configuration process
1831 =================================
1833 Your package uses a weird Configure script: See the top package, but the
1837 CONFIGURE_SCRIPT= Configure
1838 CONFIGURE_ARGS+= netbsd13
1841 10.5 Packages not building in their DISTNAME directory
1842 ======================================================
1844 Your package builds in a different directory from its base DISTNAME - see
1845 tcl and tk packages:
1847 WRKSRC= ${WRKDIR}/${DISTNAME}/unix
1850 10.6 How to fetch all distfiles at once
1851 =======================================
1853 You would like to download all the distfiles in a single batch from work or
1854 university, where you can't run a "make fetch". But there's no archive of
1855 the distfiles on ftp.netbsd.org and the one on ftp.freebsd.org contains
1856 many distfiles for which there are no ports (yet).
1858 The answer here is to do a "make fetch-list" in /usr/pkgsrc, carry the
1859 resulting list to your machine at work/school and use it there If you don't
1860 have a NetBSD-compatible ftp(1) (like lukemftp) at work, don't forget to
1861 set FETCH_CMD to something that fetches an URL:
1866 % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
1867 % scp /tmp/fetch.sh work:/tmp
1872 % tar up /tmp/distfiles and take it home
1874 If you have a machine running NetBSD, and you want to get *all* distfiles
1875 (even ones that aren't for your machine architecture), you can do so by
1876 using the above-mentioned 'make fetch-list'-approach, or fetch the distfiles
1879 % make mirror-distfiles
1881 If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can
1882 get all & everything by typing
1884 % make fetch NO_IGNORE=yes
1887 10.7 How to fetch files from behind a firewall
1888 ==============================================
1890 If you are sitting behind a firewall which does not allow direct connections
1891 to Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts.
1892 This is done using an environment variable in the form of a URL
1893 e.g. in Amdahl, the machine orpheus.amdahl.com is one of the firewalls, and
1894 it uses port 80 as the proxy port number. So the proxy environment
1895 variables look like:
1897 ftp_proxy=ftp://orpheus.amdahl.com:80/
1898 http_proxy=http://orpheus.amdahl.com:80/
1901 10.8 If your patch contains an RCS ID
1902 =====================================
1904 See section 4.3 on how to remove RCS IDs from patch files.
1907 10.9 How to pull in variables from /etc/mk.conf
1908 ===============================================
1910 The problem with package-defined variables that can be overridden via
1911 MAKECONF or /etc/mk.conf is that make(1) expands a variable as it is
1912 used, but evaluates preprocessor like statements (.if, .ifdef and
1913 .ifndef) as they are read. So, to use any variable (which may be set
1914 in /etc/mk.conf) in one of the .if* statements, the file /etc/mk.conf
1915 must be included before that .if* statement.
1917 Rather than have a number of ad-hoc ways of including /etc/mk.conf,
1918 should it exist, or MAKECONF, should it exist, include the
1919 pkgsrc/mk/bsd.prefs.mk file in the package Makefile before any
1920 preprocessor-like .if, .ifdef, or .ifndef statements:
1922 .include "../../mk/bsd.prefs.mk"
1924 .if defined(USE_MENUS)
1929 10.10 Is there a mailing list for pkg-related discussion?
1930 =========================================================
1932 Yes. We are using tech-pkg@netbsd.org for discussing package related
1933 issues. To subscribe do:
1935 % echo subscribe tech-pkg | mail majordomo@netbsd.org
1938 10.11 How do i tell "make fetch" to do passive FTP?
1939 ===================================================
1941 This depends on which utility is used to retrieve distfiles. From
1942 bsd.pkg.mk, FETCH_CMD is assigned the first available command from the
1946 ${LOCALBASE}/bsd/bin/ftp
1949 On a default NetBSD install, this will be /usr/bin/ftp, which automatically
1950 tries passive connections first, and falls back to active connections if the
1951 server refuses to do passive. For the other tools, add the following to your
1952 /etc/mk.conf file: PASSIVE_FETCH=1
1954 Having that option present will prevent /usr/bin/ftp from falling back to
1958 10.12 Dependencies on other packages
1959 ====================================
1961 Your package may depend on some other package being present - and there are
1962 various ways of expressing this dependency. NetBSD supports the
1963 BUILD_DEPENDS and DEPENDS definitions, as well as dependencies via
1964 buildlink.mk (see section 8).
1966 The basic difference between the two definitions is as follows: The
1967 DEPENDS definition registers that pre-requisite in the binary package,
1968 whilst the BUILD_DEPENDS definition does not.
1970 This means that if you only need a package present whilst you are building,
1971 it should be noted as a BUILD_DEPENDS.
1973 The format for a BUILD_DEPENDS and a DEPENDS definition is:
1975 <pre-req-package-name>:../../<category>/<pre-req-package>
1977 Please note that the "pre-req-package-name" may include any of the wildcard
1978 version numbers recognised by pkg_info(1).
1980 (a) If your package needs to use another package to build itself, this
1981 is specified using the BUILD_DEPENDS definition.
1983 BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
1985 (b) If your package needs a library with which to link, this is specified
1986 using the DEPENDS definition. An example of this is the pkgsrc/print/lyx
1987 package, which uses the xpm library, version 3.4j to build.
1989 DEPENDS+= xpm-3.4j:../../graphics/xpm
1991 You can also use wildcards in package dependences:
1993 DEPENDS+= xpm-[0-9]*:../../graphics/xpm
1995 Note that such wildcard dependencies are retained when creating binary
1996 packages. The dependency is checked when installing the binary
1997 package and any package which matches the pattern will be used.
1998 Wildcard dependencies should be used with care.
2000 The -[0-9]* should be used instead of -* to avoid potentially
2001 ambiguous matches such as tk-postgresql matching a tk-* DEPEND.
2003 (c) If your package needs some executable to be able to run correctly, this
2004 is specified using the DEPENDS definition. The pkgsrc/print/lyx package needs
2005 to be able to execute the latex binary from the teTex package when it runs,
2006 and that is specified:
2008 DEPENDS+= teTex-[0-9]*:../../print/teTeX
2010 The comment about wildcard dependencies from previous paragraph
2013 If your package needs files from another package to build, see the
2014 first part of the "do-configure" target pkgsrc/print/ghostscript5 package
2015 (it relies on the jpeg sources being present in source form during the
2018 if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
2019 cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract; \
2022 If you build any other packages that way, please make sure the working
2023 files are deleted too when this package's working files are cleaned up.
2024 The easiest way to do so is by adding a pre-clean target:
2027 cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean
2029 Please also note the BUILD_USES_MSGFMT and BUILD_USES_GETTEXT_M4 definitions,
2030 which are provided as convenience definitions. The former works out whether
2031 msgfmt(1) is part of the base system, and, if it isn't, installs the
2032 pkgsrc/devel/gettext package. The latter adds a build dependency on either an
2033 installed version of an older gettext package, or if it isn't, installs the
2034 pkgsrc/devel/gettext-m4 package.
2037 10.13 Conflicts with other packages
2038 ===================================
2040 Your package may conflict with other packages a user might already have
2041 installed on his system, e.g. if your package installs the same set of
2042 files like another package in our pkgsrc tree.
2044 In this case you can set CONFLICTS to a space separated list of packages
2045 (including version string) your package conflicts with.
2047 For example pkgsrc/x11/Xaw3d and pkgsrc/x11/Xaw-Xpm install provide the
2048 same shared library, thus you set in pkgsrc/x11/Xaw3d/Makefile:
2050 CONFLICTS= Xaw-Xpm-[0-9]*
2052 and in pkgsrc/x11/Xaw-Xpm/Makefile:
2054 CONFLICTS= Xaw3d-[0-9]*
2056 Packages will automatically conflict with other packages with the name prefix
2057 and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
2058 with the older version "Xaw3d-1.3".
2061 10.14 Software which has a WWW Home Page
2062 ========================================
2064 The NetBSD packages system now supports a variable called HOMEPAGE.
2065 If the software being packaged has a home page, the Makefile should
2066 include the URL for that page in the HOMEPAGE variable. The definition
2067 of the variable should be placed immediately after the MAINTAINER
2071 10.15 How to handle modified distfiles with the 'old' name
2072 ==========================================================
2074 Sometimes authors of a software package make some modifications after the
2075 software was released, and they put up a new distfile without changing the
2076 package's version number. If a package is already in pkgsrc at that time,
2077 the md5 checksum will no longer match. The correct way to work around this
2078 is to update the package's md5 checksum to match the package on the master
2079 site (beware, any mirrors may not be up to date yet!), and to remove the
2080 old distfile from ftp.netbsd.org's /pub/NetBSD/packages/distfiles directory.
2081 Furthermore, a mail to the package's author seems appropriate making sure
2082 the distfile was really updated on purpose, and that no trojan horse or so
2086 10.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
2087 =========================================================================
2089 When compiling the pkgsrc/pkgtools/pkg_install package, you get the error
2090 from make that it doesn't know how to make /usr/share/tmac/tmac.andoc? This
2091 indicates that you don't have installed the "text" set on your machine
2092 (nroff, ...). It is recommended to do that.
2094 In the case of the pkg_install package, you can get away with setting
2095 NOMAN=YES either in the environment or in /etc/mk.conf.
2098 10.17 How to handle incrementing versions when fixing an existing package
2099 =========================================================================
2101 When making fixes to an existing package it can be useful to change
2102 the version number in PKGNAME. To avoid conflicting with future versions
2103 by the original author, a 'nb1' ('nb2', ...) suffix can be used on package
2104 versions by setting PKGREVISION=1 (2,. ..). The "nb" is treated like a "."
2105 by the pkg tools. E.g.
2110 will result in a PKGNAME of foo-17.42nb9.
2112 When a new release of the package is released, the PKGREVISION should be
2113 removed. E.g. on a new minor release of the above package, things should
2119 10.18 "Could not find bsd.own.mk" - what's wrong?
2120 =================================================
2122 You didn't install the compiler set, comp.tgz, when you installed your
2123 NetBSD machine. Please get it and install it, by extracting it in /:
2125 # tar --unlink -pvxf .../comp.tgz
2127 comp.tgz is part of every NetBSD release, please get the one matching
2128 the release you have installed (determine via "uname -r").
2131 10.19 Restricted packages
2132 =========================
2134 Some licenses restrict how software may be re-distributed. In order to
2135 satisfy these restrictions, the package system defines five make variables
2136 that can be set to note these restrictions:
2139 This variable should be set whenever a restriction exists
2140 (regardless of its kind). Set this variable to a string
2141 containing the reason for the restriction.
2144 Binaries may not be placed on CD-ROM. Set this variable to
2145 ${RESTRICTED} whenever a binary package may not be included
2149 Binaries may not be placed on an ftp server. Set this
2150 variable to ${RESTRICTED} whenever a binary package may not
2151 not be made available on the Internet.
2154 Distfiles may not be placed on CD-ROM. Set this variable to
2155 ${RESTRICTED} if re-distribution of the source code or other
2156 distfile(s) is not allowed on CD-ROMs.
2159 Distfiles may not be placed on FTP. Set this variable to
2160 ${RESTRICTED} if re-distribution of the source code or other
2161 distfile(s) via the Internet is not allowed.
2163 Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic
2164 make variables to denote restrictions is deprecated, because they
2165 unconditionally prevent users from generating binary packages!
2168 10.20 Packages using (n)curses
2169 ==============================
2171 Some packages need curses functionality that wasn't present in NetBSD's own
2172 curses prior to 1.4Y.
2174 If ../../devel/ncurses/buildlink.mk is included in a package's Makefile,
2175 then a curses library and headers with ncurses functionality are linked
2176 into ${BUILDLINK_DIR} at pre-configure time. If ncurses is needed, then a
2177 dependency on ncurses is added to the package, otherwise, if the system
2178 curses is sufficient, then the library and headers are linked into
2179 ${BUILDLINK_DIR} with ncurses names. If ncurses is actually required, then
2180 define USE_NCURSES in the package's Makefile.
2183 10.21 Automated security check
2184 ==============================
2186 Please be aware that there can often be bugs in third-party software,
2187 and some of these bugs can leave a machine vulnerable to exploitation
2188 by attackers. In an effort to lessen the exposure, the NetBSD
2189 packages team maintains a database of known-exploits to packages which
2190 have at one time been included in pkgsrc. The database can be
2191 downloaded automatically, and a security audit of all packages
2192 installed on a system can take place. To do this, install the
2193 pkgsrc/security/audit-packages package. It has two components:
2195 (1) download-vulnerability-list, an easy way to download a list of the
2196 security vulnerabilities information. This list is kept up to date by
2197 the NetBSD security officer and the NetBSD packages team, and is
2198 distributed from the NetBSD ftp server:
2200 ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/vulnerabilities
2202 (2) audit-packages, an easy way to audit the current machine, checking
2203 each vulnerability which is known. If a vulnerable package is
2204 installed, it will be shown by output to stdout, including a
2205 description of the type of vulnerability, and a URL containing more
2208 Use of the audit-packages package is strongly recommended.
2210 The following message is displayed as part of the audit-packages
2211 installation procedure:
2213 ======================================================================
2214 You may wish to have the vulnerabilities file downloaded daily so that
2215 it remains current. This may be done by adding an appropriate entry
2216 to the root users crontab(5) entry. For example the entry
2218 # download vulnerabilities file
2219 0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1
2221 will update the vulnerability list every day at 3AM.
2223 In addition, you may wish to run the package audit from the daily
2224 security script. This may be accomplished by adding the following
2225 lines to /etc/security.local
2227 if [ -x ${PREFIX}/sbin/audit-packages ]; then
2228 ${PREFIX}/sbin/audit-packages
2230 ======================================================================
2233 Note to package developers: When a vulnerability is found, this should be
2234 noted in localsrc/security/advisories/pkg-vulnerabilities, and after the
2235 commit of that file, it should be copied to
2236 /pub/NetBSD/packages/distfiles/vulnerabilities on ftp.netbsd.org.
2239 10.22 What's the proper way to create an account from a package?
2240 ================================================================
2242 There are two make variables used to control the creation of package-specific
2243 groups and users at pre-install time. The first is PKG_GROUPS, which is a
2244 list of group[:groupid] elements, where the groupid is optional. The second
2245 is PKG_USERS, which is a list of elements of the form:
2247 user:group[:[userid][:[description][:[home][:shell]]]]
2249 where only the user and group are required, the rest being optional. A
2252 PKG_GROUPS= foogroup
2253 PKG_USERS= foouser:foogroup
2255 A more complex example is that creates two groups and two users is:
2257 PKG_GROUPS= group1 group2:1005
2258 PKG_USERS= first:group1::First\\ User \
2259 second:group2::Second\\ User:/home/second:${SH}
2261 By default, a new user will have home directory /nonexistent, and login shell
2262 /sbin/nologin unless they are specified as part of the user element.
2264 The package Makefile must also include "../../mk/bsd.pkg.install.mk" prior to
2265 the inclusion of bsd.pkg.mk. This will cause the users and groups to be
2266 created at pre-install time, and the admin will be prompted to remove them at
2267 post-deinstall time. Automatic creation of the users and groups can be
2268 toggled on and off by setting the environment variable PKG_CREATE_USERGROUP
2269 prior to package installation.
2272 10.23 How to handle compiler bugs
2273 =================================
2275 Some source files trigger bugs in the compiler, based on combinations
2276 of compiler version and architecture and almost always relation to
2277 optimsation being enabled. Common symptoms are gcc internal errors
2278 or never finishing compiling a file.
2280 Typically a workaround involves testing the MACHINE_ARCH and compiler
2281 version, disabling optimisation for that file/MACHINE_ARCH/compiler
2282 combination, and documenting it in doc/HACKS. See doc/HACKS for
2286 10.24 Packages providing info files
2287 ===================================
2289 Some packages install info files or use the makeinfo or install-info
2290 commands. In such cases, the makefile fragment mk/texinfo.mk should be
2291 included in the package Makefile before the inclusion of mk/bsd.pkg.mk.
2292 Newer versions of texinfo (version 4 and above) are, unfortunately,
2293 incompatible from previous versions at the command line level and some
2294 extensions were introduced in the TeXinfo macro set. So the package creator
2295 should ensure that the correct binaries are selected, rather than relying
2296 on the contents of the PATH variable in the shell.
2298 The main info directory file needs to be updated to reflect the
2299 installation of info files. Some packages' installation processes take care
2300 of this for you. Otherwise the NetBSD Packages Collection has an INFO_FILES
2301 definition which can be used to do this. Simply use the
2303 INFO_FILES= ident.info
2305 definition in the package Makefile, where "ident.info" is the name of the
2306 info file which installs an info dir entry.
2308 A package creator should also take care that the package build and install
2309 process uses the correct version of the makeinfo and install-info commands.
2310 Some Makefiles and configure scripts from recent software packages include
2311 the pathnames to the makeinfo and install-info commands. Unfortunately,
2312 older software packages tend not to do this, and, should this be the case,
2313 further action is required of the package creator.
2315 The mk/texinfo.mk makefile fragment will ensure that the proper makeinfo
2316 and install-info commands are available on the system as well as help the
2317 configure and build process of the package to use known binaries for these
2320 If a minimum version of makeinfo and install-info commands are required,
2321 define TEXINFO_REQD in the package's Makefile to this mininum version.
2323 If a package is not well behaved (i.e., it does not pick MAKEINFO or
2324 INSTALL_INFO in the environment at configure or build time) you should do
2325 one of the following, whichever is more appropriate:
2326 a) patch the package files so MAKEINFO or INSTALL_INFO are picked from the
2327 environment at configure or build time and get used instead of
2328 relying on makeinfo or install-info being accessible in PATH;
2329 b) put TEXINFO_OVERRIDE=YES in the package Makefile to let some sed
2330 manipulation happen on some packages source files (see contents of
2334 10.25 Packages whose distfiles aren't available for plain downloading
2335 =====================================================================
2337 If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES
2338 and a 'make fetch' will call files/getsite.sh with the name of each file
2339 to download as an argument, expecting it to output the URL of the directory
2340 from which to download it. graphics/ns-cult3d is an example of this usage.
2342 If the download can't be automated, because the user must submit personal
2343 information to apply for a password, or must pay for the source, or whatever,
2344 you can set _FETCH_MESSAGE to a macro which displays a message explaining
2345 the situation. _FETCH_MESSAGE must be executable shell commands, not just a
2346 message. (Generally, it executes ${ECHO}). As of this writing, the following
2347 packages use this: audio/realplayer, cad/simian, devel/ipv6socket,
2348 emulators/vmare-module, fonts/acroread-jpnfont, sysutils/storage-manager,
2349 www/ap-aolserver, www/openacs. Try to be consistent with them.
2352 10.26 Using pkgsrc on non-NetBSD (Linux, Solaris, Darwin, MacOS X)
2353 ==================================================================
2355 In order to use pkgsrc on a non-NetBSD operating system, you must first
2356 bootstrap the necessary utilities (BSD make, pkg_*, ...). See
2357 http://www.zoularis.org/ for information on boostrapping.
2360 10.27 Configuration files handling and placement
2361 ================================================
2363 The global variable PKG_SYSCONFBASE (and some others) can be set by the
2364 system administrator in /etc/mk.conf to define the place where
2365 configuration files get installed. Therefore, packages must be adapted to
2366 support this feature. Keep in mind that you should only install files that
2367 are strictly necessary in the configuration directory, files that can
2368 go to $PREFIX/share should go there.
2370 We will take a look at available variables first (bsd.pkg.mk contains more
2371 information). PKG_SYSCONFDIR is where the configuration files for a package
2372 may be found (that is, the full path, e.g. /etc or /usr/pkg/etc). This
2373 value may be customized in various ways:
2375 1) PKG_SYSCONFBASE is the main config directory under which all package
2376 configuration files are to be found. Users will typically want to set
2377 it to /etc, or accept the default location of $PREFIX/etc.
2379 2) PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which
2380 the configuration files for a particular package may be found. Defaults
2383 3) PKG_SYSCONFVAR is the special suffix used to distinguish any overriding
2384 values for a particular package (see next item). It defaults to
2385 ${PKGBASE}, but for a collection of related packages that should all
2386 have the same PKG_SYSCONFDIR value, it can be set in each of the
2387 package Makefiles to a common value.
2389 4) PKG_SYSCONFDIR.${PKG_SYSCONFVAR} overrides the value of
2390 ${PKG_SYSCONFDIR} for packages with the same value for PKG_SYSCONFVAR.
2392 As an example, all the various KDE packages may want to set
2393 PKG_SYSCONFVAR to "kde" so admins can set ${PKG_SYSCONFDIR.kde} in
2394 /etc/mk.conf to define where to install KDE config files.
2396 Programs' configuration directory should be defined during the configure
2397 stage. Packages that use GNU autoconf can usually do this by using the
2398 --sysconfdir parameter, but this brings some problems as we will see now.
2399 When you change this pathname in packages, you should not allow them to
2400 install files in that directory directly. Instead they need to install
2401 those files under share/examples/${PKGNAME} so PLIST can register them.
2403 Once you have the required configuration files in place (under the
2404 share/examples directory) the variable CONF_FILES should be set to copy
2405 them into PKG_SYSCONFDIR. The contents of this variable is formed by pairs
2406 of filenames; the first element of the pair specifies the file inside the
2407 examples directory (registered by PLIST) and the second element specifies
2408 the target file. This is done this way to allow binary packages to place
2409 files in the right directory using INSTALL/DEINSTALL scripts which are
2410 created automatically. The package Makefile must also include
2411 "../../mk/bsd.pkg.install.mk" prior to the inclusion of bsd.pkg.mk to use
2412 these automatically generated scripts. The automatic copying of config
2413 files can be toggled by setting the environment variable PKG_CONFIG prior
2414 to package installation.
2416 Here is an example, taken from mail/mutt/Makefile:
2418 EGDIR= ${PREFIX}/share/doc/mutt/samples
2419 CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
2421 As you can see, this package installs configuration files inside EGDIR,
2422 which are registered by PLIST. After that, the variable CONF_FILES lists
2423 the installed file first and then the target file. Users will also get an
2424 automatic message when files are installed using this method.
2427 11 Submitting & Committing
2428 ==========================
2430 11.1 Submitting your packages
2431 =============================
2433 You have to separate between binary and "normal" (source) packages here:
2435 * precompiled binary packages:
2436 Our policy is that we accept binaries only from NetBSD developers to
2437 guarantee that the packages don't contain any trojan horses etc.
2438 This is not to piss anyone off but rather to protect our users!
2439 You're still free to put up your home-made binary packages and tell
2440 the world where to get them.
2443 First, check that your package is complete, compiles and runs well; see
2444 section 9 and the rest of this document. Next, generate a gzipped
2445 tar-file of all the files needed for the package, preferably with all
2446 files in a single directory. Place this tar-file to a place where the
2447 package maintainers can fetch it using FTP or HTTP (WWW). Finally,
2448 send-pr with category "pkg", a synopsis which includes the package name
2449 and version number, a short description of your package
2450 (contents of the COMMENT variable are OK) and the URL of your tar-file.
2452 You will be notified if your send-pr has been addressed so you can remove
2455 If you want to submit several packages, please send a separate PR for
2456 each one, it's easier for us to track things that way.
2459 11.2 Committing: Importing the package into CVS
2460 ===============================================
2462 This section is only of interest for NetBSD developers with write
2463 access to the NetBSD pkgsrc repository. Please remember that cvs
2464 imports files relative to the cwd, and that the pathname that you
2465 give the "cvs import" command is so that it knows where to place
2466 the files in the repository. Newly created packages should be
2467 imported with a vendor tag of "TNF" and a release tag of "pkgsrc-base",
2470 % cd .../pkgsrc/<category>/<pkgname>
2471 % cvs import pkgsrc/<category>/<pkgname> TNF pkgsrc-base
2473 and remember to move the directory from which you imported out of
2474 the way, or cvs will complain the next time you "cvs update" your
2475 source tree. Also don't forget to add the new package to the
2476 category's Makefile.
2478 The commit message of the initial import should include part of the
2479 DESCR file, so people reading the mailing lists know what the package
2482 Please note all package updates/additions in doc/pkg-CHANGES! It's very
2483 important to keep this file up to date and conforming to the existing
2484 format, because it will be used by scripts to automatically update pages on
2485 www.netbsd.org and other sites.
2487 For new packages, "cvs import" is preferred to "cvs add" because
2488 the former gets everything with a single command, and provides a
2492 11.3 Updating a Package to a Newer Version
2493 ==========================================
2495 Please always put a concise, appropriate and relevant summary of the
2496 changes between old and new versions into the commit log when updating
2497 a package. There are various reasons for this:
2499 + a URL is volatile, and can change over time. It may go away completely,
2500 or its information may be overwritten by newer information.
2502 + having the change information between old and new versions in our CVS
2503 repository is very useful for people who use either cvs or anoncvs.
2505 + having the change information between old and new versions in our CVS
2506 repository is very useful for people who read the pkgsrc-changes mailing
2507 list, so that they can make tactical decisions about when to upgrade
2510 Please also recognise that, just because a new version of a package
2511 has been released, it should not automatically be upgraded in the CVS
2512 repository. We prefer to be conservative in the packages that are
2513 included in pkgsrc - development or beta packages are not really the
2514 best thing for most places in which pkgsrc is used. Please use your
2515 judgement about what should go into pkgsrc, and bear in mind that
2516 stability is to be preferred above new and possibly untested features.
2519 11.4 Moving a Package in pkgsrc
2520 ===============================
2522 1. Make a copy of the directory somewhere else.
2523 2. Remove all CVS dirs.
2524 Alternatively to the first two steps you can also do:
2525 cvs -d user@cvs.netbsd.org:/cvsroot export -D today pkgsrc/category/package
2526 and use that for further work.
2527 3. Fix CATEGORIES and any DEPENDS paths that just did ../package
2528 instead of ../../category/package.
2529 4. "cvs import" the modified package in the new place.
2530 5. Check if any package depends on it:
2532 grep /package */*/Makefile* */*/buildlink*
2533 6. Fix paths in packages from step 5 to point to new location.
2534 7. "cvs rm (-f)" the package at the old location.
2535 8. Remove from oldcategory/Makefile.
2536 9. Add to newcategory/Makefile.
2537 10. Commit the changed and removed files:
2538 cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
2539 and any packages from step 5, of course.
2542 12 A simple example of a package: bison
2543 =======================================
2545 I checked to find a piece of software that wasn't in the packages
2546 collection, and picked GNU bison. Quite why someone would want to have
2547 bison when Berkeley yacc is already present in the tree is beyond me, but
2548 it's useful for the purposes of this exercise.
2554 The file contents in this section must be used without the "> " prefix.
2562 DISTNAME= bison-1.25
2564 MASTER_SITES= ${MASTER_SITE_GNU}
2565 MAINTAINER= thorpej@netbsd.org
2566 HOMEPAGE= http://www.gnu.org/software/bison/bison.html
2567 COMMENT= GNU yacc clone
2570 INFO_FILES= bison.info
2572 .include "../../mk/texinfo.mk"
2573 .include "../../mk/bsd.pkg.mk"
2579 GNU version of yacc. Can make re-entrant parsers, and numerous other
2580 improvements. Why you would want this when Berkeley yacc(1) is part
2581 of the NetBSD source tree is beyond me.
2587 @comment <$>NetBSD<$>
2590 @unexec install-info --delete %D/info/bison.info %D/info/dir
2597 @exec install-info %D/info/bison.info %D/info/dir
2602 12.1.4 Checking a package "pkglint"
2603 ===================================
2605 The NetBSD package system comes with a tool called "pkglint" (located in the
2606 directory "pkgsrc/pkgtools/pkglint") which helps to check the contents of these
2607 files. After installation it is quite easy to use, just change to the
2608 directory of the package you wish to examine and execute "pkglint":
2611 OK: checking ./DESCR.
2612 OK: checking Makefile.
2613 OK: checking distinfo.
2614 OK: checking patches/patch-aa.
2617 Depending on the supplied command line arguments (see "man pkglint") more
2618 verbose checks will be performed. Use e.g. "pkglint -v" for a very verbose
2622 12.2 Steps for building, installing, packaging
2623 ==============================================
2625 Create the directory where the package lives, plus any auxiliary directories:
2627 # cd /usr/pkgsrc/lang
2632 Create Makefile, DESCR and PLIST as in section 11.1,
2633 then continue with fetching the distfile:
2636 >> bison-1.25.tar.gz doesn't seem to exist on this system.
2637 >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
2638 Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
2639 ftp: Error retrieving file: 500 Internal error
2641 >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
2642 Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
2643 ftp: Error retrieving file: 500 Internal error
2645 >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
2646 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
2647 Successfully retrieved file.
2649 Generate the checksum of the distfile into distinfo:
2656 >> Checksum OK for bison-1.25.tar.gz.
2657 ===> Extracting for bison-1.25
2658 ===> Patching for bison-1.25
2659 ===> Ignoring empty patch directory
2660 ===> Configuring for bison-1.25
2661 creating cache ./config.cache
2662 checking for gcc... cc
2663 checking whether we are using GNU C... yes
2664 checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
2665 checking how to run the C preprocessor... cc -E
2666 checking for minix/config.h... no
2667 checking for POSIXized ISC... no
2668 checking whether cross-compiling... no
2669 checking for ANSI C header files... yes
2670 checking for string.h... yes
2671 checking for stdlib.h... yes
2672 checking for memory.h... yes
2673 checking for working const... yes
2674 checking for working alloca.h... no
2675 checking for alloca... yes
2676 checking for strerror... yes
2677 updating cache ./config.cache
2678 creating ./config.status
2680 ===> Building for bison-1.25
2681 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
2682 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
2683 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
2684 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
2685 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
2686 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
2687 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
2688 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
2689 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
2690 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
2691 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
2692 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
2693 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
2694 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
2695 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
2696 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
2697 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
2698 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
2699 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
2700 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
2701 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
2702 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
2703 ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
2705 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
2707 Everything seems OK, so install the files:
2710 >> Checksum OK for bison-1.25.tar.gz.
2711 ===> Installing for bison-1.25
2712 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
2713 rm -f /usr/pkg/bin/bison
2714 cd /usr/pkg/share; rm -f bison.simple bison.hairy
2715 rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
2716 install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison
2717 /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
2718 /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
2719 cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
2720 /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
2721 ===> Registering installation for bison-1.25
2723 You can now use bison, and also - if you decide so - remove it with
2724 "pkg_delete bison-1.25". Should you decide that you want a binary package,
2728 >> Checksum OK for bison-1.25.tar.gz.
2729 ===> Building package for bison-1.25
2730 Creating package bison-1.25.tgz
2731 Registering depends:.
2732 Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
2734 Now that you don't need the source and object files any more, clean up:
2737 ===> Cleaning for bison-1.25
2740 ======================
2741 Appendix A: build logs
2742 ======================
2748 >> top-3.5beta5.tar.gz doesn't seem to exist on this system.
2749 >> Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
2750 Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheus.amdahl.com:80/)
2751 Successfully retrieved file.
2752 >> Checksum OK for top-3.5beta5.tar.gz.
2753 ===> Extracting for top-3.5beta5
2754 ===> Patching for top-3.5beta5
2755 ===> Applying NetBSD patches for top-3.5beta5
2756 ===> Configuring for top-3.5beta5
2757 /bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3.5beta5/.defaults
2758 chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install
2760 Reading configuration from last time...
2762 Using these settings:
2763 Bourne Shell /bin/sh
2765 Compiler options -DHAVE_GETOPT -O
2767 Install command /usr/bin/install
2774 Random passwd access yes
2779 bin directory $(PREFIX)/bin
2780 man directory $(PREFIX)/man/man1
2784 Building Makefile...
2785 Building top.local.h...
2787 Doing a "make clean".
2788 rm -f *.o top core core.* sigdesc.h
2789 To create the executable, type "make".
2790 To install the executable, type "make install".
2791 ===> Building for top-3.5beta5
2792 cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c top.c
2793 awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
2794 cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c commands.c
2795 cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c display.c
2796 cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c screen.c
2797 cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c username.c
2798 cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c utils.c
2799 utils.c: In function `errmsg':
2800 utils.c:348: warning: return discards `const' from pointer target type
2801 cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c version.c
2802 cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c getopt.c
2803 cc "-DOSREV=12G" -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
2805 cc -o top top.o commands.o display.o screen.o username.o utils.o version.o getopt.o machine.o -ltermcap -lm -lkvm
2811 >> Checksum OK for top-3.5beta5.tar.gz.
2812 ===> Installing for top-3.5beta5
2813 /usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
2814 /usr/bin/install top.1 /usr/pkg/man/man1/top.1
2815 strip /usr/pkg/bin/top
2816 ===> Registering installation for top-3.5beta5
2824 >> Checksum OK for top-3.5beta5.tar.gz.
2825 ===> Building package for top-3.5beta5
2826 Creating package top-3.5beta5.tgz
2827 Registering depends:.
2828 Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'
2831 ======================================================
2832 Appendix B: Layout of the FTP server's package archive
2833 ======================================================
2835 Layout for precompiled binary packages on ftp.netbsd.org:
2837 /pub/NetBSD/packages/
2840 pkgsrc -> /pub/NetBSD/NetBSD-current/pkgsrc
2858 - cd /usr/pkgsrc ; make install ; make package
2859 - upload /usr/pkgsrc/packages to
2860 ftp://ftp.netbsd.org/pub/NetBSD/packages/\
2861 `uname -r | sed 's@\.\([0-9]*\)[\._].*@\.\1@'`/`uname -p`
2862 - if necessary ln -s `uname -m` `uname -p`
2864 Disk space needed: unknown.
2866 Packages for a release version of NetBSD should be uploaded to the
2867 directory major.minor corresponding to the appropriate release. Packages
2868 for NetBSD with versions such as "1.5.1" should be uploaded to the "1.5"
2869 directory, stripping the tiny number off the directory name. For packages
2870 that need to be tightly coupled with the OS Version, such as LKM's, you
2871 may create a major.minor.tiny release directory, and place those packages
2872 therein. Such packages should be marked with the variable
2873 "OSVERSION_SPECIFIC=yes" to mark them in some way for binary package
2877 ###########################################################################
2881 # sentence-end-double-space: nil