Annotation of pkgsrc/Packages.txt, Revision 1.218
1.218 ! wiz 1: # $NetBSD: Packages.txt,v 1.217 2001/11/30 01:26:32 wiz 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.119 hubertf 15: Run this command to produce a table of contents:
1.9 hubertf 16: grep -B1 '^.====' Packages.txt | egrep -v '^.[-=]'
1.4 hubertf 17:
18:
19: 0 Intro
1.163 jlam 20: =======
1.4 hubertf 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
1.191 skrll 25: software run on NetBSD, and makes the installation (and re-installation) of
1.9 hubertf 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
1.163 jlam 39: ============
1.4 hubertf 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
1.138 agc 43: Collection, either by installing a precompiled binary package, or
44: by building your own copy using the NetBSD package system. The
45: second part, "Package Constructor's Guide", explains how to prepare
46: a package so it can be easily built by other NetBSD users without
47: knowing about the package's building details.
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<$>.
1.185 hubertf 99:
100:
101: 0.3 Typography
102: ==============
103:
104: Right now this document is written in plain ASCII text, and there's not
105: much typography applied here. Future versions may move to something like
106: HTML or DocBook, which have better ways theres.
107:
1.191 skrll 108: When giving examples for commands, shell prompts are used to show if the
1.185 hubertf 109: command should/can be issued as root, or if "normal" user privileges are
110: sufficient. We use a "#" for root's shell prompt, and a "%" for users'
111: shell prompt, assuming they use the C-shell or tcsh.
1.4 hubertf 112:
113:
114: ====================
115: Part I: User's Guide
116: ====================
117:
118: 1 Installing a precompiled binary package
119: =========================================
120:
121: This section describes how to find, retrieve and install a precompiled
122: binary package that someone else already prepared for your type of machine.
123:
124:
125: 1.1 Where to get
126: ================
127:
1.7 hubertf 128: Precompiled packages are stored on ftp.netbsd.org and its mirrors in the
1.4 hubertf 129: directory /pub/NetBSD/packages for anon FTP access. Please pick the right
130: subdirectory there as indicated by "sysctl hw.machine_arch". In that
131: directory, there is a subdirectory for each category plus a subdirectory
132: "All" which includes the actual binaries in .tgz-files. The category
133: subdirectories use symbolic links to those files. (This is the same
134: directory layout as in /usr/pkgsrc/packages).
135:
136: This same directory layout applies for CDROM distributions, only that the
137: directory may be rooted somewhere else, probably somewhere below /cdrom.
138: Please consult your CDROM's documentation for the exact location!
139:
140:
1.80 abs 141: 1.2 How to use
142: ==============
1.4 hubertf 143:
1.10 hubertf 144: If you have the files on a CDROM or downloaded them to your hard disk, you
1.4 hubertf 145: can install them with the following command (be sure to su to root first):
146:
1.184 hubertf 147: # pkg_add /path/to/package.tgz
1.4 hubertf 148:
149: If you have FTP access and you don't want to download the packages via FTP
150: prior to installation, you can do this automatically by giving pkg_add an
151: ftp-URL:
152:
1.184 hubertf 153: # pkg_add ftp://ftp.netbsd.org/pub/NetBSD/packages/<OS Ver>/<arch>/All/package.tgz
1.80 abs 154:
155: If there is any doubt, the sysctl utility can be used to determine the
156: <OS Ver>, and <arch> by running "sysctl kern.osrelease hw.machine_arch".
1.4 hubertf 157:
1.80 abs 158: Also note that any prerequisite packages needed to run the package in
159: question will be installed, too, assuming they are present where you install
160: from.
1.4 hubertf 161:
1.183 hubertf 162: After you've installed packages, be sure to have /usr/pkg/bin in your $PATH
163: so you can actually start the just installed program.
1.4 hubertf 164:
165:
166: 1.3 A word of warning
167: =====================
168:
169: Please pay very careful attention to the warnings expressed in that manual
170: page about the inherent dangers of installing binary packages which you did
171: not create yourself, and the security holes that can be introduced onto
172: your system by indiscriminate adding of such files.
173:
174:
175: 2 Installing by Building
176: ========================
1.1 hubertf 177:
1.2 hubertf 178: This assumes that the package is already part of the NetBSD package system.
1.4 hubertf 179: If it is not, then you are advised to read part II of this document,
1.35 agc 180: "Package Constructor's Guide".
1.4 hubertf 181:
182:
1.108 tron 183: 2.1 Requirements
184: ================
185:
186: To build packages from source on a NetBSD system the "comp" and the "text"
187: distribution sets must be installed. If you want to build X11 related
188: packages the "xbase" and "xcomp" distribution sets are required, too.
189:
190:
191: 2.2 Where to get pkgsrc
1.4 hubertf 192: =======================
1.2 hubertf 193:
1.183 hubertf 194: There are three ways to get pkgsrc. Either as a tar file, via SUP, or
195: via CVS. All three ways are described here.
1.153 hubertf 196:
1.2 hubertf 197: To get the package source going, you need to get the pkgsrc.tar.gz file
198: from ftp://ftp.netbsd.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz and
199: unpack it into /usr/pkgsrc.
1.1 hubertf 200:
1.27 hubertf 201: As an alternative, you can get pkgsrc via the Software Update Protocol,
202: SUP. To do so, make sure your supfile has a line saying "release=pkgsrc" in
203: it, see the examples in /usr/share/examples/supfiles, and that the
1.28 hubertf 204: directory /usr/pkgsrc does exist. Then, simply start "sup -v
205: /path/to/your/supfile".
1.153 hubertf 206:
207: To get pkgsrc via CVS, make sure you have cvs installed. If not present on
208: your system, it can be found as precompiled binary on ftp.netbsd.org.
209: To do an initial (full) checkout of pkgsrc, do the following steps:
210:
211: % setenv CVSROOT anoncvs@anoncvs.netbsd.org:/cvsroot
212: % setenv CVS_RSH ssh
213: % cd /usr
1.164 hubertf 214: % cvs checkout -P pkgsrc
1.153 hubertf 215:
1.192 agc 216: This will create the "pkgsrc" directory in your /usr, and all the
217: package source will be stored under /usr/pkgsrc. To update pkgsrc
218: after the initial checkout, make sure you have CVS_RSH set as above,
219: then do:
1.153 hubertf 220:
221: % cd /usr/pkgsrc
1.164 hubertf 222: % cvs -q update -dP
1.27 hubertf 223:
1.192 agc 224: Please also note that it is possible to have multiple copies of the
225: pkgsrc hierarchy in use at any one time - all work is done relatively
226: within the pkgsrc tree.
227:
1.4 hubertf 228:
1.108 tron 229: 2.3 Fetching distfiles
1.4 hubertf 230: ======================
231:
232: There is one gotcha: The distribution file (i.e. the unmodified source)
233: must exist on your system for the packages system to be able to build it.
1.80 abs 234: If it does not, then ftp(1) is used to fetch the distribution files
1.4 hubertf 235: automatically.
236:
1.49 frueauf 237: You can overwrite some of the major distribution sites to fit to sites
1.192 agc 238: that are close to your own. Have a look at
239: pkgsrc/mk/bsd.pkg.defaults.mk to find some examples - in particular,
240: look for the MASTER_SORT, MASTER_SORT_REGEX and INET_COUNTRY
241: definitions. This may save some of your bandwidth and time.
242:
243: You can change these settings either in your shell's environment, or,
244: if you want to keep the settings, by editing the /etc/mk.conf file,
245: and adding the definitions there.
1.49 frueauf 246:
1.10 hubertf 247: If you don't have a permanent Internet connection and you want to know
1.4 hubertf 248: which files to download, "make fetch-list" will tell you what you'll need.
249: Put these distfiles into /usr/pkgsrc/distfiles.
250:
251:
1.108 tron 252: 2.4 How to build and install
1.4 hubertf 253: ============================
254:
1.183 hubertf 255: Assuming that the distfile has been fetched (see previous section), become
256: root and change into the relevant directory. Then you can type
1.1 hubertf 257:
1.184 hubertf 258: % make
1.1 hubertf 259:
260: at the shell prompt to build the various components of the package, and
261:
1.184 hubertf 262: # make install
1.1 hubertf 263:
264: at the shell prompt to install the various components into the correct
1.4 hubertf 265: places on your system.
1.1 hubertf 266:
1.2 hubertf 267: Taking the top system utility as an example, we can install it on our
1.80 abs 268: system by building as shown in appendix A.1.
1.1 hubertf 269:
1.4 hubertf 270: The program is installed under the default root of the packages tree -
1.35 agc 271: /usr/pkg. Should this not conform to your tastes, simply set the LOCALBASE
1.4 hubertf 272: variable in your environment, and it will use that value as the root of
273: your packages tree. So, to use /usr/local, set
1.1 hubertf 274:
1.35 agc 275: LOCALBASE=/usr/local
276:
1.106 dmcmahil 277: in your environment. Please note that you should use a root which is
278: dedicated to packages and not shared with other programs (ie, do not try
279: and use LOCALBASE=/usr). This is to prevent possible conflicts between
280: programs and other files installed by the package system and whatever else
281: may have been installed there. There is, of course, one exception to
282: this - X11 packages are traditionally installed in the X11 tree. The
283: definition used to identify the root of the X11 tree is the X11BASE
284: definition.
1.91 agc 285:
286: It is possible to install X11 packages in the LOCALBASE tree, for
287: which you must install the xpkgwedge package
288: (pkgsrc/pkgtools/xpkgwedge) - see section 7.1 for further details.
1.35 agc 289:
1.49 frueauf 290: Some packages look in /etc/mk.conf to alter some configuration options
1.192 agc 291: at build time. Have a look at pkgsrc/mk/bsd.pkg.defaults.mk to
292: get an overview of what will be set there by default. Environment
293: variables such as LOCALBASE, and X11BASE can be set in /etc/mk.conf to
294: save having to remember to set them each time you want to use pkgsrc.
1.95 hubertf 295:
1.191 skrll 296: If you want to de-install and re-install a binary package that you've
1.160 hubertf 297: created (see next section), that you put into pkgsrc/packages manually or
298: that's located on a remote FTP server, you can use the the "bin-install"
299: target. This target will install a binary package - if available - via
300: pkg_add, and do a "make package" else. The list of remote FTP sites
301: searched is kept in the variable BINPKG_SITE, which defaults to
302: ftp.netbsd.org. Any flags that should be added to pkg_add(8) can be put
1.192 agc 303: into BIN_INSTALL_FLAGS. See pkgsrc/mk/bsd.pkg.defaults.mk for more details.
1.133 hubertf 304:
305: A final word of warning: If you setup a system that has a non-standard
306: setting for LOCALBASE (or X11BASE, for that matter), be sure to set that
307: before any packages are installed, as you can not use several directories
308: for the same purpose. Doing so will result in pkgsrc not being able to
309: properly detect your installed packages, and fail miserably. Note also that
310: precompiled binary packages are usually built with the default LOCALBASE of
311: /usr/pkg, and that you should *not* install any if you use a non-standard
312: LOCALBASE.
1.49 frueauf 313:
1.1 hubertf 314:
1.101 hubertf 315: 3 Making precompiled packages
316: =============================
317:
1.200 wiz 318:
1.101 hubertf 319: 3.1 Packaging a single package
1.4 hubertf 320: ==============================
1.101 hubertf 321:
1.4 hubertf 322: Once you have built and installed the package as mentioned above, you can
323: build it into a "binary package" - you might want to do this so that you
324: can use the binaries you have just built on another NetBSD system, or to
325: provide a simple means for others to use your binary package instead of
326: wasting CPU time - this is done by changing to the appropriate directory in
327: the pkgsrc tree, and typing the command
1.1 hubertf 328:
1.184 hubertf 329: # make package
1.1 hubertf 330:
1.4 hubertf 331: at the shell prompt. This will build and install your package (if not
332: already done), and then construct a binary package out of the results so
333: that you can use the pkg_* tools to manipulate this. The binary package is
334: stored under /usr/pkgsrc/packages, it's in the form of a gzipped file at
335: the present time. See appendix A.2 for a continuation of the above top
336: example.
1.1 hubertf 337:
1.4 hubertf 338: Please see the "submitting" section later in this document on how to submit
339: such a binary package.
1.1 hubertf 340:
341:
1.101 hubertf 342: 3.2 Doing a bulk build of all packages
343: ======================================
344:
345: If you want to get a full set of precompiled binary packages, this section
346: describes how to get them. Beware that the bulk build will remove all
347: currently installed packages from your your system! Having a FTP server
348: configured either on the machine doing the bulk builds or on a nearby NFS
349: server can help to make the packages available to everyone. See ftpd(8) for
350: more information. If you use a remote NFS server's storage, be sure to not
351: actually compile on NFS storage, as this slows things down a lot.
352:
353:
1.112 hubertf 354: 3.2.1 Configuration
355: ===================
356:
357: 3.2.1.1 /etc/mk.conf
358: ====================
1.101 hubertf 359:
1.192 agc 360: You may want to set things in /etc/mk.conf. Look at
361: pkgsrc/mk/bsd.pkg.defaults.mk for details of the default settings.
362: You will want to make sure that ACCEPTABLE_LICENSES meet your local
363: policy:
1.101 hubertf 364:
365: BATCH= yes # required for bulk builds
1.111 hubertf 366: DEPENDS_TARGET?= bulk-install
367: PACKAGES?= ${PKGSRCDIR}/packages/${MACHINE_ARCH}
368: OBJMACHINE?= 1 # use work.${MACHINE_ARCH}
369: WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
370: FAILOVER_FETCH= yes # insist on the correct checksum
371: PKG_DEVELOPER?= yes
372: ACCEPTABLE_LICENSES= shareware \
373: fee-based-commercial-use \
1.201 abs 374: mosaic-license \
1.111 hubertf 375: no-profit \
376: no-commercial-use \
377: non-commercial-use \
1.112 hubertf 378: limited-redistribution \
379: kermit-license \
380: sun-swing-license \
381: sun-jsdk20-license
1.111 hubertf 382:
1.144 dmcmahil 383: If you wish to use xpkgwedge for the entire build, then add:
384:
385: BULK_PREREQ+= pkgtools/xpkgwedge
386:
387: Other packages which must be installed during the bulk build to modify the
388: build behaviour may be added to the BULK_PREREQ variable. Note that currently
389: the only package for which BULK_PREREQ makes sense is xpkgwedge.
1.111 hubertf 390:
1.112 hubertf 391: 3.2.1.2 build.conf
392: ==================
393:
394: In pkgsrc/mk/bulk, copy ``build.conf-example'' to ``build.conf'' and
395: edit it, following the comments in that file. This is the config
1.191 skrll 396: file that determines where log files are generated after the build,
1.112 hubertf 397: where to mail the build report, where your pkgsrc is located and
398: which user to su(8) to to do a 'cvs update'.
1.101 hubertf 399:
1.149 dmcmahil 400: 3.2.1.3 pre-build.local
401: =======================
402:
403: It is possible to configure the bulk build to perform certain site
404: specific tasks at the end of the pre-build stage. If the file
405: ``pre-build.local'' exists in pkgsrc/mk/bulk it will be executed
406: (as a sh(1) script) at the end of the usual pre-build stage. An
407: example use of pre-build.local is to have the line:
408:
1.184 hubertf 409: # echo "I do not have enough disk space to build this pig." \
1.183 hubertf 410: > pkgsrc/games/crafty-book-enormous/$BROKENF
1.149 dmcmahil 411:
412: to prevent the system from trying to build a particular package
413: which requires nearly 3 Gb of disk space.
1.101 hubertf 414:
415: 3.2.2 Other environmental considerations
416: ========================================
417:
1.190 skrll 418: As /usr/pkg will be completely deleted at the start of bulk builds,
1.183 hubertf 419: make sure your login shell is placed somewhere else. Either drop it into
420: /usr/local/bin (and adjust your login shell in the password file), or
421: (re-)install it via pkg_add from /etc/rc.local, so you can login after a
422: reboot (remember that your current process won't die if the package is
423: removed, you just can't start any new instances of the shell any more).
424: Also, if you use a OS version below 1.5 or you still want to use the
425: pkgsrc version of ssh for some reason, be sure to install ssh before
426: starting it from rc.local:
1.101 hubertf 427:
1.184 hubertf 428: ( cd /usr/pkgsrc/security/ssh ; make bulk-install )
429: if [ -f /usr/pkg/etc/rc.d/sshd ]; then
430: /usr/pkg/etc/rc.d/sshd
431: fi
1.101 hubertf 432:
433: Not doing so will result in you being not able to log in via ssh
1.130 hubertf 434: after the bulk build is finished or if the machine gets rebooted
435: or crashes. You have been warned! :)
1.101 hubertf 436:
437:
438: 3.2.3 Operation
439: ===============
440:
1.112 hubertf 441: Make sure you don't need any of the packages still installed.
442: BEWARE: During the bulk build, ALL packages will be removed!!!
1.191 skrll 443: Be sure to remove all other things that might interfere with builds, like
1.183 hubertf 444: some libs installed in /usr/local, etc. then become root and type:
1.101 hubertf 445:
446: # cd /usr/pkgsrc
1.112 hubertf 447: # sh mk/bulk/build
448:
449: If for some reason your last build didn't complete (power failure,
450: system panic, ...), you can continue it by running:
451:
452: # sh mk/bulk/build restart
453:
454: At the end of the bulk run, you will get a summary via mail, and find
455: build logs in the directory specified by "FTP" in the "build.conf"
456: file.
457:
458:
459: 3.2.4 What it does
460: ==================
461:
462: The bulk builds consist of three steps:
463:
464: 1. pre-build: The script updates your pkgsrc via (anon)cvs, then cleans
465: out any broken distfiles, and removes all packages installed.
466:
1.191 skrll 467: 2. the bulk build: This is basically 'make bulk-package' with an optimised
1.112 hubertf 468: order in which packages will be built. Packages that don't require
469: other packages will be built first, and packages with many depends
470: will be built later.
471:
472: 3. post-build: Generates a report that's placed in the directory specified
473: in the build.conf file named ``broken.html'', a short version of
474: that report will also be mailed to the build's admin.
1.101 hubertf 475:
476: During the build, a list of broken packages will be compiled in
1.140 wiz 477: /usr/pkgsrc/.broken (or .../.broken.${MACHINE} if OBJMACHINE is set),
1.101 hubertf 478: individual build logs of broken builds can be found in the package's
479: directory. These files are used by the bulk-targets to mark broken builds
480: to not waste time trying to rebuild them, and they can be used to debug
1.112 hubertf 481: these broken package builds later.
1.101 hubertf 482:
483:
1.112 hubertf 484: 3.2.5 Disk space requirements
1.101 hubertf 485: =============================
486:
487: Currently, roughly the following requirements are valid for
1.112 hubertf 488: 1.5/i386:
1.101 hubertf 489:
490: * Distfiles: 1500MB (NFS ok)
1.112 hubertf 491: * Full set of all binaries: 1000MB (NFS ok)
1.101 hubertf 492: * Temp space for compiling: 1500MB (local disk recommended)
493:
1.154 dmcmahil 494: For 1.5/alpha:
495:
496: * Full set of all binaries: 1300MB (NFS ok)
497:
1.191 skrll 498: Note that all pkgs will be de-installed as soon as they are turned into a
1.101 hubertf 499: binary package, and that work-sources are removed, so there is no huge
500: demand to disk space. Afterwards, if the package is needed again, it will
501: be installed via pkg_add instead of building again, so there are no cycles
1.112 hubertf 502: wasted by recompiling.
1.101 hubertf 503:
1.200 wiz 504:
1.154 dmcmahil 505: 3.3 Creating a multiple CD-ROM packages collection
506: ==================================================
507:
508: After your bulk pkgsrc build has completed, you may wish to create a CD-ROM
509: set of the resulting binary packages to assist in installing packages on
1.183 hubertf 510: other machines. The package pkgsrc/pkgtools/cdpack provides a simple tool for
1.154 dmcmahil 511: creating the ISO 9660 images. `cdpack' arranges the packages on the CD-ROM's
512: in a way that keeps all the dependencies for given package on the same
513: CD as that package.
1.155 dmcmahil 514:
1.200 wiz 515:
1.155 dmcmahil 516: 3.3.1 Example of cdpack
1.163 jlam 517: =======================
1.155 dmcmahil 518:
519: Complete documentation for cdpack is found in cdpack(1). The following
520: short example assumes that the binary packages are left in
521: /usr/pkgsrc/packages/All and that sufficient disk space exists in /u2
522: to hold the ISO 9660 images.
523:
1.195 hubertf 524: # mkdir /u2/images
1.184 hubertf 525: # pkg_add /usr/pkgsrc/packages/All/cdpack
526: # cdpack /usr/pkgsrc/packages/All /u2/images
1.155 dmcmahil 527:
528: If you wish to include a common set of files (COPYRIGHT, README, etc)
529: on each CD in the collection, then you need to create a directory which
530: contains these files. For example
531:
1.184 hubertf 532: # mkdir /tmp/common
533: # echo "This is a README" > /tmp/commmon/README
534: # echo "Another file" > /tmp/common/COPYING
535: # mkdir /tmp/common/bin
536: # echo "#!/bin/sh" > /tmp/common/bin/myscript
537: # echo "echo Hello world" >> /tmp/common/bin/myscript
538: # chmod 755 /tmp/common/bin/myscript
1.155 dmcmahil 539:
540: Now create the images with
541:
1.184 hubertf 542: # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
1.155 dmcmahil 543:
544: and each image will contain "README", "COPYING", and "bin/myscript"
545: in their root directories.
1.101 hubertf 546:
1.200 wiz 547:
1.35 agc 548: ====================================
549: Part II: Package Constructor's Guide
550: ====================================
1.1 hubertf 551:
1.4 hubertf 552: 4 Package components - files, directories and contents
553: ======================================================
1.1 hubertf 554:
1.200 wiz 555: Whenever you're preparing a package, there are a number of files involved
556: which are described in the following sections.
1.1 hubertf 557:
558:
1.4 hubertf 559: 4.1 Makefile
560: ============
1.1 hubertf 561:
1.4 hubertf 562: Building, installation and creation of a binary package are all controlled
563: by the package's Makefile.
1.1 hubertf 564:
1.4 hubertf 565: There is a Makefile for each package. This file includes the standard
1.27 hubertf 566: bsd.pkg.mk file (referenced as "../../mk/bsd.pkg.mk"), which sets all the
567: definitions and actions necessary for the package to compile and install
568: itself. The mandatory fields are the DISTNAME which specifies the base name
569: of the distribution file to be downloaded from the site on the Internet,
570: MASTER_SITES which specifies that site, CATEGORIES which denotes the
571: categories into which the package falls, PKGNAME which is the name of the
1.140 wiz 572: package, the MAINTAINER name, and the COMMENT variable, which should
573: contain a one-line description of the package (the package name should not
574: appear, it will be added automatically). The maintainer variable is there
575: so that anyone who quibbles with the (always completely correct) decisions
576: taken by the guy who maintains the port can complain vigorously.
1.51 tv 577:
578: The MASTER_SITES may be set to one of the predefined sites:
579:
580: ${MASTER_SITE_XCONTRIB}
581: ${MASTER_SITE_GNU}
582: ${MASTER_SITE_PERL_CPAN}
583: ${MASTER_SITE_TEX_CTAN}
584: ${MASTER_SITE_SUNSITE}
1.136 itojun 585: ${MASTER_SITE_GNOME}
586: ${MASTER_SITE_SOURCEFORGE}
1.51 tv 587:
588: If one of these predefined sites is chosen, you may require the ability to
589: specify a subdirectory of that site. Since these macros may expand to
590: more than one actual site, you MUST use the following construct to specify
591: a subdirectory:
592:
1.53 tron 593: ${MASTER_SITE_GNU:=subdirectory/name/}
1.51 tv 594:
1.53 tron 595: (Note the trailing slash after the subdirectory name.) Use of the deprecated
596: MASTER_SITE_SUBDIR will not work.
1.218 ! wiz 597:
! 598: If the package has multiple DISTFILES from different MASTER_SITES, set
! 599: MASTER_SITE_name_of_file-0.1.2.tar.gz= ftp://some.url/path/
! 600: for all except the first distribution file, to speed up fetching the files.
1.4 hubertf 601:
602: Currently the following values are available for CATEGORIES. If more than
1.10 hubertf 603: one is used, they need to be separated by spaces:
1.4 hubertf 604:
1.140 wiz 605: archivers audio benchmarks biology cad
606: chat comms converters cross databases
607: devel editors emulators finance fonts
608: games graphics ham japanese lang
609: mail math mbone misc net
610: news parallel print security shells
611: sysutils textproc time wm www
612: x11
613:
1.49 frueauf 614: See the NetBSD packages(7) manual page for a description of all available
615: options and variables.
1.4 hubertf 616:
1.200 wiz 617: Please pay attention to the following gotchas:
1.4 hubertf 618:
619: - Add MANCOMPRESSED (if not already there) if manpages are installed in
1.25 frueauf 620: compressed form by the package; see comment in bsd.pkg.mk
1.4 hubertf 621: - Replace /usr/local by ${PREFIX} in all files (see patches below)
1.26 agc 622: - If the package installs any info files, the main info directory file
1.200 wiz 623: needs to be updated to reflect this fact. NetBSD has an INFO_FILES
1.26 agc 624: definition, which is used to do this. For example, to install the
625: indent.info entry into the info directory file, simply use the
626:
1.32 agc 627: INFO_FILES= indent.info
1.26 agc 628:
629: definition in the package Makefile. If the package does this insertion
630: for you, you should specify USE_GTEXINFO in the package Makefile, to
631: ensure that the pre-requisite GNU texinfo package is installed on your
632: system.
1.30 frueauf 633: - Adjust MAINTAINER to be either yourself, if you plan to maintain the
634: package for future updates, or set it to the default MAINTAINER
1.200 wiz 635: packages@netbsd.org.
1.42 tsarna 636: - If there exists a home page for the software in question, please
637: add the variable HOMEPAGE right after MAINTAINER. The value of this
638: variable should be the URL for the home page.
1.140 wiz 639: - Please also set the COMMENT variable to a short description of the
640: package.
641:
1.1 hubertf 642:
1.151 agc 643: 4.2 distinfo
644: ============
1.1 hubertf 645:
1.151 agc 646: Most important, the mandatory message digest, or checksum, of all the
647: distfiles needed for the package to compile, confirming they match the
648: original file distributed by the author. This ensures that the
649: distfile retrieved from the Internet has not been corrupted during
650: transfer or altered by a malign force to introduce a security hole.
651: It is best generated using the "make makesum" command. The digest
652: algorithm used was, at one stage, md5, but that was felt lacking
653: compared to sha1, and so sha1 is now the default algorithm. The
654: distfile size is also generated and stored in new distinfo files.
655: The pkgsrc/pkgtools/digest utility calculates all of the digests
656: in the distinfo file, and it provides various different algorithms.
657: At the current time, the algorithms provided are:
658:
659: md5, rmd160, sha1, sha256, sha384 and sha512
1.158 abs 660:
661: Some packages have different sets of distfiles on a per architecture
1.183 hubertf 662: basis. (A good example is pkgsrc/www/navigator). These are kept in the
1.158 abs 663: same distinfo file and care should be taken when upgrading such a
664: package to ensure distfile information is not lost.
1.151 agc 665:
666: The message digest/checksum for all the official patches found in the
667: patches/ directory (see section 4.3) for the package is also stored in
668: the distinfo file. This is a message digest/checksum of all lines in
669: the patch file except the NetBSD RCS Id. This file is generated by
670: invoking "make makepatchsum".
1.1 hubertf 671:
672:
1.4 hubertf 673: 4.3 patches/*
674: =============
1.1 hubertf 675:
1.4 hubertf 676: This directory contains files that are used by the patch(1) command to
677: modify the sources as distributed in the distribution file into a form that
678: will compile and run perfectly on NetBSD. The files are applied
679: successively in alphabetic order (as returned by a shell "patches/patch-*"
680: glob expansion), so patch-aa is applied before patch-ab etc.
1.1 hubertf 681:
1.215 hubertf 682: The patch-?? files should be in "diff -bu" format, and apply without
1.129 abs 683: a fuzz to avoid problems (To force patches to apply with fuzz you
684: can set PATCH_FUZZ_FACTOR=-F2). Furthermore, do not put changes
1.94 hubertf 685: for more than one file into a single patch-file, as this will make
686: future modifications more difficult.
1.4 hubertf 687:
1.183 hubertf 688: Similar, a file should be patched at most once, not several times by
1.150 hubertf 689: several different patches. If a file needs several patches, they should
690: be combined into one file.
691:
1.183 hubertf 692: One important thing to mention is to pay attention that no RCS IDs
693: get stored in the patch files, as these will cause problems when
694: later checked into the NetBSD CVS tree. To avoid this, use either
695: the "-U 2" or "-U 1" option to diff, or let the 'pkgdiff' command
696: from pkgsrc/pkgtools/pkgdiff help you.
1.1 hubertf 697:
1.92 wiz 698: If you don't want to worry about the problems in the last two paragraphs
1.183 hubertf 699: yourself, use pkgdiff from the pkgsrc/pkgtools/pkgdiff package, which takes
700: care of any RCS Ids by itself.
1.92 wiz 701:
702: For even more automation, we recommend using mkpatches from the same
703: package to make a whole set of patches. You just have to backup files
704: before you edit them to "filename.orig", e.g. with "cp -p filename
1.200 wiz 705: filename.orig" or, easier, by using pkgvi from the same package. If you
706: upgrade a package this way, you can easily compare the new set of patches
707: with the previously existing one with patchdiff.
1.55 agc 708:
709: When you have finished a package, remember to generate the checksums
710: for the patch files by using the "make makepatchsum" command, see
711: section 4.2.
1.1 hubertf 712:
1.180 hubertf 713: If it is desired to store any patches that should not be committed into
714: pkgsrc, they can be kept outside the pkgsrc tree in the $LOCALPATCHES
715: directory. The directory tree there is expected to have the same
716: "category/package" structure as pkgsrc, and patches are expected to be
717: stored inside these dirs (also known as $LOCALPATCHES/$PKGPATH). For
718: example if you want to keep a private patch for pkgsrc/graphics/png, keep
719: it in $LOCALPATCHES/graphics/png/mypatch. All files in the named directory
720: are expected to be patch files, and they are applied after the "normal"
721: pkgsrc patches are applied.
722:
1.1 hubertf 723:
1.210 wiz 724: 4.4 Other mandatory files
725: =========================
1.1 hubertf 726:
1.210 wiz 727: * DESCR:
1.4 hubertf 728: A multi-line description of the piece of software. This should include
729: any credits where they are due. Please bear in mind that others do not
1.80 abs 730: share your sense of humour (or spelling idiosyncrasies), and that others
1.4 hubertf 731: will read everything that you write here.
732:
1.210 wiz 733: * PLIST:
1.4 hubertf 734: This file governs the files that are installed on your system: all the
735: binaries, manual pages, etc. There are other directives which may be
736: entered in this file, to control the creation and deletion of
1.7 hubertf 737: directories, and the location of inserted files.
1.1 hubertf 738:
739:
1.210 wiz 740: 4.5 Optional files
741: ==================
1.1 hubertf 742:
1.210 wiz 743: * INSTALL:
1.4 hubertf 744: Shell script invoked twice during pkg_add. First time after package
745: extraction and before files are moved in place, the second time after
1.7 hubertf 746: the files to install are moved in place. This can be used to do any
1.4 hubertf 747: custom procedures not possible with @exec commands in PLIST. See
748: pkg_add(1) and pkg_create(1) for more information.
749:
1.210 wiz 750: * DEINSTALL:
1.66 hubertf 751: This script is executed before and after any files are removed. It is
752: this script's responsibility to clean up any additional messy details
753: around the package's installation, since all pkg_delete knows is how to
1.4 hubertf 754: delete the files created in the original distribution. See pkg_delete(1)
755: and pkg_create(1) for more information.
1.29 frueauf 756:
1.210 wiz 757: * MESSAGE:
1.49 frueauf 758: Display this file after installation of the package.
1.140 wiz 759: Useful for things like legal notices on almost-free software, etc.
760: Please note that you can modify variables in it easily by using
761: MESSAGE_SUBST in the package's Makefile:
1.184 hubertf 762:
1.140 wiz 763: MESSAGE_SUBST+= SOMEVAR="somevalue"
1.184 hubertf 764:
1.140 wiz 765: replaces
1.184 hubertf 766:
1.140 wiz 767: ${SOMEVAR}
1.184 hubertf 768:
1.210 wiz 769: in MESSAGE with "somevalue" before displaying the message.
1.1 hubertf 770:
771:
1.210 wiz 772: 4.6 work/*
1.4 hubertf 773: ==========
1.1 hubertf 774:
775: When you type "make" the distribution files are unpacked into this
776: directory. It can be removed by typing
777:
1.184 hubertf 778: # make clean
1.1 hubertf 779:
1.4 hubertf 780: at the shell prompt. Also, this directory is used to keep various
781: timestamp files.
1.46 bad 782:
1.184 hubertf 783:
1.210 wiz 784: 4.7 files/*
1.151 agc 785: ===========
786:
787: If you have any files that you wish to be placed in the package prior
788: to configuration or building, you could place these files here and use
789: a ${CP} command in the pre-configure target to achieve this.
790: Alternatively, you could simply diff the file against /dev/null and
791: use the patch mechanism to manage the creation of this file.
792:
1.49 frueauf 793:
1.4 hubertf 794: 5 PLIST* issues
795: ===============
796:
1.82 abs 797: This section addresses some special issues that one needs to pay attention
798: to when dealing with the PLIST file (or files, see below!).
1.4 hubertf 799:
800:
1.10 hubertf 801: 5.1 Miscellaneous
1.4 hubertf 802: =================
803:
1.82 abs 804: * NetBSD RCS Id:
805: Be sure to add a RCS ID line as the first thing in any PLIST file you
1.4 hubertf 806: write:
807:
808: @comment <$>NetBSD<$>
809:
1.37 hubertf 810: * ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}:
1.4 hubertf 811: Some packages like emacs and perl embed information about which
812: architecture they were built on into the pathnames where they install
813: their file. To handle this case, PLIST will be preprocessed before
1.11 hubertf 814: actually used, and the symbol "${MACHINE_ARCH}" will be replaced by
1.37 hubertf 815: what "sysctl -n hw.machine_arch" gives. The same is done if the string
816: ${MACHINE_GNU_ARCH} is embedded in PLIST somewhere - use this on
817: packages that use GNU autoconfigure.
1.11 hubertf 818:
819: Legacy note: There used to be a symbol "<$ARCH>" that was replaced by
1.43 agc 820: the output of "uname -m", but that's no longer supported and has been
821: removed.
1.45 hubertf 822:
823: * ${OPSYS}, ${OS_VERSION}:
824: Some packages want to embed the OS name and version into some paths.
825: to do this, use these two variables in PLIST. ${OPSYS} will be replaced
826: by output from "uname -s", ${OS_VERSION} will be set to what "uname -r"
827: gives.
1.162 jlam 828:
829: * ${PKGLOCALEDIR}:
830: Packages that install locale files should list them in the PLIST as
831: "${PKGLOCALEDIR}/locale/de/LC_MESSAGES/..." instead of
832: "share/locale/de/LC_MESSAGES/...". This properly handles the fact that
833: different OSes expect locale files to be either in "share" or "lib" by
834: default.
1.4 hubertf 835:
836: * Manpage-compression:
1.5 hubertf 837: Manpages should be installed in compressed form if MANZ is set (in
1.4 hubertf 838: bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST
839: file, the suffix ".gz" is appended/removed automatically for manpages
840: according to MANZ and MANCOMPRESSED being set or not, see above for
1.6 hubertf 841: details. This modification of the PLIST file is done on a copy of it,
1.210 wiz 842: not PLIST itself.
1.4 hubertf 843:
1.90 hubertf 844: * Semi-automatic PLIST generation:
845: You can use the "make print-PLIST" command to output a PLIST that matches
1.118 hubertf 846: any new files since the package was extracted. See below for more
847: information on this target.
1.90 hubertf 848:
1.4 hubertf 849:
1.145 wiz 850: 5.2 ${PLIST_SRC}
1.4 hubertf 851: ================
852:
853: To use one or more files as source for the PLIST used in generating the
854: binary package, set the variable PLIST_SRC to the names of that file(s).
1.131 hubertf 855: The files are later concatenated using cat(1), and order of things is
856: important.
1.4 hubertf 857:
1.145 wiz 858: 5.3 ${PLIST_SUBST}
859: ==================
860:
861: Similar to MESSAGE_SUBST (see above), you can add variables and their
862: expansions to this variable in the following way:
863:
864: PLIST_SUBST+= SOMEVAR="somevalue"
865:
1.191 skrll 866: which replaces all occurrences of ${SOMEVAR} in the PLIST with "somevalue".
1.145 wiz 867: For the values which are replaced by default, please look in bsd.pkg.mk
868: (and search for PLIST_SUBST).
1.109 jlam 869:
1.145 wiz 870: 5.4 Perl5 modules
1.109 jlam 871: =================
872:
873: Perl5 modules will install into different places depending on the version
874: of perl used during the build process. To address this, the NetBSD
875: packages system will append lines to the PLIST corresponding to the files
876: listed in the installed .packlist file generated by most perl5 modules.
877: This is invoked by defining PERL5_PACKLIST to a space-separated list of
878: paths to packlist files:
879:
880: PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
881:
882: The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent
883: the three locations in which perl5 modules may be installed, and may be
884: used by perl5 packages that don't have a packlist. These three variables
885: are also substituted for in the PLIST.
1.4 hubertf 886:
887: 6 Notes on fixes for packages
888: =============================
889:
890: 6.1 CPP defines
891: ===============
1.1 hubertf 892:
1.2 hubertf 893: To port an application to NetBSD, it's usually necessary for the compiler
894: to be able to judge the system on which it's compiling, and we use
895: definitions so that the C pre-processor can do this.
896:
897: To test whether you are working on a 4.4 BSD-derived system, you should use
898: the BSD definition, which is defined in <sys/param.h> on said systems.
1.1 hubertf 899:
900: #include <sys/param.h>
901:
1.2 hubertf 902: and then you can surround the BSD-specific parts of your port using the
903: conditional:
1.1 hubertf 904:
905: #if (defined(BSD) && BSD >= 199306)
906: ...
907: #endif
908:
1.2 hubertf 909: Please use the __NetBSD__ definition sparingly - it should only apply to
910: features of NetBSD that are not present in other 4.4-lite derived BSDs.
1.1 hubertf 911:
1.39 hubertf 912: 6.2 Shared libraries - libtool
913: ==============================
914:
915: NetBSD supports many different machines, with different object formats
916: like a.out and ELF, and varying abilities to do shared library and
1.80 abs 917: dynamic loading at all. To accompany this, varying commands and options
1.39 hubertf 918: have to be passed to the compiler, linker etc. to get the Right Thing,
1.44 agc 919: which can be pretty annoying especially if you don't have all the
920: machines at your hand to test things. The "libtool" pkg can help
921: here, as it just "knows" how to build both static and dynamic
922: libraries from a set our source files, thus being platform
923: independent.
1.39 hubertf 924:
1.141 skrll 925: Here's how to use libtool in a pkg in seven simple steps:
1.39 hubertf 926:
1.43 agc 927: 1. Add USE_LIBTOOL= yes to the package Makefile.
1.39 hubertf 928:
929: 2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of
930: ${CC}. You could even add it to the definition of CC, if only
931: libraries are being built in a given Makefile. This one command will
932: build both PIC and non-PIC library objects, so you need not have
933: separate shared and non-shared library rules.
934:
935: 3. For the linking of the library, remove any "ar", "ranlib", and "ld
936: -Bshareable" commands, and use instead:
937:
1.152 skrll 938: ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor
1.39 hubertf 939:
940: Note that the library is changed to have a .la extension, and the
941: objects are changed to have a .lo extension. Change OBJS as necessary.
942: This automatically creates all of the .a, .so.major.minor, and ELF
1.125 hubertf 943: symlinks (if necessary) in the build directory. Be sure to include
1.142 skrll 944: the -version-info especially when major and minor are zero, as libtool
945: will otherwise strip off the shared library version.
1.125 hubertf 946:
1.143 skrll 947: The "-release" option will produce different results for a.out and ELF
948: (excluding symlinks) in only one case. An ELF library of the form
949: libfoo-release.so.x.y will have a symlink of libfoo.so.x.y on an a.out
1.146 skrll 950: platform. This is handled automatically.
1.142 skrll 951:
952: The -rpath argument is the install directory of the library being built.
953:
1.200 wiz 954: PLIST should include all of the .a, .la and so, .so.major and
955: .so.major.minor entries.
1.126 hubertf 956:
1.125 hubertf 957: 4. When linking shared object (.so) files, i.e. files that are loaded via
958: dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
959: them getting version tacked on.
1.126 hubertf 960:
961: PLIST gets the foo.so entry.
1.39 hubertf 962:
1.125 hubertf 963: 5. When linking programs that depend on these libraries _before_ they are
1.39 hubertf 964: installed, preface the cc or ld line with "${LIBTOOL} --mode=link", and
965: it will find the correct libraries (static or shared), but please be
966: aware that libtool will not allow you to specify a relative path in -L
1.159 skrll 967: (such as -L../somelib), because it expects you to change that argument
968: to be the .la file. For example:
1.39 hubertf 969:
970: ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
971:
1.159 skrll 972: should be changed to:
1.39 hubertf 973:
974: ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
975:
1.159 skrll 976: and it will DTRT with the libraries.
1.39 hubertf 977:
1.125 hubertf 978: 6. When installing libraries, preface the install or cp command with
1.39 hubertf 979: "${LIBTOOL} --mode=install", and change the library name to .la. For
980: example:
981:
982: ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
983:
984: This will install the static .a, shared library, any needed symlinks,
985: and run "ldconfig."
986:
1.132 agc 987: 7. In your PLIST, include all of the .a, .la, and so, .so.major and
988: .so.major.minor files (this is a change from the previous behaviour).
1.39 hubertf 989:
1.88 hubertf 990:
991: 6.3 Using libtool on GNU packages that already support libtool
992: ==============================================================
1.87 rh 993:
1.200 wiz 994: Add USE_LIBTOOL=yes and LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig to the package
995: Makefile as the quick way to bypass the pkg's own libtool. The pkg's own
996: libtool is made by ltconfig script at do-configure target. If USE_LIBTOOL
997: and LTCONFIG_OVERRIDE are defined, the specified ltconfig is overridden,
998: using the pkgsrc/devel/libtool instead of the pkg's own libtool. For newer
999: versions of libtool (without ltconfig) it may be necessary to use
1.207 drochner 1000: LIBTOOL_OVERRIDE=${WRKSRC}/libtool instead.
1.107 wiz 1001:
1.191 skrll 1002: If your package makes use of the platform independent library for loading
1.159 skrll 1003: dynamic shared objects, that comes with libtool (libltdl), you should
1004: add USE_LTDL= yes to the Makefile.
1.142 skrll 1005:
1.159 skrll 1006: Some packages use libtool incorrectly so that the package may not work or
1007: build in some circumstances. Some common errors are
1.142 skrll 1008:
1009: * The inclusion of a shared object (-module) as a dependent library in an
1010: executable or library. This in itself isn't a problem if one of two things
1011: has been done.
1012:
1013: 1. The shared object is named correctly, i.e. libfoo.la and not foo.la
1014:
1015: 2. The -dlopen option is used when linking an executable.
1016:
1017: * The use of libltdl without the correct calls to initialisation routines.
1018: The function lt_dlinit() should be called and the macro
1019: LTDL_SET_PRELOADED_SYMBOLS included in executables.
1.39 hubertf 1020:
1.4 hubertf 1021:
1.206 jlam 1022: 6.4 GNU Autoconf/Automake
1023: =========================
1024:
1025: If a package needs GNU autoconf or automake to be executed to regenerate
1026: the configure script and Makefile.in makefile templates, then they should
1027: be executed in a pre-configure target. For packages that need only
1028: autoconf:
1029:
1030: pre-configure:
1031: cd ${WRKSRC}; ${LOCALBASE}/bin/autoreconf --force
1032:
1033: and for packages that need automake:
1034:
1035: pre-configure:
1036: cd ${WRKSRC}; \
1.208 jlam 1037: ${LOCALBASE}/bin/aclocal; \
1038: ${LOCALBASE}/bin/autoheader; \
1039: ${LOCALBASE}/bin/automake -a --foreign -i; \
1040: ${LOCALBASE}/bin/autoconf
1.206 jlam 1041:
1042: There are times when the configure process makes additional changes to the
1043: generated files, which then causes the build process to try to re-execute
1044: the automake sequence. This may be overridden by setting AUTOMAKE_OVERRIDE
1045: to YES in the package Makefile.
1046:
1047:
1.213 jlam 1048: 6.5 Package configuration files
1049: ===============================
1050:
1051: Packages should be taught to look for their configuration files in
1052: ${PKG_SYSCONFDIR}, which is passed through to the configure and build
1053: processes. PKG_SYSCONFDIR may be customized in various ways by setting
1054: other make variables:
1055:
1056: * PKG_SYSCONFBASE is the main config directory under which all package
1057: configuration files are to be found. This defaults to ${PREFIX}/etc, but
1058: may be overridden in /etc/mk.conf.
1059:
1060: * PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which the
1061: configuration files for a particular package may be found, e.g. the
1062: Apache configuration files may all be found under the "httpd" subdirectory
1063: of ${PKG_SYSCONFBASE}.
1064:
1065: * PKG_SYSCONFDIR.${PKGBASE} overrides the value of ${PKG_SYSCONFDIR} for a
1066: particular package. This is not meant to be set by a package Makefile, but
1067: is reserved for users who wish to override the PKG_SYSCONFDIR setting for
1068: a particular package with a special location.
1069:
1070: Users will typically want to set PKG_SYSCONFBASE to /etc, or to accept the
1071: default location of ${PREFIX}/etc.
1072:
1073:
1074: 6.6 Feedback to the author
1.4 hubertf 1075: ==========================
1076:
1077: If you have found any bugs in the package you make available, if you had to
1.82 abs 1078: do special steps to make it run under NetBSD or if you enhanced the software
1079: in various other ways, be sure to report these changes back to the original
1080: author of the program! With that kind of support, the next release of the
1081: program can incorporate these fixes, and people not using the NetBSD packages
1082: system can win from your efforts.
1.4 hubertf 1083:
1084: Support the idea of free software!
1085:
1086:
1087: 7 The build process
1088: ===================
1089:
1.35 agc 1090: The basic steps for building a program are always the same. First the
1.4 hubertf 1091: program's source (distfile) must be brought to the local system and
1.35 agc 1092: then extracted. After any patches to compile properly on NetBSD are
1093: applied, the software can be configured, then built (usually by
1.44 agc 1094: compiling), and finally the generated binaries etc. can be put into
1.35 agc 1095: place on the system. These are exactly the steps performed by the
1096: NetBSD package system, which is implemented as a series of targets in
1.192 agc 1097: a central Makefile, pkgsrc/mk/bsd.pkg.mk.
1.4 hubertf 1098:
1099:
1100: 7.1 Program location
1101: ====================
1102:
1103: Before outlining the process performed by the NetBSD package system in the
1104: next section, here's a brief discussion on where programs are installed,
1105: and which variables influence this.
1106:
1.40 tv 1107: The automatic variable PREFIX indicates where all files of the final
1108: program shall be installed. It is usually set to $LOCALBASE (/usr/pkg),
1.41 tv 1109: or $CROSSBASE for pkgs in the "cross" category, though its value becomes
1.188 jlam 1110: that of $X11BASE if USE_IMAKE or USE_X11BASE is set. The value ${PREFIX}
1111: needs to be put into the various places in the program's source where paths
1112: to these files are encoded; see sections 4.3 and 6.2 for details on this.
1.40 tv 1113:
1114: When choosing which of these variables to use, follow the following rules:
1115:
1116: * ${PREFIX} always points to the location where the current pkg will be
1117: installed. When referring to a pkg's own installation path, use ${PREFIX}.
1118:
1119: * ${LOCALBASE} is where all non-X11 pkgs are installed. If you need to
1120: construct a -I or -L argument to the compiler to find includes and
1121: libraries installed by another non-X11 pkg, use ${LOCALBASE}.
1122:
1.117 hubertf 1123: * ${X11BASE} is where the actual X11 distribution (from xsrc etc.) is installed.
1124: When looking for _standard_ X11 includes (not those installed by a pkg), use
1125: ${X11BASE}.
1.40 tv 1126:
1127: * X11 based pkgs are special in that they may be installed in either
1.91 agc 1128: X11BASE or LOCALBASE. To install X11 packages in LOCALBASE, simply
1129: install the xpkgwedge package (pkgsrc/pkgtools/xpkgwedge).
1.40 tv 1130: If you need to find includes or libraries installed by a pkg that has
1.188 jlam 1131: USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to use _both_
1132: ${X11BASE} and ${LOCALBASE}.
1.4 hubertf 1133:
1.117 hubertf 1134: * ${X11PREFIX} should be used to refer to the installed location of an X11
1135: package. X11PREFIX will be set to ${X11BASE} if xpkgwedge is not installed,
1136: and to ${LOCALBASE} if xpkgwedge is installed.
1.91 agc 1137:
1.148 agc 1138: * If xpkgwedge is installed, it is possible to have some packages installed in
1139: X11BASE and some in LOCALBASE. To determine the prefix of an installed
1140: package, the EVAL_PREFIX definition can be used. It takes pairs in the
1141: format DIRNAME=<package>, and the make(1) variable DIRNAME will be set
1142: to the prefix of the installed package <package>, or ${X11PREFIX} if the
1143: package is not installed.
1144:
1145: This is best illustrated by example.
1146:
1147: The following lines are taken from pkgsrc/wm/scwm/Makefile:
1148:
1149: EVAL_PREFIX+= GTKDIR=gtk+
1150: CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \
1151: --with-gtk-prefix="${GTKDIR}" \
1152: --enable-multibyte
1153:
1154: Specific defaults can be defined for the packages evaluated using
1155: EVAL_PREFIX, by using a definition of the form:
1156:
1157: GTKDIR_DEFAULT= ${LOCALBASE}
1158:
1159: where "GTKDIR" corresponds to the first definition in the EVAL_PREFIX pair.
1.4 hubertf 1160:
1161: 7.2 Main targets
1162: ================
1163:
1.25 frueauf 1164: The main targets used during the build process defined in bsd.pkg.mk are:
1.4 hubertf 1165:
1166: * fetch:
1167: This will check if the file(s) given in the variables DISTFILES and
1168: PATCHFILES (as defined in the package's Makefile) are present on the
1169: local system in /usr/pkgsrc/distfiles. If they are not present, they
1170: will be fetched using ftp(1) from the site(s) given in the variable
1.58 bad 1171: PATCH_SITES. The location(s) in PATCH_SITES are in the form of URLs
1.4 hubertf 1172: and can be ftp://- and http://-URLs, as ftp(1) understands both of
1173: them.
1174:
1175: * checksum:
1.151 agc 1176: After the distfile(s) are fetched, their checksum is generated and
1177: compared with the checksums stored in the distinfo file. If the
1.4 hubertf 1178: checksums don't match, the build is aborted. This is to ensure the same
1179: distfile is used for building, and that the distfile wasn't changed,
1.73 hubertf 1180: e.g. by some malign force, deliberately changed distfiles on the master
1181: distribution site or network lossage.
1.4 hubertf 1182:
1183: * extract:
1184: When the distfiles are present on the local system, they need to be
1.35 agc 1185: extracted, as they are usually in the form of some compressed archive
1186: format, most commonly .tar.gz. If only some of the distfiles need to be
1.4 hubertf 1187: uncompressed, the files to be uncompressed should be put into
1188: EXTRACT_ONLY. If the distfiles are not in .tar.gz format, they can be
1189: extracted by setting EXTRACT_CMD, EXTRACT_BEFORE_ARGS and/or
1190: EXTRACT_AFTER_ARGS.
1191:
1192: * patch:
1.180 hubertf 1193: After extraction, all the patches named by the PATCHFILES, those present
1194: in the patches subdirectory of the package as well as in
1195: $LOCALPATCHES/$PKGPATH (e.g. /usr/local/patches/graphics/png) are
1196: applied. Patchfiles ending in .Z or .gz are uncompressed before they are
1197: applied, files ending in .orig or .rej are ignored. Any special options
1198: to patch(1) can be handed in PATCH_DIST_ARGS. See section 4.3 for more
1199: details.
1.94 hubertf 1200:
1.129 abs 1201: By default patch is given special args to make it fail if the
1202: patches with some lines of fuzz. Please fix (regen) the patches
1203: so that they apply cleanly. The rationale behind this is that
1204: patches that apply cleanly may end up being applied in the wrong
1205: place, and cause severe harm there.
1.4 hubertf 1206:
1207: * configure:
1.35 agc 1208: Most pieces of software need information on the header files,
1209: system calls, and library routines which are available in NetBSD.
1210: This is the process known as configuration, and is usually
1211: automated. In most cases, a script is supplied with the source,
1.80 abs 1212: and its invocation results in generation of header files,
1.4 hubertf 1213: Makefiles, etc.
1214:
1.33 agc 1215: If the program's distfile contains its own configure script, this can
1.4 hubertf 1216: be invoked by setting HAS_CONFIGURE. If the configure script is a GNU
1217: autoconf script, GNU_CONFIGURE should be specified instead. In either
1218: case, any arguments to the configure script can be specified in the
1219: CONFIGURE_ARGS variable, and the configure script's name can be set in
1220: CONFIGURE_SCRIPT if it differs from the default "configure".
1221:
1222: If the program uses an Imakefile for configuration, the appropriate
1223: steps can be invoked by setting USE_IMAKE to YES. (If you only want the
1.91 agc 1224: package installed in $X11PREFIX but xmkmf not being run, set USE_X11BASE
1.4 hubertf 1225: instead!)
1226:
1227: * build:
1.35 agc 1228: Once configuration has taken place, the software can be built on
1229: NetBSD by invoking $MAKE_PROGRAM on $MAKEFILE with $ALL_TARGET as
1230: the target to build. The default MAKE_PROGRAM is "gmake" if
1231: USE_GMAKE is set, "make" otherwise. MAKEFILE is set to "Makefile"
1232: by default, and ALL_TARGET defaults to "all". Any of these
1233: variables can be set to change the default build process.
1.4 hubertf 1234:
1235: * install:
1.35 agc 1236: Once the build stage has completed, the final step is to install
1237: the software in public directories, for users. As in the
1238: build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but with
1239: the $INSTALL_TARGET instead, the latter defaulting to "install"
1240: (plus "install.man", if USE_IMAKE is set).
1241:
1242: If no target is specified, the default is "build". If a subsequent stage
1243: is requested, all prior stages are made: e.g. "make build" will also
1244: perform the equivalent of:
1245:
1246: make fetch
1247: make checksum
1248: make extract
1249: make patch
1250: make configure
1251: make build
1.4 hubertf 1252:
1253:
1254: 7.3 Other helpful targets
1255: =========================
1256:
1257: * pre/post-*
1258: For any of the main targets described in the previous section, two
1.35 agc 1259: auxiliary targets exist with "pre-" and "post-" used as a prefix
1260: for the main target's name. These targets are invoked before and
1261: after the main target is called, allowing extra configuration or
1262: installation steps, for example, which program's configure script
1263: or install target omitted. For any of these auxiliary targets,
1264: scripts of the same name can be placed in the package's
1.4 hubertf 1265: scripts-subdirectory that will be executed at the given time, see
1266: section 4.5.
1267:
1268: * do-*:
1.35 agc 1269: Should one of the main targets do the wrong thing, and should there
1270: be no variable to fix this, you can redefine it with the do-*
1271: target. (Note that redefining the target itself instead of the
1272: do-* target is a bad idea, as the pre-* and post-* targets won't be
1.71 agc 1273: called anymore, etc.) You will not usually need to do this.
1.4 hubertf 1274:
1275: * reinstall:
1276: If you did a "make install" and you noticed some file was not installed
1.10 hubertf 1277: properly, you can repeat the installation with this target, which will
1.4 hubertf 1278: ignore the "already installed" flag.
1279:
1.44 agc 1280: * deinstall:
1281: This target does a pkg_delete(1) in the current directory,
1.59 hubertf 1282: effectively de-installing the package. The following variables can
1.62 rh 1283: be used either on the command line or in /etc/mk.conf to tune the
1.59 hubertf 1284: behaviour:
1285:
1286: - PKG_VERBOSE:
1287: Add a "-v" to the pkg_delete(1) command.
1288:
1289: - DEINSTALLDEPENDS:
1290: Remove all packages that require (depend on) the given package.
1291: This can be used to remove any packages that may have been pulled in
1292: by a given package, e.g. if "make deinstall DEINSTALLDEPENDS=1" is
1.183 hubertf 1293: done in pkgsrc/x11/kde, this is likely to remove whole KDE. Works by
1294: adding a "-R" to the pkg_delete command line.
1.62 rh 1295:
1296: * update:
1297: This target causes the current package to be updated to the latest
1.191 skrll 1298: version. The package and all depending packages first get de-installed,
1.62 rh 1299: then current versions of the corresponding packages get compiled and
1300: installed. This is similar to manually noting which packages are
1.79 rh 1301: currently installed, then performing a series of "make deinstall" and
1.141 skrll 1302: "make install" (or whatever DEPENDS_TARGET is set to) for these packages.
1.62 rh 1303:
1.70 rh 1304: You can use the "update" target to resume package updating in case a
1.79 rh 1305: previous "make update" was interrupted for some reason. However, in
1306: this case, make sure you don't call "make clean" or otherwise remove
1307: the list of dependent packages in ${WRKDIR}. Otherwise you lose the
1308: ability to automatically update the current package along with the
1309: dependent packages you have installed.
1310:
1.100 rh 1311: Resuming an interrupted "make update" will only work as long as the
1.79 rh 1312: package tree remains unchanged. If the source code for one of the
1.100 rh 1313: packages to be updated has been changed, resuming "make update" will
1.79 rh 1314: most certainly fail!
1.70 rh 1315:
1316: The following variables can be used either on the command line or in
1317: /etc/mk.conf to alter the behaviour of "make update":
1.62 rh 1318:
1319: - DEPENDS_TARGET:
1.65 rh 1320: Install target to use for the updated package and the
1321: dependent packages. Defaults to "install". E.g.
1322: "make update DEPENDS_TARGET=package"
1.70 rh 1323:
1324: - NOCLEAN:
1325: Don't clean up after updating. Useful if you want to leave the
1326: work sources of the updated packages around for inspection or
1327: other purposes. Be sure you eventually clean up the source
1328: tree (see the "clean-update" target below) or you may run into
1329: troubles with old source code still lying around on your next
1330: "make" or "make update".
1331:
1332: - REINSTALL:
1.100 rh 1333: Deinstall each package before installing (making ${DEPENDS_TARGET}).
1334: This may be necessary if the "clean-update" target (see below) was
1335: called after interrupting a running "make update".
1.70 rh 1336:
1337: * clean-update:
1338: Clean the source tree for all packages that would get updated if
1339: "make update" was called from the current directory. This target
1340: should not be used if the current package (or any of its depending
1.191 skrll 1341: packages) have already been de-installed (e.g., after calling "make
1.70 rh 1342: update") or you may lose some packages you intended to update.
1343: As a rule of thumb: only use this target _before_ the first time
1344: you call "make update" and only if you have a dirty package tree
1345: (e.g., if you used NOCLEAN). The following variables can be used
1346: either on the command line or in /etc/mk.conf to alter the behaviour
1347: of "make clean-update":
1348:
1349: - CLEAR_DIRLIST:
1350: After "make clean", do not reconstruct the list of directories to
1351: update for this package. Only use this if "make update" successfully
1352: installed all packages you wanted to update. Normally, this is done
1353: automatically on "make update", but may have been suppressed by the
1354: NOCLEAN variable (see above).
1.44 agc 1355:
1.104 tron 1356: * info:
1357: This target invokes "pkg_info" for the current package. You can use this
1358: e.g. to check which version of a package is installed.
1359:
1.44 agc 1360: * readme:
1361: This target generates a README.html file, which can be viewed using a
1.114 hubertf 1362: browser such as navigator (pkgsrc/www/navigator) or lynx
1363: (pkgsrc/www/lynx). The generated files contain references to any
1364: packages which are in the ${PACKAGES} directory on the local host. The
1365: generated files can be made to refer to URLs based on FTP_PKG_URL_HOST
1366: and FTP_PKG_URL_DIR. For example, if I wanted to generate README.html
1.44 agc 1367: files which pointed to binary packages on the local machine, in the
1368: directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
1369: FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
1.114 hubertf 1370: subdirectories will be searched for all the binary packages.
1.60 hubertf 1371:
1372: * readme-all:
1373: Use this target to create a file README-all.html which contains a
1374: list of all packages currently available in the NetBSD Packages
1375: Collection, together with the category they belong to and a short
1376: description. This file is compiled from the pkgsrc/*/README.html
1377: files, so be sure to run this _after_ a "make readme".
1.44 agc 1378:
1379: * cdrom-readme:
1380: This is very much the same as the readme: target (see above), but is
1381: to be used when generating a pkgsrc tree to be written to a CD-ROM.
1382: This target also produces README.html files, and can be made to refer
1383: to URLs based on CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
1.56 agc 1384:
1385: * show-distfiles:
1386: This target shows which distfiles and patchfiles are needed to build
1.82 abs 1387: the package. (DISTFILES and PATCHFILES, but not patches/*)
1.57 agc 1388:
1389: * show-downlevel:
1390: This target shows nothing if the package is not installed. If a version
1391: of this package is installed, but is not the version provided in this
1392: version of pkgsrc, then a warning message is displayed. This target can
1393: be used to show which of your installed packages are downlevel, and so
1394: the old versions can be deleted, and the current ones added.
1.85 agc 1395:
1396: * show-pkgsrc-dir:
1397: This target shows the directory in the pkgsrc hierarchy from which the
1398: package can be built and installed. This may not be the same directory
1399: as the one from which the package was installed. This target is intended
1400: to be used by people who may wish to upgrade many packages on a single
1401: host, and can be invoked from the top-level pkgsrc Makefile by using the
1.86 agc 1402: target "show-host-specific-pkgs"
1.197 abs 1403:
1404: * show-installed-depends:
1405: This target shows which installed packages match the current package's
1406: DEPENDS. Useful if out of date DEPENDS are causing build problems.
1.44 agc 1407:
1.94 hubertf 1408: * check-shlibs:
1409: After a package is installed, check all it's binaries and (on ELF
1410: platforms) shared libraries if they find the shared libs they need.
1411: Run by default if PKG_DEVELOPER is set in /etc/mk.conf.
1.118 hubertf 1412:
1413: * print-PLIST:
1414: After a 'make install' from a new or upgraded pkg, this prints out an
1415: attempt to generate a new PLIST from a 'find -newer work/.extract_done'.
1416: An attempt is made to care for shared libs etc., but it is STRONGLY
1.210 wiz 1417: recommended to review the result before putting it into PLIST. On
1.118 hubertf 1418: upgrades, it's useful to diff the output of this command against an already
1.210 wiz 1419: existing PLIST file.
1.118 hubertf 1420:
1421: If the package installs files via tar(1) or other methods that don't update
1.210 wiz 1422: file access times, be sure to add these files manually to your PLIST,
1.118 hubertf 1423: as 'find -newer' won't catch them!
1.101 hubertf 1424:
1425: * bulk-package:
1426: Used to do bulk builds. If an appropriate binary package already exists,
1427: no action is taken. If not, this target will compile, install and
1428: package it (and it's depends, if PKG_DEPENDS is set properly, see
1429: section 3.2.1). After creating the binary package, the sources, the
1430: just-installed package and it's required packages are removed,
1431: preserving free disk space.
1432:
1433: * bulk-install:
1434: Used during bulk-installs to install required packages. If an
1435: appropriate binary package is available, it will be installed via
1436: pkg_add. If not, "make bulk-package" will be executed, but the installed
1437: binary not be removed. A binary package is "appropriate" to be installed
1438: via pkg_add if:
1439:
1440: - None of the package's files (Makefile, ...) were modified since it
1441: was built
1442: - None of the package's required (binary) packages were modified since
1443: it was built
1.44 agc 1444:
1.163 jlam 1445:
1446: 8 buildlink.mk methodology
1447: ==========================
1448:
1449: Many packages that install libraries and headers for use in other packages
1450: now have buildlink.mk files in their pkgsrc subdirectory. The purpose of
1451: these files is two-fold:
1452:
1.184 hubertf 1453: (1) Cause all headers and libraries used by a particular package to be
1454: found in a known location during the configure and build process.
1455: These packages are said to be "weakly-buildlinked".
1456:
1457: (2) Cause _only_ those headers and libraries used by a particular package
1458: to be found during the configure and build process.
1459: These packages are said to be "strongly-buildlinked".
1.163 jlam 1460:
1461:
1462: 8.1 Using buildlink.mk files
1463: ============================
1464:
1.191 skrll 1465: Goal (1) is accomplished by simply including the buildlink.mk file of a
1466: dependency in the package's Makefile, which does the following:
1.163 jlam 1467:
1.184 hubertf 1468: (1a) Adds a DEPENDS or BUILD_DEPENDS line for the package;
1.163 jlam 1469:
1.184 hubertf 1470: (1b) Creates a directory ${BUILDLINK_DIR}, by default set to a
1471: subdirectory of ${WRKDIR};
1.163 jlam 1472:
1.184 hubertf 1473: (1c) Links all the headers and libraries for that dependency into
1474: ${BUILDLINK_DIR}/include and ${BUILDLINK_DIR}/lib, respectively;
1.163 jlam 1475:
1.184 hubertf 1476: (1d) Prepends -I${BUILDLINK_DIR}/include to CPPFLAGS, CFLAGS, CXXFLAGS,
1477: and -L${BUILDLINK_DIR}/lib to LDFLAGS;
1.163 jlam 1478:
1.184 hubertf 1479: (1e) Creates a wrapper script for GTK+-style config scripts, often found
1480: in GNOME software, that translates -I${LOCALBASE}/include and
1481: -L${LOCALBASE}/lib into references into ${BUILDLINK_DIR}.
1.163 jlam 1482:
1483: Some packages are for software libraries whose functionality is a part of
1484: recent released versions of NetBSD, e.g. readline, OpenSSL, and ncurses.
1485: For those packages, the buildlink.mk files link the appropriate system
1486: headers and libraries into ${BUILDLINK_DIR} so that goal (1) is still met.
1487: Where possible, the system headers and libraries are renamed when linked
1488: into ${BUILDLINK_DIR} to match the names of their pkgsrc counterparts so
1489: that the files may be referenced under a consistent name.
1490:
1.182 jlam 1491: Goal (2) requires some work on the part of the package builder. As all
1492: headers and libraries used by a package may be found in ${BUILDLINK_DIR},
1493: and -I${BUILDLINK_DIR}/include and -L${BUILDLINK_DIR}/lib are already passed
1494: to the compiler, it is no longer necessary to pass -I${LOCALBASE}/include or
1.211 jlam 1495: -L${LOCALBASE}/lib to the compiler. Therefore, those lines should be removed
1.182 jlam 1496: from package Makefiles, and where necessary, the package sources should be
1497: patched to do the same. Also, if a package uses X11, then by including
1498: mk/x11.buildlink.mk, -I${BUILDLINK_X11_DIR}/include and
1499: -L${BUILDLINK_X11_DIR}/lib are also passed to the compiler instead of the
1500: corresponding directories in ${X11BASE}. Also, if USE_BUILDLINK_ONLY is
1501: defined, then -L${LOCALBASE}/lib is not automatically added to LDFLAGS in
1502: bsd.pkg.mk.
1.163 jlam 1503:
1504:
1505: 8.2 Writing buildlink.mk files
1506: ==============================
1507:
1508: Most of the work done by buildlink.mk files is encapsulated and shared
1.179 jlam 1509: through bsd.buildlink.mk, which is included by packages' buildlink.mk files.
1.163 jlam 1510: Please see the comments at the top of bsd.buildlink.mk for complete
1511: documentation on how to use the file. A simple example of a buildlink.mk
1512: for a mythical package foo follows:
1513:
1.184 hubertf 1514: .include "../../mk/bsd.buildlink.mk"
1515:
1516: BUILDLINK_DEPENDS.foo?= foo>=1.0
1517: DEPENDS+= ${BUILDLINK_DEPENDS.foo}:../../category/foo
1518:
1519: EVAL_PREFIX+= BUILDLINK_PREFIX.foo=foo
1520: BUILDLINK_FILES.foo= include/foo.h
1521: BUILDLINK_FILES.foo+= include/bar.h
1522: BUILDLINK_FILES.foo+= lib/libfoo.*
1523:
1524: # We need the libraries to be called "libbar.*".
1525: BUILDLINK_TRANSFORM.foo= -e "s|libfoo|libbar|g"
1526:
1527: BUILDLINK_TARGETS+= foo-buildlink
1528:
1529: pre-configure: foo-buildlink
1530: foo-buildlink: _BUILDLINK_USE
1.167 jlam 1531:
1532:
1533: 8.3 Converting packages to use buildlink.mk files
1534: =================================================
1535:
1536: The process of converting existing packages to use the buildlink.mk
1537: infrastructure is fairly straightforward. If a dependency on a particular
1538: package is required for its libraries and headers, then rather than
1539: directly adding a dependency on that package, include that package's
1540: buildlink.mk instead. The following variables may also be replaced with
1541: buildlink.mk files:
1542:
1543: USE_CURSES --> .include "../../devel/ncurses/buildlink.mk"
1544: USE_LIBINTL --> .include "../../devel/gettext-lib/buildlink.mk"
1545: USE_LTDL --> .include "../../devel/libtool/buildlink.mk"
1546: USE_MESA --> .include "../../graphics/Mesa/buildlink.mk"
1.186 jlam 1547: USE_MOTIF --> .include "../../mk/motif.buildlink.mk"
1.167 jlam 1548: USE_SSL --> .include "../../security/openssl/buildlink.mk"
1.182 jlam 1549: USE_X11 --> .include "../../mk/x11.buildlink.mk"
1.181 jlam 1550: USE_XAW --> .include "../../mk/xaw.buildlink.mk"
1.167 jlam 1551: USE_XPM --> .include "../../graphics/xpm/buildlink.mk"
1.172 jlam 1552:
1.175 jlam 1553: Packages that have an explicit dependency on ncurses should set USE_NCURSES
1554: to the reason why the system curses is insufficient, and include
1555: "../../devel/ncurses/buildlink.mk" afterwards. This helps to identify
1556: where the system curses differs from ncurses, and when the development of
1557: the system curses catches up in functionality, the USE_NCURSES setting may
1558: be removed.
1.188 jlam 1559:
1560: Package that need a Motif-1.2-compatible installation should define
1561: USE_MOTIF12, otherwise assume the need for a Motif-2.0-compatible
1562: installation. If MOTIFBASE or MOTIF12BASE is set, then it is assumed that
1563: they point to valid 1.2-compatible or 2.0-compatible Motif, respectively.
1.175 jlam 1564:
1565: Packages that use OpenSSL that require a specific version of OpenSSL should
1566: define USE_OPENSSL_VERSION to the minimum version number required prior to
1567: including "../../security/openssl/buildlink.mk". The version number is the
1568: hexadecimal number found in <openssl/opensslv.h>, or the variables
1569: OPENSSL_VERSION_{095A,096,096A,096B} may be used.
1.167 jlam 1570:
1.168 jlam 1571: The use of EVAL_PREFIX to find the installation prefix for packages may be
1572: removed since references to package library and header files are found
1573: through ${BUILDLINK_DIR}. If the required dependency pattern for a package
1574: differs from the default specified in the package's buildlink.mk file, then
1575: it may be set by defining BUILDLINK_DEPENDS.<pkgname> in the Makefile to
1576: the dependency pattern required.
1.173 jlam 1577:
1578: Packages will still need LDFLAGS to be set to include the appropriate rpath
1579: settings in order for built packages to find libraries. LDFLAGS should
1580: still contain -Wl,-R${LOCALBASE}/lib, and -Wl,-R${X11BASE}/lib if the
1581: package requires the X11 libraries. -Wl,-R should never refer to a
1582: ${BUILDLINK_DIR} library directory, and all such references should be
1583: purged from the build.
1.167 jlam 1584:
1585: A package that builds correctly with USE_BUILDLINK_ONLY set should have
1586: that setting added to its Makefile to note that it doesn't use any
1587: libraries or headers in ${LOCALBASE} directly, but rather references them
1.171 jlam 1588: only through ${BUILDLINK_DIR}. Note that you MUST check the build output
1589: to verify that no references to ${LOCALBASE} directories occurred during
1590: the configure or build process, or else the package cannot be marked as
1591: USE_BUILDLINK_ONLY.
1.163 jlam 1592:
1593:
1594: 9 Debugging
1.4 hubertf 1595: ===========
1596:
1.200 wiz 1597: To check out all the gotchas when building a package, here are the steps
1598: that I do in order to get a package working. Please note this is basically
1599: the same as what was explained in the previous sections, only with some
1.77 hubertf 1600: debugging aids.
1.1 hubertf 1601:
1.184 hubertf 1602: * Make sure PKG_DEVELOPER=1 is in /etc/mk.conf
1.200 wiz 1603: * Create a new directory, and run
1604:
1605: # url2pkg http://www.example.com/path/to/distfile.tar.gz
1606:
1607: You'll need to have pkgsrc/pkgtools/url2pkg installed for that.
1608: * Edit the Makefile as requested.
1.210 wiz 1609: * Fill in DESCR
1.200 wiz 1610: * ``make configure''
1611: * Add any dependancies glimpsed from the configure step to the package's
1612: Makefile.
1613: * Make the package compile, doing multiple rounds of
1614:
1615: # make
1616: # pkgvi ${WRKSRC}/some/file/that/does/not/compile
1617: # mkpatches
1618: # patchdiff
1619: # mv ${WRKDIR}/.newpatches/* patches
1620: # make mps
1621: # make clean
1622: [ mkpatches, patchdiff and pkgvi are from pkgsrc/pkgtools/pkgdiff ]
1.184 hubertf 1623:
1624: Doing as non-root user will assure that no files are modified that
1625: shouldn't, esp. not during the build phase.
1.200 wiz 1626: * Look at Makefile, fix if necessary; see section 4.1.
1627: * Generate a PLIST:
1628:
1629: # make install
1.210 wiz 1630: # make print-PLIST > PLIST
1.200 wiz 1631: # make deinstall
1.184 hubertf 1632: # make install
1.200 wiz 1633: # make deinstall
1634:
1.184 hubertf 1635: You usually need to be root to do this.
1636: * Look if there are any files left:
1637:
1.200 wiz 1638: # make print-PLIST
1639:
1.210 wiz 1640: If this brings up any files that are missing in PLIST, add them.
1.184 hubertf 1641: * Now that the PLIST is ok, install the package again and make a binary
1642: package:
1643:
1644: # make reinstall && make package
1645:
1646: * Delete the installed package:
1647:
1648: # pkg_delete blub
1649:
1650: * Repeat the above find command, which shouldn't find anything now:
1651:
1.200 wiz 1652: # make print-PLIST
1.184 hubertf 1653:
1654: * Reinstall the binary package:
1655:
1.200 wiz 1656: # pkg_add ..../blub.tgz
1.184 hubertf 1657:
1.200 wiz 1658: * Play with it. Make sure everything works.
1659: * Run pkglint from pkgsrc/pkgtools/pkglint, and fix the problems it reports.
1660:
1661: # pkglint
1662:
1663: * Submit (or commit, if you have cvs access); see section 11.
1.1 hubertf 1664:
1665:
1.163 jlam 1666: 10 FAQs & features of the package system
1667: ========================================
1.1 hubertf 1668:
1.163 jlam 1669: 10.1 Packages using GNU autoconfig
1670: ==================================
1.1 hubertf 1671:
1.4 hubertf 1672: If your package uses GNU autoconf, add the following to your package's
1673: Makefile:
1.1 hubertf 1674:
1.184 hubertf 1675: GNU_CONFIGURE= yes
1.1 hubertf 1676:
1.2 hubertf 1677: Note that this appends --prefix=${PREFIX} to CONFIGURE_ARGS, so you don't
1678: have to do that yourself, and this may not be what you want.
1.1 hubertf 1679:
1680:
1.163 jlam 1681: 10.2 Other distrib methods than .tar.gz
1682: =======================================
1.1 hubertf 1683:
1.4 hubertf 1684: If your package uses a different distribution method from .tar.gz, take a
1.183 hubertf 1685: look at the package for pkgsrc/editors/sam, which uses a gzipped shell archive
1.2 hubertf 1686: (shar), but the quick solution is to set EXTRACT_SUFX to the name after the
1.44 agc 1687: DISTNAME field, and add the following to your package's Makefile:
1.2 hubertf 1688:
1.184 hubertf 1689: EXTRACT_SUFX= .msg.gz
1690: EXTRACT_CMD= zcat
1691: EXTRACT_BEFORE_ARGS=
1692: EXTRACT_AFTER_ARGS= |sh
1.1 hubertf 1693:
1694:
1.163 jlam 1695: 10.3 Packages not creating their own subdirectory
1696: =================================================
1.4 hubertf 1697:
1698: Your package doesn't create a subdirectory for itself (like GNU software
1699: does, for instance), but extracts itself in the current directory: see
1.183 hubertf 1700: pkgsrc/editors/sam again, but the quick answer is:
1.2 hubertf 1701:
1.187 agc 1702: WRKSRC= ${WRKDIR}
1703:
1704: Please note that the old
1705:
1.184 hubertf 1706: NO_WRKSUBDIR= yes
1.187 agc 1707:
1708: has been deprecated and should not be used.
1.1 hubertf 1709:
1710:
1.163 jlam 1711: 10.4 Custom configuration process
1712: =================================
1.4 hubertf 1713:
1714: Your package uses a weird Configure script: See the top package, but the
1715: quick answer is:
1.2 hubertf 1716:
1.184 hubertf 1717: HAS_CONFIGURE= yes
1718: CONFIGURE_SCRIPT= Configure
1719: CONFIGURE_ARGS+= netbsd13
1.1 hubertf 1720:
1721:
1.163 jlam 1722: 10.5 Packages not building in their DISTNAME directory
1.4 hubertf 1723: ======================================================
1724:
1.44 agc 1725: Your package builds in a different directory from its base DISTNAME - see
1.4 hubertf 1726: tcl and tk packages:
1727:
1.184 hubertf 1728: WRKSRC= ${WRKDIR}/${DISTNAME}/unix
1.4 hubertf 1729:
1730:
1.163 jlam 1731: 10.6 How to fetch all distfiles at once
1732: =======================================
1.2 hubertf 1733:
1.4 hubertf 1734: You would like to download all the distfiles in a single batch from work or
1735: university, where you can't run a "make fetch". But there's no archive of
1736: the distfiles on ftp.netbsd.org and the one on ftp.freebsd.org contains
1737: many distfiles for which there are no ports (yet).
1738:
1.122 hubertf 1739: The answer here is to do a "make fetch-list" in /usr/pkgsrc, carry the
1740: resulting list to your machine at work/school and use it there If you don't
1741: have a NetBSD-compatible ftp(1) (like lukemftp) at work, don't forget to
1742: set FETCH_CMD to something that fetches an URL:
1743:
1744: At home:
1.184 hubertf 1745:
1746: % cd /usr/pkgsrc
1747: % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
1748: % scp /tmp/fetch.sh work:/tmp
1.122 hubertf 1749:
1750: At work:
1.184 hubertf 1751:
1752: % sh /tmp/fetch.sh
1753: % tar up /tmp/distfiles and take it home
1.122 hubertf 1754:
1755: If you have a machine running NetBSD, and you want to get *all* distfiles
1756: (even ones that aren't for your machine architecture), you can do so by
1757: using the above-mentioned 'make fetch-list'-approach, or fetch the distfiles
1758: directly by typing:
1759:
1.184 hubertf 1760: % make mirror-distfiles
1.122 hubertf 1761:
1762: If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can
1763: get all & everything by typing
1764:
1.184 hubertf 1765: % make fetch NO_IGNORE=yes
1.4 hubertf 1766:
1767:
1.163 jlam 1768: 10.7 How to fetch files from behind a firewall
1769: ==============================================
1.4 hubertf 1770:
1.82 abs 1771: If you are sitting behind a firewall which does not allow direct connections
1772: to Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts.
1773: This is done using an environment variable in the form of a URL
1.35 agc 1774: e.g. in Amdahl, the machine orpheus.amdahl.com is one of the firewalls, and
1.4 hubertf 1775: it uses port 80 as the proxy port number. So the proxy environment
1776: variables look like:
1777:
1778: ftp_proxy=ftp://orpheus.amdahl.com:80/
1779: http_proxy=http://orpheus.amdahl.com:80/
1.1 hubertf 1780:
1781:
1.163 jlam 1782: 10.8 If your patch contains an RCS ID
1783: =====================================
1.2 hubertf 1784:
1.200 wiz 1785: See section 4.3 on how to remove RCS IDs from patch files.
1.20 tron 1786:
1787:
1.163 jlam 1788: 10.9 How to pull in variables from /etc/mk.conf
1789: ===============================================
1.21 hubertf 1790:
1791: The problem with package-defined variables that can be overridden via
1.32 agc 1792: MAKECONF or /etc/mk.conf is that make(1) expands a variable as it is
1793: used, but evaluates preprocessor like statements (.if, .ifdef and
1794: .ifndef) as they are read. So, to use any variable (which may be set
1795: in /etc/mk.conf) in one of the .if* statements, the file /etc/mk.conf
1796: must be included before that .if* statement.
1797:
1798: Rather than have a number of ad-hoc ways of including /etc/mk.conf,
1799: should it exist, or MAKECONF, should it exist, include the
1800: pkgsrc/mk/bsd.prefs.mk file in the package Makefile before any
1801: preprocessor-like .if, .ifdef, or .ifndef statements:
1802:
1803: .include "../../mk/bsd.prefs.mk"
1804:
1805: .if defined(USE_MENUS)
1806: ...
1807: .endif
1.23 hubertf 1808:
1809:
1.163 jlam 1810: 10.10 Is there a mailing list for pkg-related discussion?
1811: =========================================================
1.23 hubertf 1812:
1.38 hubertf 1813: Yes. We are using tech-pkg@netbsd.org for discussing package related
1814: issues. To subscribe do:
1.23 hubertf 1815:
1.184 hubertf 1816: % echo subscribe tech-pkg | mail majordomo@netbsd.org
1.24 hubertf 1817:
1818:
1.163 jlam 1819: 10.11 How do i tell "make fetch" to do passive FTP?
1820: ===================================================
1.24 hubertf 1821:
1.82 abs 1822: This depends on which utility is used to retrieve distfiles. From
1823: bsd.pkg.mk, FETCH_CMD is assigned the first available command from the
1824: following list:
1825:
1.184 hubertf 1826: /usr/bin/fetch
1827: ${LOCALBASE}/bsd/bin/ftp
1828: /usr/bin/ftp
1.82 abs 1829:
1830: On a default NetBSD install, this will be /usr/bin/ftp, which automatically
1831: tries passive connections first, and falls back to active connections if the
1832: server refuses to do passive. For the other tools, add the following to your
1833: /etc/mk.conf file: PASSIVE_FETCH=1
1834:
1835: Having that option present will prevent /usr/bin/ftp from falling back to
1836: active transfers.
1.33 agc 1837:
1.49 frueauf 1838:
1.163 jlam 1839: 10.12 Dependencies on other packages
1840: ====================================
1.33 agc 1841:
1.72 dmcmahil 1842: Your package may depend on some other package being present - and there are
1843: various ways of expressing this dependency. NetBSD supports the
1.200 wiz 1844: BUILD_DEPENDS and DEPENDS definitions, as well as dependencies via
1845: buildlink.mk (see section 8).
1.72 dmcmahil 1846:
1.200 wiz 1847: The basic difference between the two definitions is as follows: The
1.147 hubertf 1848: DEPENDS definition registers that pre-requisite in the binary package,
1849: whilst the BUILD_DEPENDS definition does not.
1.33 agc 1850:
1.147 hubertf 1851: This means that if you only need a package present whilst you are building,
1852: it should be noted as a BUILD_DEPENDS.
1.33 agc 1853:
1.147 hubertf 1854: The format for a BUILD_DEPENDS and a DEPENDS definition is:
1855:
1856: <pre-req-package-name>:../../<category>/<pre-req-package>
1857:
1858: Please note that the "pre-req-package-name" may include any of the wildcard
1859: version numbers recognised by pkg_info(1).
1860:
1861: (a) If your package needs to use another package to build itself, this
1862: is specified using the BUILD_DEPENDS definition.
1863:
1864: BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
1865:
1.183 hubertf 1866: (b) If your package needs a library with which to link, this is specified
1867: using the DEPENDS definition. An example of this is the pkgsrc/print/lyx
1868: package, which uses the xpm library, version 3.4j to build.
1.33 agc 1869:
1.147 hubertf 1870: DEPENDS+= xpm-3.4j:../../graphics/xpm
1.64 tron 1871:
1872: You can also use wildcards in package dependences:
1873:
1.194 jlam 1874: DEPENDS+= xpm-[0-9]*:../../graphics/xpm
1.147 hubertf 1875:
1876: Note that such wildcard dependencies are retained when creating binary
1877: packages. The dependency is checked when installing the binary
1878: package and any package which matches the pattern will be used.
1.191 skrll 1879: Wildcard dependencies should be used with care.
1.64 tron 1880:
1.198 abs 1881: The -[0-9]* should be used instead of -* to avoid potentially
1882: ambiguous matches such as tk-postgresql matching a tk-* DEPEND.
1.147 hubertf 1883:
1884: (c) If your package needs some executable to be able to run correctly, this
1.183 hubertf 1885: is specified using the DEPENDS definition. The pkgsrc/print/lyx package needs
1886: to be able to execute the latex binary from the teTex package when it runs,
1.72 dmcmahil 1887: and that is specified:
1888:
1.194 jlam 1889: DEPENDS+= teTex-[0-9]*:../../print/teTeX
1.33 agc 1890:
1.84 jdolecek 1891: The comment about wildcard dependencies from previous paragraph
1892: applies here, too.
1.147 hubertf 1893:
1894: If your package needs files from another package to build, see the
1.183 hubertf 1895: first part of the "do-configure" target pkgsrc/print/ghostscript5 package
1896: (it relies on the jpeg sources being present in source form during the
1.147 hubertf 1897: build):
1898:
1.203 hubertf 1899: if [ ! -e ${PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
1900: cd ${PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract; \
1.147 hubertf 1901: fi
1.203 hubertf 1902:
1903: If you build any other packages that way, please make sure the working
1904: files are deleted too when this package's working files are cleaned up.
1905: The easiest way to do so is by adding a pre-clean target:
1906:
1907: pre-clean:
1908: cd ${PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean
1.147 hubertf 1909:
1.161 jlam 1910: Please also note the BUILD_USES_MSGFMT and BUILD_USES_GETTEXT_M4 definitions,
1911: which are provided as convenience definitions. The former works out whether
1.147 hubertf 1912: msgfmt(1) is part of the base system, and, if it isn't, installs the
1.183 hubertf 1913: pkgsrc/devel/gettext package. The latter adds a build dependency on either an
1.161 jlam 1914: installed version of an older gettext package, or if it isn't, installs the
1.183 hubertf 1915: pkgsrc/devel/gettext-m4 package.
1.34 frueauf 1916:
1.49 frueauf 1917:
1.163 jlam 1918: 10.13 Conflicts with other packages
1919: ===================================
1.34 frueauf 1920:
1921: Your package may conflict with other packages a user might already have
1922: installed on his system, e.g. if your package installs the same set of
1923: files like another package in our pkgsrc tree.
1924:
1.80 abs 1925: In this case you can set CONFLICTS to a space separated list of packages
1.34 frueauf 1926: (including version string) your package conflicts with.
1927:
1.63 tron 1928: For example pkgsrc/x11/Xaw3d and pkgsrc/x11/Xaw-Xpm install provide the
1929: same shared library, thus you set in pkgsrc/x11/Xaw3d/Makefile:
1.34 frueauf 1930:
1.194 jlam 1931: CONFLICTS= Xaw-Xpm-[0-9]*
1.34 frueauf 1932:
1.63 tron 1933: and in pkgsrc/x11/Xaw-Xpm/Makefile:
1.34 frueauf 1934:
1.194 jlam 1935: CONFLICTS= Xaw3d-[0-9]*
1.4 hubertf 1936:
1.63 tron 1937: Packages will automatically conflict with other packages with the name prefix
1938: and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
1939: with the older version "Xaw3d-1.3".
1.49 frueauf 1940:
1.98 rh 1941:
1.163 jlam 1942: 10.14 Software which has a WWW Home Page
1943: ========================================
1.42 tsarna 1944:
1945: The NetBSD packages system now supports a variable called HOMEPAGE.
1946: If the software being packaged has a home page, the Makefile should
1947: include the URL for that page in the HOMEPAGE variable. The definition
1948: of the variable should be placed immediately after the MAINTAINER
1949: variable.
1.49 frueauf 1950:
1.98 rh 1951:
1.163 jlam 1952: 10.15 How to handle modified distfiles with the 'old' name
1953: ==========================================================
1.73 hubertf 1954:
1955: Sometimes authors of a software package make some modifications after the
1956: software was released, and they put up a new distfile without changing the
1957: package's version number. If a package is already in pkgsrc at that time,
1958: the md5 checksum will no longer match. The correct way to work around this
1959: is to update the package's md5 checksum to match the package on the master
1.80 abs 1960: site (beware, any mirrors may not be up to date yet!), and to remove the
1961: old distfile from ftp.netbsd.org's /pub/NetBSD/packages/distfiles directory.
1.73 hubertf 1962: Furthermore, a mail to the package's author seems appropriate making sure
1.74 hubertf 1963: the distfile was really updated on purpose, and that no trojan horse or so
1.73 hubertf 1964: crept in.
1.78 hubertf 1965:
1.98 rh 1966:
1.163 jlam 1967: 10.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
1968: =========================================================================
1.78 hubertf 1969:
1970: When compiling the pkgsrc/pkgtools/pkg_install package, you get the error
1.83 hubertf 1971: from make that it doesn't know how to make /usr/share/tmac/tmac.andoc? This
1.78 hubertf 1972: indicates that you don't have installed the "text" set on your machine
1.150 hubertf 1973: (nroff, ...). It is recommended to do that.
1974:
1975: In the case of the pkg_install package, you can get away with setting
1976: NOMAN=YES either in the environment or in /etc/mk.conf.
1.78 hubertf 1977:
1.98 rh 1978:
1.163 jlam 1979: 10.17 How to handle incrementing versions when fixing an existing package
1980: =========================================================================
1.81 abs 1981:
1982: When making fixes to an existing package it can be useful to change
1983: the version number in PKGNAME. To avoid conflicting with future versions
1.216 hubertf 1984: by the original author, a 'nb1' ('nb2', ...) suffix is used on package
1985: versions. The "nb" is treated like a "." by the pkg tools.
1986:
1987: To set the package's revision, set the PKGREVISION variable, e.g.
1988:
1989: DISTNAME= foo-17.42
1990: PKGREVISION= 9
1991:
1992: This will result in a PKGNAME of foo-17.42nb9.
1.93 hubertf 1993:
1.98 rh 1994:
1.163 jlam 1995: 10.18 "Could not find bsd.own.mk" - what's wrong?
1996: =================================================
1.93 hubertf 1997:
1998: You didn't install the compiler set, comp.tgz, when you installed your
1999: NetBSD machine. Please get it and install it, by extracting it in /:
2000:
1.184 hubertf 2001: # tar --unlink -pvxf .../comp.tgz
1.93 hubertf 2002:
2003: comp.tgz is part of every NetBSD release, please get the one matching
2004: the release you have installed (determine via "uname -r").
2005:
1.4 hubertf 2006:
1.163 jlam 2007: 10.19 Restricted packages
2008: =========================
1.98 rh 2009:
2010: Some licenses restrict how software may be re-distributed. In order to
2011: satisfy these restrictions, the package system defines five make variables
2012: that can be set to note these restrictions:
2013:
1.184 hubertf 2014: * RESTRICTED:
2015: This variable should be set whenever a restriction exists
2016: (regardless of its kind). Set this variable to a string
2017: containing the reason for the restriction.
2018:
2019: * NO_BIN_ON_CDROM:
2020: Binaries may not be placed on CD-ROM. Set this variable to
2021: ${RESTRICTED} whenever a binary package may not be included
2022: on a CD-ROM.
2023:
2024: * NO_BIN_ON_FTP:
2025: Binaries may not be placed on an ftp server. Set this
2026: variable to ${RESTRICTED} whenever a binary package may not
1.191 skrll 2027: not be made available on the Internet.
1.184 hubertf 2028:
2029: * NO_SRC_ON_CDROM:
2030: Distfiles may not be placed on CD-ROM. Set this variable to
2031: ${RESTRICTED} if re-distribution of the source code or other
2032: distfile(s) is not allowed on CD-ROMs.
2033:
2034: * NO_SRC_ON_FTP:
2035: Distfiles may not be placed on FTP. Set this variable to
2036: ${RESTRICTED} if re-distribution of the source code or other
1.191 skrll 2037: distfile(s) via the Internet is not allowed.
1.98 rh 2038:
1.99 rh 2039: Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic
2040: make variables to denote restrictions is deprecated, because they
1.98 rh 2041: unconditionally prevent users from generating binary packages!
1.103 wiz 2042:
1.184 hubertf 2043:
1.163 jlam 2044: 10.20 Packages using (n)curses
2045: ==============================
1.103 wiz 2046:
2047: Some packages need curses functionality that wasn't present in NetBSD's own
1.217 wiz 2048: curses prior to 1.4Y.
1.163 jlam 2049:
2050: If ../../devel/ncurses/buildlink.mk is included in a package's Makefile,
2051: then a curses library and headers with ncurses functionality are linked
2052: into ${BUILDLINK_DIR} at pre-configure time. If ncurses is needed, then a
2053: dependency on ncurses is added to the package, otherwise, if the system
2054: curses is sufficient, then the library and headers are linked into
2055: ${BUILDLINK_DIR} with ncurses names. If ncurses is actually required, then
2056: define USE_NCURSES in the package's Makefile.
2057:
2058:
2059: 10.21 Automated security check
2060: ==============================
1.156 hubertf 2061:
1.157 agc 2062: Please be aware that there can often be bugs in third-party software,
2063: and some of these bugs can leave a machine vulnerable to exploitation
2064: by attackers. In an effort to lessen the exposure, the NetBSD
2065: packages team maintains a database of known-exploits to packages which
2066: have at one time been included in pkgsrc. The database can be
2067: downloaded automatically, and a security audit of all packages
2068: installed on a system can take place. To do this, install the
2069: pkgsrc/security/audit-packages package. It has two components:
2070:
1.184 hubertf 2071: (1) download-vulnerability-list, an easy way to download a list of the
2072: security vulnerabilities information. This list is kept up to date by
2073: the NetBSD security officer and the NetBSD packages team, and is
2074: distributed from the NetBSD ftp server:
1.156 hubertf 2075:
1.157 agc 2076: ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/vulnerabilities
1.156 hubertf 2077:
1.184 hubertf 2078: (2) audit-packages, an easy way to audit the current machine, checking
2079: each vulnerability which is known. If a vulnerable package is
2080: installed, it will be shown by output to stdout, including a
2081: description of the type of vulnerability, and a URL containing more
2082: information.
1.157 agc 2083:
2084: Use of the audit-packages package is strongly recommended.
2085:
2086: The following message is displayed as part of the audit-packages
2087: installation procedure:
2088:
1.193 jmc 2089: ======================================================================
1.184 hubertf 2090: You may wish to have the vulnerabilities file downloaded daily so that
2091: it remains current. This may be done by adding an appropriate entry
2092: to the root users crontab(5) entry. For example the entry
2093:
2094: # download vulnerabilities file
2095: 0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1
2096:
2097: will update the vulnerability list every day at 3AM.
2098:
2099: In addition, you may wish to run the package audit from the daily
2100: security script. This may be accomplished by adding the following
2101: lines to /etc/security.local
2102:
2103: if [ -x ${PREFIX}/sbin/audit-packages ]; then
2104: ${PREFIX}/sbin/audit-packages
2105: fi
1.193 jmc 2106: ======================================================================
1.157 agc 2107:
1.156 hubertf 2108:
2109: Note to package developers: When a vulnerability is found, this should be
2110: noted in localsrc/security/advisories/pkg-vulnerabilities, and after the
2111: commit of that file, it should be copied to
2112: /pub/NetBSD/packages/distfiles/vulnerabilities on ftp.netbsd.org.
1.177 hubertf 2113:
2114:
2115: 10.22 What's the proper way to create an account from a package?
2116: ================================================================
2117:
1.214 jlam 2118: There are two make variables used to control the creation of package-specific
2119: groups and users at pre-install time. The first is PKG_GROUPS, which is a
2120: list of group[:groupid] elements, where the groupid is optional. The second
2121: is PKG_USERS, which is a list of elements of the form:
2122:
2123: user:group[:[userid][:[description][:[home][:shell]]]]
2124:
2125: where only the user and group are required, the rest being optional. A
2126: simple example is:
2127:
2128: PKG_GROUPS= foogroup
2129: PKG_USERS= foouser:foogroup
2130:
2131: A more complex example is that creates two groups and two users is:
2132:
2133: PKG_GROUPS= group1 group2:1005
2134: PKG_USERS= first:group1::First\\ User \
2135: second:group2::Second\\ User:/home/second:${SH}
2136:
2137: By default, a new user will have home directory /nonexistent, and login shell
2138: /sbin/nologin unless they are specified as part of the user element.
2139:
2140: The package Makefile must also include "../../mk/bsd.pkg.install.mk" prior to
2141: the inclusion of bsd.pkg.mk. This will cause the users and groups to be
2142: created at pre-install time, and the admin will be prompted to remove them at
2143: post-deinstall time.
1.98 rh 2144:
2145:
1.163 jlam 2146: 11 Submitting & Committing
1.120 hubertf 2147: ==========================
2148:
1.163 jlam 2149: 11.1 Submitting your packages
1.120 hubertf 2150: =============================
2151:
1.200 wiz 2152: You have to separate between binary and "normal" (source) packages here:
1.1 hubertf 2153:
1.4 hubertf 2154: * precompiled binary packages:
1.98 rh 2155: Our policy is that we accept binaries only from NetBSD developers to
1.68 hubertf 2156: guarantee that the packages don't contain any trojan horses etc.
2157: This is not to piss anyone off but rather to protect our users!
2158: You're still free to put up your home-made binary packages and tell
2159: the world where to get them.
1.1 hubertf 2160:
1.4 hubertf 2161: * packages:
2162: First, check that your package is complete, compiles and runs well; see
1.123 hubertf 2163: section 8 and the rest of this document. Next, generate a gzipped
1.4 hubertf 2164: tar-file of all the files needed for the package, preferably with all
2165: files in a single directory. Place this tar-file to a place where the
2166: package maintainers can fetch it using FTP or HTTP (WWW). Finally,
1.67 tron 2167: send-pr with category "pkg", a synopsis which includes the package name
2168: and version number, a short description of your package
1.140 wiz 2169: (contents of the COMMENT variable are OK) and the URL of your tar-file.
1.2 hubertf 2170:
1.10 hubertf 2171: You will be notified if your send-pr has been addressed so you can remove
1.4 hubertf 2172: the tar-file.
1.123 hubertf 2173:
2174: If you want to submit several packages, please send a separate PR for
2175: each one, it's easier for us to track things that way.
1.120 hubertf 2176:
2177:
1.163 jlam 2178: 11.2 Committing: Importing the package into CVS
1.120 hubertf 2179: ===============================================
2180:
1.138 agc 2181: This section is only of interest for NetBSD developers with write
2182: access to the NetBSD pkgsrc repository. Please remember that cvs
2183: imports files relative to the cwd, and that the pathname that you
2184: give the "cvs import" command is so that it knows where to place
2185: the files in the repository. Newly created packages should be
2186: imported with a vendor tag of "TNF" and a release tag of "pkgsrc-base",
2187: e.g:
1.120 hubertf 2188:
1.184 hubertf 2189: % cd .../pkgsrc/<category>/<pkgname>
2190: % cvs import pkgsrc/<category>/<pkgname> TNF pkgsrc-base
1.139 agc 2191:
2192: and remember to move the directory from which you imported out of
2193: the way, or cvs will complain the next time you "cvs update" your
1.189 wiz 2194: source tree. Also don't forget to add the new package to the
2195: category's Makefile.
1.120 hubertf 2196:
1.199 martti 2197: The commit message of the initial import should include part of the
1.210 wiz 2198: DESCR file, so people reading the mailing lists know what the package
1.200 wiz 2199: is/does.
1.120 hubertf 2200:
2201: Please note all package updates/additions in doc/pkg-CHANGES! It's very
2202: important to keep this file up to date and conforming to the existing
2203: format, because it will be used by scripts to automatically update pages on
2204: www.netbsd.org and other sites.
1.202 agc 2205:
2206:
2207: 11.3 Updating a Package to a Newer Version
2208: ==========================================
2209:
2210: Please always put a concise, appropriate and relevant summary of the
2211: changes between old and new versions into the commit log when updating
2212: a package. There are various reasons for this:
2213:
2214: + a URL is volatile, and can change over time. It may go away completely,
2215: or its information may be overwritten by newer information.
2216:
2217: + having the change information between old and new versions in our CVS
2218: repository is very useful for people who use either cvs or anoncvs.
2219:
2220: + having the change information between old and new versions in our CVS
2221: repository is very useful for people who read the pkgsrc-changes mailing
2222: list, so that they can make tactical decisions about when to upgrade
2223: the package.
2224:
2225: Please also recognise that, just because a new version of a package
2226: has been released, it should not automatically be upgraded in the CVS
2227: repository. We prefer to be conservative in the packages that are
2228: included in pkgsrc - development or beta packages are not really the
2229: best thing for most places in which pkgsrc is used. Please use your
2230: judgement about what should go into pkgsrc, and bear in mind that
2231: stability is to be preferred above new and possibly untested features.
2232:
1.1 hubertf 2233:
2234:
1.163 jlam 2235: 12 A simple example of a package: bison
1.4 hubertf 2236: =======================================
1.1 hubertf 2237:
1.200 wiz 2238: I checked to find a piece of software that wasn't in the packages
1.4 hubertf 2239: collection, and picked GNU bison. Quite why someone would want to have
1.2 hubertf 2240: bison when Berkeley yacc is already present in the tree is beyond me, but
2241: it's useful for the purposes of this exercise.
1.1 hubertf 2242:
1.4 hubertf 2243:
1.163 jlam 2244: 12.1 files
1.4 hubertf 2245: ==========
2246:
2247: The file contents in this section must be used without the "> " prefix.
2248:
2249:
1.163 jlam 2250: 12.1.1 Makefile
1.4 hubertf 2251: ===============
2252:
1.184 hubertf 2253: # <$>NetBSD<$>
2254:
2255: DISTNAME= bison-1.25
2256: CATEGORIES= devel
2257: MASTER_SITES= ${MASTER_SITE_GNU}
1.200 wiz 2258: MAINTAINER= thorpej@netbsd.org
1.184 hubertf 2259: HOMEPAGE= http://www.gnu.org/software/bison/bison.html
2260: COMMENT= GNU yacc clone
2261:
2262: GNU_CONFIGURE= yes
2263: INFO_FILES= bison.info
2264:
2265: .include "../../mk/bsd.pkg.mk"
1.4 hubertf 2266:
2267:
1.210 wiz 2268: 12.1.2 DESCR
1.4 hubertf 2269: ================
2270:
1.184 hubertf 2271: GNU version of yacc. Can make re-entrant parsers, and numerous other
2272: improvements. Why you would want this when Berkeley yacc(1) is part
2273: of the NetBSD source tree is beyond me.
1.4 hubertf 2274:
2275:
1.210 wiz 2276: 12.1.3 PLIST
1.4 hubertf 2277: ================
2278:
1.184 hubertf 2279: @comment <$>NetBSD<$>
2280: bin/bison
2281: man/man1/bison.1.gz
2282: @unexec install-info --delete %D/info/bison.info %D/info/dir
2283: info/bison.info
2284: info/bison.info-1
2285: info/bison.info-2
2286: info/bison.info-3
2287: info/bison.info-4
2288: info/bison.info-5
2289: @exec install-info %D/info/bison.info %D/info/dir
2290: share/bison.simple
2291: share/bison.hairy
1.31 tron 2292:
2293:
1.163 jlam 2294: 12.1.4 Checking a package "pkglint"
1.42 tsarna 2295: ===================================
1.31 tron 2296:
1.42 tsarna 2297: The NetBSD package system comes with a tool called "pkglint" (located in the
1.47 abs 2298: directory "pkgsrc/pkgtools/pkglint") which helps to check the contents of these
1.31 tron 2299: files. After installation it is quite easy to use, just change to the
1.140 wiz 2300: directory of the package you wish to examine and execute "pkglint":
1.31 tron 2301:
1.184 hubertf 2302: % pkglint
1.210 wiz 2303: OK: checking ./DESCR.
1.184 hubertf 2304: OK: checking Makefile.
2305: OK: checking distinfo.
2306: OK: checking patches/patch-aa.
2307: looks fine.
1.31 tron 2308:
1.42 tsarna 2309: Depending on the supplied command line arguments (see "man pkglint") more
1.140 wiz 2310: verbose checks will be performed. Use e.g. "pkglint -v" for a very verbose
2311: check.
1.4 hubertf 2312:
2313:
1.163 jlam 2314: 12.2 Steps for building, installing, packaging
1.4 hubertf 2315: ==============================================
2316:
2317: Create the directory where the package lives, plus any auxiliary directories:
2318:
1.184 hubertf 2319: # cd /usr/pkgsrc/lang
2320: # mkdir bison
2321: # cd bison
1.200 wiz 2322: # mkdir patches pkg
1.4 hubertf 2323:
1.210 wiz 2324: Create Makefile, DESCR and PLIST as in section 11.1,
1.4 hubertf 2325: then continue with fetching the distfile:
2326:
1.184 hubertf 2327: # make fetch
2328: >> bison-1.25.tar.gz doesn't seem to exist on this system.
2329: >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
2330: Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
2331: ftp: Error retrieving file: 500 Internal error
2332:
2333: >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
2334: Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
2335: ftp: Error retrieving file: 500 Internal error
2336:
2337: >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
2338: Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
2339: Successfully retrieved file.
1.4 hubertf 2340:
1.151 agc 2341: Generate the checksum of the distfile into distinfo:
1.4 hubertf 2342:
1.184 hubertf 2343: # make makesum
1.4 hubertf 2344:
2345: Now compile:
2346:
1.184 hubertf 2347: # make
2348: >> Checksum OK for bison-1.25.tar.gz.
2349: ===> Extracting for bison-1.25
2350: ===> Patching for bison-1.25
2351: ===> Ignoring empty patch directory
2352: ===> Configuring for bison-1.25
2353: creating cache ./config.cache
2354: checking for gcc... cc
2355: checking whether we are using GNU C... yes
2356: checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
2357: checking how to run the C preprocessor... cc -E
2358: checking for minix/config.h... no
2359: checking for POSIXized ISC... no
2360: checking whether cross-compiling... no
2361: checking for ANSI C header files... yes
2362: checking for string.h... yes
2363: checking for stdlib.h... yes
2364: checking for memory.h... yes
2365: checking for working const... yes
2366: checking for working alloca.h... no
2367: checking for alloca... yes
2368: checking for strerror... yes
2369: updating cache ./config.cache
2370: creating ./config.status
2371: creating Makefile
2372: ===> Building for bison-1.25
2373: 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
2374: 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
2375: 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
2376: 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
2377: 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
2378: 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
2379: 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
2380: 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
2381: 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
2382: 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
2383: 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
2384: 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
2385: 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
2386: 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
2387: 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
2388: 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
2389: 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
2390: 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
2391: 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
2392: 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
2393: 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
2394: cc -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o getargs.o gram.o lalr.o lex.o main.o nullable.o output.o print.o reader.o reduce.o symtab.o warshall.o version.o getopt.o getopt1.o
2395: ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
2396: rm -f bison.s1
2397: sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
1.4 hubertf 2398:
1.10 hubertf 2399: Everything seems OK, so install the files:
1.4 hubertf 2400:
1.184 hubertf 2401: # make install
2402: >> Checksum OK for bison-1.25.tar.gz.
2403: ===> Installing for bison-1.25
2404: sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
2405: rm -f /usr/pkg/bin/bison
2406: cd /usr/pkg/share; rm -f bison.simple bison.hairy
2407: rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
2408: install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison
2409: /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
2410: /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
2411: cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
2412: /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
2413: ===> Registering installation for bison-1.25
1.4 hubertf 2414:
2415: You can now use bison, and also - if you decide so - remove it with
2416: "pkg_delete bison-1.25". Should you decide that you want a binary package,
2417: do this now:
2418:
1.184 hubertf 2419: # make package
2420: >> Checksum OK for bison-1.25.tar.gz.
2421: ===> Building package for bison-1.25
2422: Creating package bison-1.25.tgz
2423: Registering depends:.
2424: Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
1.4 hubertf 2425:
1.7 hubertf 2426: Now that you don't need the source and object files any more, clean up:
1.4 hubertf 2427:
1.184 hubertf 2428: # make clean
2429: ===> Cleaning for bison-1.25
1.1 hubertf 2430:
2431:
1.4 hubertf 2432: ======================
2433: Appendix A: build logs
2434: ======================
1.1 hubertf 2435:
1.4 hubertf 2436: A.1 Building top
2437: ================
1.1 hubertf 2438:
1.184 hubertf 2439: # make
2440: >> top-3.5beta5.tar.gz doesn't seem to exist on this system.
2441: >> Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
2442: Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheus.amdahl.com:80/)
2443: Successfully retrieved file.
2444: >> Checksum OK for top-3.5beta5.tar.gz.
2445: ===> Extracting for top-3.5beta5
2446: ===> Patching for top-3.5beta5
2447: ===> Applying NetBSD patches for top-3.5beta5
2448: ===> Configuring for top-3.5beta5
2449: /bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3.5beta5/.defaults
2450: chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install
2451:
2452: Reading configuration from last time...
2453:
2454: Using these settings:
2455: Bourne Shell /bin/sh
2456: C compiler cc
2457: Compiler options -DHAVE_GETOPT -O
2458: Awk command awk
2459: Install command /usr/bin/install
2460:
2461: Module netbsd13
2462: LoadMax 5.0
2463: Default TOPN -1
2464: Nominal TOPN 18
2465: Default Delay 2
2466: Random passwd access yes
2467: Table Size 47
2468: Owner root
2469: Group Owner kmem
2470: Mode 2755
2471: bin directory $(PREFIX)/bin
2472: man directory $(PREFIX)/man/man1
2473: man extension 1
2474: man style man
2475:
2476: Building Makefile...
2477: Building top.local.h...
2478: Building top.1...
2479: Doing a "make clean".
2480: rm -f *.o top core core.* sigdesc.h
2481: To create the executable, type "make".
2482: To install the executable, type "make install".
2483: ===> Building for top-3.5beta5
2484: cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c top.c
2485: awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
2486: cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c commands.c
2487: cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c display.c
2488: cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c screen.c
2489: cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c username.c
2490: cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c utils.c
2491: utils.c: In function `errmsg':
2492: utils.c:348: warning: return discards `const' from pointer target type
2493: cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c version.c
2494: cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c getopt.c
2495: cc "-DOSREV=12G" -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
2496: rm -f top
2497: cc -o top top.o commands.o display.o screen.o username.o utils.o version.o getopt.o machine.o -ltermcap -lm -lkvm
2498: #
2499: #
2500: #
2501: #
2502: # make install
2503: >> Checksum OK for top-3.5beta5.tar.gz.
2504: ===> Installing for top-3.5beta5
2505: /usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
2506: /usr/bin/install top.1 /usr/pkg/man/man1/top.1
2507: strip /usr/pkg/bin/top
2508: ===> Registering installation for top-3.5beta5
2509: #
1.2 hubertf 2510:
1.1 hubertf 2511:
1.4 hubertf 2512: A.2 Packaging top
2513: =================
1.1 hubertf 2514:
1.184 hubertf 2515: # make package
2516: >> Checksum OK for top-3.5beta5.tar.gz.
2517: ===> Building package for top-3.5beta5
2518: Creating package top-3.5beta5.tgz
2519: Registering depends:.
2520: Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'
1.1 hubertf 2521:
1.2 hubertf 2522:
1.4 hubertf 2523: ======================================================
2524: Appendix B: Layout of the FTP server's package archive
2525: ======================================================
2526:
1.10 hubertf 2527: Layout for precompiled binary packages on ftp.netbsd.org:
1.4 hubertf 2528:
2529: /pub/NetBSD/packages/
2530: README
2531: distfiles/
1.8 hubertf 2532: pkgsrc -> /pub/NetBSD/NetBSD-current/pkgsrc
1.140 wiz 2533: 1.5/
1.4 hubertf 2534: i386/
2535: All/
2536: archivers/
2537: foo -> ../All/foo
2538: ...
2539: m68k/
2540: All/
2541: archivers/
2542: foo -> ../All/foo
2543: ...
2544: amiga -> m68k
2545: atari -> m68k
2546: ...
2547:
2548:
2549: To create:
2550: - cd /usr/pkgsrc ; make install ; make package
2551: - upload /usr/pkgsrc/packages to
1.134 garbled 2552: ftp://ftp.netbsd.org/pub/NetBSD/packages/\
2553: `uname -r | sed 's@\.\([0-9]*\)[\._].*@\.\1@'`/`sysctl -n hw.machine_arch`
1.4 hubertf 2554: - if necessary ln -s `sysctl -n hw.machine` `sysctl -n hw.machine_arch`
1.1 hubertf 2555:
1.4 hubertf 2556: Disk space needed: unknown.
1.121 garbled 2557:
2558: Packages for a release version of NetBSD should be uploaded to the
2559: directory major.minor corresponding to the appropriate release. Packages
2560: for NetBSD with versions such as "1.5.1" should be uploaded to the "1.5"
2561: directory, stripping the tiny number off the directory name. For packages
2562: that need to be tightly coupled with the OS Version, such as LKM's, you
2563: may create a major.minor.tiny release directory, and place those packages
1.134 garbled 2564: therein. Such packages should be marked with the variable
2565: "OSVERSION_SPECIFIC=yes" to mark them in some way for binary package
2566: builders.
1.1 hubertf 2567:
1.2 hubertf 2568:
2569: ###########################################################################
2570: # Local Variables:
1.4 hubertf 2571: # mode: Text
2572: # fill-column: 75
2573: # sentence-end-double-space: nil
1.2 hubertf 2574: # End:
CVSweb <webmaster@jp.NetBSD.org>