Annotation of pkgsrc/Packages.txt, Revision 1.114
1.114 ! hubertf 1: # $NetBSD: Packages.txt,v 1.113 2000/09/18 10:24:59 abs Exp $
1.2 hubertf 2: ###########################################################################
3:
1.4 hubertf 4: ==========================
5: Documentation on the
6: NetBSD Package System
7: ==========================
1.1 hubertf 8:
1.4 hubertf 9: Hubert Feyrer, Alistair Crooks
1.1 hubertf 10:
11:
1.4 hubertf 12: Table of contents:
13: ==================
14:
1.105 hubertf 15: Run this command to produce a table of contents:`:w
1.9 hubertf 16: grep -B1 '^.====' Packages.txt | egrep -v '^.[-=]'
1.4 hubertf 17:
18:
19: 0 Intro
20: ========
21:
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
1.9 hubertf 24: packages collection incorporates any such changes necessary to make that
25: software run on NetBSD, and makes the installation (and reinstallation) of
26: the software package easy by means of a single command.
27:
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
1.35 agc 32: retrieval of one-line comments or more verbose descriptions are all simple.
1.9 hubertf 33:
34: Both the NetBSD packages collection and the NetBSD package system are
35: derived from FreeBSD.
1.4 hubertf 36:
37:
38: 0.1 Overview
39: =============
40:
1.35 agc 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 by
44: building your own copy using the NetBSD package system. The second
45: part, "Package Constructor's Guide", explains how to prepare a package so
46: it can be easily built by other NetBSD users without knowing about the
47: package's building details.
1.4 hubertf 48:
49:
50: 0.2 Terminology
51: ===============
52:
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:
55:
56: * Package:
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
1.35 agc 59: system. Packages are traditionally stored under /usr/pkgsrc.
1.4 hubertf 60:
61: * The NetBSD package system:
62: This is the part of the NetBSD operating system handling building
1.80 abs 63: (compiling), installing, and removing of packages.
1.4 hubertf 64:
65: * Distfile:
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.
72:
73: * Port:
74: This is the term used by FreeBSD people for what we call a package.
1.9 hubertf 75: In NetBSD terminology, "port" refers to a different architecture.
1.4 hubertf 76:
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.
84:
1.44 agc 85: Sometimes, this is referred to by the term "package" too,
86: especially in the context of precompiled packages.
1.4 hubertf 87:
88: * Program:
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.
92:
1.82 abs 93: * NetBSD RCS IDs:
1.4 hubertf 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<$>.
99:
100:
101: ====================
102: Part I: User's Guide
103: ====================
104:
105: 1 Installing a precompiled binary package
106: =========================================
107:
108: This section describes how to find, retrieve and install a precompiled
109: binary package that someone else already prepared for your type of machine.
110:
111:
112: 1.1 Where to get
113: ================
114:
1.7 hubertf 115: Precompiled packages are stored on ftp.netbsd.org and its mirrors in the
1.4 hubertf 116: directory /pub/NetBSD/packages for anon FTP access. Please pick the right
117: subdirectory there as indicated by "sysctl hw.machine_arch". In that
118: directory, there is a subdirectory for each category plus a subdirectory
119: "All" which includes the actual binaries in .tgz-files. The category
120: subdirectories use symbolic links to those files. (This is the same
121: directory layout as in /usr/pkgsrc/packages).
122:
123: This same directory layout applies for CDROM distributions, only that the
124: directory may be rooted somewhere else, probably somewhere below /cdrom.
125: Please consult your CDROM's documentation for the exact location!
126:
127:
1.80 abs 128: 1.2 How to use
129: ==============
1.4 hubertf 130:
1.10 hubertf 131: If you have the files on a CDROM or downloaded them to your hard disk, you
1.4 hubertf 132: can install them with the following command (be sure to su to root first):
133:
134: pkg_add /path/to/package.tgz
135:
136: If you have FTP access and you don't want to download the packages via FTP
137: prior to installation, you can do this automatically by giving pkg_add an
138: ftp-URL:
139:
1.80 abs 140: pkg_add ftp://ftp.netbsd.org/pub/NetBSD/packages/<OS Ver>/<arch>/All/package.tgz
141:
142: If there is any doubt, the sysctl utility can be used to determine the
143: <OS Ver>, and <arch> by running "sysctl kern.osrelease hw.machine_arch".
1.4 hubertf 144:
1.80 abs 145: Also note that any prerequisite packages needed to run the package in
146: question will be installed, too, assuming they are present where you install
147: from.
1.4 hubertf 148:
149: After you've installed packages, be sure to have /usr/pkg in your $PATH so
150: you can actually start the just installed program.
151:
152:
153: 1.3 A word of warning
154: =====================
155:
156: Please pay very careful attention to the warnings expressed in that manual
157: page about the inherent dangers of installing binary packages which you did
158: not create yourself, and the security holes that can be introduced onto
159: your system by indiscriminate adding of such files.
160:
161:
162: 2 Installing by Building
163: ========================
1.1 hubertf 164:
1.2 hubertf 165: This assumes that the package is already part of the NetBSD package system.
1.4 hubertf 166: If it is not, then you are advised to read part II of this document,
1.35 agc 167: "Package Constructor's Guide".
1.4 hubertf 168:
169:
1.108 tron 170: 2.1 Requirements
171: ================
172:
173: To build packages from source on a NetBSD system the "comp" and the "text"
174: distribution sets must be installed. If you want to build X11 related
175: packages the "xbase" and "xcomp" distribution sets are required, too.
176:
177:
178: 2.2 Where to get pkgsrc
1.4 hubertf 179: =======================
1.2 hubertf 180:
181: To get the package source going, you need to get the pkgsrc.tar.gz file
182: from ftp://ftp.netbsd.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz and
183: unpack it into /usr/pkgsrc.
1.1 hubertf 184:
1.27 hubertf 185: As an alternative, you can get pkgsrc via the Software Update Protocol,
186: SUP. To do so, make sure your supfile has a line saying "release=pkgsrc" in
187: it, see the examples in /usr/share/examples/supfiles, and that the
1.28 hubertf 188: directory /usr/pkgsrc does exist. Then, simply start "sup -v
189: /path/to/your/supfile".
1.27 hubertf 190:
1.4 hubertf 191:
1.108 tron 192: 2.3 Fetching distfiles
1.4 hubertf 193: ======================
194:
195: There is one gotcha: The distribution file (i.e. the unmodified source)
196: must exist on your system for the packages system to be able to build it.
1.80 abs 197: If it does not, then ftp(1) is used to fetch the distribution files
1.4 hubertf 198: automatically.
199:
1.49 frueauf 200: You can overwrite some of the major distribution sites to fit to sites
201: that are close to your own. Have a look at /usr/pkgsrc/mk/mk.conf.example
1.80 abs 202: to find some examples. This may save some of your bandwidth and time.
203:
204: When you have selected your settings, install your configuration into
205: /etc/mk.conf
1.49 frueauf 206:
1.10 hubertf 207: If you don't have a permanent Internet connection and you want to know
1.4 hubertf 208: which files to download, "make fetch-list" will tell you what you'll need.
209: Put these distfiles into /usr/pkgsrc/distfiles.
210:
211:
1.108 tron 212: 2.4 How to build and install
1.4 hubertf 213: ============================
214:
1.2 hubertf 215: Assuming that has been done, become root and change into the relevant
1.4 hubertf 216: directory. Then you can type
1.1 hubertf 217:
218: make
219:
220: at the shell prompt to build the various components of the package, and
221:
222: make install
223:
224: at the shell prompt to install the various components into the correct
1.4 hubertf 225: places on your system.
1.1 hubertf 226:
1.2 hubertf 227: Taking the top system utility as an example, we can install it on our
1.80 abs 228: system by building as shown in appendix A.1.
1.1 hubertf 229:
1.4 hubertf 230: The program is installed under the default root of the packages tree -
1.35 agc 231: /usr/pkg. Should this not conform to your tastes, simply set the LOCALBASE
1.4 hubertf 232: variable in your environment, and it will use that value as the root of
233: your packages tree. So, to use /usr/local, set
1.1 hubertf 234:
1.35 agc 235: LOCALBASE=/usr/local
236:
1.106 dmcmahil 237: in your environment. Please note that you should use a root which is
238: dedicated to packages and not shared with other programs (ie, do not try
239: and use LOCALBASE=/usr). This is to prevent possible conflicts between
240: programs and other files installed by the package system and whatever else
241: may have been installed there. There is, of course, one exception to
242: this - X11 packages are traditionally installed in the X11 tree. The
243: definition used to identify the root of the X11 tree is the X11BASE
244: definition.
1.91 agc 245:
246: It is possible to install X11 packages in the LOCALBASE tree, for
247: which you must install the xpkgwedge package
248: (pkgsrc/pkgtools/xpkgwedge) - see section 7.1 for further details.
1.35 agc 249:
1.49 frueauf 250: Some packages look in /etc/mk.conf to alter some configuration options
1.91 agc 251: at build time. Have a look at /usr/pkgsrc/mk/mk.conf.example to get
252: an overview of what you can set there. Environment variables such as
1.80 abs 253: LOCALBASE, and X11BASE can also be set in /etc/mk.conf to save having
254: to remember to set them each time you want to use pkgsrc.
1.95 hubertf 255:
256: If you want to deinstall and re-install a binary package that you've
257: created (see next section) or that you put into pkgsrc/packages
258: manually, you can use the the "bin-install" target, which will
259: install a binary package - if available - via pkg_add, and do a "make
260: package" else.
1.49 frueauf 261:
1.1 hubertf 262:
1.101 hubertf 263: 3 Making precompiled packages
264: =============================
265:
266: 3.1 Packaging a single package
1.4 hubertf 267: ==============================
1.101 hubertf 268:
1.4 hubertf 269: Once you have built and installed the package as mentioned above, you can
270: build it into a "binary package" - you might want to do this so that you
271: can use the binaries you have just built on another NetBSD system, or to
272: provide a simple means for others to use your binary package instead of
273: wasting CPU time - this is done by changing to the appropriate directory in
274: the pkgsrc tree, and typing the command
1.1 hubertf 275:
276: make package
277:
1.4 hubertf 278: at the shell prompt. This will build and install your package (if not
279: already done), and then construct a binary package out of the results so
280: that you can use the pkg_* tools to manipulate this. The binary package is
281: stored under /usr/pkgsrc/packages, it's in the form of a gzipped file at
282: the present time. See appendix A.2 for a continuation of the above top
283: example.
1.1 hubertf 284:
1.4 hubertf 285: Please see the "submitting" section later in this document on how to submit
286: such a binary package.
1.1 hubertf 287:
288:
1.101 hubertf 289: 3.2 Doing a bulk build of all packages
290: ======================================
291:
292: If you want to get a full set of precompiled binary packages, this section
293: describes how to get them. Beware that the bulk build will remove all
294: currently installed packages from your your system! Having a FTP server
295: configured either on the machine doing the bulk builds or on a nearby NFS
296: server can help to make the packages available to everyone. See ftpd(8) for
297: more information. If you use a remote NFS server's storage, be sure to not
298: actually compile on NFS storage, as this slows things down a lot.
299:
300:
1.112 hubertf 301: 3.2.1 Configuration
302: ===================
303:
304: 3.2.1.1 /etc/mk.conf
305: ====================
1.101 hubertf 306:
307: You may want to set things in /etc/mk.conf:
308:
309: BATCH= yes # required for bulk builds
1.111 hubertf 310: DEPENDS_TARGET?= bulk-install
311: PACKAGES?= ${PKGSRCDIR}/packages/${MACHINE_ARCH}
312: OBJMACHINE?= 1 # use work.${MACHINE_ARCH}
313: WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
314: FAILOVER_FETCH= yes # insist on the correct checksum
315: PKG_DEVELOPER?= yes
316: ACCEPTABLE_LICENSES= shareware \
317: fee-based-commercial-use \
318: no-profit \
319: no-commercial-use \
320: non-commercial-use \
1.112 hubertf 321: limited-redistribution \
322: kermit-license \
323: sun-swing-license \
324: sun-jsdk20-license
1.111 hubertf 325:
326:
1.112 hubertf 327: 3.2.1.2 build.conf
328: ==================
329:
330: In pkgsrc/mk/bulk, copy ``build.conf-example'' to ``build.conf'' and
331: edit it, following the comments in that file. This is the config
332: file that determines where logfiles are generated after the build,
333: where to mail the build report, where your pkgsrc is located and
334: which user to su(8) to to do a 'cvs update'.
1.101 hubertf 335:
336:
337: 3.2.2 Other environmental considerations
338: ========================================
339:
1.110 hubertf 340: Drop your favourite login shell in /usr/local, or install it from
341: /etc/rc.local. Also, be sure to install ssh before starting it from
1.101 hubertf 342: rc.local:
343:
1.110 hubertf 344: ( cd /usr/pkgsrc/security/ssh ; make bulk-install )
1.101 hubertf 345: if [ -f /usr/pkg/etc/rc.d/sshd.sh ]; then
346: /usr/pkg/etc/rc.d/sshd.sh
347: fi
348:
349: Not doing so will result in you being not able to log in via ssh
350: after the bulk build is finished. You have been warned! :)
351:
352:
353: 3.2.3 Operation
354: ===============
355:
1.112 hubertf 356: Make sure you don't need any of the packages still installed.
357: BEWARE: During the bulk build, ALL packages will be removed!!!
358: Be sure to remove all other things (from /usr/local, ...). Become
359: root and type:
1.101 hubertf 360:
361: # cd /usr/pkgsrc
1.112 hubertf 362: # sh mk/bulk/build
363:
364: If for some reason your last build didn't complete (power failure,
365: system panic, ...), you can continue it by running:
366:
367: # sh mk/bulk/build restart
368:
369: At the end of the bulk run, you will get a summary via mail, and find
370: build logs in the directory specified by "FTP" in the "build.conf"
371: file.
372:
373:
374: 3.2.4 What it does
375: ==================
376:
377: The bulk builds consist of three steps:
378:
379: 1. pre-build: The script updates your pkgsrc via (anon)cvs, then cleans
380: out any broken distfiles, and removes all packages installed.
381:
382: 2. the bulk build: This is basically 'make bulk-package' with an optimized
383: order in which packages will be built. Packages that don't require
384: other packages will be built first, and packages with many depends
385: will be built later.
386:
387: 3. post-build: Generates a report that's placed in the directory specified
388: in the build.conf file named ``broken.html'', a short version of
389: that report will also be mailed to the build's admin.
1.101 hubertf 390:
391: During the build, a list of broken packages will be compiled in
392: .usr/pkgsrc/.broken (or .../.broken.${MACHINE} if OBJMACHINE is set),
393: individual build logs of broken builds can be found in the package's
394: directory. These files are used by the bulk-targets to mark broken builds
395: to not waste time trying to rebuild them, and they can be used to debug
1.112 hubertf 396: these broken package builds later.
1.101 hubertf 397:
398:
1.112 hubertf 399: 3.2.5 Disk space requirements
1.101 hubertf 400: =============================
401:
402: Currently, roughly the following requirements are valid for
1.112 hubertf 403: 1.5/i386:
1.101 hubertf 404:
405: * Distfiles: 1500MB (NFS ok)
1.112 hubertf 406: * Full set of all binaries: 1000MB (NFS ok)
1.101 hubertf 407: * Temp space for compiling: 1500MB (local disk recommended)
408:
409: Note that all pkgs will be deinstalled as soon as they are turned into a
410: binary package, and that work-sources are removed, so there is no huge
411: demand to disk space. Afterwards, if the package is needed again, it will
412: be installed via pkg_add instead of building again, so there are no cycles
1.112 hubertf 413: wasted by recompiling.
1.101 hubertf 414:
415:
1.35 agc 416: ====================================
417: Part II: Package Constructor's Guide
418: ====================================
1.1 hubertf 419:
1.4 hubertf 420: 4 Package components - files, directories and contents
421: ======================================================
1.1 hubertf 422:
1.4 hubertf 423: Whenever you're preparing a package from the FreeBSD ports collection or
1.82 abs 424: doing it from scratch, there are a number of files involved which are
1.4 hubertf 425: described in the following sections. Special directions are given for what
426: differs from FreeBSD ports for each file.
1.1 hubertf 427:
428:
1.4 hubertf 429: 4.1 Makefile
430: ============
1.1 hubertf 431:
1.4 hubertf 432: Building, installation and creation of a binary package are all controlled
433: by the package's Makefile.
1.1 hubertf 434:
1.4 hubertf 435: There is a Makefile for each package. This file includes the standard
1.27 hubertf 436: bsd.pkg.mk file (referenced as "../../mk/bsd.pkg.mk"), which sets all the
437: definitions and actions necessary for the package to compile and install
438: itself. The mandatory fields are the DISTNAME which specifies the base name
439: of the distribution file to be downloaded from the site on the Internet,
440: MASTER_SITES which specifies that site, CATEGORIES which denotes the
441: categories into which the package falls, PKGNAME which is the name of the
442: package and the MAINTAINER name. This is so that anyone who quibbles with
443: the (always completely correct) decisions taken by the guy who maintains
444: the port can complain vigorously.
1.51 tv 445:
446: The MASTER_SITES may be set to one of the predefined sites:
447:
448: ${MASTER_SITE_XCONTRIB}
449: ${MASTER_SITE_GNU}
450: ${MASTER_SITE_PERL_CPAN}
451: ${MASTER_SITE_TEX_CTAN}
452: ${MASTER_SITE_SUNSITE}
453:
454: If one of these predefined sites is chosen, you may require the ability to
455: specify a subdirectory of that site. Since these macros may expand to
456: more than one actual site, you MUST use the following construct to specify
457: a subdirectory:
458:
1.53 tron 459: ${MASTER_SITE_GNU:=subdirectory/name/}
1.51 tv 460:
1.53 tron 461: (Note the trailing slash after the subdirectory name.) Use of the deprecated
462: MASTER_SITE_SUBDIR will not work.
1.4 hubertf 463:
464: Currently the following values are available for CATEGORIES. If more than
1.10 hubertf 465: one is used, they need to be separated by spaces:
1.4 hubertf 466:
1.92 wiz 467: archivers databases ham net security
468: audio devel japanese news shells
469: benchmarks distfiles lang packages sysutils
470: biology editors mail parallel templates
471: cad emulators math pkglocate textproc
472: comms fonts mbone pkgtools www
473: converters games meta-pkgs plan9 x11
474: cross graphics misc print
1.4 hubertf 475:
1.49 frueauf 476: See the NetBSD packages(7) manual page for a description of all available
477: options and variables.
1.4 hubertf 478:
479: Please pay attention to the following gotchas, especially when preparing a
1.26 agc 480: package from the FreeBSD ports collection:
1.4 hubertf 481:
1.36 agc 482: - Remove all MANx and CATx definitions from the package Makefile -
483: NetBSD has implemented automatic manual page handling, and these
484: definitions are now obsolete.
1.4 hubertf 485: - Add MANCOMPRESSED (if not already there) if manpages are installed in
1.25 frueauf 486: compressed form by the package; see comment in bsd.pkg.mk
1.4 hubertf 487: - Replace /usr/local by ${PREFIX} in all files (see patches below)
1.44 agc 488: - Delete any ldconfig commands - this will be done automatically for you
489: if the NetBSD platform supports ldconfig, and other measures will be
490: taken on platforms which do not support ldconfig (e.g. NetBSD/Alpha)
1.4 hubertf 491: - If modifying a package from the FreeBSD ports collection, preserve
492: their RCS ID: remove the '$'s around the FreeBSD RCS Id, and insert the
493: word FreeBSD, then add a <$>NetBSD<$> (Without the <>s, please remember
494: the Terminology section), i.e.:
1.1 hubertf 495:
1.4 hubertf 496: before:
497: # <$>Id: Makefile,v 1.17 1997/06/16 06:39:51 max Exp <$>
1.1 hubertf 498:
1.4 hubertf 499: after:
500: # <$>NetBSD<$>
501: # FreeBSD Id: Makefile,v 1.17 1997/06/16 06:39:51 max Exp
1.26 agc 502: - If the package installs any info files, the main info directory file
503: needs to be updated to reflect this fact. NetBSD now has an INFO_FILES
504: definition, which is used to do this. For example, to install the
505: indent.info entry into the info directory file, simply use the
506:
1.32 agc 507: INFO_FILES= indent.info
1.26 agc 508:
509: definition in the package Makefile. If the package does this insertion
510: for you, you should specify USE_GTEXINFO in the package Makefile, to
511: ensure that the pre-requisite GNU texinfo package is installed on your
512: system.
1.30 frueauf 513: - Adjust MAINTAINER to be either yourself, if you plan to maintain the
514: package for future updates, or set it to the default MAINTAINER
515: packages@netbsd.org, as it is unlikely that the FreeBSD people will
516: care about NetBSD packages.
1.42 tsarna 517: - If there exists a home page for the software in question, please
518: add the variable HOMEPAGE right after MAINTAINER. The value of this
519: variable should be the URL for the home page.
1.1 hubertf 520:
1.4 hubertf 521: 4.2 files/*
522: ===========
1.1 hubertf 523:
1.82 abs 524: * files/md5:
525: Most important, the mandatory md5 checksum of all the distfiles needed for
526: the package to compile, confirming they match the original file any patches
527: were generated against. This ensures that the distfile retrieved from the
528: Internet has not been corrupted during transfer or altered by a malign force
529: to introduce a security hole. It can be generated by hand using the md5(1)
530: command or by invoking "make makesum".
531:
532: * files/patch-sum:
533: The checksum file for all the official patches for the package, found in the
534: patches/ directory (see section 4.3). This checksum file includes an MD5
535: checksum of all lines in the patch file except the NetBSD RCS Id. This file
536: is generated by invoking "make makepatchsum".
1.55 agc 537:
1.4 hubertf 538: Besides that, if you have any files that you wish to be placed in the
539: package prior to configuration or building, you could place these files
1.82 abs 540: here and use a ${CP} command in the pre-configure target to achieve this.
1.4 hubertf 541: Alternatively, you could simply diff the file against /dev/null and use the
542: patch mechanism to manage the creation of this file.
1.1 hubertf 543:
544:
1.4 hubertf 545: 4.3 patches/*
546: =============
1.1 hubertf 547:
1.4 hubertf 548: This directory contains files that are used by the patch(1) command to
549: modify the sources as distributed in the distribution file into a form that
550: will compile and run perfectly on NetBSD. The files are applied
551: successively in alphabetic order (as returned by a shell "patches/patch-*"
552: glob expansion), so patch-aa is applied before patch-ab etc.
1.1 hubertf 553:
1.94 hubertf 554: The patch-?? files should be in diff -bu format, and apply without
555: a fuzz to avoid problems. (The latter condition is ensured by
556: setting PKG_DEVELOPER in /etc/mk.conf - the build will fail if a
557: patch applies with fuzz only). Furthermore, do not put changes
558: for more than one file into a single patch-file, as this will make
559: future modifications more difficult.
1.4 hubertf 560:
561: One important thing to mention is to pay attention that no RCS IDs get
562: stored in the patch files, as these will cause problems when later checked
1.97 hubertf 563: into the NetBSD CVS tree. To avoid this, use the "-U 2" or "-U 1" option to
1.4 hubertf 564: diff.
1.1 hubertf 565:
1.92 wiz 566: If you don't want to worry about the problems in the last two paragraphs
567: yourself, use pkgdiff from the pkgtools/pkgdiff package, which takes care
568: of any RCS Ids by itself.
569:
570: For even more automation, we recommend using mkpatches from the same
571: package to make a whole set of patches. You just have to backup files
572: before you edit them to "filename.orig", e.g. with "cp -p filename
573: filename.orig". If you upgrade a package this way, you can easily compare
574: the new set of patches with the previously existing one with patchdiff.
575:
1.4 hubertf 576: When preparing a FreeBSD port for the NetBSD packages system, it's likely
577: that the FreeBSD port will work on NetBSD. However, check that the person
578: who ported the software to FreeBSD has not played fast and loose with the
579: __FreeBSD__ cpp definition without good cause - a simple way to do this is
580: to do
1.1 hubertf 581:
1.4 hubertf 582: grep -i freebsd patches/patch-??
1.1 hubertf 583:
1.4 hubertf 584: in the package directory.
1.1 hubertf 585:
1.4 hubertf 586: Besides taking care of any FreeBSDisms, be sure to provide patches to
1.80 abs 587: replace any occurrence of /usr/local in any "Makefile"s in the original
1.4 hubertf 588: package with ${PREFIX}.
1.55 agc 589:
590: When you have finished a package, remember to generate the checksums
591: for the patch files by using the "make makepatchsum" command, see
592: section 4.2.
1.1 hubertf 593:
594:
1.4 hubertf 595: 4.4 pkg/*
596: =========
1.1 hubertf 597:
1.4 hubertf 598: This directory contains several files used to manage the creation of binary
599: packages. Files from this directory are used in the binary package itself,
1.2 hubertf 600: and will thus be installed on other machines, so you should be aware that
601: there is a wider audience than you might think for your comments and
602: witticisms.
1.1 hubertf 603:
1.4 hubertf 604: 4.4.1 Mandatory files
605: =====================
1.1 hubertf 606:
1.4 hubertf 607: * pkg/COMMENT:
608: A one-line description of the piece of software. There is no need to
1.7 hubertf 609: mention the package's name - this will automatically be added by the
1.4 hubertf 610: pkg_* tools when they are invoked.
611:
612: * pkg/DESCR:
613: A multi-line description of the piece of software. This should include
614: any credits where they are due. Please bear in mind that others do not
1.80 abs 615: share your sense of humour (or spelling idiosyncrasies), and that others
1.4 hubertf 616: will read everything that you write here.
617:
618: * pkg/PLIST:
619: This file governs the files that are installed on your system: all the
620: binaries, manual pages, etc. There are other directives which may be
621: entered in this file, to control the creation and deletion of
1.7 hubertf 622: directories, and the location of inserted files.
1.1 hubertf 623:
1.4 hubertf 624: If you're updating a FreeBSD package to work for NetBSD, please pay special
625: attention to the following things in pkg/PLIST:
1.1 hubertf 626:
1.52 agc 627: - If there are any "@exec ldconfig ..." statements, or any "@unexec
628: ldconfig ...", delete them. NetBSD works out automatically whether to
629: call ldconfig, since some NetBSD architectures do not have ldconfig.
1.4 hubertf 630: - Add any missing @dirrm statements
1.82 abs 631: - Remove any MANx= definitions in the package Makefile
1.69 agc 632:
633: You could also investigate the port2pkg package (pkgsrc/pkgtools/port2pkg),
634: which does a lot of the donkey work for you.
1.1 hubertf 635:
636:
1.4 hubertf 637: 4.4.2 Optional files
638: ====================
1.1 hubertf 639:
1.4 hubertf 640: * pkg/INSTALL:
641: Shell script invoked twice during pkg_add. First time after package
642: extraction and before files are moved in place, the second time after
1.7 hubertf 643: the files to install are moved in place. This can be used to do any
1.4 hubertf 644: custom procedures not possible with @exec commands in PLIST. See
645: pkg_add(1) and pkg_create(1) for more information.
646:
647: * pkg/DEINSTALL:
1.66 hubertf 648: This script is executed before and after any files are removed. It is
649: this script's responsibility to clean up any additional messy details
650: around the package's installation, since all pkg_delete knows is how to
1.4 hubertf 651: delete the files created in the original distribution. See pkg_delete(1)
652: and pkg_create(1) for more information.
653:
654: * pkg/REQ:
655: Require-script that is invoked before installation and de-installation
656: to ensure things like certain accounts being available, user/sysadmin
657: agreeing with usage policy, etc.
1.29 frueauf 658:
659: * pkg/MESSAGE
1.49 frueauf 660: Display this file after installation of the package.
1.29 frueauf 661: Useful for things like legal notices on almost-free software,
662: etc.
1.1 hubertf 663:
664:
1.4 hubertf 665: 4.5 scripts/*
666: =============
1.1 hubertf 667:
1.4 hubertf 668: This directory contains any files that are necessary for configuration of
669: your software, etc. If a script with any of the following names is present,
670: it will be executed at the appropriate time during the build process:
1.1 hubertf 671:
1.4 hubertf 672: pre-fetch post-fetch
673: pre-extract post-extract
674: pre-patch post-patch
675: pre-configure post-configure configure
676: pre-build post-build
677: pre-install post-install
678: pre-package post-package
1.1 hubertf 679:
1.82 abs 680: Note that you should NOT define a pre-* or post-* target in the Makefile
681: which executes the matching scripts/[pre|post]-* script. bsd.pkg.mk runs
682: any existing Makefile target first, then searches for scripts/* and runs
683: it using sh(1). Running the script from the Makefile would cause it to
684: be run twice.
685:
1.4 hubertf 686: See section 7 for a description of the build process.
1.1 hubertf 687:
688:
1.4 hubertf 689: 4.6 work/*
690: ==========
1.1 hubertf 691:
692: When you type "make" the distribution files are unpacked into this
693: directory. It can be removed by typing
694:
695: make clean
696:
1.4 hubertf 697: at the shell prompt. Also, this directory is used to keep various
698: timestamp files.
1.46 bad 699:
1.49 frueauf 700:
1.46 bad 701: 4.7 importing the package into CVS
702: ==================================
703:
704: Newly created packages should be imported with a vendor tag of "TNF" and
705: a release tag of "pkgsrc-base", e.g::
706:
707: cvs import pkgsrc/<category>/frobnitz TNF pkgsrc-base
708:
1.82 abs 709: Packages derived from a FreeBSD port should be imported with a vendor tag
1.46 bad 710: of "FREEBSD" and a release tag of "FreeBSD-current-YYYY-MM-DD" (YYYY-MM-DD
711: being the date when the snapshot of the port were taken form the FreeBSD
712: tree), and then doing the necessary modifications by normal CVS operations.
713: E.g:
714:
715: cvs import pkgsrc/<category>/mumbler FREEBSD FreeBSD-current-1998-04-01
716: cvs rm patches/patch-a
717: cvs add patches/patch-aa
718: cvs ci
1.4 hubertf 719:
1.92 wiz 720: Please note all package updates/additions in doc/pkg-CHANGES! It's very
721: important to keep this file up to date and conforming to the existing
722: format, because it will be used by scripts to automatically update pages on
723: www.netbsd.org.
1.49 frueauf 724:
1.4 hubertf 725:
726: 5 PLIST* issues
727: ===============
728:
1.82 abs 729: This section addresses some special issues that one needs to pay attention
730: to when dealing with the PLIST file (or files, see below!).
1.4 hubertf 731:
732:
1.10 hubertf 733: 5.1 Miscellaneous
1.4 hubertf 734: =================
735:
1.82 abs 736: * NetBSD RCS Id:
737: Be sure to add a RCS ID line as the first thing in any PLIST file you
1.4 hubertf 738: write:
739:
740: @comment <$>NetBSD<$>
741:
742: * ranlib:
743: Don't put any ranlib commands into your PLIST files, as they will cause
744: troubles when the package is removed. Just make sure the build-process
745: does run ranlib - it usually does - and you can leave this out. This is
746: usually only a problem when using ports from FreeBSD.
747:
748: * ldconfig:
1.43 agc 749: Don't put any ldconfig commands into your PLIST files, as they will
750: cause problems. All shared object caching is done automatically in
751: NetBSD (this takes place when you see the "Automatic shared object
752: handling" message), and so you can leave this out. If any shared
753: objects are found in the package, they will be dealt with
754: automatically, running ldconfig on platforms which need it, and not
755: otherwise. This is usually only a problem when using ports from
756: FreeBSD.
1.4 hubertf 757:
1.37 hubertf 758: * ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}:
1.4 hubertf 759: Some packages like emacs and perl embed information about which
760: architecture they were built on into the pathnames where they install
761: their file. To handle this case, PLIST will be preprocessed before
1.11 hubertf 762: actually used, and the symbol "${MACHINE_ARCH}" will be replaced by
1.37 hubertf 763: what "sysctl -n hw.machine_arch" gives. The same is done if the string
764: ${MACHINE_GNU_ARCH} is embedded in PLIST somewhere - use this on
765: packages that use GNU autoconfigure.
1.11 hubertf 766:
767: Legacy note: There used to be a symbol "<$ARCH>" that was replaced by
1.43 agc 768: the output of "uname -m", but that's no longer supported and has been
769: removed.
1.45 hubertf 770:
771: * ${OPSYS}, ${OS_VERSION}:
772: Some packages want to embed the OS name and version into some paths.
773: to do this, use these two variables in PLIST. ${OPSYS} will be replaced
774: by output from "uname -s", ${OS_VERSION} will be set to what "uname -r"
775: gives.
1.4 hubertf 776:
777: * Manpage-compression:
1.5 hubertf 778: Manpages should be installed in compressed form if MANZ is set (in
1.4 hubertf 779: bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST
780: file, the suffix ".gz" is appended/removed automatically for manpages
781: according to MANZ and MANCOMPRESSED being set or not, see above for
1.6 hubertf 782: details. This modification of the PLIST file is done on a copy of it,
783: not pkg/PLIST itself.
1.4 hubertf 784:
1.90 hubertf 785: * Semi-automatic PLIST generation:
786: You can use the "make print-PLIST" command to output a PLIST that matches
787: any new files since the package was extracted. If the package installs
788: files via tar(1) or other methods that don't update file access times, be
789: sure to add these files manually to your pkg/PLIST!
790:
1.4 hubertf 791:
792: 5.2 MD/MI vs. general PLIST
793: ===========================
794:
795: Sometimes the packaging list in pkg/PLIST differs between platforms, e.g.
796: if one of them supports shared libs and the other does not. To address
797: this, a hook has been introduced into the NetBSD packages system to provide
798: a PLIST file defined on conditions set freely in the package's Makefile.
799:
800:
801: 5.2.1 $PLIST_SRC
802: ================
803:
804: To use one or more files as source for the PLIST used in generating the
805: binary package, set the variable PLIST_SRC to the names of that file(s).
806: The files are later concatenated using cat(1), and order of things is an
807: important issue, see below.
808:
809:
810: 5.2.2 PLIST-mi, PLIST-md.shared, PLIST-md.static
811: ================================================
812:
813: If PLIST_SRC is not set (the usual case), and if there is no pkg/PLIST, the
1.10 hubertf 814: packages system looks for pkg/PLIST-mi, and pkg/PLIST-md.shared or
1.4 hubertf 815: pkg/PLIST-md.static to handle differences due to the platform being able to
816: handle shared libs or not. PLIST-mi contains machine independent files,
817: PLIST-md.* contain machine dependent files, which may differ between
818: architectures that don't support dynamic libs/shared loading. Currently,
819: this is only used in the perl-packages, and as perl5 on alpha doesn't
820: support dynamic loading of extensions like perl/Tk yet, PLIST.mi-static is
821: also used on the alpha (besides pmax and powerpc). Alpha will hopefully be
822: removed soon when perl's fixed for dynamic loading.
1.1 hubertf 823:
1.4 hubertf 824: (This handling of MI/MD PLIST files is implemented by setting PLIST_SRC to
825: either "PLIST-mi PLIST-md.static" or "PLIST-mi PLIST-md.shared", see
1.25 frueauf 826: /usr/pkgsrc/mk/bsd.pkg.mk).
1.1 hubertf 827:
1.4 hubertf 828:
829: 5.2.3 Order in the PLIST* file(s)
830: =================================
831:
832: There is one gotcha regarding the ordering of @dirrm statements: any MI
833: @dirrm directives that follow any MD @dirrm's *must* go into the PLIST.md-*
834: files, as the files PLIST-mi and PLIST.md-{shared/static} are concatenated
835: in exactly this order. If the MI directory would be listed in PLIST-mi, it
836: would be removed before the MD directory, which wouldn't work.
837:
838: E.g. if you have the following dirs:
839: foo/mi
840: foo/mi/md
841:
842: then PLIST-mi contains:
843: <nothing>
844:
845: and PLIST-md.* contain:
846: @dirrm foo/mi/md
847: @dirrm foo/mi
848:
849: This will lead to some @dirrm statements being duplicated, but it's the
1.35 agc 850: only way to ensure everything is properly removed. The same care must be
1.4 hubertf 851: taken when PLIST_SRC is set to some package-specific settings.
852:
1.109 jlam 853:
854: 5.3 Perl5 modules
855: =================
856:
857: Perl5 modules will install into different places depending on the version
858: of perl used during the build process. To address this, the NetBSD
859: packages system will append lines to the PLIST corresponding to the files
860: listed in the installed .packlist file generated by most perl5 modules.
861: This is invoked by defining PERL5_PACKLIST to a space-separated list of
862: paths to packlist files:
863:
864: PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
865:
866: The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent
867: the three locations in which perl5 modules may be installed, and may be
868: used by perl5 packages that don't have a packlist. These three variables
869: are also substituted for in the PLIST.
1.4 hubertf 870:
871: 6 Notes on fixes for packages
872: =============================
873:
874: 6.1 CPP defines
875: ===============
1.1 hubertf 876:
1.2 hubertf 877: To port an application to NetBSD, it's usually necessary for the compiler
878: to be able to judge the system on which it's compiling, and we use
879: definitions so that the C pre-processor can do this.
880:
881: The really impatient should just note that a number of the FreeBSD ports
882: (which are called packages in the NetBSD world) rely on the CPP definition
1.4 hubertf 883: __FreeBSD__. This should be used sparingly, for FreeBSD-specific features,
884: but unfortunately this is not always the case. A number also rely on the
885: fact that the CPU type is an Intel-based little-endian CPU.
1.2 hubertf 886:
887: To test whether you are working on a 4.4 BSD-derived system, you should use
888: the BSD definition, which is defined in <sys/param.h> on said systems.
1.1 hubertf 889:
890: #include <sys/param.h>
891:
1.2 hubertf 892: and then you can surround the BSD-specific parts of your port using the
893: conditional:
1.1 hubertf 894:
895: #if (defined(BSD) && BSD >= 199306)
896: ...
897: #endif
898:
1.2 hubertf 899: Please use the __NetBSD__ definition sparingly - it should only apply to
900: features of NetBSD that are not present in other 4.4-lite derived BSDs.
1.1 hubertf 901:
902: You should also avoid defining __FreeBSD__=1 and then simply using the
1.4 hubertf 903: FreeBSD port, if only from an aesthetic viewpoint.
904:
1.1 hubertf 905:
1.39 hubertf 906: 6.2 Shared libraries - libtool
907: ==============================
908:
909: NetBSD supports many different machines, with different object formats
910: like a.out and ELF, and varying abilities to do shared library and
1.80 abs 911: dynamic loading at all. To accompany this, varying commands and options
1.39 hubertf 912: have to be passed to the compiler, linker etc. to get the Right Thing,
1.44 agc 913: which can be pretty annoying especially if you don't have all the
914: machines at your hand to test things. The "libtool" pkg can help
915: here, as it just "knows" how to build both static and dynamic
916: libraries from a set our source files, thus being platform
917: independent.
1.39 hubertf 918:
1.89 rh 919: Here's how to use libtool in a pkg in six simple steps:
1.39 hubertf 920:
1.43 agc 921: 1. Add USE_LIBTOOL= yes to the package Makefile.
1.39 hubertf 922:
923: 2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of
924: ${CC}. You could even add it to the definition of CC, if only
925: libraries are being built in a given Makefile. This one command will
926: build both PIC and non-PIC library objects, so you need not have
927: separate shared and non-shared library rules.
928:
929: 3. For the linking of the library, remove any "ar", "ranlib", and "ld
930: -Bshareable" commands, and use instead:
931:
932: ${LIBTOOL} --mode=link cc -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor
933:
934: Note that the library is changed to have a .la extension, and the
935: objects are changed to have a .lo extension. Change OBJS as necessary.
936: This automatically creates all of the .a, .so.major.minor, and ELF
937: symlinks (if necessary) in the build directory.
938:
939: 4. When linking programs that depend on these libraries _before_ they are
940: installed, preface the cc or ld line with "${LIBTOOL} --mode=link", and
941: it will find the correct libraries (static or shared), but please be
942: aware that libtool will not allow you to specify a relative path in -L
943: (such as -L../somelib), because it is trying to force you to change
944: that argument to be the .la file. For example:
945:
946: ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
947:
948: won't work; it needs to be changed to:
949:
950: ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
951:
952: and it will DTRT with the libraries. If you *must* use a relative path
953: with -L, and you are not going to run this program before installing
954: it, you can omit the use of libtool during link and install of this
955: program if you add the subdirectory ".libs" in your -L command:
956:
957: ${CC} -o someprog -L../somelib/.libs -lsomelib
958:
959: 5. When installing libraries, preface the install or cp command with
960: "${LIBTOOL} --mode=install", and change the library name to .la. For
961: example:
962:
963: ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
964:
965: This will install the static .a, shared library, any needed symlinks,
966: and run "ldconfig."
967:
968: 6. In your PLIST, include the .a, .la, and .so.major.minor files. Don't
1.96 hubertf 969: include the ELF symlink files (.so.major, .so); those are added
970: automatic.
1.39 hubertf 971:
1.88 hubertf 972:
973: 6.3 Using libtool on GNU packages that already support libtool
974: ==============================================================
1.87 rh 975:
1.75 sakamoto 976: Add USE_LIBTOOL=yes and LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig to the
1.82 abs 977: package Makefile as the quick way to bypass the pkg's own libtool.
1.75 sakamoto 978: The pkg's own libtool is made by ltconfig script at do-configure target.
1.82 abs 979: If USE_LIBTOOL and LTCONFIG_OVERRIDE are defined, the specified ltconfig is
1.87 rh 980: overridden, using the devel/libtool instead of the pkg's own libtool.
1.82 abs 981: If the pkg already has an original "libtool" which we can replace with
1.87 rh 982: devel/libtool you may have to specify LIBTOOL_OVERRIDE to the package
1.82 abs 983: Makefile.
1.107 wiz 984:
1.39 hubertf 985:
1.88 hubertf 986: 6.4 Gotchas of FreeBSD ports
1.4 hubertf 987: ============================
1.1 hubertf 988:
1.4 hubertf 989: See section 4.1 for Makefile issues (MANx, CATx, MANCOMPRESSED, ldconfig,
990: RCS IDs) and section 4.3 for gotchas on using patches from FreeBSD ports.
1.1 hubertf 991:
1.44 agc 992: One of the biggest problems with FreeBSD ports is that too many of
993: them assume they will install into /usr/local, instead of honouring
1.80 abs 994: any ${PREFIX} setting properly. To change this, add something like the
1.44 agc 995: following into your package Makefile:
1.4 hubertf 996:
997: pre-configure:
998: for f in `find ${WRKDIR} -type f -print|xargs grep -l '/usr/local'`; do
999: \
1.17 hubertf 1000: ${SED} -e 's:/usr/local:'${PREFIX}':g' < $$f > $$f.pdone && ${MV} $
1.4 hubertf 1001: $f.pdone $$f; \
1002: done
1003:
1.7 hubertf 1004: This is taken from the sysutils/rtty package; be sure this works for your
1.4 hubertf 1005: package - it may actually make sense to look for some things in /usr/local,
1.10 hubertf 1006: for example. So don't blindly replace all occurrences of /usr/local!
1.6 hubertf 1007:
1.44 agc 1008: FreeBSD has decided to list manual pages in the package Makefile, with
1009: no corresponding entry in the PLIST. You will thus need to add any
1010: MAN[1-8ln] files to the PLIST, before deleting the MAN[1-8ln]
1011: definition. Similarly with MLINKS and CAT[1-8ln] entries.
1012:
1013: Side note on manpages in PLIST: we don't take any notice of any .gz
1014: suffix there, as many FreeBSD ports seem to have .gz pages in PLIST
1015: even when they install manpages without compressing them; rather, we
1016: add our own .gz suffix there according to MANZ. In short, it does not
1017: matter whether the manual page name in the PLIST has a .gz suffix or
1018: not - if it needs one which is not already there, it will be appended
1019: automatically, and if there is a .gz suffix which is not needed, it
1020: will be deleted automatically.
1.54 agc 1021:
1022: Some packages use bsd-style .mk files when building, and so any manual
1023: pages that are installed will be gzip-compressed, if MANZ is set, or
1024: not if MANZ is not set. If the package uses bsd-style .mk files, the
1025: variable MANCOMPRESSED_IF_MANZ should be set to a value of "yes" in
1026: the package Makefile.
1.4 hubertf 1027:
1028:
1.88 hubertf 1029: 6.5 Feedback to the author
1.4 hubertf 1030: ==========================
1031:
1032: If you have found any bugs in the package you make available, if you had to
1.82 abs 1033: do special steps to make it run under NetBSD or if you enhanced the software
1034: in various other ways, be sure to report these changes back to the original
1035: author of the program! With that kind of support, the next release of the
1036: program can incorporate these fixes, and people not using the NetBSD packages
1037: system can win from your efforts.
1.4 hubertf 1038:
1039: Support the idea of free software!
1040:
1041:
1042: 7 The build process
1043: ===================
1044:
1.35 agc 1045: The basic steps for building a program are always the same. First the
1.4 hubertf 1046: program's source (distfile) must be brought to the local system and
1.35 agc 1047: then extracted. After any patches to compile properly on NetBSD are
1048: applied, the software can be configured, then built (usually by
1.44 agc 1049: compiling), and finally the generated binaries etc. can be put into
1.35 agc 1050: place on the system. These are exactly the steps performed by the
1051: NetBSD package system, which is implemented as a series of targets in
1052: a central Makefile, /usr/pkgsrc/mk/bsd.pkg.mk.
1.4 hubertf 1053:
1054:
1055: 7.1 Program location
1056: ====================
1057:
1058: Before outlining the process performed by the NetBSD package system in the
1059: next section, here's a brief discussion on where programs are installed,
1060: and which variables influence this.
1061:
1.40 tv 1062: The automatic variable PREFIX indicates where all files of the final
1063: program shall be installed. It is usually set to $LOCALBASE (/usr/pkg),
1.41 tv 1064: or $CROSSBASE for pkgs in the "cross" category, though its value becomes
1.48 agc 1065: that of $X11BASE if USE_IMAKE, USE_MOTIF, or USE_X11BASE is set. The value
1.41 tv 1066: ${PREFIX} needs to be put into the various places in the program's source
1067: where paths to these files are encoded; see sections 4.3 and 6.2 for
1068: details on this.
1.40 tv 1069:
1070: When choosing which of these variables to use, follow the following rules:
1071:
1072: * ${PREFIX} always points to the location where the current pkg will be
1073: installed. When referring to a pkg's own installation path, use ${PREFIX}.
1074:
1075: * ${LOCALBASE} is where all non-X11 pkgs are installed. If you need to
1076: construct a -I or -L argument to the compiler to find includes and
1077: libraries installed by another non-X11 pkg, use ${LOCALBASE}.
1078:
1079: * ${X11BASE} is where the actual X11 distribution is installed. When looking
1080: for _standard_ X11 includes (not those installed by a pkg), use ${X11BASE}.
1081:
1082: * X11 based pkgs are special in that they may be installed in either
1.91 agc 1083: X11BASE or LOCALBASE. To install X11 packages in LOCALBASE, simply
1084: install the xpkgwedge package (pkgsrc/pkgtools/xpkgwedge).
1.40 tv 1085: If you need to find includes or libraries installed by a pkg that has
1.48 agc 1086: USE_IMAKE, USE_MOTIF, or USE_X11BASE in its pkg Makefile, you need to use
1.61 dmcmahil 1087: _both_ ${X11BASE} and ${LOCALBASE}.
1.4 hubertf 1088:
1.91 agc 1089: * ${X11BASE} points to the root of the installed X11 tree. To refer to the
1090: installed location of an X11 package, use the ${X11PREFIX} definition (this
1091: will be ${X11BASE} if xpkgwedge is not installed, and ${LOCALBASE} if
1092: xpkgwedge is installed).
1093:
1.4 hubertf 1094:
1095: 7.2 Main targets
1096: ================
1097:
1.25 frueauf 1098: The main targets used during the build process defined in bsd.pkg.mk are:
1.4 hubertf 1099:
1100: * fetch:
1101: This will check if the file(s) given in the variables DISTFILES and
1102: PATCHFILES (as defined in the package's Makefile) are present on the
1103: local system in /usr/pkgsrc/distfiles. If they are not present, they
1104: will be fetched using ftp(1) from the site(s) given in the variable
1.58 bad 1105: PATCH_SITES. The location(s) in PATCH_SITES are in the form of URLs
1.4 hubertf 1106: and can be ftp://- and http://-URLs, as ftp(1) understands both of
1107: them.
1108:
1109: * checksum:
1110: After the distfile(s) are fetched, their MD5 checksum is generated and
1111: compared with the checksums stored in the files/md5 file. If the
1112: checksums don't match, the build is aborted. This is to ensure the same
1113: distfile is used for building, and that the distfile wasn't changed,
1.73 hubertf 1114: e.g. by some malign force, deliberately changed distfiles on the master
1115: distribution site or network lossage.
1.4 hubertf 1116:
1117: * extract:
1118: When the distfiles are present on the local system, they need to be
1.35 agc 1119: extracted, as they are usually in the form of some compressed archive
1120: format, most commonly .tar.gz. If only some of the distfiles need to be
1.4 hubertf 1121: uncompressed, the files to be uncompressed should be put into
1122: EXTRACT_ONLY. If the distfiles are not in .tar.gz format, they can be
1123: extracted by setting EXTRACT_CMD, EXTRACT_BEFORE_ARGS and/or
1124: EXTRACT_AFTER_ARGS.
1125:
1126: * patch:
1127: After extraction, all the patches named by the PATCHFILES and those
1.35 agc 1128: present in the patches subdirectory of the package are applied.
1129: Patchfiles ending in .Z or .gz are uncompressed before they are
1130: applied, files ending in .orig or .rej are ignored. Any special
1131: options to patch(1) can be handed in PATCH_DIST_ARGS. See section
1132: 4.3 for more details.
1.94 hubertf 1133:
1134: If PKG_DEVELOPER is set in /etc/mk.conf, patch is given special args
1135: to make it fail if the patches with some lines of fuzz. Please fix
1136: (regen) the patches so that they apply cleanly. The rationale behind
1137: this is that patches that apply cleanly may end up being applied in the
1138: wrong place, and cause severe harm there.
1.4 hubertf 1139:
1140: * configure:
1.35 agc 1141: Most pieces of software need information on the header files,
1142: system calls, and library routines which are available in NetBSD.
1143: This is the process known as configuration, and is usually
1144: automated. In most cases, a script is supplied with the source,
1.80 abs 1145: and its invocation results in generation of header files,
1.4 hubertf 1146: Makefiles, etc.
1147:
1148: If the program doesn't come with its own configure script, one can be
1149: placed in the package's scripts directory, called "configure". If so, it
1150: is executed using sh(1).
1151:
1.33 agc 1152: If the program's distfile contains its own configure script, this can
1.4 hubertf 1153: be invoked by setting HAS_CONFIGURE. If the configure script is a GNU
1154: autoconf script, GNU_CONFIGURE should be specified instead. In either
1155: case, any arguments to the configure script can be specified in the
1156: CONFIGURE_ARGS variable, and the configure script's name can be set in
1157: CONFIGURE_SCRIPT if it differs from the default "configure".
1158:
1159: If the program uses an Imakefile for configuration, the appropriate
1160: steps can be invoked by setting USE_IMAKE to YES. (If you only want the
1.91 agc 1161: package installed in $X11PREFIX but xmkmf not being run, set USE_X11BASE
1.4 hubertf 1162: instead!)
1163:
1164: * build:
1.35 agc 1165: Once configuration has taken place, the software can be built on
1166: NetBSD by invoking $MAKE_PROGRAM on $MAKEFILE with $ALL_TARGET as
1167: the target to build. The default MAKE_PROGRAM is "gmake" if
1168: USE_GMAKE is set, "make" otherwise. MAKEFILE is set to "Makefile"
1169: by default, and ALL_TARGET defaults to "all". Any of these
1170: variables can be set to change the default build process.
1.4 hubertf 1171:
1172: * install:
1.35 agc 1173: Once the build stage has completed, the final step is to install
1174: the software in public directories, for users. As in the
1175: build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but with
1176: the $INSTALL_TARGET instead, the latter defaulting to "install"
1177: (plus "install.man", if USE_IMAKE is set).
1178:
1179: If no target is specified, the default is "build". If a subsequent stage
1180: is requested, all prior stages are made: e.g. "make build" will also
1181: perform the equivalent of:
1182:
1183: make fetch
1184: make checksum
1185: make extract
1186: make patch
1187: make configure
1188: make build
1.4 hubertf 1189:
1190:
1191: 7.3 Other helpful targets
1192: =========================
1193:
1194: * pre/post-*
1195: For any of the main targets described in the previous section, two
1.35 agc 1196: auxiliary targets exist with "pre-" and "post-" used as a prefix
1197: for the main target's name. These targets are invoked before and
1198: after the main target is called, allowing extra configuration or
1199: installation steps, for example, which program's configure script
1200: or install target omitted. For any of these auxiliary targets,
1201: scripts of the same name can be placed in the package's
1.4 hubertf 1202: scripts-subdirectory that will be executed at the given time, see
1203: section 4.5.
1204:
1205: * do-*:
1.35 agc 1206: Should one of the main targets do the wrong thing, and should there
1207: be no variable to fix this, you can redefine it with the do-*
1208: target. (Note that redefining the target itself instead of the
1209: do-* target is a bad idea, as the pre-* and post-* targets won't be
1.71 agc 1210: called anymore, etc.) You will not usually need to do this.
1.4 hubertf 1211:
1212: * reinstall:
1213: If you did a "make install" and you noticed some file was not installed
1.10 hubertf 1214: properly, you can repeat the installation with this target, which will
1.4 hubertf 1215: ignore the "already installed" flag.
1216:
1.44 agc 1217: * deinstall:
1218: This target does a pkg_delete(1) in the current directory,
1.59 hubertf 1219: effectively de-installing the package. The following variables can
1.62 rh 1220: be used either on the command line or in /etc/mk.conf to tune the
1.59 hubertf 1221: behaviour:
1222:
1223: - PKG_VERBOSE:
1224: Add a "-v" to the pkg_delete(1) command.
1225:
1226: - DEINSTALLDEPENDS:
1227: Remove all packages that require (depend on) the given package.
1228: This can be used to remove any packages that may have been pulled in
1229: by a given package, e.g. if "make deinstall DEINSTALLDEPENDS=1" is
1230: done in x11/kde, this is likely to remove whole KDE. Works by adding
1231: a "-R" to the pkg_delete command line.
1.62 rh 1232:
1233: * update:
1234: This target causes the current package to be updated to the latest
1235: version. The package and all depending packages first get deinstalled,
1236: then current versions of the corresponding packages get compiled and
1237: installed. This is similar to manually noting which packages are
1.79 rh 1238: currently installed, then performing a series of "make deinstall" and
1239: and "make install" (or whatever DEPENDS_TARGET is set to) for these
1240: packages.
1.62 rh 1241:
1.70 rh 1242: You can use the "update" target to resume package updating in case a
1.79 rh 1243: previous "make update" was interrupted for some reason. However, in
1244: this case, make sure you don't call "make clean" or otherwise remove
1245: the list of dependent packages in ${WRKDIR}. Otherwise you lose the
1246: ability to automatically update the current package along with the
1247: dependent packages you have installed.
1248:
1.100 rh 1249: Resuming an interrupted "make update" will only work as long as the
1.79 rh 1250: package tree remains unchanged. If the source code for one of the
1.100 rh 1251: packages to be updated has been changed, resuming "make update" will
1.79 rh 1252: most certainly fail!
1.70 rh 1253:
1254: The following variables can be used either on the command line or in
1255: /etc/mk.conf to alter the behaviour of "make update":
1.62 rh 1256:
1257: - DEPENDS_TARGET:
1.65 rh 1258: Install target to use for the updated package and the
1259: dependent packages. Defaults to "install". E.g.
1260: "make update DEPENDS_TARGET=package"
1.70 rh 1261:
1262: - NOCLEAN:
1263: Don't clean up after updating. Useful if you want to leave the
1264: work sources of the updated packages around for inspection or
1265: other purposes. Be sure you eventually clean up the source
1266: tree (see the "clean-update" target below) or you may run into
1267: troubles with old source code still lying around on your next
1268: "make" or "make update".
1269:
1270: - REINSTALL:
1.100 rh 1271: Deinstall each package before installing (making ${DEPENDS_TARGET}).
1272: This may be necessary if the "clean-update" target (see below) was
1273: called after interrupting a running "make update".
1.70 rh 1274:
1275: * clean-update:
1276: Clean the source tree for all packages that would get updated if
1277: "make update" was called from the current directory. This target
1278: should not be used if the current package (or any of its depending
1279: packages) have already been deinstalled (e.g., after calling "make
1280: update") or you may lose some packages you intended to update.
1281: As a rule of thumb: only use this target _before_ the first time
1282: you call "make update" and only if you have a dirty package tree
1283: (e.g., if you used NOCLEAN). The following variables can be used
1284: either on the command line or in /etc/mk.conf to alter the behaviour
1285: of "make clean-update":
1286:
1287: - CLEAR_DIRLIST:
1288: After "make clean", do not reconstruct the list of directories to
1289: update for this package. Only use this if "make update" successfully
1290: installed all packages you wanted to update. Normally, this is done
1291: automatically on "make update", but may have been suppressed by the
1292: NOCLEAN variable (see above).
1.44 agc 1293:
1.104 tron 1294: * info:
1295: This target invokes "pkg_info" for the current package. You can use this
1296: e.g. to check which version of a package is installed.
1297:
1.44 agc 1298: * readme:
1299: This target generates a README.html file, which can be viewed using a
1.114 ! hubertf 1300: browser such as navigator (pkgsrc/www/navigator) or lynx
! 1301: (pkgsrc/www/lynx). The generated files contain references to any
! 1302: packages which are in the ${PACKAGES} directory on the local host. The
! 1303: generated files can be made to refer to URLs based on FTP_PKG_URL_HOST
! 1304: and FTP_PKG_URL_DIR. For example, if I wanted to generate README.html
1.44 agc 1305: files which pointed to binary packages on the local machine, in the
1306: directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
1307: FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
1.114 ! hubertf 1308: subdirectories will be searched for all the binary packages.
1.60 hubertf 1309:
1310: * readme-all:
1311: Use this target to create a file README-all.html which contains a
1312: list of all packages currently available in the NetBSD Packages
1313: Collection, together with the category they belong to and a short
1314: description. This file is compiled from the pkgsrc/*/README.html
1315: files, so be sure to run this _after_ a "make readme".
1.44 agc 1316:
1317: * cdrom-readme:
1318: This is very much the same as the readme: target (see above), but is
1319: to be used when generating a pkgsrc tree to be written to a CD-ROM.
1320: This target also produces README.html files, and can be made to refer
1321: to URLs based on CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
1.56 agc 1322:
1323: * show-distfiles:
1324: This target shows which distfiles and patchfiles are needed to build
1.82 abs 1325: the package. (DISTFILES and PATCHFILES, but not patches/*)
1.57 agc 1326:
1327: * show-downlevel:
1328: This target shows nothing if the package is not installed. If a version
1329: of this package is installed, but is not the version provided in this
1330: version of pkgsrc, then a warning message is displayed. This target can
1331: be used to show which of your installed packages are downlevel, and so
1332: the old versions can be deleted, and the current ones added.
1.85 agc 1333:
1334: * show-pkgsrc-dir:
1335: This target shows the directory in the pkgsrc hierarchy from which the
1336: package can be built and installed. This may not be the same directory
1337: as the one from which the package was installed. This target is intended
1338: to be used by people who may wish to upgrade many packages on a single
1339: host, and can be invoked from the top-level pkgsrc Makefile by using the
1.86 agc 1340: target "show-host-specific-pkgs"
1.44 agc 1341:
1.94 hubertf 1342: * check-shlibs:
1343: After a package is installed, check all it's binaries and (on ELF
1344: platforms) shared libraries if they find the shared libs they need.
1345: Run by default if PKG_DEVELOPER is set in /etc/mk.conf.
1.101 hubertf 1346:
1347: * bulk-package:
1348: Used to do bulk builds. If an appropriate binary package already exists,
1349: no action is taken. If not, this target will compile, install and
1350: package it (and it's depends, if PKG_DEPENDS is set properly, see
1351: section 3.2.1). After creating the binary package, the sources, the
1352: just-installed package and it's required packages are removed,
1353: preserving free disk space.
1354:
1355: * bulk-install:
1356: Used during bulk-installs to install required packages. If an
1357: appropriate binary package is available, it will be installed via
1358: pkg_add. If not, "make bulk-package" will be executed, but the installed
1359: binary not be removed. A binary package is "appropriate" to be installed
1360: via pkg_add if:
1361:
1362: - None of the package's files (Makefile, ...) were modified since it
1363: was built
1364: - None of the package's required (binary) packages were modified since
1365: it was built
1.44 agc 1366:
1.4 hubertf 1367: 8 Debugging
1368: ===========
1369:
1.77 hubertf 1370: To check out all the gotchas when building a package (wither from
1371: a FreeBSD port, or from scratch), here are the steps that I do in
1372: order to get a package working. Please note this is basically the
1373: same as what was explained in the previous sections, only with some
1374: debugging aids.
1.1 hubertf 1375:
1.94 hubertf 1376: - Make sure PKG_DEVELOPER=1 is in /etc/mk.conf
1.4 hubertf 1377: - Retrieve port from FreeBSD collection
1378: - Fix RCS-ID in the package's Makefile, see section 4.1.
1.10 hubertf 1379: - Import unchanged FreeBSD source (ONLY if you have cvs access, not needed
1.4 hubertf 1380: otherwise):
1.12 hubertf 1381: (cd .../pkgsrc/category/pkgname ; cvs import pkgsrc/category/pkgname \
1.4 hubertf 1382: FREEBSD FreeBSD-current-yyyy-mm-dd)
1.33 agc 1383: - If you did a CVS import, check it out to apply the following fixes
1.12 hubertf 1384: (not needed if you don't have CVS access!)
1.4 hubertf 1385: - Look at Makefile, fix if necessary; see section 4.1.
1386: - Look at patches, remember if not appropriate
1387: - Have a look at pkg/PLIST, add a "@comment <$>NetBSD<$>" line at the
1388: beginning of any PLIST file (see section 5).
1389: - make
1.10 hubertf 1390: - If something is not ok, fix; for patches: fix the file, then re-generate
1.18 hubertf 1391: the diff: 'diff -bu foo.orig foo >../../patches/patch-xx' (mv patch-xx
1.4 hubertf 1392: patch-xx.orig before); If there's no foo.orig from a previous patch, be
1393: sure to have an old version of the file somewhere; re-iterate :)
1.10 hubertf 1394: - If all builds OK: touch /tmp/bla
1.4 hubertf 1395: - make install
1396: - find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla >/tmp/x
1.10 hubertf 1397: (or whatever you set LOCALBASE and X11BASE to)
1.4 hubertf 1398: - pkg_delete blub
1.90 hubertf 1399: - find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla (or diff against output of
1400: 'make print-PLIST'): if this brings up any files, that are missing in
1401: pkg/PLIST*; add them.
1.35 agc 1402: - Compare pkg/PLIST* against /tmp/x, fix the former one
1.4 hubertf 1403: ( sort /tmp/x >/tmp/x2 ; sort pkg/PLIST >/tmp/P ; sdiff /tmp/x2 /tmp/P )
1404: - make reinstall && make package
1405: - pkg_delete blub
1406: - "find /usr/pkg/ /usr/X11R6/ -type f -newer /tmp/bla" shouldn't find anything
1407: now
1408: - pkg_add .../blub.tgz
1409: - Play with it :)
1410: - pkg_delete - still no file should be left (re-run above find)
1.82 abs 1411: - make clean && touch /tmp/bla && make install && make clean && make deinstall
1412: then run the find again. Yes, some software authors write Makefiles that
1413: install files during the build target. Sigh. Re-run the find, and fix the
1414: PLIST. Repeat until certain the software does not install any files that
1415: aren't in PLIST.
1.33 agc 1416: - submit (or commit, if you have cvs access); see section 10.
1.1 hubertf 1417:
1418:
1.4 hubertf 1419: 9 FAQs & features of the package system
1420: =======================================
1.1 hubertf 1421:
1.103 wiz 1422: 9.1 Packages using GNU autoconfig
1.82 abs 1423: 9.2 Other distrib methods than .tar.gz
1424: 9.3 Packages not creating their own subdirectory
1425: 9.4 Custom configuration process
1426: 9.5 Packages not building in their DISTNAME directory
1427: 9.6 How to fetch all distfiles at once
1428: 9.7 How to fetch files from behind a firewall
1429: 9.8 If your patch contains an RCS ID
1430: 9.9 How to pull in variables from /etc/mk.conf
1431: 9.10 Is there a mailing list for pkg-related discussion?
1432: 9.11 How do i tell "make fetch" to do passive FTP?
1433: 9.12 Dependencies on other packages
1434: 9.13 Conflicts with other packages
1435: 9.14 Software which has a WWW Home Page
1436: 9.15 How to handle modified distfiles with the 'old' name
1.98 rh 1437: 9.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
1438: 9.17 How to handle incrementing versions when fixing an existing package
1439: 9.18 "Could not find bsd.own.mk" - what's wrong?
1440: 9.19 Restricted packages
1.103 wiz 1441: 9.20 Packages using (n)curses
1.82 abs 1442:
1443:
1444: 9.1 Packages using GNU autoconfig
1.4 hubertf 1445: =================================
1.1 hubertf 1446:
1.4 hubertf 1447: If your package uses GNU autoconf, add the following to your package's
1448: Makefile:
1.1 hubertf 1449:
1450: > GNU_CONFIGURE= yes
1451:
1.2 hubertf 1452: Note that this appends --prefix=${PREFIX} to CONFIGURE_ARGS, so you don't
1453: have to do that yourself, and this may not be what you want.
1.1 hubertf 1454:
1455:
1.4 hubertf 1456: 9.2 Other distrib methods than .tar.gz
1457: ======================================
1.1 hubertf 1458:
1.4 hubertf 1459: If your package uses a different distribution method from .tar.gz, take a
1.113 abs 1460: look at the package for editors/sam, which uses a gzipped shell archive
1.2 hubertf 1461: (shar), but the quick solution is to set EXTRACT_SUFX to the name after the
1.44 agc 1462: DISTNAME field, and add the following to your package's Makefile:
1.2 hubertf 1463:
1.1 hubertf 1464: > EXTRACT_SUFX= .msg.gz
1465: > EXTRACT_CMD= zcat
1466: > EXTRACT_BEFORE_ARGS=
1467: > EXTRACT_AFTER_ARGS= |sh
1468:
1469:
1.4 hubertf 1470: 9.3 Packages not creating their own subdirectory
1471: ================================================
1472:
1473: Your package doesn't create a subdirectory for itself (like GNU software
1474: does, for instance), but extracts itself in the current directory: see
1.113 abs 1475: editors/sam again, but the quick answer is:
1.2 hubertf 1476:
1.1 hubertf 1477: > NO_WRKSUBDIR= yes
1478:
1479:
1.4 hubertf 1480: 9.4 Custom configuration process
1481: ================================
1482:
1483: Your package uses a weird Configure script: See the top package, but the
1484: quick answer is:
1.2 hubertf 1485:
1.1 hubertf 1486: > HAS_CONFIGURE= yes
1487: > CONFIGURE_SCRIPT= Configure
1.44 agc 1488: > CONFIGURE_ARGS+= netbsd13
1.1 hubertf 1489:
1490:
1.44 agc 1491: 9.5 Packages not building in their DISTNAME directory
1.4 hubertf 1492: ======================================================
1493:
1.44 agc 1494: Your package builds in a different directory from its base DISTNAME - see
1.4 hubertf 1495: tcl and tk packages:
1496:
1497: > WRKSRC= ${WRKDIR}/${DISTNAME}/unix
1498:
1499:
1500: 9.6 How to fetch all distfiles at once
1501: ======================================
1.2 hubertf 1502:
1.4 hubertf 1503: You would like to download all the distfiles in a single batch from work or
1504: university, where you can't run a "make fetch". But there's no archive of
1505: the distfiles on ftp.netbsd.org and the one on ftp.freebsd.org contains
1506: many distfiles for which there are no ports (yet).
1507:
1508: The answer here is to do a "make fetch-list" in /usr/pkgsrc and use the
1509: resulting list.
1510:
1511:
1512: 9.7 How to fetch files from behind a firewall
1513: =============================================
1514:
1.82 abs 1515: If you are sitting behind a firewall which does not allow direct connections
1516: to Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts.
1517: This is done using an environment variable in the form of a URL
1.35 agc 1518: e.g. in Amdahl, the machine orpheus.amdahl.com is one of the firewalls, and
1.4 hubertf 1519: it uses port 80 as the proxy port number. So the proxy environment
1520: variables look like:
1521:
1522: ftp_proxy=ftp://orpheus.amdahl.com:80/
1523: http_proxy=http://orpheus.amdahl.com:80/
1.1 hubertf 1524:
1525:
1.4 hubertf 1526: 9.8 If your patch contains an RCS ID
1527: ====================================
1.2 hubertf 1528:
1.4 hubertf 1529: See section 4.3 on how to remove RCS IDs from patch files.
1.20 tron 1530:
1531:
1.22 tron 1532: 9.9 How to pull in variables from /etc/mk.conf
1533: ==============================================
1.21 hubertf 1534:
1535: The problem with package-defined variables that can be overridden via
1.32 agc 1536: MAKECONF or /etc/mk.conf is that make(1) expands a variable as it is
1537: used, but evaluates preprocessor like statements (.if, .ifdef and
1538: .ifndef) as they are read. So, to use any variable (which may be set
1539: in /etc/mk.conf) in one of the .if* statements, the file /etc/mk.conf
1540: must be included before that .if* statement.
1541:
1542: Rather than have a number of ad-hoc ways of including /etc/mk.conf,
1543: should it exist, or MAKECONF, should it exist, include the
1544: pkgsrc/mk/bsd.prefs.mk file in the package Makefile before any
1545: preprocessor-like .if, .ifdef, or .ifndef statements:
1546:
1547: .include "../../mk/bsd.prefs.mk"
1548:
1549: .if defined(USE_MENUS)
1550: ...
1551: .endif
1.23 hubertf 1552:
1553:
1554: 9.10 Is there a mailing list for pkg-related discussion?
1555: ========================================================
1556:
1.38 hubertf 1557: Yes. We are using tech-pkg@netbsd.org for discussing package related
1558: issues. To subscribe do:
1.23 hubertf 1559:
1.38 hubertf 1560: echo subscribe tech-pkg | mail majordomo@netbsd.org
1.24 hubertf 1561:
1562:
1563: 9.11 How do i tell "make fetch" to do passive FTP?
1564: ==================================================
1565:
1.82 abs 1566: This depends on which utility is used to retrieve distfiles. From
1567: bsd.pkg.mk, FETCH_CMD is assigned the first available command from the
1568: following list:
1569:
1570: /usr/bin/fetch
1571: ${LOCALBASE}/bsd/bin/ftp
1572: /usr/bin/ftp
1573:
1574: On a default NetBSD install, this will be /usr/bin/ftp, which automatically
1575: tries passive connections first, and falls back to active connections if the
1576: server refuses to do passive. For the other tools, add the following to your
1577: /etc/mk.conf file: PASSIVE_FETCH=1
1578:
1579: Having that option present will prevent /usr/bin/ftp from falling back to
1580: active transfers.
1.33 agc 1581:
1.49 frueauf 1582:
1.33 agc 1583: 9.12 Dependencies on other packages
1584: ===================================
1585:
1.72 dmcmahil 1586: Your package may depend on some other package being present - and there are
1587: various ways of expressing this dependency. NetBSD supports the
1588: BUILD_DEPENDS and DEPENDS definitions (beware: the DEPENDS definition is
1589: not the same as FreeBSD's deprecated one, and NetBSD does not use the
1590: FreeBSD LIB_DEPENDS definition any more - it proved problematic on ELF
1591: NetBSD platforms).
1592:
1593: [In the following examples, the BUILD_DEPENDS dependencies have the format:
1594: <file>:<directory containing package to build>[:<stage>] If the <stage>
1595: isn't specified, it defaults to ``install''. If the file contains a '/', it
1596: is interpreted as a regular file - otherwise, the name is taken to be an
1597: executable file, and the PATH is searched for <file>. If the regular file
1.80 abs 1598: is not found, or the executable file is not in the path, then the
1.33 agc 1599: pre-requisite package will be built from the sources in <directory
1.72 dmcmahil 1600: containing the package to build>. The DEPENDS definition specifies a
1.33 agc 1601: package name (which contains its version number), and the directory
1602: containing the package to build if this version of the package is not
1603: installed.]
1604:
1605: (a) If your package needs files from another package to build, see the
1606: print/ghostscript5 package (it relies on the jpeg sources being
1607: present in source form during the build):
1608:
1.76 hubertf 1609: BUILD_DEPENDS+= ../../graphics/jpeg/${WRKDIR:T}/jpeg-6a:../../graphics/jpeg:extract
1.33 agc 1610:
1611: (b) If your package needs to use another package to build itself, this
1612: is specified using the BUILD_DEPENDS definition, but without
1613: specifying the stage ``:extract'' in (a) above. An example is the
1614: print/lyx package, which uses the latex binary during its build
1615: process:
1616:
1.76 hubertf 1617: BUILD_DEPENDS+= latex:../../print/teTeX
1.33 agc 1618:
1619: (c) If your package needs a library with which to link, this is
1620: specified using the DEPENDS definition. An example of this is the
1621: print/lyx package, which uses the xpm library, version 3.4j to build.
1622:
1623: DEPENDS+= xpm-3.4j:../../graphics/xpm
1.64 tron 1624:
1625: You can also use wildcards in package dependences:
1626:
1627: DEPENDS+= xpm-*:../../graphics/xpm
1628:
1.84 jdolecek 1629: Note that such wildcard dependencies are retained when creating
1630: binary package. The dependency is checked when installing the binary
1631: package and any package which matches the pattern would be used.
1632: Beware that wildard dependencies should be used with a bit of care.
1633: Simple example for package which needs some version of Tk installed,
1634: but doesn't care which exactly - dependency
1635:
1636: DEPENDS+= tk-*:../../x11/tk80
1637:
1638: would also match e.g. tk-postgresql-6.5.3, which is not what was
1639: needed. ALWAYS ensure that the wildcard doesn't match more than it should.
1.33 agc 1640:
1.72 dmcmahil 1641: (d) If your package needs some executable to be able to run correctly, this
1642: is specified using the DEPENDS definition. The print/lyx package needs to
1643: be able to execute the latex binary from the teTex package when it runs,
1644: and that is specified:
1645:
1.76 hubertf 1646: DEPENDS+= teTex-*:../../print/teTeX
1.33 agc 1647:
1.84 jdolecek 1648: The comment about wildcard dependencies from previous paragraph
1649: applies here, too.
1.34 frueauf 1650:
1.49 frueauf 1651:
1.34 frueauf 1652: 9.13 Conflicts with other packages
1653: ==================================
1654:
1655: Your package may conflict with other packages a user might already have
1656: installed on his system, e.g. if your package installs the same set of
1657: files like another package in our pkgsrc tree.
1658:
1.80 abs 1659: In this case you can set CONFLICTS to a space separated list of packages
1.34 frueauf 1660: (including version string) your package conflicts with.
1661:
1.63 tron 1662: For example pkgsrc/x11/Xaw3d and pkgsrc/x11/Xaw-Xpm install provide the
1663: same shared library, thus you set in pkgsrc/x11/Xaw3d/Makefile:
1.34 frueauf 1664:
1.63 tron 1665: CONFLICTS= Xaw-Xpm-*
1.34 frueauf 1666:
1.63 tron 1667: and in pkgsrc/x11/Xaw-Xpm/Makefile:
1.34 frueauf 1668:
1.63 tron 1669: CONFLICTS= Xaw3d-*
1.4 hubertf 1670:
1.63 tron 1671: Packages will automatically conflict with other packages with the name prefix
1672: and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
1673: with the older version "Xaw3d-1.3".
1.49 frueauf 1674:
1.98 rh 1675:
1.42 tsarna 1676: 9.14 Software which has a WWW Home Page
1677: =======================================
1678:
1679: The NetBSD packages system now supports a variable called HOMEPAGE.
1680: If the software being packaged has a home page, the Makefile should
1681: include the URL for that page in the HOMEPAGE variable. The definition
1682: of the variable should be placed immediately after the MAINTAINER
1683: variable.
1.49 frueauf 1684:
1.98 rh 1685:
1.73 hubertf 1686: 9.15 How to handle modified distfiles with the 'old' name
1687: =========================================================
1688:
1689: Sometimes authors of a software package make some modifications after the
1690: software was released, and they put up a new distfile without changing the
1691: package's version number. If a package is already in pkgsrc at that time,
1692: the md5 checksum will no longer match. The correct way to work around this
1693: is to update the package's md5 checksum to match the package on the master
1.80 abs 1694: site (beware, any mirrors may not be up to date yet!), and to remove the
1695: old distfile from ftp.netbsd.org's /pub/NetBSD/packages/distfiles directory.
1.73 hubertf 1696: Furthermore, a mail to the package's author seems appropriate making sure
1.74 hubertf 1697: the distfile was really updated on purpose, and that no trojan horse or so
1.73 hubertf 1698: crept in.
1.78 hubertf 1699:
1.98 rh 1700:
1.83 hubertf 1701: 9.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
1.78 hubertf 1702: ========================================================================
1703:
1704: When compiling the pkgsrc/pkgtools/pkg_install package, you get the error
1.83 hubertf 1705: from make that it doesn't know how to make /usr/share/tmac/tmac.andoc? This
1.78 hubertf 1706: indicates that you don't have installed the "text" set on your machine
1707: (nroff, ...). Please do that.
1708:
1.98 rh 1709:
1.81 abs 1710: 9.17 How to handle incrementing versions when fixing an existing package
1711: ========================================================================
1712:
1713: When making fixes to an existing package it can be useful to change
1714: the version number in PKGNAME. To avoid conflicting with future versions
1715: by the original author, use a 'nb1' suffix (later versions should
1716: increment this to give 'nb2' and so on).
1.93 hubertf 1717:
1.98 rh 1718:
1.93 hubertf 1719: 9.18 "Could not find bsd.own.mk" - what's wrong?
1720: ================================================
1721:
1722: You didn't install the compiler set, comp.tgz, when you installed your
1723: NetBSD machine. Please get it and install it, by extracting it in /:
1724:
1725: tar --unlink -pvxf .../comp.tgz
1726:
1727: comp.tgz is part of every NetBSD release, please get the one matching
1728: the release you have installed (determine via "uname -r").
1729:
1.4 hubertf 1730:
1.98 rh 1731: 9.19 Restricted packages
1732: ========================
1733:
1734: Some licenses restrict how software may be re-distributed. In order to
1735: satisfy these restrictions, the package system defines five make variables
1736: that can be set to note these restrictions:
1737:
1738: - RESTRICTED:
1739: This variable should be set whenever a restriction exists
1740: (regardless of its kind). Set this variable to a string
1741: containing the reason for the restriction.
1742:
1743: - NO_BIN_ON_CDROM:
1744: Binaries may not be placed on CD-ROM. Set this variable to
1745: ${RESTRICTED} whenever a binary package may not be included
1746: on a CD-ROM.
1747:
1748: - NO_BIN_ON_FTP:
1749: Binaries may not be placed on an ftp server. Set this
1750: variable to ${RESTRICTED} whenever a binary package may not
1751: not be made available on the internet.
1752:
1753: - NO_SRC_ON_CDROM:
1754: Distfiles may not be placed on CD-ROM. Set this variable to
1755: ${RESTRICTED} if re-distribution of the source code or other
1756: distfile(s) is not allowed on CD-ROMs.
1757:
1758: - NO_SRC_ON_FTP:
1759: Distfiles may not be placed on FTP. Set this variable to
1760: ${RESTRICTED} if re-distribution of the source code or other
1761: distfile(s) via the internet is not allowed.
1762:
1.99 rh 1763: Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic
1764: make variables to denote restrictions is deprecated, because they
1.98 rh 1765: unconditionally prevent users from generating binary packages!
1.103 wiz 1766:
1767: 9.20 Packages using (n)curses
1768: =============================
1769:
1770: Some packages need curses functionality that wasn't present in NetBSD's own
1771: curses prior to 1.4Y. For packages using such functionality there are some
1772: variables: If USE_CURSES is set in a package's Makefile, NEED_NCURSES is
1773: set automatically to YES or NO, depending on whether a dependency on
1774: ncurses is needed on this system. You can use this variable to e.g. add
1775: arguments to configure to tell the package whether to use ncurses.
1776:
1777: Additionally, you can set REPLACE_NCURSES to some filenames; in each of
1778: these files, each occurrence of 'ncurses' is replaced by 'curses' if the
1779: package doesn't need ncurses. You may need this in some cases if ncurses
1780: are installed, and the package's configure script prefers ncurses.
1781:
1782: For example, in mail/mutt, the relevant lines are:
1783: USE_CURSES= YES
1784: REPLACE_NCURSES= configure configure.in
1785: [...]
1786: .include "../../mk/bsd.pkg.mk"
1787:
1788: .if defined(NEED_NCURSES) && ${NEED_NCURSES} == "YES"
1789: CONFIGURE_ARGS+= --with-curses=${LOCALBASE}
1790: .endif
1791:
1792: Please note that the check for NEED_NCURSES has to be below the
1793: inclusion of bsd.pkg.mk, since the variable is set there.
1.98 rh 1794:
1795:
1.4 hubertf 1796: 10 Submitting
1797: =============
1.1 hubertf 1798:
1.4 hubertf 1799: * precompiled binary packages:
1.98 rh 1800: Our policy is that we accept binaries only from NetBSD developers to
1.68 hubertf 1801: guarantee that the packages don't contain any trojan horses etc.
1802: This is not to piss anyone off but rather to protect our users!
1803: You're still free to put up your home-made binary packages and tell
1804: the world where to get them.
1.1 hubertf 1805:
1.4 hubertf 1806: * packages:
1807: First, check that your package is complete, compiles and runs well; see
1808: section 8 and the rest of this document. Then, generate a gzipped
1809: tar-file of all the files needed for the package, preferably with all
1810: files in a single directory. Place this tar-file to a place where the
1811: package maintainers can fetch it using FTP or HTTP (WWW). Finally,
1.67 tron 1812: send-pr with category "pkg", a synopsis which includes the package name
1813: and version number, a short description of your package
1814: (contents of pkg/COMMENT are OK) and the URL of your tar-file.
1.2 hubertf 1815:
1.10 hubertf 1816: You will be notified if your send-pr has been addressed so you can remove
1.4 hubertf 1817: the tar-file.
1.1 hubertf 1818:
1819:
1.4 hubertf 1820: 11 A simple example of a package: bison
1821: =======================================
1.1 hubertf 1822:
1823: I checked to find a piece of software that isn't in the FreeBSD ports
1.4 hubertf 1824: collection, and picked GNU bison. Quite why someone would want to have
1.2 hubertf 1825: bison when Berkeley yacc is already present in the tree is beyond me, but
1826: it's useful for the purposes of this exercise.
1.1 hubertf 1827:
1.4 hubertf 1828:
1829: 11.1 files
1830: ==========
1831:
1832: The file contents in this section must be used without the "> " prefix.
1833:
1834:
1835: 11.1.1 Makefile
1836: ===============
1837:
1.13 hubertf 1838: > # <$>NetBSD<$>
1.1 hubertf 1839: >
1840: > DISTNAME= bison-1.25
1.42 tsarna 1841: > CATEGORIES= devel
1.1 hubertf 1842: > MASTER_SITES= ${MASTER_SITE_GNU}
1.25 frueauf 1843: >
1.42 tsarna 1844: > MAINTAINER= thorpej@netbsd.org
1845: > HOMEPAGE= http://www.gnu.org/software/bison/bison.html
1.1 hubertf 1846: >
1847: > GNU_CONFIGURE= yes
1.42 tsarna 1848: > INFO_FILES= bison.info
1.1 hubertf 1849: >
1.25 frueauf 1850: > .include "../../mk/bsd.pkg.mk"
1.4 hubertf 1851:
1852:
1853: 11.1.2 pkg/COMMENT
1854: ==================
1855:
1856: > GNU yacc clone.
1857:
1858:
1859: 11.1.3 pkg/DESCR
1860: ================
1861:
1862: > GNU version of yacc. Can make re-entrant parsers, and numerous other
1863: > improvements. Why you would want this when Berkeley yacc(1) is part
1864: > of the NetBSD source tree is beyond me.
1865:
1866:
1867: 11.1.4 pkg/PLIST
1868: ================
1869:
1.25 frueauf 1870: > @comment <$>NetBSD<$>
1.4 hubertf 1871: > bin/bison
1.25 frueauf 1872: > man/man1/bison.1.gz
1.50 frueauf 1873: > @unexec install-info --delete %D/info/bison.info %D/info/dir
1.25 frueauf 1874: > info/bison.info
1875: > info/bison.info-1
1876: > info/bison.info-2
1877: > info/bison.info-3
1878: > info/bison.info-4
1879: > info/bison.info-5
1.50 frueauf 1880: > @exec install-info %D/info/bison.info %D/info/dir
1.25 frueauf 1881: > share/bison.simple
1882: > share/bison.hairy
1.31 tron 1883:
1884:
1.42 tsarna 1885: 11.1.5 Checking a package "pkglint"
1886: ===================================
1.31 tron 1887:
1.42 tsarna 1888: The NetBSD package system comes with a tool called "pkglint" (located in the
1.47 abs 1889: directory "pkgsrc/pkgtools/pkglint") which helps to check the contents of these
1.31 tron 1890: files. After installation it is quite easy to use, just change to the
1.42 tsarna 1891: directory of the package you which to examine and execute "pkglint":
1.31 tron 1892:
1.42 tsarna 1893: > tron@lyssa:/usr/pkgsrc/devel/bison>pkglint
1.31 tron 1894: > OK: checking pkg/COMMENT.
1895: > OK: checking pkg/DESCR.
1896: > OK: checking Makefile.
1897: > OK: checking files/md5.
1898: > OK: checking patches/patch-aa.
1899: > looks fine.
1900:
1.42 tsarna 1901: Depending on the supplied command line arguments (see "man pkglint") more
1.61 dmcmahil 1902: intensive checks will be performed. Use e.g. "pkglint -a -v" for a very
1.31 tron 1903: detailed and verbose check.
1.4 hubertf 1904:
1905:
1906: 11.2 Steps for building, installing, packaging
1907: ==============================================
1908:
1909: Create the directory where the package lives, plus any auxiliary directories:
1910:
1911: > root@pumpy:/u/pkgsrc/lang(1765)# cd /usr/pkgsrc/lang
1912: > root@pumpy:/u/pkgsrc/lang(1765)# mkdir bison
1913: > root@pumpy:/u/pkgsrc/lang(1766)# cd bison
1.1 hubertf 1914: > root@pumpy:/u/pkgsrc/lang/bison(1768)# mkdir files patches pkg
1.4 hubertf 1915:
1916: Create Makefile, pkg/COMMENT, pkg/DESCR and pkg/PLIST as in section 11.1,
1917: then continue with fetching the distfile:
1918:
1.1 hubertf 1919: > root@pumpy:/u/pkgsrc/lang/bison(1769)# make fetch
1920: > >> bison-1.25.tar.gz doesn't seem to exist on this system.
1921: > >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
1922: > Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
1923: > ftp: Error retrieving file: 500 Internal error
1924: >
1925: > >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
1926: > Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
1927: > ftp: Error retrieving file: 500 Internal error
1928: >
1929: > >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
1930: > Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
1931: > Successfully retrieved file.
1.4 hubertf 1932:
1933: Generate the checksum of the distfile into files/md5:
1934:
1935: > root@pumpy:/u/pkgsrc/lang/bison(1770)# make makesum
1936:
1937: Now compile:
1938:
1.1 hubertf 1939: > root@pumpy:/u/pkgsrc/lang/bison(1777)# make
1940: > >> Checksum OK for bison-1.25.tar.gz.
1941: > ===> Extracting for bison-1.25
1942: > ===> Patching for bison-1.25
1943: > ===> Ignoring empty patch directory
1944: > ===> Configuring for bison-1.25
1945: > creating cache ./config.cache
1946: > checking for gcc... cc
1947: > checking whether we are using GNU C... yes
1948: > checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
1949: > checking how to run the C preprocessor... cc -E
1950: > checking for minix/config.h... no
1951: > checking for POSIXized ISC... no
1952: > checking whether cross-compiling... no
1953: > checking for ANSI C header files... yes
1954: > checking for string.h... yes
1955: > checking for stdlib.h... yes
1956: > checking for memory.h... yes
1957: > checking for working const... yes
1958: > checking for working alloca.h... no
1959: > checking for alloca... yes
1960: > checking for strerror... yes
1961: > updating cache ./config.cache
1962: > creating ./config.status
1963: > creating Makefile
1964: > ===> Building for bison-1.25
1965: > 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
1966: > 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
1967: > 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
1968: > 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
1969: > 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
1970: > 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
1971: > 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
1972: > 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
1973: > 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
1974: > 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
1975: > 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
1976: > 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
1977: > 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
1978: > 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
1979: > 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
1980: > 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
1981: > 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
1982: > 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
1983: > 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
1984: > 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
1985: > 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
1.39 hubertf 1986: > 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
1987: getopt.o getopt1.o
1.1 hubertf 1988: > ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
1989: > rm -f bison.s1
1990: > sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
1.4 hubertf 1991:
1.10 hubertf 1992: Everything seems OK, so install the files:
1.4 hubertf 1993:
1.1 hubertf 1994: > root@pumpy:/u/pkgsrc/lang/bison(1785)# make install
1995: > >> Checksum OK for bison-1.25.tar.gz.
1996: > ===> Installing for bison-1.25
1997: > sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
1998: > rm -f /usr/pkg/bin/bison
1999: > cd /usr/pkg/share; rm -f bison.simple bison.hairy
2000: > rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
2001: > install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison
2002: > /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
2003: > /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
2004: > cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
2005: > /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
2006: > ===> Registering installation for bison-1.25
1.4 hubertf 2007:
2008: You can now use bison, and also - if you decide so - remove it with
2009: "pkg_delete bison-1.25". Should you decide that you want a binary package,
2010: do this now:
2011:
1.1 hubertf 2012: > root@pumpy:/u/pkgsrc/lang/bison(1786)# make package
2013: > >> Checksum OK for bison-1.25.tar.gz.
2014: > ===> Building package for bison-1.25
2015: > Creating package bison-1.25.tgz
2016: > Registering depends:.
2017: > Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
1.4 hubertf 2018:
1.7 hubertf 2019: Now that you don't need the source and object files any more, clean up:
1.4 hubertf 2020:
1.1 hubertf 2021: > root@pumpy:/u/pkgsrc/lang/bison(1787)# make clean
2022: > ===> Cleaning for bison-1.25
2023:
2024:
1.4 hubertf 2025: ======================
2026: Appendix A: build logs
2027: ======================
1.1 hubertf 2028:
1.4 hubertf 2029: A.1 Building top
2030: ================
1.1 hubertf 2031:
1.4 hubertf 2032: > Script started on Fri Oct 3 13:22:31 1997
2033: > root@pumpy:/u/pkgsrc/sysutils/top(1342)# make
2034: > >> top-3.5beta5.tar.gz doesn't seem to exist on this system.
2035: > >> Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
2036: > Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheus.amdahl.com:80/)
2037: > Successfully retrieved file.
2038: > >> Checksum OK for top-3.5beta5.tar.gz.
2039: > ===> Extracting for top-3.5beta5
2040: > ===> Patching for top-3.5beta5
2041: > ===> Applying NetBSD patches for top-3.5beta5
2042: > ===> Configuring for top-3.5beta5
2043: > /bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3.5beta5/.defaults
2044: > chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install
2045: >
2046: > Reading configuration from last time...
2047: >
2048: > Using these settings:
2049: > Bourne Shell /bin/sh
2050: > C compiler cc
2051: > Compiler options -DHAVE_GETOPT -O
2052: > Awk command awk
2053: > Install command /usr/bin/install
2054: >
2055: > Module netbsd13
2056: > LoadMax 5.0
2057: > Default TOPN -1
2058: > Nominal TOPN 18
2059: > Default Delay 2
2060: > Random passwd access yes
2061: > Table Size 47
2062: > Owner root
2063: > Group Owner kmem
2064: > Mode 2755
2065: > bin directory $(PREFIX)/bin
2066: > man directory $(PREFIX)/man/man1
2067: > man extension 1
2068: > man style man
2069: >
2070: > Building Makefile...
2071: > Building top.local.h...
2072: > Building top.1...
2073: > Doing a "make clean".
2074: > rm -f *.o top core core.* sigdesc.h
2075: > To create the executable, type "make".
2076: > To install the executable, type "make install".
2077: > ===> Building for top-3.5beta5
2078: > cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c top.c
2079: > awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
2080: > cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c commands.c
2081: > cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c display.c
2082: > cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c screen.c
2083: > cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c username.c
2084: > cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c utils.c
2085: > utils.c: In function `errmsg':
2086: > utils.c:348: warning: return discards `const' from pointer target type
2087: > cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c version.c
2088: > cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c getopt.c
2089: > cc "-DOSREV=12G" -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
2090: > rm -f top
2091: > cc -o top top.o commands.o display.o screen.o username.o utils.o version.o getopt.o machine.o -ltermcap -lm -lkvm
2092: > root@pumpy:/u/pkgsrc/sysutils/top(1343)# make install
2093: > >> Checksum OK for top-3.5beta5.tar.gz.
2094: > ===> Installing for top-3.5beta5
2095: > /usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
2096: > /usr/bin/install top.1 /usr/pkg/man/man1/top.1
2097: > strip /usr/pkg/bin/top
2098: > ===> Registering installation for top-3.5beta5
2099: > root@pumpy:/u/pkgsrc/sysutils/top(1344)#
1.2 hubertf 2100:
1.1 hubertf 2101:
1.4 hubertf 2102: A.2 Packaging top
2103: =================
1.1 hubertf 2104:
1.4 hubertf 2105: > root@pumpy:/u/pkgsrc/sysutils/top(1344)# make package
2106: > >> Checksum OK for top-3.5beta5.tar.gz.
2107: > ===> Building package for top-3.5beta5
2108: > Creating package top-3.5beta5.tgz
2109: > Registering depends:.
2110: > Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'
2111: > root@pumpy:/u/pkgsrc/sysutils/top(1345)#
1.1 hubertf 2112:
1.2 hubertf 2113:
1.4 hubertf 2114: ======================================================
2115: Appendix B: Layout of the FTP server's package archive
2116: ======================================================
2117:
1.10 hubertf 2118: Layout for precompiled binary packages on ftp.netbsd.org:
1.4 hubertf 2119:
2120: /pub/NetBSD/packages/
2121: README
2122: distfiles/
1.8 hubertf 2123: pkgsrc -> /pub/NetBSD/NetBSD-current/pkgsrc
1.4 hubertf 2124: 1.3/
2125: i386/
2126: All/
2127: archivers/
2128: foo -> ../All/foo
2129: ...
2130: m68k/
2131: All/
2132: archivers/
2133: foo -> ../All/foo
2134: ...
2135: amiga -> m68k
2136: atari -> m68k
2137: ...
2138:
2139:
2140: To create:
2141: - cd /usr/pkgsrc ; make install ; make package
2142: - upload /usr/pkgsrc/packages to
1.17 hubertf 2143: ftp://ftp.netbsd.org/pub/NetBSD/packages/`uname -r`/`sysctl -n hw.machine_arch`
1.4 hubertf 2144: - if necessary ln -s `sysctl -n hw.machine` `sysctl -n hw.machine_arch`
1.1 hubertf 2145:
1.4 hubertf 2146: Disk space needed: unknown.
1.1 hubertf 2147:
1.2 hubertf 2148:
2149: ###########################################################################
2150: # Local Variables:
1.4 hubertf 2151: # mode: Text
2152: # fill-column: 75
2153: # sentence-end-double-space: nil
1.2 hubertf 2154: # End:
CVSweb <webmaster@jp.NetBSD.org>
![[BACK]](/icons/back.gif){kind=icon}
Return to Packages.txt CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [cvs.NetBSD.org] / pkgsrc