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