From 550ac289b54bde3fca09bb3000ab050cbf3f5385 Mon Sep 17 00:00:00 2001 From: wiz Date: Sun, 10 Sep 2006 19:55:23 +0000 Subject: regen --- doc/pkgsrc.html | 5360 ++++++++++++++++++++++++++++--------------------------- doc/pkgsrc.txt | 1044 +++++++---- 2 files changed, 3357 insertions(+), 3047 deletions(-) (limited to 'doc') diff --git a/doc/pkgsrc.html b/doc/pkgsrc.html index 80fb946f234..59cb98e1c22 100644 --- a/doc/pkgsrc.html +++ b/doc/pkgsrc.html @@ -307,34 +307,44 @@
17.3.2. Using libtool on GNU packages that already support libtool
17.3.3. GNU Autoconf/Automake
-
17.4. Fixing problems in the build phase
+
17.4. Programming languages
-
17.4.1. Compiling C and C++ code conditionally
-
17.4.2. How to handle compiler bugs
-
17.4.3. Undefined reference to “...”
+
17.4.1. C, C++, and Fortran
+
17.4.2. Java
+
17.4.3. Packages containing perl scripts
+
17.4.4. Other programming languages
-
17.5. Fixing problems in the install phase
+
17.5. Fixing problems in the build phase
-
17.5.1. Creating needed directories
-
17.5.2. Where to install documentation
-
17.5.3. Installing score files
-
17.5.4. Packages containing perl scripts
-
17.5.5. Packages with hardcoded paths to other interpreters
-
17.5.6. Packages installing perl modules
-
17.5.7. Packages installing info files
-
17.5.8. Packages installing man pages
-
17.5.9. Packages installing GConf2 data files
-
17.5.10. Packages installing scrollkeeper data files
-
17.5.11. Packages installing X11 fonts
-
17.5.12. Packages installing GTK2 modules
-
17.5.13. Packages installing SGML or XML data
-
17.5.14. Packages installing extensions to the MIME database
-
17.5.15. Packages using intltool
-
17.5.16. Packages installing startup scripts
-
17.5.17. Packages installing TeX modules
-
17.5.18. Packages installing hicolor theme icons
-
17.5.19. Packages installing desktop files
+
17.5.1. Compiling C and C++ code conditionally
+
17.5.2. How to handle compiler bugs
+
17.5.3. Undefined reference to “...”
+
17.5.4. Running out of memory
+
17.6. Fixing problems in the install phase
+
+
17.6.1. Creating needed directories
+
17.6.2. Where to install documentation
+
17.6.3. Installing score files
+
17.6.4. Packages with hardcoded paths to other interpreters
+
17.6.5. Packages installing perl modules
+
17.6.6. Packages installing info files
+
17.6.7. Packages installing man pages
+
17.6.8. Packages installing GConf2 data files
+
17.6.9. Packages installing scrollkeeper data files
+
17.6.10. Packages installing X11 fonts
+
17.6.11. Packages installing GTK2 modules
+
17.6.12. Packages installing SGML or XML data
+
17.6.13. Packages installing extensions to the MIME database
+
17.6.14. Packages using intltool
+
17.6.15. Packages installing startup scripts
+
17.6.16. Packages installing TeX modules
+
17.6.17. Packages supporting running binaries in + emulation
+
17.6.18. Packages installing hicolor theme icons
+
17.6.19. Packages installing desktop files
+
+
17.7. Marking packages as having problems
18. Debugging
19. Submitting and Committing
@@ -636,13 +646,11 @@ minutes!

pkgsrc. Packages are traditionally stored under /usr/pkgsrc.

The NetBSD package system
-

- This is the former name of “pkgsrc”. It is - part of the NetBSD operating system and can be bootstrapped to - run on non-NetBSD operating systems as well. It handles - building (compiling), installing, and removing of - packages. -

+

This is the former name of “pkgsrc”. It + is part of the NetBSD operating system and can be bootstrapped + to run on non-NetBSD operating systems as well. It handles + building (compiling), installing, and removing of + packages.

Distfile

This term describes the file or files that are provided by the author of the piece of software to @@ -1226,27 +1234,28 @@ file and inspect the contents before extracting it. 

 # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
 # cd pkgsrc/bootstrap
-# ./bootstrap
+# ./bootstrap +

See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways to get - pkgsrc before bootstrapping. The given - bootstrap command will use the defaults of - /usr/pkg for the - prefix where programs will be installed in, - and /var/db/pkg for the package database - directory where pkgsrc will do its internal bookkeeping. - However, these can also be set using command-line - arguments.

+ pkgsrc before bootstrapping. The given + bootstrap command will use the defaults of + /usr/pkg for the + prefix where programs will be installed in, + and /var/db/pkg for the package database + directory where pkgsrc will do its internal bookkeeping. + However, these can also be set using command-line + arguments.

Binary packages for the pkgsrc tools and an initial set of packages is - available for supported platforms. An up-to-date list of these can be - found on www.pkgsrc.org. - Note that this only works for privileged builds that install - into /usr/pkg.

+ available for supported platforms. An up-to-date list of these can be + found on www.pkgsrc.org. + Note that this only works for privileged builds that install + into /usr/pkg.

Note

The bootstrap installs a bmake tool. - Use this bmake when building via pkgsrc. - For examples in this guide, use bmake - instead of “make”.

+ Use this bmake when building via pkgsrc. + For examples in this guide, use bmake + instead of “make”.

@@ -1261,14 +1270,14 @@ file and inspect the contents before extracting it. image, or a UFS partition.

Before you start, you will need to download and install the Mac OS X Developer - Tools from Apple's Developer Connection. See http://developer.apple.com/macosx/ - for details. Also, make sure you install X11 for Mac OS X and the X11 SDK - from http://www.apple.com/macosx/x11/download/ - if you intend to build packages that use the X11 Window System.

+ Tools from Apple's Developer Connection. See http://developer.apple.com/macosx/ + for details. Also, make sure you install X11 for Mac OS X and the X11 SDK + from http://www.apple.com/macosx/x11/download/ + if you intend to build packages that use the X11 Window System.

If you already have a UFS partition, or have a spare partition - that you can format as UFS, it is recommended to use that instead of - the disk image. It'll be somewhat faster and will mount automatically - at boot time, where you must manually mount a disk image.

+ that you can format as UFS, it is recommended to use that instead of + the disk image. It'll be somewhat faster and will mount automatically + at boot time, where you must manually mount a disk image.

Note

You cannot use an ordinary HFS+ file system for pkgsrc, because pkgsrc currently @@ -1293,80 +1302,81 @@ file and inspect the contents before extracting it.

3.3.1.2. Using a UFS partition

By default, /usr will be on your root file - system, normally HFS+. It is possible to use the default - prefix of /usr/pkg - by symlinking /usr/pkg to a directory on a UFS - file system. Obviously, another symlink is required if you want to - place the package database directory outside the - prefix. e.g.

+ system, normally HFS+. It is possible to use the default + prefix of /usr/pkg + by symlinking /usr/pkg to a directory on a UFS + file system. Obviously, another symlink is required if you want to + place the package database directory outside the + prefix. e.g.

# ./bootstrap --pkgdbdir /usr/pkg/pkgdb

If you created your partitions at the time of installing Mac OS X - and formatted the target partition as UFS, it should automatically - mount on /Volumes/<volume name> when the - machine boots. If you are (re)formatting a partition as UFS, you need - to ensure that the partition map correctly reflects - “Apple_UFS” and not “Apple_HFS”.

+ and formatted the target partition as UFS, it should automatically + mount on /Volumes/<volume name> when the + machine boots. If you are (re)formatting a partition as UFS, you need + to ensure that the partition map correctly reflects + “Apple_UFS” and not “Apple_HFS”.

The problem is that none of the disk tools will let you touch a - disk that is booted from. You can unmount the partition, but even if - you newfs it, the partition type will be incorrect and the - automounter won't mount it. It can be mounted manually, but it won't - appear in Finder.

+ disk that is booted from. You can unmount the partition, but even if + you newfs it, the partition type will be incorrect and the + automounter won't mount it. It can be mounted manually, but it won't + appear in Finder.

You'll need to boot off of the OS X Installation (User) CD. When - the Installation program starts, go up to the menu and select Disk - Utility. Now, you will be able to select the partition you want - to be UFS, and Format it Apple UFS. Quit the Disk Utility, quit the - installer which will reboot your machine. The new UFS file system - will appear in Finder.

+ the Installation program starts, go up to the menu and select Disk + Utility. Now, you will be able to select the partition you want + to be UFS, and Format it Apple UFS. Quit the Disk Utility, quit the + installer which will reboot your machine. The new UFS file system + will appear in Finder.

Be aware that the permissions on the new file system will be writable - by root only.

+ by root only.

This note is as of 10.2 (Jaguar) and applies to earlier versions. - Hopefully Apple will fix Disk Utility in 10.3 (Panther).

+ Hopefully Apple will fix Disk Utility in 10.3 (Panther).

3.3.2. FreeBSD

-

- FreeBSD 4.7 and 5.0 have been tested and are supported, other versions - may work.

+

FreeBSD 4.7 and 5.0 have been tested and are supported, + other versions may work.

Care should be taken so that the tools that this kit installs do not conflict - with the FreeBSD userland tools. There are several steps:

+ with the FreeBSD userland tools. There are several steps:

  1. FreeBSD stores its ports pkg database in - /var/db/pkg. It is therefore - recommended that you choose a different location (e.g. - /usr/pkgdb) by - using the --pkgdbdir option to the bootstrap script.

    2. + /var/db/pkg. It is therefore + recommended that you choose a different location (e.g. + /usr/pkgdb) by + using the --pkgdbdir option to the bootstrap script.

  2. If you do not intend to use the FreeBSD ports tools, it's probably a - good idea to move them out of the way to avoid confusion, e.g.

    -
    # cd /usr/sbin
+	  good idea to move them out of the way to avoid confusion, e.g.
    
+
    +# cd /usr/sbin
 # mv pkg_add pkg_add.orig
 # mv pkg_create pkg_create.orig
 # mv pkg_delete pkg_delete.orig
-# mv pkg_info pkg_info.orig
    
+# mv pkg_info pkg_info.orig
+

  3. An example /etc/mk.conf file will be placed in - /etc/mk.conf.example file - when you use the bootstrap script.

    4. + /etc/mk.conf.example file + when you use the bootstrap script.

3.3.3. Interix

Interix is a POSIX-compatible subsystem for the Windows NT kernel, - providing a Unix-like environment with a tighter kernel integration than - available with Cygwin. It is part of the Windows Services for Unix - package, available for free for any licensed copy of Windows 2000, XP - (not including XP Home), or 2003. SFU can be downloaded from http://www.microsoft.com/windows/sfu/.

+ providing a Unix-like environment with a tighter kernel integration than + available with Cygwin. It is part of the Windows Services for Unix + package, available for free for any licensed copy of Windows 2000, XP + (not including XP Home), or 2003. SFU can be downloaded from http://www.microsoft.com/windows/sfu/.

Services for Unix 3.5, current as of this writing, has been tested. 3.0 - or 3.1 may work, but are not officially supported. (The main difference - in 3.0/3.1 is lack of pthreads.)

+ or 3.1 may work, but are not officially supported. (The main difference + in 3.0/3.1 is lack of pthreads.)

3.3.3.1. When installing Interix/SFU

At an absolute minimum, the following packages must be installed from - the Windows Services for Unix 3.5 distribution in order to use pkgsrc:

+ the Windows Services for Unix 3.5 distribution in order to use pkgsrc:

  • Utilities -> Base Utilities

  • Interix GNU Components -> (all)

    • @@ -1374,43 +1384,43 @@ file and inspect the contents before extracting it.

  • Interix SDK

When using pkgsrc on Interix, DO NOT install the Utilities subcomponent - "UNIX Perl". That is Perl 5.6 without shared module support, installed to - /usr/local, and will only cause confusion. Instead, install Perl 5.8 from - pkgsrc (or from a binary package).

+ "UNIX Perl". That is Perl 5.6 without shared module support, installed to + /usr/local, and will only cause confusion. Instead, install Perl 5.8 from + pkgsrc (or from a binary package).

The Remote Connectivity subcomponent "Windows Remote Shell Service" does - not need to be installed, but Remote Connectivity itself should be - installed in order to have a working inetd.

+ not need to be installed, but Remote Connectivity itself should be + installed in order to have a working inetd.

During installation you may be asked whether to enable setuid - behavior for Interix programs, and whether to make pathnames default to - case-sensitive. Setuid should be enabled, and case-sensitivity MUST be - enabled. (Without case-sensitivity, a large number of packages including - perl will not build.)

+ behavior for Interix programs, and whether to make pathnames default to + case-sensitive. Setuid should be enabled, and case-sensitivity MUST be + enabled. (Without case-sensitivity, a large number of packages including + perl will not build.)

NOTE: Newer Windows service packs change the way binary execution - works (via the Data Execution Prevention feature). In order to use - pkgsrc and other gcc-compiled binaries reliably, a hotfix containing - POSIX.EXE, PSXDLL.DLL, PSXRUN.EXE, and PSXSS.EXE (899522 or newer) - must be installed. Hotfixes are available from Microsoft through a - support contract; however, a NetBSD developer has made most Interix - hotfixes available for personal use from http://www.duh.org/interix/hotfixes.php.

+ works (via the Data Execution Prevention feature). In order to use + pkgsrc and other gcc-compiled binaries reliably, a hotfix containing + POSIX.EXE, PSXDLL.DLL, PSXRUN.EXE, and PSXSS.EXE (899522 or newer) + must be installed. Hotfixes are available from Microsoft through a + support contract; however, a NetBSD developer has made most Interix + hotfixes available for personal use from http://www.duh.org/interix/hotfixes.php.

3.3.3.2. What to do if Interix/SFU is already installed

If SFU is already installed and you wish to alter these settings to work - with pkgsrc, note the following things.

+ with pkgsrc, note the following things.

  • To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft - Windows Services for UNIX, then click Change. In the installer, choose - Add or Remove, then uncheck Utilities->UNIX Perl.

    • + Windows Services for UNIX, then click Change. In the installer, choose + Add or Remove, then uncheck Utilities->UNIX Perl.

  • To enable case-sensitivity for the file system, run REGEDIT.EXE, and - change the following registry key:

    + change the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel

    Set the DWORD value "obcaseinsensitive" to 0; then reboot.

  • To enable setuid binaries (optional), run REGEDIT.EXE, and change the - following registry key:

    + following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX

    Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.

    • @@ -1420,84 +1430,84 @@ file and inspect the contents before extracting it.

    3.3.3.3. Important notes for using pkgsrc

    The package manager (either the pkgsrc "su" user, or the user - running "pkg_add") must be a member of the local Administrators - group. Such a user must also be used to run the bootstrap. This is - slightly relaxed from the normal pkgsrc requirement of "root".

    + running "pkg_add") must be a member of the local Administrators + group. Such a user must also be used to run the bootstrap. This is + slightly relaxed from the normal pkgsrc requirement of "root".

    The package manager should use a umask of 002. "make install" will - automatically complain if this is not the case. This ensures that - directories written in /var/db/pkg are Administrators-group writeable.

    + automatically complain if this is not the case. This ensures that + directories written in /var/db/pkg are Administrators-group writeable.

    The popular Interix binary packages from http://www.interopsystems.com/ - use an older version of pkgsrc's pkg_* tools. Ideally, these should - NOT be used in conjunction with pkgsrc. If you choose to use them at - the same time as the pkgsrc packages, ensure that you use the proper - pkg_* tools for each type of binary package.

    + use an older version of pkgsrc's pkg_* tools. Ideally, these should + NOT be used in conjunction with pkgsrc. If you choose to use them at + the same time as the pkgsrc packages, ensure that you use the proper + pkg_* tools for each type of binary package.

    The TERM setting used for DOS-type console windows (including those - invoked by the csh and ksh startup shortcuts) is "interix". Most systems - don't have a termcap/terminfo entry for it, but the following .termcap - entry provides adequate emulation in most cases:

    + invoked by the csh and ksh startup shortcuts) is "interix". Most systems + don't have a termcap/terminfo entry for it, but the following .termcap + entry provides adequate emulation in most cases:

    -    interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
-
    + interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi: +

3.3.3.4. Limitations of the Interix platform

Though Interix suffices as a familiar and flexible substitute - for a full Unix-like platform, it has some drawbacks that should - be noted for those desiring to make the most of Interix.

+ for a full Unix-like platform, it has some drawbacks that should + be noted for those desiring to make the most of Interix.

  • X11:

    Interix comes with the standard set of X11R6 client libraries, - and can run X11 based applications, but it does - not come with an X server. Some options are - StarNet X-Win32, - Hummingbird Exceed - (available in a trimmed version for Interix from Interop Systems as the - Interop X Server), - and the free X11 server included with - Cygwin.

    + and can run X11 based applications, but it does + not come with an X server. Some options are + StarNet X-Win32, + Hummingbird Exceed + (available in a trimmed version for Interix from Interop Systems as the + Interop X Server), + and the free X11 server included with + Cygwin.

    Also, StarNet Communications has graciously provided a free - version of their X-Win32 product that accepts connections only - from localhost: - X-Win32 LX, - recommended by the maintainer of Interix pkgsrc support.

    + version of their X-Win32 product that accepts connections only + from localhost: + X-Win32 LX, + recommended by the maintainer of Interix pkgsrc support.

  • X11 acceleration:

    Because Interix runs in a completely different NT subsystem from - Win32 applications, it does not currently support various X11 - protocol extensions for acceleration (such as MIT-SHM or DGA). - Most interactive applications to a local X server will run - reasonably fast, but full motion video and other graphics - intensive applications may require a faster-than-expected CPU.

    + Win32 applications, it does not currently support various X11 + protocol extensions for acceleration (such as MIT-SHM or DGA). + Most interactive applications to a local X server will run + reasonably fast, but full motion video and other graphics + intensive applications may require a faster-than-expected CPU.

  • Audio:

    Interix has no native support for audio output. For audio - support, pkgsrc uses the esound client/server - audio system on Interix. Unlike on most platforms, the - audio/esound package does - not contain the esd - server component. To output audio via an Interix host, the - emulators/cygwin_esound package - must also be installed.

    + support, pkgsrc uses the esound client/server + audio system on Interix. Unlike on most platforms, the + audio/esound package does + not contain the esd + server component. To output audio via an Interix host, the + emulators/cygwin_esound package + must also be installed.

  • CD/DVDs, USB, and SCSI:

    Direct device access is not currently supported in Interix, so it - is not currently possible to access CD/DVD drives, USB devices, - or SCSI devices through non-filesystem means. Among other things, - this makes it impossible to use Interix directly for CD/DVD - burning.

    + is not currently possible to access CD/DVD drives, USB devices, + or SCSI devices through non-filesystem means. Among other things, + this makes it impossible to use Interix directly for CD/DVD + burning.

  • Tape drives:

    Due to the same limitations as for CD-ROMs and SCSI devices, tape - drives are also not directly accessible in Interix. However, - support is in work to make tape drive access possible by using - Cygwin as a bridge (similarly to audio bridged via Cygwin's - esound server).

    + drives are also not directly accessible in Interix. However, + support is in work to make tape drive access possible by using + Cygwin as a bridge (similarly to audio bridged via Cygwin's + esound server).

@@ -1505,149 +1515,153 @@ file and inspect the contents before extracting it.

3.3.3.5. Known issues for pkgsrc on Interix

It is not necessary, in general, to have a "root" user on the - Windows system; any member of the local Administrators group will - suffice. However, some packages currently assume that the user - named "root" is the privileged user. To accommodate these, you - may create such a user; make sure it is in the local group - Administrators (or your language equivalent).

-

"pkg_add" creates directories of mode 0755, not 0775, in - $PKG_DBDIR. For the time being, install packages as the local - Administrator (or your language equivalent), or run the following - command after installing a package to work around the issue:

+ Windows system; any member of the local Administrators group will + suffice. However, some packages currently assume that the user + named "root" is the privileged user. To accommodate these, you + may create such a user; make sure it is in the local group + Administrators (or your language equivalent).

+

pkg_add creates directories of mode + 0755, not 0775, in $PKG_DBDIR. For the + time being, install packages as the local Administrator (or + your language equivalent), or run the following command after + installing a package to work around the issue:

-# chmod -R g+w $PKG_DBDIR
+# chmod -R g+w $PKG_DBDIR +

3.3.4. IRIX

You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro - compiler (cc/c89). Please set the CC environment variable - according to your preference. If you do not have a license for the MIPSpro - compiler suite, you can download a gcc tardist file from http://freeware.sgi.com/.

+ compiler (cc/c89). Please set the CC environment variable + according to your preference. If you do not have a license for the MIPSpro + compiler suite, you can download a gcc tardist file from http://freeware.sgi.com/.

Please note that you will need IRIX 6.5.17 or higher, as this is the earliest - version of IRIX providing support for if_indextoname(3), if_nametoindex(3), - etc.

+ version of IRIX providing support for if_indextoname(3), if_nametoindex(3), + etc.

At this point in time, pkgsrc only supports one ABI at a time. That is, you cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit ABI. If you start out using "abi=n32", that's what all your packages will be built with.

Therefore, please make sure that you have no conflicting - CFLAGS in your environment or the - /etc/mk.conf. Particularly, make sure that you do not - try to link n32 object files with lib64 or vice versa. Check your - /etc/compiler.defaults!

+ CFLAGS in your environment or the + /etc/mk.conf. Particularly, make sure that you do not + try to link n32 object files with lib64 or vice versa. Check your + /etc/compiler.defaults!

If you have the actual pkgsrc tree mounted via NFS from a different host, - please make sure to set WRKOBJDIR to a local directory, - as it appears that IRIX linker occasionally runs into issues when trying to - link over a network-mounted file system.

+ please make sure to set WRKOBJDIR to a local directory, + as it appears that IRIX linker occasionally runs into issues when trying to + link over a network-mounted file system.

The bootstrapping process should set all the right options for programs such - as imake(1), but you may want to set some options depending on your local - setup. Please see pkgsrc/mk/defaults/mk.conf and, of - course, your compiler's man pages for details.

+ as imake(1), but you may want to set some options depending on your local + setup. Please see pkgsrc/mk/defaults/mk.conf and, of + course, your compiler's man pages for details.

If you are using SGI's MIPSPro compiler, please set -

+ 

-    PKGSRC_COMPILER=        mipspro
-
+ PKGSRC_COMPILER= mipspro +

- in /etc/mk.conf. Otherwise, pkgsrc will assume you - are using gcc and may end up passing invalid flags to the compiler. Note that - bootstrap should create an appropriate mk.conf.example by - default.

+ in /etc/mk.conf. Otherwise, pkgsrc will assume you + are using gcc and may end up passing invalid flags to the compiler. Note that + bootstrap should create an appropriate mk.conf.example by + default.

If you have both the MIPSPro compiler chain installed as well as gcc, - but want to make sure that MIPRPro is used, please set your PATH - to not include the location of gcc (often - /usr/freeware/bin), and (important) pass the - '--preserve-path' flag.

+ but want to make sure that MIPRPro is used, please set your PATH + to not include the location of gcc (often + /usr/freeware/bin), and (important) pass the + '--preserve-path' flag.

3.3.5. Linux

-

- Some versions of Linux (for example Debian GNU/Linux) need either - libtermcap or libcurses (libncurses). Installing the distributions - libncurses-dev package (or equivalent) should fix the problem.

-

- pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++ - Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested. -

+

Some versions of Linux (for example Debian GNU/Linux) need + either libtermcap or libcurses (libncurses). Installing the + distributions libncurses-dev package (or equivalent) should fix + the problem.

+

pkgsrc supports both gcc (GNU Compiler Collection) and icc + (Intel C++ Compiler). gcc is the default. icc 8.0 and 8.1 on + i386 have been tested.

To bootstrap using icc, assuming the default icc installation - directory:

+ directory:

-    env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \
-            ac_cv___attribute__=yes ./bootstrap
-
+ env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ + ac_cv___attribute__=yes ./bootstrap +

Note

icc 8.1 needs the `-i-static' argument instead of -static-libcxa.

icc supports __attribute__, but the GNU configure test uses a nested - function, which icc does not support. #undef'ing __attribute__ has the - unfortunate side-effect of breaking many of the Linux header files, which - cannot be compiled properly without __attribute__. The test must be - overridden so that __attribute__ is assumed supported by the - compiler.

+ function, which icc does not support. #undef'ing __attribute__ has the + unfortunate side-effect of breaking many of the Linux header files, which + cannot be compiled properly without __attribute__. The test must be + overridden so that __attribute__ is assumed supported by the + compiler.

After bootstrapping, you should set PKGSRC_COMPILER - in /etc/mk.conf:

+ in /etc/mk.conf:

-    PKGSRC_COMPILER=        icc
-
+ PKGSRC_COMPILER= icc +

The default installation directory for icc is - /opt/intel_cc_80, which - is also the pkgsrc default. If you have installed it into a different - directory, set ICCBASE in - /etc/mk.conf:

+ /opt/intel_cc_80, which + is also the pkgsrc default. If you have installed it into a different + directory, set ICCBASE in + /etc/mk.conf:

-    ICCBASE=                /opt/icc
-
+ ICCBASE= /opt/icc +

pkgsrc uses the static linking method of the runtime libraries - provided by icc, so binaries can be run on other systems which do not - have the shared libraries installed.

-

Libtool, however, extracts a list of libraries from the ld(1) - command run when linking a C++ shared library and records it, throwing - away the -Bstatic and -Bdynamic options interspersed between the libraries. - This means that libtool-linked C++ shared libraries will have a - runtime dependency on the icc libraries until this is fixed in libtool. -

+ provided by icc, so binaries can be run on other systems which do not + have the shared libraries installed.

+

Libtool, however, extracts a list of libraries from the + ld(1) command run when linking a C++ shared library and + records it, throwing away the -Bstatic and -Bdynamic options + interspersed between the libraries. This means that + libtool-linked C++ shared libraries will have a runtime + dependency on the icc libraries until this is fixed in + libtool.

3.3.6. OpenBSD

OpenBSD 3.0 and 3.2 are tested and supported.

Care should be taken so that the tools that this kit installs do not conflict - with the OpenBSD userland tools. There are several steps:

+ with the OpenBSD userland tools. There are several steps:

  1. OpenBSD stores its ports pkg database in - /var/db/pkg. It is therefore - recommended that you choose a different location (e.g. - /usr/pkgdb) by - using the --pkgdbdir option to the bootstrap script.

    2. + /var/db/pkg. It is therefore + recommended that you choose a different location (e.g. + /usr/pkgdb) by + using the --pkgdbdir option to the bootstrap script.

  2. If you do not intend to use the OpenBSD ports tools, it's probably a - good idea to move them out of the way to avoid confusion, e.g.

    -
    # cd /usr/sbin
+	  good idea to move them out of the way to avoid confusion, e.g.
    
+
    +# cd /usr/sbin
 # mv pkg_add pkg_add.orig
 # mv pkg_create pkg_create.orig
 # mv pkg_delete pkg_delete.orig
-# mv pkg_info pkg_info.orig
    
+# mv pkg_info pkg_info.orig
+

  3. An example /etc/mk.conf file will be placed in - /etc/mk.conf.example file - when you use the bootstrap script. OpenBSD's make program uses - /etc/mk.conf - as well. You can work around this by enclosing all the pkgsrc-specific parts - of the file with:

    + /etc/mk.conf.example file + when you use the bootstrap script. OpenBSD's make program uses + /etc/mk.conf + as well. You can work around this by enclosing all the pkgsrc-specific parts + of the file with:

    -    .ifdef BSD_PKG_MK
-    # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
-    .else
-    # OpenBSD stuff
-    .endif
-
    + .ifdef BSD_PKG_MK + # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here + .else + # OpenBSD stuff + .endif +
@@ -1655,10 +1669,10 @@ file and inspect the contents before extracting it.

3.3.7. Solaris

Solaris 2.6 through 9 are supported on both x86 and sparc. - You will need a working C compiler. Both gcc 2.95.3 and - Sun WorkShop 5 have been tested.

+ You will need a working C compiler. Both gcc 2.95.3 and + Sun WorkShop 5 have been tested.

The following packages are required on Solaris 8 for the bootstrap - process and to build packages.

+ process and to build packages.

  • SUNWsprot

  • SUNWarc

    • @@ -1667,45 +1681,45 @@ file and inspect the contents before extracting it.

  • SUNWlibm

Please note that the use of GNU binutils on Solaris is - not supported, as of June 2006.

+ not supported, as of June 2006.

Whichever compiler you use, please ensure the compiler tools and - your $prefix are in your PATH. This includes - /usr/ccs/{bin,lib} - and e.g. /usr/pkg/{bin,sbin}.

+ your $prefix are in your PATH. This includes + /usr/ccs/{bin,lib} + and e.g. /usr/pkg/{bin,sbin}.

3.3.7.1. If you are using gcc

It makes life much simpler if you only use the same gcc consistently - for building all packages.

+ for building all packages.

It is recommended that an external gcc be used only for bootstrapping, - then either build gcc from - lang/gcc or install a binary gcc - package, then remove gcc used during bootstrapping.

+ then either build gcc from + lang/gcc or install a binary gcc + package, then remove gcc used during bootstrapping.

Binary packages of gcc can be found through http://www.sun.com/bigadmin/common/freewareSearch.html.

3.3.7.2. If you are using Sun WorkShop

You will need at least the following packages installed (from WorkShop - 5.0)

+ 5.0)

  • SPROcc - - Sun WorkShop Compiler C 5.0

    • + - Sun WorkShop Compiler C 5.0

  • SPROcpl - - Sun WorkShop Compiler C++ 5.0

    • + - Sun WorkShop Compiler C++ 5.0

  • SPROild - - Sun WorkShop Incremental Linker

    • + - Sun WorkShop Incremental Linker

  • SPROlang - - Sun WorkShop Compilers common components

    • + - Sun WorkShop Compilers common components

You should set CC, CXX and - optionally, CPP in /etc/mk.conf, - e.g.:

+ optionally, CPP in /etc/mk.conf, + e.g.:

-    CC=     cc
-    CXX=    CC
-    CPP=    /usr/ccs/lib/cpp
-
+ CC= cc + CXX= CC + CPP= /usr/ccs/lib/cpp +

@@ -1719,25 +1733,25 @@ file and inspect the contents before extracting it. called cc64 and put it somewhere in the PATH:

-    #! /bin/sh
-    exec /opt/SUNWspro/bin/cc -xtarget=ultra -xarch=v9 ${1+"$@"}
-
+ #! /bin/sh + exec /opt/SUNWspro/bin/cc -xtarget=ultra -xarch=v9 ${1+"$@"} +

Then, pass the definition for CC in the environment of the bootstrap command:

-    $ cd bootstrap
-    $ CC=cc64 ./bootstrap
-
+ $ cd bootstrap + $ CC=cc64 ./bootstrap +

After bootstrapping, there are two alternative ways, depending on whether you want to find bugs in packages or get your system ready quickly. If you just want a running system, add the following lines to your mk.conf file:

-    CC=                     cc64
-    CXX=                    CC64
-    PKGSRC_COMPILER=        sunpro
-
+ CC= cc64 + CXX= CC64 + PKGSRC_COMPILER= sunpro +

This way, all calls to the compiler will be intercepted by the above wrapper and therefore get the necessary ABI options automatically. (Don't forget to create the shell script @@ -1747,13 +1761,13 @@ file and inspect the contents before extracting it. the following lines to your mk.conf file:

-    CC=                     cc
-    CXX=                    CC
-    PKGSRC_COMPILER=        sunpro
-    CFLAGS=                 -xtarget=ultra -xarch=v9
-    CXXFLAGS=               -xtarget=ultra -xarch=v9
-    LDFLAGS=                -xtarget=ultra -xarch=v9
-
+ CC= cc + CXX= CC + PKGSRC_COMPILER= sunpro + CFLAGS= -xtarget=ultra -xarch=v9 + CXXFLAGS= -xtarget=ultra -xarch=v9 + LDFLAGS= -xtarget=ultra -xarch=v9 +

Packages that don't use the flags provided in the configuration file will try to build 32-bit binaries and fail during linking. Detecting this is useful to prevent bugs on @@ -1764,14 +1778,14 @@ file and inspect the contents before extracting it.

3.3.7.4. Common problems

Sometimes, when using libtool, - /bin/ksh crashes with a segmentation fault. - The workaround is to use another shell for the configure - scripts, for example by installing shells/bash and adding the following lines - to your mk.conf:

+ /bin/ksh crashes with a segmentation fault. + The workaround is to use another shell for the configure + scripts, for example by installing shells/bash and adding the following lines + to your mk.conf:

-    CONFIG_SHELL=   ${LOCALBASE}/bin/bash
-    WRAPPER_SHELL=  ${LOCALBASE}/bin/bash
-
+ CONFIG_SHELL= ${LOCALBASE}/bin/bash + WRAPPER_SHELL= ${LOCALBASE}/bin/bash +

Then, rebuild the devel/libtool-base package.

@@ -1894,18 +1908,17 @@ file and inspect the contents before extracting it.

4.1.2. Installing binary packages

-

If you have the files on a CD-ROM or downloaded them to +

If you have the files on a CD-ROM or downloaded them to your hard disk, you can install them with the following command (be sure to su to root first):

# pkg_add /path/to/package.tgz
-

If you have FTP access and you don't want to download the +

If you have FTP access and you don't want to download the packages via FTP prior to installation, you can do this - automatically by giving pkg_add an FTP URL: -

+ automatically by giving pkg_add an FTP URL:

# pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All/package

Note that any prerequisite packages needed to run the package in question will be installed, too, assuming they are - present where you install from.

+ present where you install from.

To save some typing, you can set the PKG_PATH environment variable to a semicolon-separated list of paths (including remote URLs); trailing slashes are not allowed. @@ -1926,7 +1939,7 @@ file and inspect the contents before extracting it.

After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin in your PATH so you can actually start the just - installed program.

+ installed program.

@@ -2034,8 +2047,7 @@ package on your system and rebuild any dependencies.

4.2. Building packages from source

-

-After obtaining pkgsrc, the pkgsrc directory +

After obtaining pkgsrc, the pkgsrc directory now contains a set of packages, organized into categories. You can browse the online index of packages, or run make readme from the pkgsrc directory to build local @@ -2080,7 +2092,7 @@ to your mk.conf.

You can overwrite some of the major distribution sites to fit to sites that are close to your own. Have a look at pkgsrc/mk/defaults/mk.conf to find some examples - — in particular, look for the MASTER_SORT, + — in particular, look for the MASTER_SORT, MASTER_SORT_REGEX and INET_COUNTRY definitions. This may save some of your bandwidth and time.

@@ -2117,7 +2129,7 @@ compile time. use the pkgsrc bmake command instead of “make” in the examples in this guide.

-

For example, type

+

For example, type

% cd misc/figlet
 % make

at the shell prompt to build the various components of the @@ -2224,14 +2236,13 @@ You can now enter:

4.2.4. Selecting the compiler

By default, pkgsrc will use GCC to build packages. This may be - overridden by setting the following variables in /etc/mk.conf: -

+ overridden by setting the following variables in /etc/mk.conf:

PKGSRC_COMPILER:
-

This is a list of values specifying the chain of +

This is a list of values specifying the chain of compilers to invoke when building packages. Valid values - are:

+ are:

  • distcc: distributed C/C++ (chainable)

    • @@ -2246,20 +2257,20 @@ You can now enter:

  • sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio

-

The default is +

The default is “gcc”. You can use ccache and/or distcc with an appropriate PKGSRC_COMPILER setting, e.g. “ccache gcc”. This variable should always be - terminated with a value for a real compiler.

+ terminated with a value for a real compiler.

GCC_REQD:
-

This specifies the minimum version of GCC to use +

This specifies the minimum version of GCC to use when building packages. If the system GCC doesn't satisfy this requirement, then pkgsrc will build and - install one of the GCC packages to use instead.

+ install one of the GCC packages to use instead.

@@ -2341,7 +2352,7 @@ You can now enter: can be NFS-mounted while ${WRKOBJDIR} is local to every architecture. (It should be noted that PKGSRCDIR should not be set by the user - — it is an internal definition which refers to the + — it is an internal definition which refers to the root of the pkgsrc tree. It is possible to have many pkgsrc tree instances.)

  • LOCALPATCHES: @@ -2363,8 +2374,6 @@ You can now enter: package to automatically create binary packages after installing dependencies.

    • -

    -

    @@ -2401,7 +2410,7 @@ You can now enter: find their shared libs.

    -

    +

  • PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst @@ -2507,32 +2516,28 @@ PKG_OPTIONS.apache= suexec

    6.1. Building a single binary package

    -

    - Once you have built and installed a package, you can create a - binary package which can be installed on - another system with pkg_add(1). This saves having to build - the same package on a group of hosts and wasting CPU time. It - also provides a simple means for others to install your package, - should you distribute it. -

    -

    - To create a binary package, change into the appropriate - directory in pkgsrc, and run make - package: -

    -
    # cd misc/figlet
-# make package
    -

    - This will build and install your package (if not already done), - and then build a binary package from what was installed. You can - then use the pkg_* tools to manipulate - it. Binary packages are created by default in - /usr/pkgsrc/packages, in the form of a - gzipped tar file. See Section B.2, “Packaging figlet” for a - continuation of the above misc/figlet example.

    -

    - See Chapter 19, Submitting and Committing for information on how to submit - such a binary package.

    +

    Once you have built and installed a package, you can create + a binary package which can be installed on + another system with pkg_add(1). This saves having to build + the same package on a group of hosts and wasting CPU time. It also + provides a simple means for others to install your package, should + you distribute it.

    +

    To create a binary package, change into the appropriate + directory in pkgsrc, and run make + package:

    +
    +# cd misc/figlet
+# make package
+
    +

    This will build and install your package (if not already done), + and then build a binary package from what was installed. You can + then use the pkg_* tools to manipulate + it. Binary packages are created by default in + /usr/pkgsrc/packages, in the form of a + gzipped tar file. See Section B.2, “Packaging figlet” for a + continuation of the above misc/figlet example.

    +

    See Chapter 19, Submitting and Committing for information on how to submit + such a binary package.

    @@ -2543,16 +2548,16 @@ PKG_OPTIONS.apache= suexec

    6.3. Doing a bulk build of all packages

    If you want to get a full set of precompiled binary - packages, this section describes how to get them. Beware that - the bulk build will remove all currently installed packages from - your system!

    + packages, this section describes how to get them. Beware that + the bulk build will remove all currently installed packages from + your system!

    Having an FTP server configured either on the - machine doing the bulk builds or on a nearby NFS server can help - to make the packages available to other machines that can then - save time by installing only the binary packages. See ftpd(8) for - more information. If you use a remote NFS server's storage, be - sure to not actually compile on NFS storage, as this slows - things down a lot.

    + machine doing the bulk builds or on a nearby NFS server can help + to make the packages available to other machines that can then + save time by installing only the binary packages. See ftpd(8) for + more information. If you use a remote NFS server's storage, be + sure to not actually compile on NFS storage, as this slows + things down a lot.

    6.3.1. Configuration

    @@ -2560,142 +2565,141 @@ PKG_OPTIONS.apache= suexec

    6.3.1.1. build.conf

    The build.conf file is the main - configuration file for bulk builds. You can configure how your - copy of pkgsrc is kept up to date, how the distfiles are - downloaded, how the packages are built and how the report is - generated. You can find an annotated example file in - pkgsrc/mk/bulk/build.conf-example. To use - it, copy build.conf-example to - build.conf and edit it, following the - comments in that file.

    + configuration file for bulk builds. You can configure how your + copy of pkgsrc is kept up to date, how the distfiles are + downloaded, how the packages are built and how the report is + generated. You can find an annotated example file in + pkgsrc/mk/bulk/build.conf-example. To use + it, copy build.conf-example to + build.conf and edit it, following the + comments in that file.

    6.3.1.2. /etc/mk.conf

    You may want to set variables in - /etc/mk.conf. - Look at pkgsrc/mk/defaults/mk.conf for - details of the default settings. You will want to ensure that - ACCEPTABLE_LICENSES meet your local policy. - As used in this example, _ACCEPTABLE=yes - accepts all licenses.

    + /etc/mk.conf. + Look at pkgsrc/mk/defaults/mk.conf for + details of the default settings. You will want to ensure that + ACCEPTABLE_LICENSES meet your local policy. + As used in this example, _ACCEPTABLE=yes + accepts all licenses.

    -    PACKAGES?=      ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
-    WRKOBJDIR?=     /usr/tmp/pkgsrc   # build here instead of in pkgsrc
-    BSDSRCDIR=      /usr/src
-    BSDXSRCDIR=     /usr/xsrc         # for x11/xservers
-    OBJHOSTNAME?=   yes               # use work.`hostname`
-    FAILOVER_FETCH= yes               # insist on the correct checksum
-    PKG_DEVELOPER?= yes
-    _ACCEPTABLE=    yes
-
    + PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH} + WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc + BSDSRCDIR= /usr/src + BSDXSRCDIR= /usr/xsrc # for x11/xservers + OBJHOSTNAME?= yes # use work.`hostname` + FAILOVER_FETCH= yes # insist on the correct checksum + PKG_DEVELOPER?= yes + _ACCEPTABLE= yes +

    Some options that are especially useful for bulk builds can be found at the top lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are briefly described here.

    • If you are on a slow machine, you may want to - set USE_BULK_BROKEN_CHECK to - “no”.

      • + set USE_BULK_BROKEN_CHECK to + “no”.

    • If you are doing bulk builds from a read-only - copy of pkgsrc, you have to set BULKFILESDIR - to the directory where all log files are created. Otherwise the - log files are created in the pkgsrc directory.

      • + copy of pkgsrc, you have to set BULKFILESDIR + to the directory where all log files are created. Otherwise the + log files are created in the pkgsrc directory.

    • Another important variable is - BULK_PREREQ, which is a list of packages that - should be always available while building other - packages.

      • + BULK_PREREQ, which is a list of packages that + should be always available while building other + packages.

    Some other options are scattered in the pkgsrc infrastructure:

    • ALLOW_VULNERABLE_PACKAGES - should be set to yes. The purpose of the bulk - builds is creating binary packages, no matter if they are - vulnerable or not. When uploading the packages to a public - server, the vulnerable packages will be put into a directory of - their own. Leaving this variable unset would prevent the bulk - build system from even trying to build them, so possible - building errors would not show up.

      • + should be set to yes. The purpose of the bulk + builds is creating binary packages, no matter if they are + vulnerable or not. When uploading the packages to a public + server, the vulnerable packages will be put into a directory of + their own. Leaving this variable unset would prevent the bulk + build system from even trying to build them, so possible + building errors would not show up.

    • CHECK_FILES - (pkgsrc/mk/bsd.pkg.check.mk) can be set to - “yes” to check that the installed set of files - matches the PLIST.

      • + (pkgsrc/mk/bsd.pkg.check.mk) can be set to + “yes” to check that the installed set of files + matches the PLIST.

    • CHECK_INTERPRETER - (pkgsrc/mk/bsd.pkg.check.mk) can be set to - “yes” to check that the installed - “#!”-scripts will find their - interpreter.

      • + (pkgsrc/mk/bsd.pkg.check.mk) can be set to + “yes” to check that the installed + “#!”-scripts will find their + interpreter.

    6.3.1.3. pre-build.local

    It is possible to configure the bulk build to perform - certain site-specific tasks at the end of the pre-build - stage. If the file - pre-build.local exists in - /usr/pkgsrc/mk/bulk, it will be executed - (as a sh(1) script) at the end of the usual pre-build - stage. An example use of - pre-build.local is to have the line:

    + certain site-specific tasks at the end of the pre-build + stage. If the file + pre-build.local exists in + /usr/pkgsrc/mk/bulk, it will be executed + (as a sh(1) script) at the end of the usual pre-build + stage. An example use of + pre-build.local is to have the line:

    echo "I do not have enough disk space to build this pig." \
-    > misc/openoffice/$BROKENF
    + > misc/openoffice/$BROKENF

    to prevent the system from trying to build a particular package - which requires nearly 3 GB of disk space.

    + which requires nearly 3 GB of disk space.

    6.3.2. Other environmental considerations

    As /usr/pkg will be completely - deleted at the start of bulk builds, make sure your login - shell is placed somewhere else. Either drop it into - /usr/local/bin (and adjust your login - shell in the passwd file), or (re-)install it via - pkg_add(1) from /etc/rc.local, so - you can login after a reboot (remember that your current - process won't die if the package is removed, you just can't - start any new instances of the shell any more). Also, if you - use NetBSD earlier than 1.5, or you still want to use the pkgsrc - version of ssh for some reason, be sure to install ssh before - starting it from rc.local:

    + deleted at the start of bulk builds, make sure your login + shell is placed somewhere else. Either drop it into + /usr/local/bin (and adjust your login + shell in the passwd file), or (re-)install it via + pkg_add(1) from /etc/rc.local, so + you can login after a reboot (remember that your current + process won't die if the package is removed, you just can't + start any new instances of the shell any more). Also, if you + use NetBSD earlier than 1.5, or you still want to use the pkgsrc + version of ssh for some reason, be sure to install ssh before + starting it from rc.local:

    -    ( cd /usr/pkgsrc/security/ssh ; make bulk-install )
-    if [ -f /usr/pkg/etc/rc.d/sshd ]; then
-        /usr/pkg/etc/rc.d/sshd
-    fi
-
    + ( cd /usr/pkgsrc/security/ssh ; make bulk-install ) + if [ -f /usr/pkg/etc/rc.d/sshd ]; then + /usr/pkg/etc/rc.d/sshd + fi +

    Not doing so will result in you being not able to log in - via ssh after the bulk build is finished or if the machine - gets rebooted or crashes. You have been warned! :)

    + via ssh after the bulk build is finished or if the machine + gets rebooted or crashes. You have been warned! :)

    6.3.3. Operation

    Make sure you don't need any of the packages still - installed. -

    + installed.

    Warning

    During the bulk build, all packages will be - removed!

    + removed!

    Be sure to remove all other things that might - interfere with builds, like some libs installed in - /usr/local, etc. then become root and type:

    -
    # cd /usr/pkgsrc
-# sh mk/bulk/build
    + interfere with builds, like some libs installed in + /usr/local, etc. then become root and type:

    +
    +# cd /usr/pkgsrc
+# sh mk/bulk/build
+

    If for some reason your last build didn't complete (power - failure, system panic, ...), you can continue it by - running:

    + failure, system panic, ...), you can continue it by + running:

    # sh mk/bulk/build restart
    -

    - At the end of the bulk build, you will get a summary via mail, - and find build logs in the directory specified by - FTP in the build.conf - file. -

    +

    At the end of the bulk build, you will get a summary via mail, + and find build logs in the directory specified by + FTP in the build.conf + file.

    @@ -2703,94 +2707,72 @@ PKG_OPTIONS.apache= suexec

    The bulk builds consist of three steps:

    1. pre-build
    -

    - The script updates your pkgsrc tree via (anon)cvs, then - cleans out any broken distfiles, and removes all - packages installed.

    +

    The script updates your pkgsrc tree via (anon)cvs, then + cleans out any broken distfiles, and removes all + packages installed.

    2. the bulk build
    -

    - This is basically “make bulk-package” with - an optimised order in which packages will be - built. Packages that don't require other packages will - be built first, and packages with many dependencies will - be built later. -

    +

    This is basically “make bulk-package” with + an optimised order in which packages will be + built. Packages that don't require other packages will + be built first, and packages with many dependencies will + be built later.

    3. post-build
    -

    - Generates a report that's placed in the directory - specified in the build.conf file - named broken.html, a short version - of that report will also be mailed to the build's - admin.

    +

    Generates a report that's placed in the directory + specified in the build.conf file + named broken.html, a short version + of that report will also be mailed to the build's + admin.

    -

    - During the build, a list of broken packages will be compiled - in /usr/pkgsrc/.broken (or - .../.broken.${MACHINE} if - OBJMACHINE is set), individual build logs - of broken builds can be found in the package's - directory. These files are used by the bulk-targets to mark - broken builds to not waste time trying to rebuild them, and - they can be used to debug these broken package builds - later. -

    +

    During the build, a list of broken packages will be compiled + in /usr/pkgsrc/.broken (or + .../.broken.${MACHINE} if + OBJMACHINE is set), individual build logs + of broken builds can be found in the package's + directory. These files are used by the bulk-targets to mark + broken builds to not waste time trying to rebuild them, and + they can be used to debug these broken package builds + later.

    6.3.5. Disk space requirements

    Currently, roughly the following requirements are valid for - NetBSD 2.0/i386:

    + NetBSD 2.0/i386:

      -

    • - 10 GB - distfiles (NFS ok) -

      • -

    • - 8 GB - full set of all binaries (NFS ok) -

      • -

    • - 5 GB - temp space for compiling (local disk recommended) -

      • +

    • 10 GB - distfiles (NFS ok)

      • +

    • 8 GB - full set of all binaries (NFS ok)

      • +

    • 5 GB - temp space for compiling (local disk recommended)

    -

    - Note that all pkgs will be de-installed as soon as they are - turned into a binary package, and that sources are removed, - so there is no excessively huge demand to disk - space. Afterwards, if the package is needed again, it will - be installed via pkg_add(1) instead of building again, so - there are no cycles wasted by recompiling. -

    +

    Note that all pkgs will be de-installed as soon as they are + turned into a binary package, and that sources are removed, + so there is no excessively huge demand to disk + space. Afterwards, if the package is needed again, it will + be installed via pkg_add(1) instead of building again, so + there are no cycles wasted by recompiling.

    6.3.6. Setting up a sandbox for chrooted builds

    -

    - If you don't want all the packages nuked from a machine - (rendering it useless for anything but pkg compiling), there - is the possibility of doing the package bulk build inside a - chroot environment. -

    -

    - The first step is to set up a chroot sandbox, - e.g. /usr/sandbox. This can be done by - using null mounts, or manually. -

    -

    - There is a shell script called - pkgsrc/mk/bulk/mksandbox which will set - up the sandbox environment using null mounts. It will also - create a script called sandbox in the - root of the sandbox environment, which will allow the null - mounts to be activated using the sandbox - mount command and deactivated using the - sandbox umount command. -

    -

    - To set up a sandbox environment by hand, after extracting all - the sets from a NetBSD installation or doing a make - distribution DESTDIR=/usr/sandbox in - /usr/src/etc, be sure the following items - are present and properly configured: -

    +

    If you don't want all the packages nuked from a machine + (rendering it useless for anything but pkg compiling), there + is the possibility of doing the package bulk build inside a + chroot environment.

    +

    The first step is to set up a chroot sandbox, + e.g. /usr/sandbox. This can be done by + using null mounts, or manually.

    +

    There is a shell script called + pkgsrc/mk/bulk/mksandbox which will set + up the sandbox environment using null mounts. It will also + create a script called sandbox in the + root of the sandbox environment, which will allow the null + mounts to be activated using the sandbox + mount command and deactivated using the + sandbox umount command.

    +

    To set up a sandbox environment by hand, after extracting all + the sets from a NetBSD installation or doing a make + distribution DESTDIR=/usr/sandbox in + /usr/src/etc, be sure the following items + are present and properly configured:

    1. Kernel

      @@ -2814,9 +2796,9 @@ PKG_OPTIONS.apache= suexec

    2. /usr/src (system sources, - e. g. for sysutils/aperture):

      + e. g. for sysutils/aperture):

      # ln -s ../disk1/cvs .
-# ln -s cvs/src-2.0 src
      + # ln -s cvs/src-2.0 src

    3. Create /var/db/pkg (not part of default install):

      @@ -2828,198 +2810,175 @@ PKG_OPTIONS.apache= suexec

    4. Checkout pkgsrc via cvs into - /usr/sandbox/usr/pkgsrc:

      -
      # cd /usr/sandbox/usr
-# cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
      + /usr/sandbox/usr/pkgsrc:

      +
      +# cd /usr/sandbox/usr
+# cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc
+

      Do not mount/link this to the copy of your pkgsrc tree - you do development in, as this will likely cause problems! -

      + you do development in, as this will likely cause problems!

    5. Make - /usr/sandbox/usr/pkgsrc/packages and - .../distfiles point somewhere - appropriate. NFS- and/or nullfs-mounts may come in handy! -

      6. + /usr/sandbox/usr/pkgsrc/packages and + .../distfiles point somewhere + appropriate. NFS- and/or nullfs-mounts may come in handy!

    6. Edit /etc/mk.conf, see Section 6.3.1.2, “/etc/mk.conf”.

    7. Adjust mk/bulk/build.conf to suit your needs.

    When the chroot sandbox is set up, you can start - the build with the following steps:

    -
    # cd /usr/sandbox/usr/pkgsrc
-# sh mk/bulk/do-sandbox-build
    -

    - This will just jump inside the sandbox and start building. At - the end of the build, mail will be sent with the results of - the build. Created binary pkgs will be in - /usr/sandbox/usr/pkgsrc/packages - (wherever that points/mounts to/from).

    + the build with the following steps:

    +
    +# cd /usr/sandbox/usr/pkgsrc
+# sh mk/bulk/do-sandbox-build
+
    +

    This will just jump inside the sandbox and start building. At + the end of the build, mail will be sent with the results of + the build. Created binary pkgs will be in + /usr/sandbox/usr/pkgsrc/packages + (wherever that points/mounts to/from).

    6.3.7. Building a partial set of packages

    -

    In addition to building a complete set of all packages in - pkgsrc, the pkgsrc/mk/bulk/build script - may be used to build a subset of the packages contained in - pkgsrc. By setting SPECIFIC_PKGS - in /etc/mk.conf, the variables

    +

    In addition to building a complete set of all packages in + pkgsrc, the pkgsrc/mk/bulk/build script + may be used to build a subset of the packages contained in + pkgsrc. By setting SPECIFIC_PKGS + in /etc/mk.conf, the variables

    • SITE_SPECIFIC_PKGS

    • HOST_SPECIFIC_PKGS

    • GROUP_SPECIFIC_PKGS

    • USER_SPECIFIC_PKGS

    -

    will define the set of packages which should be built. - The bulk build code will also include any packages which are - needed as dependencies for the explicitly listed packages. -

    -

    One use of this is to do a bulk build with - SPECIFIC_PKGS in a chroot sandbox - periodically to have a complete set of the binary packages - needed for your site available without the overhead of - building extra packages that are not needed.

    +

    will define the set of packages which should be built. + The bulk build code will also include any packages which are + needed as dependencies for the explicitly listed packages.

    +

    One use of this is to do a bulk build with + SPECIFIC_PKGS in a chroot sandbox + periodically to have a complete set of the binary packages + needed for your site available without the overhead of + building extra packages that are not needed.

    6.3.8. Uploading results of a bulk build

    -

    - This section describes how pkgsrc developers can upload binary - pkgs built by bulk builds to ftp.NetBSD.org. -

    -

    - If you would like to automatically create checksum files for the - binary packages you intend to upload, remember to set - MKSUMS=yes in your - mk/bulk/build.conf. -

    -

    - If you would like to PGP sign the checksum files (highly - recommended!), remember to set - SIGN_AS=username@NetBSD.org in your - mk/bulk/build.conf. This will prompt you for - your GPG password to sign the files before uploading everything. -

    -

    - Then, make sure that you have RSYNC_DST - set properly in your mk/bulk/build.conf - file, i.e. adjust it to something like one of the following: -

    +

    This section describes how pkgsrc developers can upload binary + pkgs built by bulk builds to ftp.NetBSD.org.

    +

    If you would like to automatically create checksum files for the + binary packages you intend to upload, remember to set + MKSUMS=yes in your + mk/bulk/build.conf.

    +

    If you would like to PGP sign the checksum files (highly + recommended!), remember to set + SIGN_AS=username@NetBSD.org in your + mk/bulk/build.conf. This will prompt you for + your GPG password to sign the files before uploading everything.

    +

    Then, make sure that you have RSYNC_DST + set properly in your mk/bulk/build.conf + file, i.e. adjust it to something like one of the following:

    RSYNC_DST=ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload

    Please use appropriate values for "pkgsrc-200xQy", - "NetBSD-a.b.c" and "arch" here. If your login on ftp.NetBSD.org - is different from your local login, write your login directly - into the variable, e.g. my local account is "feyrer", but for my - login "hubertf", I use:

    -
    RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
    -

    - A separate upload directory is used - here to allow "closing" the directory during upload. To do - so, run the following command on ftp.NetBSD.org next: -

    + "NetBSD-a.b.c" and "arch" here. If your login on ftp.NetBSD.org + is different from your local login, write your login directly + into the variable, e.g. my local account is "feyrer", but for my + login "hubertf", I use:

    +
    RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
    +

    A separate upload directory is used + here to allow "closing" the directory during upload. To do + so, run the following command on ftp.NetBSD.org next:

    nbftp% mkdir -p -m 750 /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
    -

    - Please note that /pub/NetBSD/packages is - only appropriate for packages for the NetBSD operating - system. Binary packages for other operating systems should go - into /pub/pkgsrc. -

    -

    - Before uploading the binary pkgs, ssh authentication needs to - be set up. This example shows how to set up temporary keys - for the root account inside the sandbox - (assuming that no keys should be present there usually): -

    -
    # chroot /usr/sandbox
+
    Please note that /pub/NetBSD/packages is
+      only appropriate for packages for the NetBSD operating
+      system. Binary packages for other operating systems should go
+      into /pub/pkgsrc.
    
+
    Before uploading the binary pkgs, ssh authentication needs
+      to be set up. This example shows how to set up temporary keys
+      for the root account inside the sandbox
+      (assuming that no keys should be present there usually):
    
+
    +# chroot /usr/sandbox
 chroot-# rm $HOME/.ssh/id-dsa*
 chroot-# ssh-keygen -t dsa
-chroot-# cat $HOME/.ssh/id-dsa.pub 
    
-
    
-        Now take the output of id-dsa.pub and
-        append it to your ~/.ssh/authorized_keys
-        file on ftp.NetBSD.org. You can remove the key after the
-        upload is done!
-      
    
-
    
-        Next, test if your ssh connection really works:
-      
    
+chroot-# cat $HOME/.ssh/id-dsa.pub
+
    +

    Now take the output of id-dsa.pub and + append it to your ~/.ssh/authorized_keys + file on ftp.NetBSD.org. You can remove the key after the + upload is done!

    +

    Next, test if your ssh connection really works:

    chroot-# ssh ftp.NetBSD.org date
    -

    - Use "-l yourNetBSDlogin" here as appropriate! -

    -

    - Now after all this works, you can exit the sandbox and start - the upload: -

    -
    chroot-# exit
+
    Use "-l yourNetBSDlogin" here as appropriate!
    
+
    Now after all this works, you can exit the sandbox and start
+      the upload:
    
+
    +chroot-# exit
 # cd /usr/sandbox/usr/pkgsrc
-# sh mk/bulk/do-sandbox-upload 
    
-
    
-        The upload process may take quite some time. Use ls(1) or
-        du(1) on the FTP server to monitor progress of the
-        upload. The upload script will take care of not uploading
-        restricted packages and putting vulnerable packages into the
-        vulnerable subdirectory.
-      
    
-
    
-        After the upload has ended, first thing is to revoke ssh access:
-      
    
+# sh mk/bulk/do-sandbox-upload
+
    +

    The upload process may take quite some time. Use ls(1) or + du(1) on the FTP server to monitor progress of the + upload. The upload script will take care of not uploading + restricted packages and putting vulnerable packages into the + vulnerable subdirectory.

    +

    After the upload has ended, first thing is to revoke ssh access:

    nbftp% vi ~/.ssh/authorized_keys
-Gdd:x!
    -

    - Use whatever is needed to remove the key you've entered - before! Last, move the uploaded packages out of the - upload directory to have them accessible - to everyone: -

    -
    nbftp% cd /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch
+      Gdd:x!
    +

    Use whatever is needed to remove the key you've entered + before! Last, move the uploaded packages out of the + upload directory to have them accessible + to everyone:

    +
    +nbftp% cd /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch
 nbftp% mv upload/* .
 nbftp% rmdir upload
-nbftp% chmod 755 .
    +nbftp% chmod 755 . +

    6.4. Creating a multiple CD-ROM packages collection

    -

    - After your pkgsrc bulk-build has completed, you may wish to - create a CD-ROM set of the resulting binary packages to assist - in installing packages on other machines. The - pkgtools/cdpack package provides - a simple tool for creating the ISO 9660 images. - cdpack arranges the packages on the CD-ROMs in a - way that keeps all the dependencies for a given package on the same - CD as that package. -

    +

    After your pkgsrc bulk-build has completed, you may wish to + create a CD-ROM set of the resulting binary packages to assist + in installing packages on other machines. The + pkgtools/cdpack package provides + a simple tool for creating the ISO 9660 images. + cdpack arranges the packages on the CD-ROMs in a + way that keeps all the dependencies for a given package on the same + CD as that package.

    6.4.1. Example of cdpack

    -

    - Complete documentation for cdpack is found in the cdpack(1) - man page. The following short example assumes that the binary - packages are left in - /usr/pkgsrc/packages/All and that - sufficient disk space exists in /u2 to - hold the ISO 9660 images.

    -
    # mkdir /u2/images
+
    Complete documentation for cdpack is found in the cdpack(1)
+      man page. The following short example assumes that the binary
+      packages are left in
+      /usr/pkgsrc/packages/All and that
+      sufficient disk space exists in /u2 to
+      hold the ISO 9660 images.
    
+
    +# mkdir /u2/images
 # pkg_add /usr/pkgsrc/packages/All/cdpack
-# cdpack /usr/pkgsrc/packages/All /u2/images
    
-
    
-        If you wish to include a common set of files
-	(COPYRIGHT, README,
-	etc.) on each CD in the collection, then you need to create a
-	directory which contains these files. e.g.
-      
    
-
    # mkdir /tmp/common
+# cdpack /usr/pkgsrc/packages/All /u2/images
+      
    
+
    If you wish to include a common set of files
+      (COPYRIGHT, README,
+      etc.) on each CD in the collection, then you need to create a
+      directory which contains these files. e.g.
    
+
    +# mkdir /tmp/common
 # echo "This is a README" > /tmp/common/README
 # echo "Another file" > /tmp/common/COPYING
 # mkdir /tmp/common/bin
 # echo "#!/bin/sh" > /tmp/common/bin/myscript
 # echo "echo Hello world" >> /tmp/common/bin/myscript
-# chmod 755 /tmp/common/bin/myscript
    
+# chmod 755 /tmp/common/bin/myscript
+

    Now create the images:

    # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images

    Each image will contain README, - COPYING, and bin/myscript - in their root directories.

    + COPYING, and bin/myscript + in their root directories.

    @@ -3108,8 +3067,7 @@ with each package.

  • pkgtools/libnbcompat: Compatibility library for pkgsrc tools.

  • pkgtools/mtree: Installed on - non-BSD systems due to lack of native mtree. -

    • + non-BSD systems due to lack of native mtree.

  • pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or for use on operating @@ -3237,8 +3195,7 @@ you will have to add the following line into

    Note

    The DragonFly operating system defaults to using -this X.org X11 implementation from pkgsrc. -

    +this X.org X11 implementation from pkgsrc.

    • @@ -3325,7 +3282,7 @@ environment or in /etc/mk.conf.

    7.12. What does “Could not find bsd.own.mk” mean?

    -

    You didn't install the compiler set, comp.tgz, +

    You didn't install the compiler set, comp.tgz, when you installed your NetBSD machine. Please get and install it, by extracting it in /:

    # cd /
@@ -3402,10 +3359,9 @@ package is strongly recommended!  After
 “audit-packages” is installed, please read
 the package's message, which you can get by running pkg_info -D
 audit-packages.
    
-
    If this package is installed, pkgsrc builds will use it to perform
-a security check before building any package.  See
-Section 5.2, “Variables affecting the build process” for ways to control this check.
-
    
+
    If this package is installed, pkgsrc builds will use it to
+perform a security check before building any package.  See Section 5.2, “Variables affecting the build process” for ways to control this
+check.

    @@ -3607,34 +3563,44 @@ a security check before building any package. See
    17.3.2. Using libtool on GNU packages that already support libtool
    17.3.3. GNU Autoconf/Automake
    -
    17.4. Fixing problems in the build phase
    +
    17.4. Programming languages
    -
    17.4.1. Compiling C and C++ code conditionally
    -
    17.4.2. How to handle compiler bugs
    -
    17.4.3. Undefined reference to “...”
    +
    17.4.1. C, C++, and Fortran
    +
    17.4.2. Java
    +
    17.4.3. Packages containing perl scripts
    +
    17.4.4. Other programming languages
    -
    17.5. Fixing problems in the install phase
    +
    17.5. Fixing problems in the build phase
    -
    17.5.1. Creating needed directories
    -
    17.5.2. Where to install documentation
    -
    17.5.3. Installing score files
    -
    17.5.4. Packages containing perl scripts
    -
    17.5.5. Packages with hardcoded paths to other interpreters
    -
    17.5.6. Packages installing perl modules
    -
    17.5.7. Packages installing info files
    -
    17.5.8. Packages installing man pages
    -
    17.5.9. Packages installing GConf2 data files
    -
    17.5.10. Packages installing scrollkeeper data files
    -
    17.5.11. Packages installing X11 fonts
    -
    17.5.12. Packages installing GTK2 modules
    -
    17.5.13. Packages installing SGML or XML data
    -
    17.5.14. Packages installing extensions to the MIME database
    -
    17.5.15. Packages using intltool
    -
    17.5.16. Packages installing startup scripts
    -
    17.5.17. Packages installing TeX modules
    -
    17.5.18. Packages installing hicolor theme icons
    -
    17.5.19. Packages installing desktop files
    +
    17.5.1. Compiling C and C++ code conditionally
    +
    17.5.2. How to handle compiler bugs
    +
    17.5.3. Undefined reference to “...”
    +
    17.5.4. Running out of memory
    +
    17.6. Fixing problems in the install phase
    +
    +
    17.6.1. Creating needed directories
    +
    17.6.2. Where to install documentation
    +
    17.6.3. Installing score files
    +
    17.6.4. Packages with hardcoded paths to other interpreters
    +
    17.6.5. Packages installing perl modules
    +
    17.6.6. Packages installing info files
    +
    17.6.7. Packages installing man pages
    +
    17.6.8. Packages installing GConf2 data files
    +
    17.6.9. Packages installing scrollkeeper data files
    +
    17.6.10. Packages installing X11 fonts
    +
    17.6.11. Packages installing GTK2 modules
    +
    17.6.12. Packages installing SGML or XML data
    +
    17.6.13. Packages installing extensions to the MIME database
    +
    17.6.14. Packages using intltool
    +
    17.6.15. Packages installing startup scripts
    +
    17.6.16. Packages installing TeX modules
    +
    17.6.17. Packages supporting running binaries in + emulation
    +
    17.6.18. Packages installing hicolor theme icons
    +
    17.6.19. Packages installing desktop files
    +
    +
    17.7. Marking packages as having problems
    18. Debugging
    19. Submitting and Committing
    @@ -3765,212 +3731,237 @@ a security check before building any package. See
    9.7. files/*

    -

    Whenever you're preparing a package, there are a number of - files involved which are described in the following - sections.

    +

    Whenever you're preparing a package, there are a number of +files involved which are described in the following +sections.

    9.1. Makefile

    Building, installation and creation of a binary package are all - controlled by the package's Makefile. - The Makefile describes various things about - a package, for example from where to get it, how to configure, - build, and install it. -

    + controlled by the package's Makefile. + The Makefile describes various things about + a package, for example from where to get it, how to configure, + build, and install it.

    A package Makefile contains several - sections that describe the package.

    + sections that describe the package.

    In the first section there are the following variables, which - should appear exactly in the order given here. The ordering and - grouping of variables is mostly historical and has no further - meaning.

    + should appear exactly in the order given here. The order and + grouping of the variables is mostly historical and has no further + meaning.

    • DISTNAME is the basename of the - distribution file to be downloaded from the package's - website.

      • + distribution file to be downloaded from the package's + website.

    • PKGNAME is the name of the - package, as used by pkgsrc. You only need to provide it if it - differs from DISTNAME. Usually it is the directory name together - with the version number. It must match the regular expression - ^[A-Za-z0-9][A-Za-z0-9-_.+]*$, that is, it - starts with a letter or digit, and contains only letters, digits, - dashes, underscores, dots and plus signs.

      • + package, as used by pkgsrc. You only need to provide it if + DISTNAME (which is the default) is not a good + name for the package in pkgsrc. Usually it is the pkgsrc + directory name together with the version number. It must match the + regular expression + ^[A-Za-z0-9][A-Za-z0-9-_.+]*$, that is, it + starts with a letter or digit, and contains only letters, digits, + dashes, underscores, dots and plus signs.

      +

    • SVR4_PKGNAME is the name of + the package file to create if the PKGNAME + isn't unique on a SVR4 system. The default is + PKGNAME, which may be shortened when you use + pkgtools/gensolpkg. Only add + SVR4_PKGNAME if PKGNAME + does not produce an unique package name on a SVR4 system. + The length of SVR4_PKGNAME is limited to 5 + characters.

    • CATEGORIES is a list of categories - which the package fits in. You can choose any of the top-level - directories of pkgsrc for it.

      + which the package fits in. You can choose any of the top-level + directories of pkgsrc for it.

      Currently the following values are available for - CATEGORIES. If more than - one is used, they need to be separated by spaces:

      + CATEGORIES. If more than + one is used, they need to be separated by spaces:

      -    archivers     cross         geography     meta-pkgs     security
-    audio         databases     graphics      misc          shells
-    benchmarks    devel         ham           multimedia    sysutils
-    biology       editors       inputmethod   net           textproc
-    cad           emulators     lang          news          time
-    chat          finance       mail          parallel      wm
-    comms         fonts         math          pkgtools      www
-    converters    games         mbone         print         x11
-
      + archivers cross geography meta-pkgs security + audio databases graphics misc shells + benchmarks devel ham multimedia sysutils + biology editors inputmethod net textproc + cad emulators lang news time + chat finance mail parallel wm + comms fonts math pkgtools www + converters games mbone print x11 +

    • MASTER_SITES, - DYNAMIC_MASTER_SITES, - DIST_SUBDIR, EXTRACT_SUFX - and DISTFILES are discussed in detail in - Section 15.5, “The fetch phase”.

      • + DYNAMIC_MASTER_SITES, + DIST_SUBDIR, EXTRACT_SUFX + and DISTFILES are discussed in detail in + Section 15.5, “The fetch phase”.

    The second section contains information about separately - downloaded patches, if any. -

    + downloaded patches, if any. +

    • PATCHFILES: - Name(s) of additional files that contain distribution patches. - There is no default. pkgsrc will look for them at - PATCH_SITES. - They will automatically be uncompressed before patching if - the names end with .gz or - .Z.

      • + Name(s) of additional files that contain distribution patches. + There is no default. pkgsrc will look for them at + PATCH_SITES. + They will automatically be uncompressed before patching if + the names end with .gz or + .Z.

    • PATCH_SITES: - Primary location(s) for distribution patch files (see - PATCHFILES below) if not found locally.

      • + Primary location(s) for distribution patch files (see + PATCHFILES below) if not found locally.

    -

    -

    The third section contains the following variables. -

    +

    • MAINTAINER is the email address - of the person who feels responsible for this package, and who is - most likely to look at problems or questions regarding this - package which have been reported with send-pr(1). Other - developers should contact the MAINTAINER before - making major changes to the package. When packaging a new program, - set MAINTAINER to yourself. If you really can't - maintain the package for future updates, set it to - .

      • + of the person who feels responsible for this package, and who is + most likely to look at problems or questions regarding this + package which have been reported with send-pr(1). Other + developers should contact the MAINTAINER before + making major changes to the package. When packaging a new program, + set MAINTAINER to yourself. If you really can't + maintain the package for future updates, set it to + .

    • HOMEPAGE is a URL where users can - find more information about the package.

      • + find more information about the package.

    • COMMENT is a one-line - description of the package (should not include the package - name).

      • + description of the package (should not include the package + name).

    -

    -

    Other variables that affect the build: -

    +

    • WRKSRC: The directory where the - interesting distribution files of the package are found. The - default is ${WRKDIR}/${DISTNAME}, which - works for most packages.

      + interesting distribution files of the package are found. The + default is ${WRKDIR}/${DISTNAME}, which + works for most packages.

      If a package doesn't create a subdirectory for itself - (most GNU software does, for instance), but extracts itself in - the current directory, you should set WRKSRC= - ${WRKDIR}.

      -

      If a package doesn't create a subdirectory with the name - of DISTNAME but some different name, set - WRKSRC to point to the proper name in - ${WRKDIR}, for example WRKSRC= - ${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for other examples.

      + (most GNU software does, for instance), but extracts itself in + the current directory, you should set + WRKSRC=${WRKDIR}.

      +

      If a package doesn't create a subdirectory with the + name of DISTNAME but some different name, + set WRKSRC to point to the proper name in + ${WRKDIR}, for example + WRKSRC=${WRKDIR}/${DISTNAME}/unix. See + lang/tcl and x11/tk for other examples.

      The name of the working directory created by pkgsrc is - taken from the WRKDIR_BASENAME variable. By - default, its value is work. If you want - to use the same pkgsrc tree for building different kinds of - binary packages, you can change the variable according to your - needs. Two other variables handle common cases of setting - WRKDIR_BASENAME individually. If - OBJHOSTNAME is defined in - /etc/mk.conf, the first component of the - host's name is attached to the directory name. If - OBJMACHINE is defined, the platform name is - attached, which might look like work.i386 - or work.sparc.

      + taken from the WRKDIR_BASENAME + variable. By default, its value is + work. If you want to use the same + pkgsrc tree for building different kinds of binary packages, + you can change the variable according to your needs. Two + other variables handle common cases of setting + WRKDIR_BASENAME individually. If + OBJHOSTNAME is defined in + /etc/mk.conf, the first component of + the host's name is attached to the directory name. If + OBJMACHINE is defined, the platform name + is attached, which might look like + work.i386 or + work.sparc.

    -

    -

    Please pay attention to the following gotchas:

    9.2. distinfo

    The distinfo file contains the message - digest, or checksum, of each distfile needed for the package. This - ensures that the distfiles retrieved from the Internet have not been - corrupted during transfer or altered by a malign force to introduce - a security hole. Due to recent rumor about weaknesses of digest - algorithms, all distfiles are protected using both SHA1 and RMD160 - message digests, as well as the file size.

    + digest, or checksum, of each distfile needed for the package. This + ensures that the distfiles retrieved from the Internet have not been + corrupted during transfer or altered by a malign force to introduce + a security hole. Due to recent rumor about weaknesses of digest + algorithms, all distfiles are protected using both SHA1 and RMD160 + message digests, as well as the file size.

    The distinfo file also contains the - checksums for all the patches found in the - patches directory (see Section 9.3, “patches/*”).

    + checksums for all the patches found in the + patches directory (see Section 9.3, “patches/*”).

    To regenerate the distinfo file, use the - make makedistinfo or make mdi - command.

    + make makedistinfo or make mdi + command.

    Some packages have different sets of distfiles depending on - the platform, for example www/navigator). These are kept in the same - distinfo file and care should be taken when - upgrading such a package to ensure distfile information is not - lost.

    + the platform, for example www/navigator). These are kept in the same + distinfo file and care should be taken when + upgrading such a package to ensure distfile information is not + lost.

    9.3. patches/*

    This directory contains files that are used by the - patch(1) command to - modify the sources as distributed in the distribution file into a form - that will compile and run perfectly on NetBSD. The files are applied - successively in alphabetic order (as returned by a shell - “patches/patch-*” glob expansion), so - patch-aa is applied before - patch-ab, etc.

    + patch(1) command to + modify the sources as distributed in the distribution file into a form + that will compile and run perfectly on NetBSD. The files are applied + successively in alphabetic order (as returned by a shell + “patches/patch-*” glob expansion), so + patch-aa is applied before + patch-ab, etc.

    The patch-* files should be in - diff -bu format, and apply without a fuzz to avoid - problems. (To force patches to apply - with fuzz you can set PATCH_FUZZ_FACTOR=-F2). - Furthermore, do not put changes for more than one file into a single - patch file, as this will make future modifications more difficult.

    + diff -bu format, and apply without a fuzz to avoid + problems. (To force patches to apply + with fuzz you can set PATCH_FUZZ_FACTOR=-F2). + Furthermore, do not put changes for more than one file into a single + patch file, as this will make future modifications more difficult.

    Similar, a file should be patched at most once, not several times by - several different patches. If a file needs several patches, they should - be combined into one file.

    + several different patches. If a file needs several patches, they should + be combined into one file.

    One important thing to mention is to pay attention that no RCS IDs - get stored in the patch files, as these will cause problems when - later checked into the NetBSD CVS tree. Use the - pkgdiff from the - pkgtools/pkgdiff package to avoid - these problems.

    -

    For even more automation, we recommend using mkpatches from the same - package to make a whole set of patches. You just have to backup files - before you edit them to filename.orig, e.g. with - cp -p filename filename.orig or, easier, by using - pkgvi again from the same package. If you upgrade a package - this way, you can easily compare the new set of patches with the - previously existing one with patchdiff.

    -

    When you have finished a package, remember to generate the checksums - for the patch files by using the make makepatchsum - command, see Section 9.2, “distinfo”.

    + get stored in the patch files, as these will cause problems when + later checked into the NetBSD CVS tree. Use the + pkgdiff from the + pkgtools/pkgdiff package to avoid + these problems.

    +

    For even more automation, we recommend using + mkpatches from the same package to make a + whole set of patches. You just have to backup files before you + edit them to filename.orig, e.g. with + cp -p filename filename.orig or, easier, by + using pkgvi again from the same package. If + you upgrade a package this way, you can easily compare the new + set of patches with the previously existing one with + patchdiff. Copy the patches you want to use + or update from the work/.newpatches + directory to patches/.

    +

    When you have finished a package, remember to generate + the checksums for the patch files by using the make + makepatchsum command, see Section 9.2, “distinfo”.

    +

    When adding a patch that corrects a problem in the + distfile (rather than e.g. enforcing pkgsrc's view of where + man pages should go), send the patch as a bug report to the + maintainer. This benefits non-pkgsrc users of the package, + and usually makes it possible to remove the patch in future + version.

    +

    If you want to share patches between multiple packages + in pkgsrc, e.g. because they use the same distfiles, set + PATCHDIR to the path where the patch files + can be found, e.g.:

    +
    +    PATCHDIR= ${.CURDIR}/../xemacs/patches
+

    Patch files that are distributed by the author or other - maintainers can be listed in - $PATCHFILES.

    -

    If it is desired to store any patches that should not be committed into - pkgsrc, they can be kept outside the pkgsrc tree in the - $LOCALPATCHES - directory. The directory tree there is expected to have the same - “category/package” structure as pkgsrc, and patches are - expected to be stored inside these dirs (also known as - $LOCALPATCHES/$PKGPATH). For - example, if you want to keep a private patch for - pkgsrc/graphics/png, keep - it in $LOCALPATCHES/graphics/png/mypatch. All - files in the named directory are expected to be patch files, and - they are applied after pkgsrc patches are applied.

    + maintainers can be listed in + PATCHFILES.

    +

    If it is desired to store any patches that should not be + committed into pkgsrc, they can be kept outside the pkgsrc + tree in the $LOCALPATCHES directory. The + directory tree there is expected to have the same + “category/package” structure as pkgsrc, and + patches are expected to be stored inside these dirs (also + known as $LOCALPATCHES/$PKGPATH). For + example, if you want to keep a private patch for + pkgsrc/graphics/png, keep it in + $LOCALPATCHES/graphics/png/mypatch. All + files in the named directory are expected to be patch files, + and they are applied after pkgsrc patches are + applied.

    9.3.1. Patching guidelines

    @@ -3983,7 +3974,7 @@ a security check before building any package. See specific features you need. For example, instead of assuming that kqueue is available under NetBSD and using the __NetBSD__ macro to conditionalize - kqueue support, add a check that detects kqueue itself — + kqueue support, add a check that detects kqueue itself — yes, this generally involves patching the configure script. There is absolutely nothing that prevents some OSes from adopting interfaces from other OSes @@ -3991,7 +3982,7 @@ a security check before building any package. See cannot take into account.

    Of course, checking for features generally involves more work on the developer's side, but the resulting changes are - clearner and there are chances they will work on many other + cleaner and there are chances they will work on many other platforms. Not to mention that there are higher chances of being later integrated into the mainstream sources. Remember: It doesn't work unless it is right!

    @@ -4014,9 +4005,9 @@ a security check before building any package. See configure script 
    case ${target_os} in
-      netbsd*) have_kvm=yes ;;
-      *)       have_kvm=no  ;;
-  esac
    + netbsd*) have_kvm=yes ;; + *) have_kvm=no ;; + esac 
    AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)
    @@ -4026,40 +4017,40 @@ a security check before building any package. See C source file 
    #if defined(__NetBSD__)
-  #  include <sys/event.h>
-  #endif
    + # include <sys/event.h> + #endif 
    #if defined(HAVE_SYS_EVENT_H)
-  #  include <sys/event.h>
-  #endif
    + # include <sys/event.h> + #endif C source file 
    int
-  monitor_file(...)
-  {
-  #if defined(__NetBSD__)
-      int fd = kqueue();
-      ...
-  #else
-      ...
-  #endif
-  }
    + monitor_file(...) + { + #if defined(__NetBSD__) + int fd = kqueue(); + ... + #else + ... + #endif + } 
    int
-  monitor_file(...)
-  {
-  #if defined(HAVE_KQUEUE)
-      int fd = kqueue();
-      ...
-  #else
-      ...
-  #endif
-  }
    + monitor_file(...) + { + #if defined(HAVE_KQUEUE) + int fd = kqueue(); + ... + #else + ... + #endif + } @@ -4100,16 +4091,16 @@ a security check before building any package. See
    DESCR

    A multi-line description of the piece of software. This should include - any credits where they are due. Please bear in mind that others do not - share your sense of humour (or spelling idiosyncrasies), and that others - will read everything that you write here.

    + any credits where they are due. Please bear in mind that others do not + share your sense of humour (or spelling idiosyncrasies), and that others + will read everything that you write here.

    PLIST
    -

    - This file governs the files that are installed on your system: all the - binaries, manual pages, etc. There are other directives which may be - entered in this file, to control the creation and deletion of - directories, and the location of inserted files. - See Chapter 11, PLIST issues for more information.

    +

    This file governs the files that are installed on your + system: all the binaries, manual pages, etc. There are other + directives which may be entered in this file, to control the + creation and deletion of directories, and the location of + inserted files. See Chapter 11, PLIST issues for more + information.

    @@ -4121,33 +4112,44 @@ a security check before building any package. See
    INSTALL

    This shell script is invoked twice by pkg_add(1). - First time after package - extraction and before files are moved in place, the second time after - the files to install are moved in place. This can be used to do any - custom procedures not possible with @exec commands in - PLIST. See - pkg_add(1) and pkg_create(1) for more information.

    + First time after package extraction and before files are + moved in place, the second time after the files to install + are moved in place. This can be used to do any custom + procedures not possible with @exec commands in + PLIST. See pkg_add(1) and + pkg_create(1) for more information. See also Section 13.1, “Files and directories outside the installation prefix”.

    DEINSTALL

    This script is executed before and after any files are removed. It is - this script's responsibility to clean up any additional messy details - around the package's installation, since all pkg_delete knows is how to - delete the files created in the original distribution. - See pkg_delete(1) - and pkg_create(1) for more information.

    + this script's responsibility to clean up any additional messy details + around the package's installation, since all pkg_delete knows is how to + delete the files created in the original distribution. + See pkg_delete(1) + and pkg_create(1) for more information.

    MESSAGE

    This file is displayed after installation of the package. - Useful for things like legal notices on almost-free - software and hints for updating config files after - installing modules for apache, PHP etc. - Please note that you can modify variables in it easily by using - MESSAGE_SUBST in the package's - Makefile:

    + Useful for things like legal notices on almost-free + software and hints for updating config files after + installing modules for apache, PHP etc. + Please note that you can modify variables in it easily by using + MESSAGE_SUBST in the package's + Makefile:

    -    MESSAGE_SUBST+=  SOMEVAR="somevalue"
-
    + MESSAGE_SUBST+= SOMEVAR="somevalue" +

    replaces "${SOMEVAR}" with “somevalue” in - MESSAGE.

    + MESSAGE. By default, substitution is + performed for PKGNAME, + PKGBASE, PREFIX, + LOCALBASE, X11PREFIX, + X11BASE, + PKG_SYSCONFDIR, + ROOT_GROUP, and + ROOT_GROUP.

    +

    You can display a different or additional files by + setting the MESSAGE_SRC variable. Its + default is MESSAGE, if the file + exists.

    ALTERNATIVES

    FIXME: There is no documentation on the @@ -4202,25 +4204,32 @@ a security check before building any package. See

    9.6. work*

    When you type make, the distribution files are - unpacked into the directory denoted by - WRKDIR. It can be removed by running - make clean. Besides the sources, this - directory is also used to keep various timestamp files. - The directory gets removed completely on clean. - The default is ${.CURDIR}/work - or ${.CURDIR}/work.${MACHINE_ARCH} - if OBJMACHINE is set.

    + unpacked into the directory denoted by + WRKDIR. It can be removed by running + make clean. Besides the sources, this + directory is also used to keep various timestamp files. + The directory gets removed completely on clean. + The default is ${.CURDIR}/work + or ${.CURDIR}/work.${MACHINE_ARCH} + if OBJMACHINE is set.

    9.7. files/*

    If you have any files that you wish to be placed in the package prior - to configuration or building, you could place these files here and use - a “${CP}” command in the - “pre-configure” target to achieve - this. Alternatively, you could simply diff the file against - /dev/null and use the patch mechanism to manage - the creation of this file.

    + to configuration or building, you could place these files here and use + a ${CP} command in the + “pre-configure” target to achieve + this. Alternatively, you could simply diff the file against + /dev/null and use the patch mechanism to manage + the creation of this file.

    +

    If you want to share files in this way with other + packages, set the FILESDIR variable to point + to the other package's files directory, + e.g.:

    +
    +      FILESDIR=${.CURDIR}/../xemacs/files
+
    @@ -4288,7 +4297,7 @@ a security check before building any package. See operate on the words, others operate on the string as a whole. When a string is split into words, it is split as you would expect it from sh(1).

    -

    No rule without exception—the .for +

    No rule without exception—the .for loop does not follow the shell quoting rules but splits at sequences of whitespace.

    There are several types of variables that should be handled @@ -4531,97 +4540,94 @@ a security check before building any package. See

    11.8. Sharing directories between packages
    -

    The PLIST file contains a package's - “packing list”, i.e. a list of files that belong to - the package (relative to the ${PREFIX} - directory it's been installed in) plus some additional statements - - see the pkg_create(1) man page for a full list. - This chapter addresses some issues that need attention when - dealing with the PLIST file (or files, see - below!).

    +

    The PLIST file contains a package's + “packing list”, i.e. a list of files that belong to + the package (relative to the ${PREFIX} + directory it's been installed in) plus some additional statements + - see the pkg_create(1) man page for a full list. + This chapter addresses some issues that need attention when + dealing with the PLIST file (or files, see + below!).

    11.1. RCS ID

    -

    - Be sure to add a RCS ID line as the first thing in any - PLIST file you write: -

    +

    Be sure to add a RCS ID line as the first thing in any + PLIST file you write:

    -    @comment $NetBSD$
-
    + @comment $NetBSD$ +

    11.2. Semi-automatic PLIST generation

    You can use the make print-PLIST command - to output a PLIST that matches any new files since the package - was extracted. See Section 15.16, “Other helpful targets” for - more information on this target.

    + to output a PLIST that matches any new files since the package + was extracted. See Section 15.16, “Other helpful targets” for + more information on this target.

    11.3. Tweaking output of make print-PLIST

    -

    If you have used any of the *-dirs packages, as explained in - Section 11.8, “Sharing directories between packages”, you may have noticed that - make print-PLIST outputs a set of - @comments instead of real - @dirrm lines. You can also do this for - specific directories and files, so that the results of that - command are very close to reality. This helps a - lot during the update of packages.

    -

    The PRINT_PLIST_AWK variable takes a set - of AWK patterns and actions that are used to filter the output of - print-PLIST. You can append any chunk of AWK - scripting you like to it, but be careful with quoting.

    -

    For example, to get all files inside the - libdata/foo directory removed from the - resulting PLIST:

    +

    If you have used any of the *-dirs packages, as explained in + Section 11.8, “Sharing directories between packages”, you may have noticed that + make print-PLIST outputs a set of + @comments instead of real + @dirrm lines. You can also do this for + specific directories and files, so that the results of that + command are very close to reality. This helps a + lot during the update of packages.

    +

    The PRINT_PLIST_AWK variable takes a set + of AWK patterns and actions that are used to filter the output of + print-PLIST. You can append any chunk of AWK + scripting you like to it, but be careful with quoting.

    +

    For example, to get all files inside the + libdata/foo directory removed from the + resulting PLIST:

    -    PRINT_PLIST_AWK+=       /^libdata\/foo/ { next; }
-
    -

    And to get all the @dirrm lines referring - to a specific (shared) directory converted to - @comments:

    + PRINT_PLIST_AWK+= /^libdata\/foo/ { next; } + +

    And to get all the @dirrm lines referring + to a specific (shared) directory converted to + @comments:

    -    PRINT_PLIST_AWK+=       /^@dirrm share\/specific/ { print "@comment " $$0; next; }
-
    + PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; } +

    11.4. Variable substitution in PLIST

    -

    - A number of variables are substituted automatically in PLISTs - when a package is installed on a system. This includes the - following variables:

    +

    A number of variables are substituted automatically in + PLISTs when a package is installed on a system. This includes the + following variables:

    ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}

    Some packages like emacs and perl embed information - about which architecture they were built on into the - pathnames where they install their files. To handle this - case, PLIST will be preprocessed before actually used, and - the symbol - “${MACHINE_ARCH}” will be - replaced by what uname -p gives. The - same is done if the string - ${MACHINE_GNU_ARCH} is embedded in - PLIST somewhere - use this on packages that have GNU - autoconf-created configure scripts.

    + about which architecture they were built on into the + pathnames where they install their files. To handle this + case, PLIST will be preprocessed before actually used, and + the symbol + “${MACHINE_ARCH}” will be + replaced by what uname -p gives. The + same is done if the string + ${MACHINE_GNU_ARCH} is embedded in + PLIST somewhere - use this on packages that have GNU + autoconf-created configure scripts.

    Legacy note

    There used to be a symbol - “$ARCH” that - was replaced by the output of uname - -m, but that's no longer supported and has - been removed.

    + “$ARCH” that + was replaced by the output of uname + -m, but that's no longer supported and has + been removed.

    ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}

    Some packages want to embed the OS name and version - into some paths. To do this, use these variables in the - PLIST: -

    + into some paths. To do this, use these variables in the + PLIST: +

    • ${OPSYS} - output of “uname -s”

    • ${LOWER_OPSYS} - lowercase common name (eg. “solaris”)

      • @@ -4629,46 +4635,48 @@ a security check before building any package. See
    -

    For a complete list of values which are replaced by - default, please look in bsd.pkg.mk (and - search for PLIST_SUBST).

    -

    If you want to change other variables not listed above, you - can add variables and their expansions to this variable in the - following way, similar to MESSAGE_SUBST (see Section 9.5, “Optional files”):

    +

    For a complete list of values which are replaced by + default, please look in bsd.pkg.mk (and + search for PLIST_SUBST).

    +

    If you want to change other variables not listed above, you + can add variables and their expansions to this variable in the + following way, similar to MESSAGE_SUBST (see Section 9.5, “Optional files”):

    -    PLIST_SUBST+=   SOMEVAR="somevalue"
-
    + PLIST_SUBST+= SOMEVAR="somevalue" +

    This replaces all occurrences of “${SOMEVAR}” - in the PLIST with “somevalue”.

    + in the PLIST with + “somevalue”.

    11.5. Man page compression

    Man pages should be installed in compressed form if - MANZ is set (in bsd.own.mk), - and uncompressed otherwise. To handle this in the - PLIST file, the suffix “.gz” is - appended/removed automatically for man pages according to - MANZ and MANCOMPRESSED being set - or not, see above for details. This modification of the - PLIST file is done on a copy of it, not - PLIST itself.

    + MANZ is set (in bsd.own.mk), + and uncompressed otherwise. To handle this in the + PLIST file, the suffix “.gz” is + appended/removed automatically for man pages according to + MANZ and MANCOMPRESSED being set + or not, see above for details. This modification of the + PLIST file is done on a copy of it, not + PLIST itself.

    11.6. Changing PLIST source with PLIST_SRC

    To use one or more files as source for the PLIST used - in generating the binary package, set the variable - PLIST_SRC to the names of that file(s). - The files are later concatenated using cat(1), and order of things is - important.

    + in generating the binary package, set the variable + PLIST_SRC to the names of that file(s). + The files are later concatenated using cat(1), and the order of things is + important. The default for PLIST_SRC is + ${PKGDIR}/PLIST.

    11.7. Platform-specific and differing PLISTs

    Some packages decide to install a different set of files based on - the operating system being used. These differences can be - automatically handled by using the following files:

    + the operating system being used. These differences can be + automatically handled by using the following files:

    • PLIST.common

    • PLIST.${OPSYS}

      • @@ -4680,58 +4688,56 @@ a security check before building any package. See

      11.8. Sharing directories between packages

      -

      A “shared directory” is a directory where - multiple (and unrelated) packages install files. These - directories are problematic because you have to add special tricks - in the PLIST to conditionally remove them, or have some - centralized package handle them.

      -

      Within pkgsrc, you'll find both approaches. If a directory - is shared by a few unrelated packages, it's often not worth to add - an extra package to remove it. Therefore, one simply does: -

      +

      A “shared directory” is a directory where + multiple (and unrelated) packages install files. These + directories are problematic because you have to add special tricks + in the PLIST to conditionally remove them, or have some + centralized package handle them.

      +

      Within pkgsrc, you'll find both approaches. If a directory + is shared by a few unrelated packages, it's often not worth to add + an extra package to remove it. Therefore, one simply does:

      -    @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE}
-
      -

      in the PLISTs of all affected packages, instead of the - regular "@dirrm" line.

      -

      However, if the directory is shared across many packages, two - different solutions are available:

      + @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE} + +

      in the PLISTs of all affected packages, instead of the + regular "@dirrm" line.

      +

      However, if the directory is shared across many packages, two + different solutions are available:

        -

      1. If the packages have a common dependency, the directory - can be removed in that. For example, see - textproc/scrollkeeper, which - removes the shared directory - share/omf.

        2. -

      2. If the packages using the directory are not related at - all (they have no common dependencies), a *-dirs package is - used.

        3. +

      3. If the packages have a common dependency, the directory + can be removed in that. For example, see + textproc/scrollkeeper, which + removes the shared directory + share/omf.

        4. +

      4. If the packages using the directory are not related at + all (they have no common dependencies), a *-dirs package is + used.

      -

      From now on, we'll discuss the second solution. To get an - idea of the *-dirs packages available, issue:

      +

      From now on, we'll discuss the second solution. To get an + idea of the *-dirs packages available, issue:

      -    % cd .../pkgsrc
-    % ls -d */*-dirs
-
      -

      Their use from other packages is very simple. The - USE_DIRS variable takes a list of package names - (without the “-dirs” part) together with the required - version number (always pick the latest one when writing new - packages).

      -

      For example, if a package installs files under - share/applications, it should have the - following line in it: -

      + % cd .../pkgsrc + % ls -d */*-dirs + +

      Their use from other packages is very simple. The + USE_DIRS variable takes a list of package names + (without the “-dirs” part) together with the required + version number (always pick the latest one when writing new + packages).

      +

      For example, if a package installs files under + share/applications, it should have the + following line in it:

      -    USE_DIRS+=      xdg-1.1
-
      -

      After regenerating the PLIST using make - print-PLIST, you should get the right (commented out) - lines.

      -

      Note that even if your package is using - $X11BASE, it must not depend on the - *-x11-dirs packages. Just specify the name without that part and - pkgsrc (in particular, mk/dirs.mk) will take - care of it.

      + USE_DIRS+= xdg-1.1 + +

      After regenerating the PLIST using make + print-PLIST, you should get the right (commented out) + lines.

      +

      Note that even if your package is using + $X11BASE, it must not depend on the + *-x11-dirs packages. Just specify the name without that part and + pkgsrc (in particular, mk/dirs.mk) will take + care of it.

    @@ -4754,239 +4760,231 @@ a security check before building any package. See

    Buildlink is a framework in pkgsrc that controls what headers and libraries - are seen by a package's configure and build processes. This is implemented - in a two step process:

    + are seen by a package's configure and build processes. This is implemented + in a two step process:

    1. Symlink headers and libraries for dependencies into - BUILDLINK_DIR, which by default is a subdirectory - of WRKDIR.

      2. + BUILDLINK_DIR, which by default is a subdirectory + of WRKDIR.

    2. Create wrapper scripts that are used in place of the normal compiler - tools that translate -I${LOCALBASE}/include and - -L${LOCALBASE}/lib into references to - BUILDLINK_DIR. The wrapper scripts also make - native compiler on some operating systems look like GCC, so that - packages that expect GCC won't require modifications to build with - those native compilers.

      3. + tools that translate -I${LOCALBASE}/include and + -L${LOCALBASE}/lib into references to + BUILDLINK_DIR. The wrapper scripts also make + native compiler on some operating systems look like GCC, so that + packages that expect GCC won't require modifications to build with + those native compilers.

    This normalizes the environment in which a package is built so that the - package may be built consistently despite what other software may be - installed. Please note that the normal system header and library paths, - e.g. /usr/include, - /usr/lib, etc., are always searched -- buildlink3 is - designed to insulate the package build from non-system-supplied - software.

    + package may be built consistently despite what other software may be + installed. Please note that the normal system header and library paths, + e.g. /usr/include, + /usr/lib, etc., are always searched -- buildlink3 is + designed to insulate the package build from non-system-supplied + software.

    12.1. Converting packages to use buildlink3

    The process of converting packages to use the buildlink3 - framework (“bl3ifying”) is fairly straightforward. - The things to keep in mind are:

    + framework (“bl3ifying”) is fairly straightforward. + The things to keep in mind are:

      -

    1. Ensure that the build always calls the wrapper scripts - instead of the actual toolchain. Some packages are tricky, - and the only way to know for sure is the check - ${WRKDIR}/.work.log to see if the - wrappers are being invoked.

      2. -

    2. Don't override PREFIX from within - the package Makefile, e.g. Java VMs, standalone shells, - etc., because the code to symlink files into - ${BUILDLINK_DIR} looks for files - relative to “pkg_info -qp pkgname”. -

      3. -

    3. Remember that only the - buildlink3.mk files that you list in a - package's Makefile are added as dependencies for that package. -

      4. +

    4. Ensure that the build always calls the wrapper scripts + instead of the actual toolchain. Some packages are tricky, + and the only way to know for sure is the check + ${WRKDIR}/.work.log to see if the + wrappers are being invoked.

      5. +

    5. Don't override PREFIX from within + the package Makefile, e.g. Java VMs, standalone shells, + etc., because the code to symlink files into + ${BUILDLINK_DIR} looks for files + relative to “pkg_info -qp pkgname”. +

      6. +

    6. Remember that only the + buildlink3.mk files that you list in a + package's Makefile are added as dependencies for that package. +

    -

    If a dependency on a particular package is required for its libraries and - headers, then we replace:

    +

    If a dependency on a particular package is required for its libraries and + headers, then we replace:

    -    DEPENDS+=   foo>=1.1.0:../../category/foo
-
    + DEPENDS+= foo>=1.1.0:../../category/foo +

    with

    -    .include "../../category/foo/buildlink3.mk"
-
    + .include "../../category/foo/buildlink3.mk" +

    The buildlink3.mk files usually define the required dependencies. If you need a newer version of the dependency when using buildlink3.mk - files, then you can define it in your Makefile; for example: -

    + files, then you can define it in your Makefile; for example:

    -    BUILDLINK_API_DEPENDS.foo+=   foo>=1.1.0
-    .include "../../category/foo/buildlink3.mk"
-
    + BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0 + .include "../../category/foo/buildlink3.mk" +

    There are several buildlink3.mk - files in pkgsrc/mk - that handle special package issues:

    + files in pkgsrc/mk + that handle special package issues:

    • bdb.buildlink3.mk chooses either - the native or a pkgsrc Berkeley DB implementation based on - the values of BDB_ACCEPTED and - BDB_DEFAULT.

      • + the native or a pkgsrc Berkeley DB implementation based on + the values of BDB_ACCEPTED and + BDB_DEFAULT.

    • curses.buildlink3.mk: If the system - comes with neither Curses nor NCurses, this will take care - to install the devel/ncurses package.

      • + comes with neither Curses nor NCurses, this will take care + to install the devel/ncurses package.

    • krb5.buildlink3.mk uses the value - of KRB5_ACCEPTED to choose between - adding a dependency on Heimdal or MIT-krb5 for packages that - require a Kerberos 5 implementation.

      • + of KRB5_ACCEPTED to choose between + adding a dependency on Heimdal or MIT-krb5 for packages that + require a Kerberos 5 implementation.

    • motif.buildlink3.mk checks - for a system-provided - Motif installation or adds a dependency on x11/lesstif or - x11/openmotif.

      • + for a system-provided + Motif installation or adds a dependency on x11/lesstif or + x11/openmotif.

    • oss.buildlink3.mk defines several - variables that may be used by packages that use the - Open Sound System (OSS) API.

      • + variables that may be used by packages that use the + Open Sound System (OSS) API.

    • pgsql.buildlink3.mk will accept - either Postgres 7.3 or 7.4, whichever is found installed. See - the file for more information.

      • + either Postgres 7.3 or 7.4, whichever is found installed. See + the file for more information.

    • pthread.buildlink3.mk uses the value of - PTHREAD_OPTS and checks for native pthreads or adds - a dependency on devel/pth as needed.

      • + PTHREAD_OPTS and checks for native pthreads or adds + a dependency on devel/pth as needed.

    • xaw.buildlink3.mk uses the value of - XAW_TYPE to choose a particular Athena widgets - library.

      • + XAW_TYPE to choose a particular Athena widgets + library.

    The comments in those buildlink3.mk - files provide a more complete - description of how to use them properly.

    + files provide a more complete + description of how to use them properly.

    12.2. Writing buildlink3.mk files

    -

    A package's buildlink3.mk file is - included by Makefiles to indicate the need to compile and link - against header files and libraries provided by the package. A - buildlink3.mk file should always provide - enough information to add the correct type of dependency - relationship and include any other - buildlink3.mk files that it needs to find - headers and libraries that it needs in turn.

    -

    To generate an initial buildlink3.mk - file for further editing, Rene Hexel's pkgtools/createbuildlink - package is highly recommended. For most packages, the following - command will generate a good starting point for - buildlink3.mk files:

    -
    % cd pkgsrc/category/pkgdir
-% createbuildlink >buildlink3.mk
    +

    A package's buildlink3.mk file is + included by Makefiles to indicate the need to compile and link + against header files and libraries provided by the package. A + buildlink3.mk file should always provide + enough information to add the correct type of dependency + relationship and include any other + buildlink3.mk files that it needs to find + headers and libraries that it needs in turn.

    +

    To generate an initial buildlink3.mk + file for further editing, Rene Hexel's pkgtools/createbuildlink + package is highly recommended. For most packages, the following + command will generate a good starting point for + buildlink3.mk files:

    +
    +% cd pkgsrc/category/pkgdir
+% createbuildlink >buildlink3.mk
+

    12.2.1. Anatomy of a buildlink3.mk file

    The following real-life example - buildlink3.mk is taken - from pkgsrc/graphics/tiff:

    + buildlink3.mk is taken + from pkgsrc/graphics/tiff:

    -    # $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $
+	# $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $
 
-    BUILDLINK_DEPTH:=       ${BUILDLINK_DEPTH}+
-    TIFF_BUILDLINK3_MK:=    ${TIFF_BUILDLINK3_MK}+
+	BUILDLINK_DEPTH:=       ${BUILDLINK_DEPTH}+
+	TIFF_BUILDLINK3_MK:=    ${TIFF_BUILDLINK3_MK}+
 
-    .if !empty(BUILDLINK_DEPTH:M+)
-    BUILDLINK_DEPENDS+=     tiff
-    .endif
+	.if !empty(BUILDLINK_DEPTH:M+)
+	BUILDLINK_DEPENDS+=     tiff
+	.endif
 
-    BUILDLINK_PACKAGES:=    ${BUILDLINK_PACKAGES:Ntiff}
-    BUILDLINK_PACKAGES+=    tiff
+	BUILDLINK_PACKAGES:=    ${BUILDLINK_PACKAGES:Ntiff}
+	BUILDLINK_PACKAGES+=    tiff
 
-    .if !empty(TIFF_BUILDLINK3_MK:M+)
-    BUILDLINK_API_DEPENDS.tiff+=        tiff>=3.6.1
-    BUILDLINK_PKGSRCDIR.tiff?=      ../../graphics/tiff
-    .endif  # TIFF_BUILDLINK3_MK
+	.if !empty(TIFF_BUILDLINK3_MK:M+)
+	BUILDLINK_API_DEPENDS.tiff+=        tiff>=3.6.1
+	BUILDLINK_PKGSRCDIR.tiff?=      ../../graphics/tiff
+	.endif  # TIFF_BUILDLINK3_MK
 
-    .include "../../devel/zlib/buildlink3.mk"
-    .include "../../graphics/jpeg/buildlink3.mk"
+	.include "../../devel/zlib/buildlink3.mk"
+	.include "../../graphics/jpeg/buildlink3.mk"
 
-    BUILDLINK_DEPTH:=       ${BUILDLINK_DEPTH:S/+$//}
-
    -

    The header and footer manipulate - BUILDLINK_DEPTH, which is common across all - buildlink3.mk files and is used to track - at what depth we are including - buildlink3.mk files.

    -

    The first section controls if the dependency on - pkg is added. - BUILDLINK_DEPENDS is the global list of - packages for which dependencies are added by - buildlink3.

    -

    The second section advises pkgsrc that the - buildlink3.mk file for - pkg has been included at some point. - BUILDLINK_PACKAGES is the global list of - packages for which buildlink3.mk files - have been included. It must always be - appended to within a buildlink3.mk - file.

    -

    The third section is protected from multiple inclusion - and controls how the dependency on pkg is - added. Several important variables are set in the section: -

    + BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//} + +

    The header and footer manipulate + BUILDLINK_DEPTH, which is common across all + buildlink3.mk files and is used to track + at what depth we are including + buildlink3.mk files.

    +

    The first section controls if the dependency on + pkg is added. + BUILDLINK_DEPENDS is the global list of + packages for which dependencies are added by + buildlink3.

    +

    The second section advises pkgsrc that the + buildlink3.mk file for + pkg has been included at some point. + BUILDLINK_PACKAGES is the global list of + packages for which buildlink3.mk files + have been included. It must always be + appended to within a buildlink3.mk + file.

    +

    The third section is protected from multiple inclusion + and controls how the dependency on pkg is + added. Several important variables are set in the section:

      -

    • BUILDLINK_API_DEPENDS.pkg - is the actual dependency recorded in the installed - package; this should always be set using - += to ensure that - we're appending to any pre-existing list of values. This - variable should be set to the first version of the - package that had an API change. -

      • -

    • BUILDLINK_PKGSRCDIR.pkg - is the location of the pkg - pkgsrc directory.

      • -

    • - BUILDLINK_DEPMETHOD.pkg - (not shown above) controls whether we use - BUILD_DEPENDS or - DEPENDS to add the dependency on - pkg. - The build dependency is selected by setting - BUILDLINK_DEPMETHOD.pkg - to “build”. By default, the - full dependency is used. -

      • -

    • - BUILDLINK_INCDIRS.pkg +

    • BUILDLINK_API_DEPENDS.pkg + is the actual dependency recorded in the installed + package; this should always be set using + += to ensure that + we're appending to any pre-existing list of values. This + variable should be set to the first version of the + package that had an API change. +

      • +

    • BUILDLINK_PKGSRCDIR.pkg + is the location of the pkg + pkgsrc directory.

      • +

    • BUILDLINK_DEPMETHOD.pkg + (not shown above) controls whether we use + BUILD_DEPENDS or + DEPENDS to add the dependency on + pkg. The build dependency is + selected by setting + BUILDLINK_DEPMETHOD.pkg + to “build”. By default, the full dependency is + used.

      • +

    • BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS.pkg (not shown above) are lists of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and library search paths. These default to “include” and “lib” - respectively.

      • -

    • - BUILDLINK_CPPFLAGS.pkg + respectively.

      • +

    • BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags to add to CPPFLAGS, which are passed on to the configure and build phases. The “-I” option should be avoided and instead be handled using BUILDLINK_INCDIRS.pkg as - above.

      • + above.

    -

    The following variables are all optionally defined within - this second section (protected against multiple inclusion) and - control which package files are symlinked into - ${BUILDLINK_DIR} and how their names are - transformed during the symlinking:

    +

    The following variables are all optionally defined within + this second section (protected against multiple inclusion) and + control which package files are symlinked into + ${BUILDLINK_DIR} and how their names are + transformed during the symlinking:

      -

    • - BUILDLINK_FILES.pkg +

    • BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to ${BUILDLINK_PREFIX.pkg} to be symlinked into ${BUILDLINK_DIR}, - e.g. include/*.h.

      • -

    • - BUILDLINK_FILES_CMD.pkg - (not shown above) is a shell pipeline that - outputs to stdout a list of files relative to - ${BUILDLINK_PREFIX.pkg}. - The resulting files are to be symlinked - into ${BUILDLINK_DIR}. By default, - this takes the +CONTENTS of a - pkg and filters it through - ${BUILDLINK_CONTENTS_FILTER.pkg}. -

      • -

    • - BUILDLINK_CONTENTS_FILTER.pkg + e.g. include/*.h.

      • +

    • BUILDLINK_FILES_CMD.pkg + (not shown above) is a shell pipeline that + outputs to stdout a list of files relative to + ${BUILDLINK_PREFIX.pkg}. + The resulting files are to be symlinked + into ${BUILDLINK_DIR}. By default, + this takes the +CONTENTS of a + pkg and filters it through + ${BUILDLINK_CONTENTS_FILTER.pkg}.

      • +

    • BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that filters +CONTENTS input into a list of files relative to @@ -4997,228 +4995,211 @@ a security check before building any package. See and lib directories in the package +CONTENTS, and for pkgviews packages, it outputs any libtool archives in - lib directories. -

      • -

    • - BUILDLINK_TRANSFORM.pkg + lib directories.

      • +

    • BUILDLINK_TRANSFORM.pkg (not shown above) is a list of sed arguments used to transform the name of the source filename into a destination filename, e.g. -e - "s|/curses.h|/ncurses.h|g". -

      • + "s|/curses.h|/ncurses.h|g".

    -

    The last section includes any - buildlink3.mk needed for - pkg's library dependencies. - Including these buildlink3.mk files - means that the headers and libraries for these - dependencies are also symlinked into - ${BUILDLINK_DIR} - whenever the pkg - buildlink3.mk - file is included. -

    +

    The last section includes any + buildlink3.mk needed for + pkg's library dependencies. + Including these buildlink3.mk files + means that the headers and libraries for these + dependencies are also symlinked into + ${BUILDLINK_DIR} + whenever the pkg + buildlink3.mk + file is included.

    12.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files

    -

    - The situation that requires increasing the dependency listed in +

    The situation that requires increasing the dependency listed in BUILDLINK_API_DEPENDS.pkg after a package update is when the API or interface to the - header files change.

    -

    In this case, - BUILDLINK_API_DEPENDS.pkg - should be adjusted to require at least the new package - version. In some cases, the packages that depend on this new - version may need their PKGREVISIONs - increased and, if they have buildlink3.mk - files, their - BUILDLINK_API_DEPENDS.pkg - adjusted, too. This is needed so pkgsrc will require the - correct package dependency and not settle for an older one - when building the source.

    -

    - BUILDLINK_ABI_DEPENDS.pkg + header files change.

    +

    In this case, + BUILDLINK_API_DEPENDS.pkg + should be adjusted to require at least the new package + version. In some cases, the packages that depend on this new + version may need their PKGREVISIONs + increased and, if they have buildlink3.mk + files, their + BUILDLINK_API_DEPENDS.pkg + adjusted, too. This is needed so pkgsrc will require the + correct package dependency and not settle for an older one + when building the source.

    +

    BUILDLINK_ABI_DEPENDS.pkg should be increased when the binary interface or sonames (major number of the library version) of any installed shared libraries change. This is needed so that binary packages made using it will require the correct package dependency and not settle for an older one which will not - contain the necessary shared libraries.

    -

    - See Section 17.1.6, “Handling dependencies” for + contain the necessary shared libraries.

    +

    See Section 17.1.6, “Handling dependencies” for more information about dependencies on other packages, including the BUILDLINK_ABI_DEPENDS and - ABI_DEPENDS definitions.

    -

    Please take careful consideration before adjusting - BUILDLINK_API_DEPENDS.pkg - or - BUILDLINK_ABI_DEPENDS.pkg - as we don't want to cause unneeded package deletions and - rebuilds. In many cases, new versions of packages work just - fine with older dependencies.

    -

    - Also it is not needed to set + ABI_DEPENDS definitions.

    +

    Please take careful consideration before adjusting + BUILDLINK_API_DEPENDS.pkg + or + BUILDLINK_ABI_DEPENDS.pkg + as we don't want to cause unneeded package deletions and + rebuilds. In many cases, new versions of packages work just + fine with older dependencies.

    +

    Also it is not needed to set BUILDLINK_ABI_DEPENDS.pkg when it is identical to - BUILDLINK_API_DEPENDS.pkg.

    + BUILDLINK_API_DEPENDS.pkg.

    12.3. Writing builtin.mk files

    -

    - Some packages in pkgsrc install headers and libraries that +

    Some packages in pkgsrc install headers and libraries that coincide with headers and libraries present in the base system. Aside from a buildlink3.mk file, these packages should also include a builtin.mk file that includes the necessary checks to decide whether using the built-in software or the pkgsrc software is - appropriate.

    -

    The only requirements of a builtin.mk file for - pkg are: -

    + appropriate.

    +

    The only requirements of a builtin.mk file for + pkg are:

      -

    1. It should set - USE_BUILTIN.pkg - to either “yes” or “no” - after it is included. -

      2. -

    2. It should not override any - USE_BUILTIN.pkg - which is already set before the - builtin.mk file is included. -

      3. -

    3. It should be written to allow multiple inclusion. This - is very important and takes careful - attention to Makefile coding. -

      4. +

    4. It should set + USE_BUILTIN.pkg + to either “yes” or “no” + after it is included.

      5. +

    5. It should not override any + USE_BUILTIN.pkg + which is already set before the + builtin.mk file is included.

      6. +

    6. It should be written to allow multiple inclusion. This + is very important and takes careful + attention to Makefile coding.

    12.3.1. Anatomy of a builtin.mk file

    The following is the recommended template for builtin.mk - files:

    + files:

    -    .if !defined(IS_BUILTIN.foo)
-    #
-    # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
-    # genuinely exists in the system or not.
-    #
-    IS_BUILTIN.foo?=        no
+	.if !defined(IS_BUILTIN.foo)
+	#
+	# IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
+	# genuinely exists in the system or not.
+	#
+	IS_BUILTIN.foo?=        no
 
-    # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
-    # version can be determined.
-    #
-    .  if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
-    BUILTIN_PKG.foo?=       foo-1.0
-    .  endif
-    .endif  # IS_BUILTIN.foo
+	# BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
+	# version can be determined.
+	#
+	.  if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
+	BUILTIN_PKG.foo?=       foo-1.0
+	.  endif
+	.endif  # IS_BUILTIN.foo
 
-    .if !defined(USE_BUILTIN.foo)
-    USE_BUILTIN.foo?=       ${IS_BUILTIN.foo}
-    .  if defined(BUILTIN_PKG.foo)
-    .    for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
-    .      if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
-    USE_BUILTIN.foo!=                                                       \
-          if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then     \
-                  ${ECHO} "yes";                                            \
-          else                                                              \
-                  ${ECHO} "no";                                             \
-          fi
-    .      endif
-    .    endfor
-    .  endif
-    .endif  # USE_BUILTIN.foo
+	.if !defined(USE_BUILTIN.foo)
+	USE_BUILTIN.foo?=       ${IS_BUILTIN.foo}
+	.  if defined(BUILTIN_PKG.foo)
+	.    for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
+	.      if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
+	USE_BUILTIN.foo!=                                                       \
+	if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then     \
+	${ECHO} "yes";                                            \
+	else                                                              \
+	${ECHO} "no";                                             \
+	fi
+	.      endif
+	.    endfor
+	.  endif
+	.endif  # USE_BUILTIN.foo
 
-    CHECK_BUILTIN.foo?=     no
-    .if !empty(CHECK_BUILTIN.foo:M[nN][oO])
-    #
-    # Here we place code that depends on whether USE_BUILTIN.foo is set to
-    # "yes" or "no".
-    #
-    .endif  # CHECK_BUILTIN.foo
-
    -

    The first section sets - IS_BUILTIN.pkg - depending on if pkg really exists - in the base system. This should not be a base system software - with similar functionality to pkg; - it should only be “yes” if the actual package is - included as part of the base system. This variable is only - used internally within the builtin.mk - file.

    -

    The second section sets - BUILTIN_PKG.pkg - to the version of pkg in the base - system if it exists (if - IS_BUILTIN.pkg - is “yes”). This variable is only used internally - within the builtin.mk file.

    -

    The third section sets - USE_BUILTIN.pkg - and is required in all - builtin.mk files. The code in this - section must make the determination whether the built-in - software is adequate to satisfy the dependencies listed in - BUILDLINK_API_DEPENDS.pkg. - This is typically done by comparing - BUILTIN_PKG.pkg - against each of the dependencies in - BUILDLINK_API_DEPENDS.pkg. - USE_BUILTIN.pkg - must be set to the correct value by the - end of the builtin.mk file. Note that - USE_BUILTIN.pkg - may be “yes” even if - IS_BUILTIN.pkg - is “no” because we may make the determination - that the built-in version of the software is similar enough to - be used as a replacement.

    -

    The last section is guarded by - CHECK_BUILTIN.pkg, - and includes code that uses the value of - USE_BUILTIN.pkg - set in the previous section. This typically includes, e.g., - adding additional dependency restrictions and listing - additional files to symlink into - ${BUILDLINK_DIR} (via - BUILDLINK_FILES.pkg). -

    + CHECK_BUILTIN.foo?= no + .if !empty(CHECK_BUILTIN.foo:M[nN][oO]) + # + # Here we place code that depends on whether USE_BUILTIN.foo is set to + # "yes" or "no". + # + .endif # CHECK_BUILTIN.foo + +

    The first section sets + IS_BUILTIN.pkg + depending on if pkg really exists + in the base system. This should not be a base system software + with similar functionality to pkg; + it should only be “yes” if the actual package is + included as part of the base system. This variable is only + used internally within the builtin.mk + file.

    +

    The second section sets + BUILTIN_PKG.pkg + to the version of pkg in the base + system if it exists (if + IS_BUILTIN.pkg + is “yes”). This variable is only used internally + within the builtin.mk file.

    +

    The third section sets + USE_BUILTIN.pkg + and is required in all + builtin.mk files. The code in this + section must make the determination whether the built-in + software is adequate to satisfy the dependencies listed in + BUILDLINK_API_DEPENDS.pkg. + This is typically done by comparing + BUILTIN_PKG.pkg + against each of the dependencies in + BUILDLINK_API_DEPENDS.pkg. + USE_BUILTIN.pkg + must be set to the correct value by the + end of the builtin.mk file. Note that + USE_BUILTIN.pkg + may be “yes” even if + IS_BUILTIN.pkg + is “no” because we may make the determination + that the built-in version of the software is similar enough to + be used as a replacement.

    +

    The last section is guarded by + CHECK_BUILTIN.pkg, + and includes code that uses the value of + USE_BUILTIN.pkg + set in the previous section. This typically includes, e.g., + adding additional dependency restrictions and listing additional + files to symlink into ${BUILDLINK_DIR} (via + BUILDLINK_FILES.pkg).

    12.3.2. Global preferences for native or pkgsrc software

    -

    - When building packages, it's possible to choose whether to set - a global preference for using either the built-in (native) - version or the pkgsrc version of software to satisfy a - dependency. This is controlled by setting - PREFER_PKGSRC and - PREFER_NATIVE. These variables take values - of either “yes”, “no”, or a list of - packages. PREFER_PKGSRC tells pkgsrc to - use the pkgsrc versions of software, while - PREFER_NATIVE tells pkgsrc to use the - built-in versions. Preferences are determined by the most - specific instance of the package in either - PREFER_PKGSRC or - PREFER_NATIVE. If a package is specified - in neither or in both variables, then - PREFER_PKGSRC has precedence over - PREFER_NATIVE. For example, to require - using pkgsrc versions of software for all but the most basic - bits on a NetBSD system, you can set:

    +

    When building packages, it's possible to choose whether to set + a global preference for using either the built-in (native) + version or the pkgsrc version of software to satisfy a + dependency. This is controlled by setting + PREFER_PKGSRC and + PREFER_NATIVE. These variables take values + of either “yes”, “no”, or a list of + packages. PREFER_PKGSRC tells pkgsrc to + use the pkgsrc versions of software, while + PREFER_NATIVE tells pkgsrc to use the + built-in versions. Preferences are determined by the most + specific instance of the package in either + PREFER_PKGSRC or + PREFER_NATIVE. If a package is specified + in neither or in both variables, then + PREFER_PKGSRC has precedence over + PREFER_NATIVE. For example, to require + using pkgsrc versions of software for all but the most basic + bits on a NetBSD system, you can set:

    -    PREFER_PKGSRC=  yes
-    PREFER_NATIVE=  getopt skey tcp_wrappers
-
    -

    A package must have a - builtin.mk - file to be listed in PREFER_NATIVE, - otherwise it is simply ignored in that list. -

    + PREFER_PKGSRC= yes + PREFER_NATIVE= getopt skey tcp_wrappers + +

    A package must have a + builtin.mk + file to be listed in PREFER_NATIVE, + otherwise it is simply ignored in that list.

    @@ -5280,15 +5261,29 @@ which means that it cannot register files outside this directory (absolute path names are not allowed). Despite this restriction, some packages need to install files outside this location; e.g., under ${VARBASE} or -${PKG_SYSCONFDIR}.

    -

    The only way to achieve this is to create such files during -installation time by using the installation scripts. These scripts can run -arbitrary commands, so they have the potential to create and manage files -anywhere in the file system. Here is where pkginstall comes into play: it -provides generic scripts to abstract the manipulation of such files and -directories based on variables set in the package's -Makefile. The rest of this section describes these -variables.

    +${PKG_SYSCONFDIR}. The only way to achieve this +is to create such files during installation time by using +installation scripts.

    +

    The generic installation scripts are shell scripts that can +contain arbitrary code. The list of scripts to execute is taken from +the INSTALL_FILE variable, which defaults to +INSTALL. A similar variable exists for package +removal (DEINSTALL_FILE, whose default is +DEINSTALL). These scripts can run arbitrary +commands, so they have the potential to create and manage files +anywhere in the file system.

    +

    Using these general installation files is not recommended, but +may be needed in some special cases. One reason for avoiding them is +that the user has to trust the packager that there is no unwanted or +simply erroneous code included in the installation script. Also, +previously there were many similar scripts for the same functionality, +and fixing a common error involved finding and changing all of +them.

    +

    The pkginstall framework offers another, standardized way. It +provides generic scripts to abstract the manipulation of such files +and directories based on variables set in the package's +Makefile. The rest of this section describes +these variables.

    13.1.1. Directory manipulation

    @@ -5533,18 +5528,18 @@ syntax:

         user:group
    -

    Further specification of user details may be done by setting per-user -variables. -PKG_UID.user is the numeric -UID for the user. -PKG_GECOS.user is the user's -description or comment. -PKG_HOME.user is the user's -home directory, and defaults to /nonexistent if not -specified. -PKG_SHELL.user is the user's -shell, and defaults to /sbinno/login if not specified. -

    +

    Further specification of user details may be done by setting +per-user variables. +PKG_UID.user is the +numeric UID for the user. +PKG_GECOS.user is the +user's description or comment. +PKG_HOME.user is the +user's home directory, and defaults to +/nonexistent if not specified. +PKG_SHELL.user is the +user's shell, and defaults to /sbinno/login if +not specified.

    Similarly, groups can be created by adding entries to the PKG_GROUPS variable, whose syntax is:

    @@ -5830,158 +5825,158 @@ support.” The file is sorted by option names.
    
 
    
 15.1. Introduction
    
 
    This chapter gives a detailed description on how a package is
-built. Building a package is separated into different
-phases (for example fetch,
-build, install), all of which are
-described in the following sections. Each phase is splitted into
-so-called stages, which take the name of the
-containing phase, prefixed by one of pre-,
-do- or post-. (Examples are
-pre-configure, post-build.) Most
-of the actual work is done in the do-* stages.
    
+    built. Building a package is separated into different
+    phases (for example fetch,
+    build, install), all of which are
+    described in the following sections. Each phase is splitted into
+    so-called stages, which take the name of the
+    containing phase, prefixed by one of pre-,
+    do- or post-. (Examples are
+    pre-configure, post-build.) Most
+    of the actual work is done in the do-* stages.
    
 
    The basic steps for building a program are always the same.  First
-the program's source (distfile) must be brought to
-the local system and then extracted. After any pkgsrc-specific patches
-to compile properly are applied, the software can be configured, then
-built (usually by compiling), and finally the generated binaries, etc.
-can be put into place on the system.
    
+    the program's source (distfile) must be brought to
+    the local system and then extracted. After any pkgsrc-specific patches
+    to compile properly are applied, the software can be configured, then
+    built (usually by compiling), and finally the generated binaries, etc.
+    can be put into place on the system.

    15.2. Program location

    Before outlining the process performed by the NetBSD package system in - the next section, here's a brief discussion on where programs are - installed, and which variables influence this.

    + the next section, here's a brief discussion on where programs are + installed, and which variables influence this.

    The automatic variable PREFIX indicates - where all files of the final program shall be installed. It is - usually set to LOCALBASE - (/usr/pkg), or CROSSBASE - for pkgs in the “cross” category. The value of - PREFIX needs to be put - into the various places in the program's source where paths to - these files are encoded. See Section 9.3, “patches/*” and Section 17.3.1, “Shared libraries - libtool” for more details.

    + where all files of the final program shall be installed. It is + usually set to LOCALBASE + (/usr/pkg), or CROSSBASE + for pkgs in the “cross” category. The value of + PREFIX needs to be put + into the various places in the program's source where paths to + these files are encoded. See Section 9.3, “patches/*” and Section 17.3.1, “Shared libraries - libtool” for more details.

    When choosing which of these variables to use, - follow the following rules:

    + follow the following rules:

    • PREFIX always points to the location where the current - pkg will be installed. When referring to a pkg's own installation path, - use “${PREFIX}”.

      • + pkg will be installed. When referring to a pkg's own installation path, + use “${PREFIX}”.

    • LOCALBASE is where all non-X11 pkgs are installed. - If you need to construct a -I or -L argument to the compiler to find - includes and libraries installed by another non-X11 pkg, use - “${LOCALBASE}”. The name - LOCALBASE stems from FreeBSD, which - installed all packages in /usr/local. As - pkgsrc leaves /usr/local for the system - administrator, this variable is a misnomer.

      • + If you need to construct a -I or -L argument to the compiler to find + includes and libraries installed by another non-X11 pkg, use + “${LOCALBASE}”. The name + LOCALBASE stems from FreeBSD, which + installed all packages in /usr/local. As + pkgsrc leaves /usr/local for the system + administrator, this variable is a misnomer.

    • X11BASE is where the actual X11 distribution (from - xsrc, etc.) is installed. When looking for - standard X11 includes (not - those installed by a pkg), use “${X11BASE}”.

      • + xsrc, etc.) is installed. When looking for + standard X11 includes (not + those installed by a pkg), use “${X11BASE}”.

    • X11-based packages are special in that they may be installed in - either X11BASE or LOCALBASE.

      + either X11BASE or LOCALBASE.

      Usually, X11 packages should be installed under - LOCALBASE whenever possible. Note that you will - need to include ../../mk/x11.buildlink3.mk - in them to request the - presence of X11 and to get the right compilation flags.

      + LOCALBASE whenever possible. Note that you will + need to include ../../mk/x11.buildlink3.mk + in them to request the + presence of X11 and to get the right compilation flags.

      Even though, there are some packages that cannot be installed - under LOCALBASE: those that come with app-defaults - files. These packages are special and they must be placed under - X11BASE. To accomplish this, set either - USE_X11BASE or USE_IMAKE in - your package.

      + under LOCALBASE: those that come with app-defaults + files. These packages are special and they must be placed under + X11BASE. To accomplish this, set either + USE_X11BASE or USE_IMAKE in + your package.

      Some notes: If you need - to find includes or libraries installed by a pkg that has - USE_IMAKE or USE_X11BASE in - its pkg Makefile, you need to look in - both ${X11BASE} and - ${LOCALBASE}. To force installation of - all X11 packages in LOCALBASE, the - pkgtools/xpkgwedge package - is enabled by default.

      + to find includes or libraries installed by a pkg that has + USE_IMAKE or USE_X11BASE in + its pkg Makefile, you need to look in + both ${X11BASE} and + ${LOCALBASE}. To force installation of + all X11 packages in LOCALBASE, the + pkgtools/xpkgwedge package + is enabled by default.

    • X11PREFIX should be used to refer to the installed - location of an X11 package. X11PREFIX will be set to - X11BASE if xpkgwedge is not installed, - and to LOCALBASE if xpkgwedge is installed.

      • + location of an X11 package. X11PREFIX will be set to + X11BASE if xpkgwedge is not installed, + and to LOCALBASE if xpkgwedge is installed.

    • If xpkgwedge is installed, it is possible to have some packages installed - in X11BASE and some in LOCALBASE. - To determine the prefix of an installed package, the - EVAL_PREFIX definition can be used. It takes pairs in the - format “DIRNAME=<package>”, and the make(1) variable - DIRNAME will be set to the prefix of the installed - package <package>, or “${X11PREFIX}” if the package is - not installed.

      + in X11BASE and some in LOCALBASE. + To determine the prefix of an installed package, the + EVAL_PREFIX definition can be used. It takes pairs in the + format “DIRNAME=<package>”, and the make(1) variable + DIRNAME will be set to the prefix of the installed + package <package>, or “${X11PREFIX}” if the package is + not installed.

      This is best illustrated by example.

      The following lines are taken from - pkgsrc/wm/scwm/Makefile:

      + pkgsrc/wm/scwm/Makefile:

      -    EVAL_PREFIX+=           GTKDIR=gtk+
-    CONFIGURE_ARGS+=        --with-guile-prefix=${LOCALBASE:Q}
-    CONFIGURE_ARGS+=        --with-gtk-prefix=${GTKDIR:Q}
-    CONFIGURE_ARGS+=        --enable-multibyte
-
      + EVAL_PREFIX+= GTKDIR=gtk+ + CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} + CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} + CONFIGURE_ARGS+= --enable-multibyte +

      Specific defaults can be defined for the packages evaluated using - EVAL_PREFIX, by using a definition of the form:

      + EVAL_PREFIX, by using a definition of the form:

      -    GTKDIR_DEFAULT= ${LOCALBASE}
-
      + GTKDIR_DEFAULT= ${LOCALBASE} +

      where GTKDIR corresponds - to the first definition in - the EVAL_PREFIX pair.

      + to the first definition in + the EVAL_PREFIX pair.

    • Within ${PREFIX}, packages should - install files according to hier(7), with the exception that - manual pages go into ${PREFIX}/man, not - ${PREFIX}/share/man.

      • + install files according to hier(7), with the exception that + manual pages go into ${PREFIX}/man, not + ${PREFIX}/share/man.

    15.3. Directories used during the build process

    When building a package, a number of directories is used to store -source files, temporary files, pkgsrc-internal files, and so on. These -directories are explained here.

    + source files, temporary files, pkgsrc-internal files, and so on. These + directories are explained here.

    Some of the directory variables contain relative pathnames. There -are two common base directories for these relative directories: -PKGSRCDIR/PKGPATH is used for directories that are -pkgsrc-specific. WRKSRC is used for directories -inside the package itself.

    + are two common base directories for these relative directories: + PKGSRCDIR/PKGPATH is used for directories that are + pkgsrc-specific. WRKSRC is used for directories + inside the package itself.

    PKGSRCDIR

    This is an absolute pathname that points to the pkgsrc -root directory. Generally, you don't need -it.

    + root directory. Generally, you don't need + it.

    PKGPATH

    This is a pathname relative to -PKGSRCDIR that points to the current -package.

    + PKGSRCDIR that points to the current + package.

    WRKDIR

    This is an absolute pathname pointing to the directory -where all work takes place. The distfiles are extraced to this -directory. It also contains temporary directories and log files used by -the various pkgsrc frameworks, like buildlink or -the wrappers.

    + where all work takes place. The distfiles are extraced to this + directory. It also contains temporary directories and log files used by + the various pkgsrc frameworks, like buildlink or + the wrappers.

    WRKSRC

    This is an absolute pathname pointing to the directory -where the distfiles are extracted. It is usually a direct subdirectory -of WRKDIR, and often it's the only directory entry -that isn't hidden. This variable may be changed by a package -Makefile.

    + where the distfiles are extracted. It is usually a direct subdirectory + of WRKDIR, and often it's the only directory entry + that isn't hidden. This variable may be changed by a package + Makefile.

    15.4. Running a phase

    You can run a particular phase by typing make -phase, where phase is the name of the -phase. This will automatically run all phases that are required for this -phase. The default phase is build, that is, when you -run make without parameters in a package directory, -the package will be built, but not installed.

    + phase, where phase is the name of the + phase. This will automatically run all phases that are required for this + phase. The default phase is build, that is, when you + run make without parameters in a package directory, + the package will be built, but not installed.

    @@ -6262,7 +6257,7 @@ is executed.

    .for d in ${BUILD_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \ - -f ${MAKEFILE} ${BUILD_TARGET} + -f ${MAKE_FILE} ${BUILD_TARGET} .endfor

    BUILD_DIRS (default: “.”) is a @@ -6271,12 +6266,12 @@ these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, -MAKEFILE and BUILD_TARGET may all +MAKE_FILE and BUILD_TARGET may all be changed by the package.

    The default value of MAKE_PROGRAM is “gmake” if USE_TOOLS contains “gmake”, “make” otherwise. The default value -of MAKEFILE is “Makefile”, and +of MAKE_FILE is “Makefile”, and BUILD_TARGET defaults to “all”.

    @@ -6298,7 +6293,7 @@ of MAKEFILE is “Makefile< .for d in ${INSTALL_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \ - -f ${MAKEFILE} ${BUILD_TARGET} + -f ${MAKE_FILE} ${BUILD_TARGET} .endfor

    The variable's meanings are analogous to the ones in the @@ -6367,129 +6362,133 @@ of MAKEFILE is “Makefile< 15.16. Other helpful targets

    pre/post-*
    -

    For any of the main targets described in the previous section, two - auxiliary targets exist with “pre-” and - “post-” used as a prefix - for the main target's name. These targets are invoked before and - after the main target is called, allowing extra configuration or - installation steps be performed from a package's Makefile, for - example, which a program's configure script - or install target omitted.

    +

    For any of the main targets described in the previous + section, two auxiliary targets exist with + “pre-” and “post-” used as a + prefix for the main target's name. These targets are + invoked before and after the main target is called, allowing + extra configuration or installation steps be performed from + a package's Makefile, for example, which a program's + configure script or install target omitted.

    do-*
    -

    Should one of the main targets do the wrong thing, and should there - be no variable to fix this, you can redefine it with the do-* - target. (Note that redefining the target itself instead of the - do-* target is a bad idea, as the pre-* and post-* targets won't be - called anymore, etc.) You will not usually need to do this.

    +

    Should one of the main targets do the wrong thing, and + should there be no variable to fix this, you can redefine it + with the do-* target. (Note that redefining the target + itself instead of the do-* target is a bad idea, as the + pre-* and post-* targets won't be called anymore, etc.) You + will not usually need to do this.

    reinstall
    -

    If you did a make install and you noticed some file - was not installed properly, you can repeat the installation with this - target, which will ignore the “already installed” flag.

    +

    If you did a make install and you + noticed some file was not installed properly, you can repeat + the installation with this target, which will ignore the + “already installed” flag.

    deinstall

    This target does a pkg_delete(1) in the current directory, - effectively de-installing the package. The following variables can - be used to tune the behaviour:

    + effectively de-installing the package. The following variables can + be used to tune the behaviour:

    PKG_VERBOSE

    Add a "-v" to the pkg_delete(1) command.

    DEINSTALLDEPENDS

    Remove all packages that require (depend on) the given package. - This can be used to remove any packages that may have been pulled in - by a given package, e.g. if make deinstall - DEINSTALLDEPENDS=1 is done in - pkgsrc/x11/kde, this is likely to remove whole - KDE. Works by adding “-R” to the pkg_delete(1) command line.

    + This can be used to remove any packages that may have been pulled in + by a given package, e.g. if make deinstall + DEINSTALLDEPENDS=1 is done in + pkgsrc/x11/kde, this is likely to remove whole + KDE. Works by adding “-R” to the pkg_delete(1) command line.

    update

    This target causes the current package to be updated to the latest - version. The package and all depending packages first get de-installed, - then current versions of the corresponding packages get compiled and - installed. This is similar to manually noting which packages are - currently installed, then performing a series of make - deinstall and make install (or whatever - UPDATE_TARGET is set to) for these packages.

    + version. The package and all depending packages first get de-installed, + then current versions of the corresponding packages get compiled and + installed. This is similar to manually noting which packages are + currently installed, then performing a series of make + deinstall and make install (or whatever + UPDATE_TARGET is set to) for these packages.

    You can use the “update” target to resume package - updating in case a previous make update was interrupted - for some reason. However, in this case, make sure you don't call - make clean or otherwise remove the list of dependent - packages in WRKDIR. Otherwise, you lose the - ability to automatically update the current package along with the - dependent packages you have installed.

    + updating in case a previous make update was interrupted + for some reason. However, in this case, make sure you don't call + make clean or otherwise remove the list of dependent + packages in WRKDIR. Otherwise, you lose the + ability to automatically update the current package along with the + dependent packages you have installed.

    Resuming an interrupted make update will only work as - long as the package tree remains unchanged. If the source code for - one of the packages to be updated has been changed, resuming - make update will most certainly fail!

    + long as the package tree remains unchanged. If the source code for + one of the packages to be updated has been changed, resuming + make update will most certainly fail!

    The following variables can be used either on the command line or in - /etc/mk.conf to alter the behaviour of - make update:

    + /etc/mk.conf to alter the behaviour of + make update:

    UPDATE_TARGET

    Install target to recursively use for the updated package and the - dependent packages. Defaults to DEPENDS_TARGET if set, - “install” otherwise for make update. - e.g. make update UPDATE_TARGET=package

    + dependent packages. Defaults to DEPENDS_TARGET if set, + “install” otherwise for make update. + e.g. make update UPDATE_TARGET=package

    NOCLEAN

    Don't clean up after updating. Useful if you want to leave the - work sources of the updated packages around for inspection or - other purposes. Be sure you eventually clean up the source - tree (see the “clean-update” target below) or you may - run into troubles with old source code still lying around on your - next make or make update.

    + work sources of the updated packages around for inspection or + other purposes. Be sure you eventually clean up the source + tree (see the “clean-update” target below) or you may + run into troubles with old source code still lying around on your + next make or make update.

    REINSTALL

    Deinstall each package before installing (making - DEPENDS_TARGET). This may be necessary if the - “clean-update” target (see below) was called after - interrupting a running make update.

    + DEPENDS_TARGET). This may be necessary if the + “clean-update” target (see below) was called after + interrupting a running make update.

    DEPENDS_TARGET

    Allows you to disable recursion and hardcode the target for - packages. The default is “update” for the update target, - facilitating a recursive update of prerequisite packages. - Only set DEPENDS_TARGET if you want to disable - recursive updates. Use UPDATE_TARGET instead to just - set a specific target for each package to be installed during - make update (see above).

    + packages. The default is “update” for the update target, + facilitating a recursive update of prerequisite packages. + Only set DEPENDS_TARGET if you want to disable + recursive updates. Use UPDATE_TARGET instead to just + set a specific target for each package to be installed during + make update (see above).

    clean-update

    Clean the source tree for all packages that would get updated if - make update was called from the current directory. - This target should not be used if the current package (or any of its - depending packages) have already been de-installed (e.g., after calling - make update) or you may lose some packages you intended - to update. As a rule of thumb: only use this target - before the first time you run - make update and only if you have a dirty package tree - (e.g., if you used NOCLEAN).

    + make update was called from the current directory. + This target should not be used if the current package (or any of its + depending packages) have already been de-installed (e.g., after calling + make update) or you may lose some packages you intended + to update. As a rule of thumb: only use this target + before the first time you run + make update and only if you have a dirty package tree + (e.g., if you used NOCLEAN).

    If you are unsure about whether your tree is clean, you can either - perform a make clean at the top of the tree, or use - the following sequence of commands from the directory of the package - you want to update (before running - make update for the first time, otherwise you lose - all the packages you wanted to update!):

    -
    # make clean-update
+	  perform a make clean at the top of the tree, or use
+	  the following sequence of commands from the directory of the package
+	  you want to update (before running
+	  make update for the first time, otherwise you lose
+	  all the packages you wanted to update!):
    
+
    +# make clean-update
 # make clean CLEANDEPENDS=YES
-# make update
    
+# make update
+

    The following variables can be used either on the command line or in - /etc/mk.conf to alter the behaviour of - make clean-update:

    + /etc/mk.conf to alter the behaviour of + make clean-update:

    CLEAR_DIRLIST

    After make clean, do not reconstruct the list of - directories to update for this package. Only use this if make - update successfully installed all packages you wanted to - update. Normally, this is done automatically on make - update, but may have been suppressed by the - NOCLEAN variable (see above).

    + directories to update for this package. Only use this if make + update successfully installed all packages you wanted to + update. Normally, this is done automatically on make + update, but may have been suppressed by the + NOCLEAN variable (see above).

    info

    This target invokes pkg_info(1) for the current - package. You can use this to check which version of a package is - installed.

    + package. You can use this to check which version of a package is + installed.

    readme

    This target generates a README.html file, which can be viewed using a browser such as @@ -6509,93 +6508,95 @@ of MAKEFILE is “Makefile< searched for all the binary packages.

    readme-all

    Use this target to create a file README-all.html - which contains a list of all packages currently available in the NetBSD - Packages Collection, together with the category they belong to and a - short description. This file is compiled from the - pkgsrc/*/README.html files, so be sure to run - this after a make readme.

    + which contains a list of all packages currently available in the NetBSD + Packages Collection, together with the category they belong to and a + short description. This file is compiled from the + pkgsrc/*/README.html files, so be sure to run + this after a make readme.

    cdrom-readme

    This is very much the same as the “readme” target (see - above), but is to be used when generating a pkgsrc tree to be written - to a CD-ROM. This target also produces - README.html files, and can be made to refer - to URLs based on CDROM_PKG_URL_HOST and - CDROM_PKG_URL_DIR.

    + above), but is to be used when generating a pkgsrc tree to be written + to a CD-ROM. This target also produces + README.html files, and can be made to refer + to URLs based on CDROM_PKG_URL_HOST and + CDROM_PKG_URL_DIR.

    show-distfiles
    -

    This target shows which distfiles and patchfiles are needed to build - the package. (DISTFILES and - PATCHFILES, but not patches/*)

    +

    This target shows which distfiles and patchfiles are + needed to build the package (ALLFILES, + which contains all DISTFILES and + PATCHFILES, but not + patches/*).

    show-downlevel

    This target shows nothing if the package is not installed. If a version - of this package is installed, but is not the version provided in this - version of pkgsrc, then a warning message is displayed. This target can - be used to show which of your installed packages are downlevel, and so - the old versions can be deleted, and the current ones added.

    + of this package is installed, but is not the version provided in this + version of pkgsrc, then a warning message is displayed. This target can + be used to show which of your installed packages are downlevel, and so + the old versions can be deleted, and the current ones added.

    show-pkgsrc-dir

    This target shows the directory in the pkgsrc hierarchy from which the - package can be built and installed. This may not be the same directory - as the one from which the package was installed. This target is intended - to be used by people who may wish to upgrade many packages on a single - host, and can be invoked from the top-level pkgsrc Makefile by using the - “show-host-specific-pkgs” target.

    + package can be built and installed. This may not be the same directory + as the one from which the package was installed. This target is intended + to be used by people who may wish to upgrade many packages on a single + host, and can be invoked from the top-level pkgsrc Makefile by using the + “show-host-specific-pkgs” target.

    show-installed-depends

    This target shows which installed packages match the current package's - DEPENDS. Useful if out of date dependencies are - causing build problems.

    + DEPENDS. Useful if out of date dependencies are + causing build problems.

    check-shlibs

    After a package is installed, check all its binaries and (on ELF - platforms) shared libraries to see if they find the shared libs they need. - Run by default if PKG_DEVELOPER is set in - /etc/mk.conf.

    + platforms) shared libraries to see if they find the shared libs they need. + Run by default if PKG_DEVELOPER is set in + /etc/mk.conf.

    print-PLIST

    After a “make install” from a new or - upgraded pkg, this prints out an attempt to generate a new - PLIST from a find -newer - work/.extract_done. An attempt is made to care - for shared libs etc., but it is - strongly recommended to review the - result before putting it into - PLIST. On upgrades, it's useful to - diff the output of this command against an already - existing PLIST file.

    + upgraded pkg, this prints out an attempt to generate a new + PLIST from a find -newer + work/.extract_done. An attempt is made to care + for shared libs etc., but it is + strongly recommended to review the + result before putting it into + PLIST. On upgrades, it's useful to + diff the output of this command against an already + existing PLIST file.

    If the package installs files via tar(1) or other - methods that don't update file access times, be sure to - add these files manually to your - PLIST, as the “find - -newer” command used by this target won't catch - them!

    -

    See Section 11.3, “Tweaking output of make print-PLIST” for more - information on this target.

    + methods that don't update file access times, be sure to + add these files manually to your + PLIST, as the “find + -newer” command used by this target won't catch + them!

    +

    See Section 11.3, “Tweaking output of make print-PLIST” for more + information on this target.

    bulk-package

    Used to do bulk builds. If an appropriate binary package already exists, - no action is taken. If not, this target will compile, install and - package it (and its depends, if PKG_DEPENDS is - set properly. See Section 6.3.1, “Configuration”). - After creating the binary - package, the sources, the just-installed package and its required - packages are removed, preserving free disk space.

    + no action is taken. If not, this target will compile, install and + package it (and its depends, if PKG_DEPENDS is + set properly. See Section 6.3.1, “Configuration”). + After creating the binary + package, the sources, the just-installed package and its required + packages are removed, preserving free disk space.

    Beware that this target may deinstall all - packages installed on a system!

    + packages installed on a system!

    bulk-install

    Used during bulk-installs to install required packages. If an - up-to-date binary package is available, it will be installed via - pkg_add(1). If not, make bulk-package will be executed, - but the installed binary won't be removed.

    -

    A binary package is considered “up-to-date” to be - installed via pkg_add(1) if:

    + up-to-date binary package is available, it will be installed via + pkg_add(1). If not, make bulk-package will be executed, + but the installed binary won't be removed.

    +

    A binary package is considered “up-to-date” to be + installed via pkg_add(1) if:

    • None of the package's files (Makefile, - ...) were modified since it was built.

      • + ...) were modified since it was built.

    • None of the package's required (binary) packages were - modified since it was built.

      • + modified since it was built.

    Beware that this target may deinstall all - packages installed on a system!

    + packages installed on a system!

    @@ -6611,86 +6612,65 @@ of MAKEFILE is “Makefile<
    16.3. Tools provided by platforms
    -

    -The USE_TOOLS definition is used both internally +

    The USE_TOOLS definition is used both internally by pkgsrc and also for individual packages to define what commands are needed for building a package (like BUILD_DEPENDS) or for later run-time of an installed packaged (such as DEPENDS). If the native system provides an adequate tool, then in many cases, a pkgsrc -package will not be used. -

    -

    -When building a package, the replacement tools are +package will not be used.

    +

    When building a package, the replacement tools are made available in a directory (as symlinks or wrapper scripts) that is early in the executable search path. Just like the buildlink -system, this helps with consistent builds. -

    -

    -A tool may be needed to help build a specific package. For example, -perl, GNU make (gmake) or yacc may be needed. -

    -

    -Also a tool may be needed, for example, because the native system's supplied +system, this helps with consistent builds.

    +

    A tool may be needed to help build a specific package. For example, +perl, GNU make (gmake) or yacc may be needed.

    +

    Also a tool may be needed, for example, because the native system's supplied tool may be inefficient for building a package with pkgsrc. For example, a package may need GNU awk, bison (instead of -yacc) or a better sed. -

    -

    -The tools used by a package can be listed by running -make show-tools. -

    +yacc) or a better sed.

    +

    The tools used by a package can be listed by running +make show-tools.

    16.1. Tools for pkgsrc builds

    -

    -The default set of tools used by pkgsrc is defined in +

    The default set of tools used by pkgsrc is defined in bsd.pkg.mk. This includes standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be seen by running: -make show-var VARNAME=USE_TOOLS. -

    -

    -If a package needs a specific program to build +make show-var VARNAME=USE_TOOLS.

    +

    If a package needs a specific program to build then the USE_TOOLS variable can be used -to define the tools needed. -

    +to define the tools needed.

    16.2. Tools needed by packages

    -

    -In the following examples, the :pkgsrc means to use the pkgsrc version +

    In the following examples, the :pkgsrc means to use the pkgsrc version and not the native version for a build dependency. And the :run means that it is used for a run-time dependencies also (and becomes a DEPENDS). The default is a build dependency which can be set with :build. (So in this example, it is the same as gmake:build -and pkg-config:build.) -

    +and pkg-config:build.)

     USE_TOOLS+=     mktemp:pkgsrc
 USE_TOOLS+=     gmake perl:run pkg-config
    -

    -When using the tools framework, a +

    When using the tools framework, a TOOLS_PATH.foo variable is defined which contains the full path to the appropriate tool. For example, TOOLS_PATH.bash could be “/bin/bash” -on Linux systems. -

    -

    -If you always need a pkgsrc version of the +on Linux systems.

    +

    If you always need a pkgsrc version of the tool at run-time, then just use DEPENDS instead. -

    16.3. Tools provided by platforms

    -

    -When improving or porting pkgsrc to a new platform, have a look +

    When improving or porting pkgsrc to a new platform, have a look at (or create) the corresponding platform specific make file fragment under pkgsrc/mk/tools/tools.${OPSYS}.mk which defines the name of the common tools. For example:

    @@ -6737,34 +6717,44 @@ TOOLS_PLATFORM.true?= true # shell builtin
    17.3.2. Using libtool on GNU packages that already support libtool
    17.3.3. GNU Autoconf/Automake
    -
    17.4. Fixing problems in the build phase
    +
    17.4. Programming languages
    +
    +
    17.4.1. C, C++, and Fortran
    +
    17.4.2. Java
    +
    17.4.3. Packages containing perl scripts
    +
    17.4.4. Other programming languages
    +
    +
    17.5. Fixing problems in the build phase
    -
    17.4.1. Compiling C and C++ code conditionally
    -
    17.4.2. How to handle compiler bugs
    -
    17.4.3. Undefined reference to “...”
    +
    17.5.1. Compiling C and C++ code conditionally
    +
    17.5.2. How to handle compiler bugs
    +
    17.5.3. Undefined reference to “...”
    +
    17.5.4. Running out of memory
    -
    17.5. Fixing problems in the install phase
    +
    17.6. Fixing problems in the install phase
    -
    17.5.1. Creating needed directories
    -
    17.5.2. Where to install documentation
    -
    17.5.3. Installing score files
    -
    17.5.4. Packages containing perl scripts
    -
    17.5.5. Packages with hardcoded paths to other interpreters
    -
    17.5.6. Packages installing perl modules
    -
    17.5.7. Packages installing info files
    -
    17.5.8. Packages installing man pages
    -
    17.5.9. Packages installing GConf2 data files
    -
    17.5.10. Packages installing scrollkeeper data files
    -
    17.5.11. Packages installing X11 fonts
    -
    17.5.12. Packages installing GTK2 modules
    -
    17.5.13. Packages installing SGML or XML data
    -
    17.5.14. Packages installing extensions to the MIME database
    -
    17.5.15. Packages using intltool
    -
    17.5.16. Packages installing startup scripts
    -
    17.5.17. Packages installing TeX modules
    -
    17.5.18. Packages installing hicolor theme icons
    -
    17.5.19. Packages installing desktop files
    +
    17.6.1. Creating needed directories
    +
    17.6.2. Where to install documentation
    +
    17.6.3. Installing score files
    +
    17.6.4. Packages with hardcoded paths to other interpreters
    +
    17.6.5. Packages installing perl modules
    +
    17.6.6. Packages installing info files
    +
    17.6.7. Packages installing man pages
    +
    17.6.8. Packages installing GConf2 data files
    +
    17.6.9. Packages installing scrollkeeper data files
    +
    17.6.10. Packages installing X11 fonts
    +
    17.6.11. Packages installing GTK2 modules
    +
    17.6.12. Packages installing SGML or XML data
    +
    17.6.13. Packages installing extensions to the MIME database
    +
    17.6.14. Packages using intltool
    +
    17.6.15. Packages installing startup scripts
    +
    17.6.16. Packages installing TeX modules
    +
    17.6.17. Packages supporting running binaries in + emulation
    +
    17.6.18. Packages installing hicolor theme icons
    +
    17.6.19. Packages installing desktop files
    +
    17.7. Marking packages as having problems
    @@ -6774,445 +6764,445 @@ TOOLS_PLATFORM.true?= true # shell builtin

    17.1.1. Portability of packages

    One appealing feature of pkgsrc is that it runs on many - different platforms. As a result, it is important to ensure, - where possible, that packages in pkgsrc are portable. This - chapter mentions some particular details you should pay - attention to while working on pkgsrc.

    + different platforms. As a result, it is important to ensure, + where possible, that packages in pkgsrc are portable. This + chapter mentions some particular details you should pay + attention to while working on pkgsrc.

    17.1.2. How to pull in user-settable variables from mk.conf

    The pkgsrc user can configure pkgsrc by overriding several - variables in the file pointed to by MAKECONF, - which is /etc/mk.conf by default. When you - want to use those variables in the preprocessor directives of - make(1) (for example .if or - .for), you need to include the file - ../../mk/bsd.prefs.mk before, which in turn - loads the user preferences.

    + variables in the file pointed to by MAKECONF, + which is /etc/mk.conf by default. When you + want to use those variables in the preprocessor directives of + make(1) (for example .if or + .for), you need to include the file + ../../mk/bsd.prefs.mk before, which in turn + loads the user preferences.

    But note that some variables may not be completely defined - after ../../mk/bsd.prefs.mk has been - included, as they may contain references to variables that are - not yet defined. In shell commands this is no problem, since - variables are actually macros, which are only expanded when they - are used. But in the preprocessor directives mentioned above and - in dependency lines (of the form target: - dependencies) the variables are expanded at load - time.

    + after ../../mk/bsd.prefs.mk has been + included, as they may contain references to variables that are + not yet defined. In shell commands this is no problem, since + variables are actually macros, which are only expanded when they + are used. But in the preprocessor directives mentioned above and + in dependency lines (of the form target: + dependencies) the variables are expanded at load + time.

    Note

    Currently there is no exhaustive list of all - variables that tells you whether they can be used at load time - or only at run time, but it is in preparation.

    + variables that tells you whether they can be used at load time + or only at run time, but it is in preparation.

    17.1.3. User interaction

    Occasionally, packages require interaction from the user, and this can be - in a number of ways:

    + in a number of ways:

    • When fetching the distfiles, some packages require user - interaction such as entering username/password or accepting a - license on a web page.

      • + interaction such as entering username/password or accepting a + license on a web page.

    • When extracting the distfiles, some packages may ask for passwords.

    • help to configure the package before it is built

    • help during the build process

    • help during the installation of a package

    The INTERACTIVE_STAGE definition is provided to notify - the pkgsrc mechanism of an interactive stage which will be needed, and - this should be set in the package's Makefile, e.g.:

    + the pkgsrc mechanism of an interactive stage which will be needed, and + this should be set in the package's Makefile, e.g.:

    -    INTERACTIVE_STAGE=      build
-
    + INTERACTIVE_STAGE= build +

    Multiple interactive stages can be specified:

    -    INTERACTIVE_STAGE=      configure install
-
    + INTERACTIVE_STAGE= configure install +

    17.1.4. Handling licenses

    A package may be covered by a license which the user has - or has not agreed to accept. For these cases, pkgsrc contains - a mechanism to note that a package is covered by a particular - license, and the package cannot be built unless the user has - accepted the license. (Installation of binary packages are - not currently subject to this mechanism.) Packages with - licenses that are either Open Source according to the Open - Source Initiative or Free according to the Free Software - Foundation will not be marked with a license tag. Packages - with licenses that have not been determined to meet either - definition will be marked with a license tag referring to the - license. This will prevent building unless pkgsrc is informed - that the license is acceptable, and enables displaying the - license.

    + or has not agreed to accept. For these cases, pkgsrc contains + a mechanism to note that a package is covered by a particular + license, and the package cannot be built unless the user has + accepted the license. (Installation of binary packages are + not currently subject to this mechanism.) Packages with + licenses that are either Open Source according to the Open + Source Initiative or Free according to the Free Software + Foundation will not be marked with a license tag. Packages + with licenses that have not been determined to meet either + definition will be marked with a license tag referring to the + license. This will prevent building unless pkgsrc is informed + that the license is acceptable, and enables displaying the + license.

    The license tag mechanism is intended to address - copyright-related issues surrounding building, installing and - using a package, and not to address redistribution issues (see - RESTRICTED and - NO_SRC_ON_FTP, etc.). However, the above - definition of licenses for which tags are not needed implies - that packages with redistribution restrictions should have - tags.

    -

    - Denoting that a package is covered by a particular license is - done by placing the license in - pkgsrc/licenses and setting the - LICENSE variable to a string identifying - the license, e.g. in - graphics/xv:

    + copyright-related issues surrounding building, installing and + using a package, and not to address redistribution issues (see + RESTRICTED and + NO_SRC_ON_FTP, etc.). However, the above + definition of licenses for which tags are not needed implies + that packages with redistribution restrictions should have + tags.

    +

    Denoting that a package is covered by a particular license + is done by placing the license in + pkgsrc/licenses and setting the + LICENSE variable to a string identifying the + license, e.g. in graphics/xv:

    -    LICENSE=        xv-license
-
    -

    - When trying to build, the user will get a notice that the - package is covered by a license which has not been - accepted:

    + LICENSE= xv-license + +

    When trying to build, the user will get a notice that the + package is covered by a license which has not been + accepted:

    -    % make
-    ===> xv-3.10anb9 has an unacceptable license: xv-license.
-    ===>     To view the license, enter "/usr/bin/make show-license".
-    ===>     To indicate acceptance, add this line to your /etc/mk.conf:
-    ===>     ACCEPTABLE_LICENSES+=xv-license
-    *** Error code 1
-
    + % make + ===> xv-3.10anb9 has an unacceptable license: xv-license. + ===> To view the license, enter "/usr/bin/make show-license". + ===> To indicate acceptance, add this line to your /etc/mk.conf: + ===> ACCEPTABLE_LICENSES+=xv-license + *** Error code 1 +

    The license can be viewed with make - show-license, and if it is considered appropriate, - the line printed above can be added to - /etc/mk.conf to indicate acceptance of - the particular license:

    + show-license, and if it is considered appropriate, + the line printed above can be added to + /etc/mk.conf to indicate acceptance of + the particular license:

    -    ACCEPTABLE_LICENSES+=xv-license
-
    + ACCEPTABLE_LICENSES+=xv-license +

    When adding a package with a new license, the license - text should be added to pkgsrc/licenses - for displaying. A list of known licenses can be seen in this - directory as well as by looking at the list of (commented - out) ACCEPTABLE_LICENSES variable - settings in - pkgsrc/mk/defaults/mk.conf.

    + text should be added to pkgsrc/licenses + for displaying. A list of known licenses can be seen in this + directory as well as by looking at the list of (commented + out) ACCEPTABLE_LICENSES variable + settings in + pkgsrc/mk/defaults/mk.conf.

    The use of LICENSE=shareware, - LICENSE=no-commercial-use, and similar - language is deprecated because it does not crisply refer to - a particular license text. Another problem with such usage - is that it does not enable a user to denote acceptance of - the license for a single package without accepting the same - license text for another package. In particular, this can - be inappropriate when e.g. one accepts a particular license to - indicate to pkgsrc that a fee has been paid.

    + LICENSE=no-commercial-use, and similar + language is deprecated because it does not crisply refer to + a particular license text. Another problem with such usage + is that it does not enable a user to denote acceptance of + the license for a single package without accepting the same + license text for another package. In particular, this can + be inappropriate when e.g. one accepts a particular license to + indicate to pkgsrc that a fee has been paid.

    17.1.5. Restricted packages

    Some licenses restrict how software may be re-distributed. - In order to satisfy these restrictions, the package system - defines five make variables that can be set to note these - restrictions:

    + In order to satisfy these restrictions, the package system + defines five make variables that can be set to note these + restrictions:

    • RESTRICTED

      This variable should be set whenever a restriction - exists (regardless of its kind). Set this variable to a - string containing the reason for the restriction.

      + exists (regardless of its kind). Set this variable to a + string containing the reason for the restriction.

    • NO_BIN_ON_CDROM

      Binaries may not be placed on CD-ROM. Set this - variable to ${RESTRICTED} whenever a - binary package may not be included on a CD-ROM.

      + variable to ${RESTRICTED} whenever a + binary package may not be included on a CD-ROM.

    • NO_BIN_ON_FTP

      Binaries may not be placed on an FTP server. Set - this variable to ${RESTRICTED} - whenever a binary package may not not be made available - on the Internet.

      + this variable to ${RESTRICTED} + whenever a binary package may not not be made available + on the Internet.

    • NO_SRC_ON_CDROM

      Distfiles may not be placed on CD-ROM. Set this - variable to ${RESTRICTED} if - re-distribution of the source code or other distfile(s) is - not allowed on CD-ROMs.

      + variable to ${RESTRICTED} if + re-distribution of the source code or other distfile(s) is + not allowed on CD-ROMs.

    • NO_SRC_ON_FTP

      Distfiles may not be placed on FTP. Set this variable - to ${RESTRICTED} if re-distribution of - the source code or other distfile(s) via the Internet is not - allowed.

      + to ${RESTRICTED} if re-distribution of + the source code or other distfile(s) via the Internet is not + allowed. If this variable is not set, the distfile(s) will + be mirrored on ftp.NetBSD.org.

    Please note that the use of NO_PACKAGE, - IGNORE, NO_CDROM, or other - generic make variables to denote restrictions is deprecated, - because they unconditionally prevent users from generating - binary packages!

    + IGNORE, NO_CDROM, or other + generic make variables to denote restrictions is deprecated, + because they unconditionally prevent users from generating + binary packages!

    17.1.6. Handling dependencies

    Your package may depend on some other package being present - - and there are various ways of expressing this - dependency. pkgsrc supports the BUILD_DEPENDS - and DEPENDS definitions, the - USE_TOOLS definition, as well as - dependencies via buildlink3.mk, which is - the preferred way to handle dependencies, and which uses the - variables named above. See Chapter 12, Buildlink methodology for more - information.

    + - and there are various ways of expressing this + dependency. pkgsrc supports the BUILD_DEPENDS + and DEPENDS definitions, the + USE_TOOLS definition, as well as + dependencies via buildlink3.mk, which is + the preferred way to handle dependencies, and which uses the + variables named above. See Chapter 12, Buildlink methodology for more + information.

    The basic difference between the two variables is as - follows: The DEPENDS definition registers - that pre-requisite in the binary package so it will be pulled in - when the binary package is later installed, whilst the - BUILD_DEPENDS definition does not, marking a - dependency that is only needed for building the package. -

    + follows: The DEPENDS definition registers + that pre-requisite in the binary package so it will be pulled in + when the binary package is later installed, whilst the + BUILD_DEPENDS definition does not, marking a + dependency that is only needed for building the package.

    This means that if you only need a package present whilst - you are building, it should be noted as a - BUILD_DEPENDS.

    + you are building, it should be noted as a + BUILD_DEPENDS.

    The format for a BUILD_DEPENDS and a - DEPENDS definition is:

    + DEPENDS definition is:

    -    <pre-req-package-name>:../../<category>/<pre-req-package>
-
    + <pre-req-package-name>:../../<category>/<pre-req-package> +

    Please note that the “pre-req-package-name” - may include any of the wildcard version numbers recognized by - pkg_info(1).

    + may include any of the wildcard version numbers recognized by + pkg_info(1).

    1. If your package needs another package's binaries or - libraries to build or run, and if that package has a - buildlink3.mk file available, use it: -

      + libraries to build or run, and if that package has a + buildlink3.mk file available, use it:

      -    .include "../../graphics/jpeg/buildlink3.mk"
-
      + .include "../../graphics/jpeg/buildlink3.mk" +

    2. If your package needs to use another package to build - itself and there is no buildlink3.mk - file available, use the BUILD_DEPENDS - definition:

      + itself and there is no buildlink3.mk + file available, use the BUILD_DEPENDS + definition:

      -    BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
-
      + BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf +

    3. If your package needs a library with which to link and again there is no buildlink3.mk file - available, this is specified using the - DEPENDS definition. For example:

      + available, this is specified using the + DEPENDS definition. For example:

      -    DEPENDS+=       xpm-3.4j:../../graphics/xpm
-
      + DEPENDS+= xpm-3.4j:../../graphics/xpm +

      You can also use wildcards in package dependences:

      -    DEPENDS+=       xpm-[0-9]*:../../graphics/xpm
-
      + DEPENDS+= xpm-[0-9]*:../../graphics/xpm +

      Note that such wildcard dependencies are retained when - creating binary packages. The dependency is checked when - installing the binary package and any package which matches - the pattern will be used. Wildcard dependencies should be - used with care.

      + creating binary packages. The dependency is checked when + installing the binary package and any package which matches + the pattern will be used. Wildcard dependencies should be + used with care.

      The “-[0-9]*” should be used instead of - “-*” to avoid potentially ambiguous matches - such as “tk-postgresql” matching a - “tk-*” DEPENDS.

      + “-*” to avoid potentially ambiguous matches + such as “tk-postgresql” matching a + “tk-*” DEPENDS.

      Wildcards can also be used to specify that a package - will only build against a certain minimum version of a - pre-requisite:

      + will only build against a certain minimum version of a + pre-requisite:

      -    DEPENDS+=       tiff>=3.5.4:../../graphics/tiff
-
      + DEPENDS+= tiff>=3.5.4:../../graphics/tiff +

      This means that the package will build against version - 3.5.4 of the tiff library or newer. Such a dependency may - be warranted if, for example, the API of the library has - changed with version 3.5.4 and a package would not compile - against an earlier version of tiff.

      + 3.5.4 of the tiff library or newer. Such a dependency may + be warranted if, for example, the API of the library has + changed with version 3.5.4 and a package would not compile + against an earlier version of tiff.

      Please note that such dependencies should only be - updated if a package requires a newer pre-requisite, but - not to denote recommendations such as - ABI changes that do not prevent a package from building - correctly. Such recommendations can be expressed using - ABI_DEPENDS:

      + updated if a package requires a newer pre-requisite, but + not to denote recommendations such as + ABI changes that do not prevent a package from building + correctly. Such recommendations can be expressed using + ABI_DEPENDS:

      -    ABI_DEPENDS+=   tiff>=3.6.1:../../graphics/tiff
-
      + ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff +

      In addition to the above DEPENDS - line, this denotes that while a package will build against - tiff>=3.5.4, at least version 3.6.1 is recommended. - ABI_DEPENDS entries will be turned into - dependencies unless explicitly ignored (in which case a - warning will be printed).

      + line, this denotes that while a package will build against + tiff>=3.5.4, at least version 3.6.1 is recommended. + ABI_DEPENDS entries will be turned into + dependencies unless explicitly ignored (in which case a + warning will be printed).

      To ignore these ABI dependency recommendations and just - use the required DEPENDS, set - USE_ABI_DEPENDS=NO. This may make - it easier and faster to update packages built using pkgsrc, - since older compatible dependencies can continue to be - used. This is useful for people who watch their rebuilds - very carefully; it is not very good as a general-purpose - hammer. If you use it, you need to be mindful of possible - ABI changes, including those from the underlying OS. -

      + use the required DEPENDS, set + USE_ABI_DEPENDS=NO. This may make + it easier and faster to update packages built using pkgsrc, + since older compatible dependencies can continue to be + used. This is useful for people who watch their rebuilds + very carefully; it is not very good as a general-purpose + hammer. If you use it, you need to be mindful of possible + ABI changes, including those from the underlying OS.

      Packages that are built with recommendations ignored - may not be uploaded to ftp.NetBSD.org by developers and - should not be used across different systems that may have - different versions of binary packages installed.

      + may not be uploaded to ftp.NetBSD.org by developers and + should not be used across different systems that may have + different versions of binary packages installed.

      For security fixes, please update the package - vulnerabilities file. See Section 17.1.10, “Handling packages with security problems” for more - information.

      + vulnerabilities file. See Section 17.1.10, “Handling packages with security problems” for more + information.

    4. If your package needs some executable to be able to run - correctly and if there's no - buildlink3.mk file, this is specified - using the DEPENDS variable. The - print/lyx package needs to - be able to execute the latex binary from the teTeX package - when it runs, and that is specified:

      + correctly and if there's no + buildlink3.mk file, this is specified + using the DEPENDS variable. The + print/lyx package needs to + be able to execute the latex binary from the teTeX package + when it runs, and that is specified:

      -    DEPENDS+=        teTeX-[0-9]*:../../print/teTeX
-
      + DEPENDS+= teTeX-[0-9]*:../../print/teTeX +

      The comment about wildcard dependencies from previous - paragraph applies here, too.

      + paragraph applies here, too.

    If your package needs files from another package to build, - add the relevant distribution files to - DISTFILES, so they will be extracted - automatically. See the print/ghostscript package for an example. - (It relies on the jpeg sources being present in source form - during the build.)

    + add the relevant distribution files to + DISTFILES, so they will be extracted + automatically. See the print/ghostscript package for an example. + (It relies on the jpeg sources being present in source form + during the build.)

    Please also note the BUILD_USES_MSGFMT - and BUILD_USES_GETTEXT_M4 definitions, which - are provided as convenience definitions. The former works out - whether msgfmt(1) is part of the base system, and, if it isn't, - installs the devel/gettext package. - The latter adds a build dependency on either an installed - version of an older gettext package, or if it isn't, installs the - devel/gettext-m4 package.

    + and BUILD_USES_GETTEXT_M4 definitions, which + are provided as convenience definitions. The former works out + whether msgfmt(1) is part of the base system, and, if it isn't, + installs the devel/gettext package. + The latter adds a build dependency on either an installed + version of an older gettext package, or if it isn't, installs the + devel/gettext-m4 package.

    17.1.7. Handling conflicts with other packages

    Your package may conflict with other packages a user might - already have installed on his system, e.g. if your package - installs the same set of files like another package in our - pkgsrc tree.

    + already have installed on his system, e.g. if your package + installs the same set of files like another package in our + pkgsrc tree.

    In this case you can set CONFLICTS to a - space-separated list of packages (including version string) your - package conflicts with.

    + space-separated list of packages (including version string) your + package conflicts with.

    For example, x11/Xaw3d - and x11/Xaw-Xpm - install the same shared library, thus you set in - pkgsrc/x11/Xaw3d/Makefile:

    + and x11/Xaw-Xpm + install the same shared library, thus you set in + pkgsrc/x11/Xaw3d/Makefile:

    -    CONFLICTS=      Xaw-Xpm-[0-9]*
-
    -

    and in pkgsrc/x11/Xaw-Xpm/Makefile: -

    + CONFLICTS= Xaw-Xpm-[0-9]* + +

    and in pkgsrc/x11/Xaw-Xpm/Makefile:

    -    CONFLICTS=      Xaw3d-[0-9]*
-
    + CONFLICTS= Xaw3d-[0-9]* +

    Packages will automatically conflict with other packages - with the name prefix and a different version - string. “Xaw3d-1.5” e.g. will automatically - conflict with the older version “Xaw3d-1.3”. -

    + with the name prefix and a different version + string. “Xaw3d-1.5” e.g. will automatically + conflict with the older version “Xaw3d-1.3”.

    17.1.8. Packages that cannot or should not be built

    There are several reasons why a package might be - instructed to not build under certain circumstances. If the - package builds and runs on most platforms, the exceptions - should be noted with NOT_FOR_PLATFORM. If - the package builds and runs on a small handful of platforms, - set ONLY_FOR_PLATFORM instead. - Both ONLY_FOR_PLATFORM and - NOT_FOR_PLATFORM are OS triples - (OS-version-platform) that can use glob-style - wildcards.

    + instructed to not build under certain circumstances. If the + package builds and runs on most platforms, the exceptions + should be noted with NOT_FOR_PLATFORM. If + the package builds and runs on a small handful of platforms, + set ONLY_FOR_PLATFORM instead. + Both ONLY_FOR_PLATFORM and + NOT_FOR_PLATFORM are OS triples + (OS-version-platform) that can use glob-style + wildcards.

    If the package should be skipped (for example, because it - provides functionality already provided by the system), set - PKG_SKIP_REASON to a descriptive message. - If the package should fail because some preconditions are not - met, set PKG_FAIL_REASON to a descriptive - message.

    + provides functionality already provided by the system), set + PKG_SKIP_REASON to a descriptive message. + If the package should fail because some preconditions are not + met, set PKG_FAIL_REASON to a descriptive + message.

    17.1.9. Packages which should not be deleted, once installed

    To ensure that a package may not be deleted, once it has been - installed, the PKG_PRESERVE definition should - be set in the package Makefile. This will be carried into any - binary package that is made from this pkgsrc entry. A - “preserved” package will - not be deleted using pkg_delete(1) unless the - “-f” option is used.

    + installed, the PKG_PRESERVE definition should + be set in the package Makefile. This will be carried into any + binary package that is made from this pkgsrc entry. A + “preserved” package will + not be deleted using pkg_delete(1) unless the + “-f” option is used.

    17.1.10. Handling packages with security problems

    When a vulnerability is found, this should be noted in - localsrc/security/advisories/pkg-vulnerabilities, - and after committing that file, use make upload - in the same directory to update the file on ftp.NetBSD.org.

    + localsrc/security/advisories/pkg-vulnerabilities, + and after committing that file, use make upload + in the same directory to update the file on ftp.NetBSD.org.

    After fixing the vulnerability by a patch, its - PKGREVISION should be increased (this - is of course not necessary if the problem is fixed by using - a newer release of the software).

    + PKGREVISION should be increased (this + is of course not necessary if the problem is fixed by using + a newer release of the software).

    Also, if the fix should be applied to the stable pkgsrc - branch, be sure to submit a pullup request!

    + branch, be sure to submit a pullup request!

    Binary packages already on ftp.NetBSD.org will be handled - semi-automatically by a weekly cron job.

    + semi-automatically by a weekly cron job.

    17.1.11. How to handle incrementing versions when fixing an existing package

    When making fixes to an existing package it can be useful - to change the version number in PKGNAME. To - avoid conflicting with future versions by the original author, a - “nb1”, “nb2”, ... suffix can be used - on package versions by setting PKGREVISION=1 - (2, ...). The “nb” is treated like a - “.” by the pkg tools. e.g.

    + to change the version number in PKGNAME. To + avoid conflicting with future versions by the original author, a + “nb1”, “nb2”, ... suffix can be used + on package versions by setting PKGREVISION=1 + (2, ...). The “nb” is treated like a + “.” by the package tools. e.g.

    -    DISTNAME=       foo-17.42
-    PKGREVISION=    9
-
    + DISTNAME= foo-17.42 + PKGREVISION= 9 +

    will result in a PKGNAME of - “foo-17.42nb9”.

    + “foo-17.42nb9”. If you want to use the original + value of PKGNAME without the “nbX” + suffix, e.g. for setting DIST_SUBDIR, use + PKGNAME_NOREV.

    When a new release of the package is released, the - PKGREVISION should be removed, e.g. on a new - minor release of the above package, things should be like:

    + PKGREVISION should be removed, e.g. on a new + minor release of the above package, things should be like:

    -    DISTNAME=       foo-17.43
-
    -

    PKGREVISION should be incremented for any non-trivial change in the - resulting binary package. Without a PKGREVISION bump, someone with - the previous version installed has no way of knowing that their - package is out of date. Thus, changes without increasing PKGREVISION - are essentially labeled "this is so trivial that no reasonable person - would want to upgrade", and this is the rough test for when increasing - PKGREVISION is appropriate. Examples of changes that do not merit - increasing PKGREVISION are:

    + DISTNAME= foo-17.43 + +

    PKGREVISION should be incremented for any + non-trivial change in the resulting binary package. Without a + PKGREVISION bump, someone with the previous + version installed has no way of knowing that their package is out + of date. Thus, changes without increasing + PKGREVISION are essentially labeled "this is so + trivial that no reasonable person would want to upgrade", and this + is the rough test for when increasing + PKGREVISION is appropriate. Examples of + changes that do not merit increasing + PKGREVISION are:

    -Changing HOMEPAGE, MAINTAINER, or comments in Makefile.
-Changing build variables if the resulting binary package is the same.
-Changing DESCR.
-Adding PKG_OPTIONS if the default options don't change.
-
    -

    Examples of changes that do merit an increase to PKGREVISION - include:

    + Changing HOMEPAGE, MAINTAINER, + or comments in Makefile. + Changing build variables if the resulting binary package is the same. + Changing DESCR. + Adding PKG_OPTIONS if the default options don't change. + +

    Examples of changes that do merit an increase to + PKGREVISION include:

    -Security fixes
-Changes or additions to a patch file
-Changes to the PLIST
-
    + Security fixes + Changes or additions to a patch file + Changes to the PLIST +

    PKGREVISION must also be incremented when dependencies have ABI changes.

    @@ -7220,60 +7210,60 @@ Changes to the PLIST

    17.1.12. Substituting variable text in the package files (the SUBST framework)

    When you want to replace the same text in multiple files - or when the replacement text varies, patches alone cannot help. - This is where the SUBST framework comes in. It provides an - easy-to-use interface for replacing text in files. - Example:

    + or when the replacement text varies, patches alone cannot help. + This is where the SUBST framework comes in. It provides an + easy-to-use interface for replacing text in files. + Example:

    -    SUBST_CLASSES+=                 fix-paths
-    SUBST_STAGE.fix-paths=          pre-configure
-    SUBST_MESSAGE.fix-paths=        Fixing absolute paths.
-    SUBST_FILES.fix-paths=          src/*.c
-    SUBST_FILES.fix-paths+=         scripts/*.sh
-    SUBST_SED.fix-paths=            -e 's,"/usr/local,"${PREFIX},g'
-    SUBST_SED.fix-paths+=           -e 's,"/var/log,"${VARBASE}/log,g'
-
    + SUBST_CLASSES+= fix-paths + SUBST_STAGE.fix-paths= pre-configure + SUBST_MESSAGE.fix-paths= Fixing absolute paths. + SUBST_FILES.fix-paths= src/*.c + SUBST_FILES.fix-paths+= scripts/*.sh + SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g' + SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g' +

    SUBST_CLASSES is a list of identifiers - that are used to identify the different SUBST blocks that are - defined. The SUBST framework is heavily used by pkgsrc, so it is - important to always use the += operator with - this variable. Otherwise some substitutions may be - skipped.

    + that are used to identify the different SUBST blocks that are + defined. The SUBST framework is heavily used by pkgsrc, so it is + important to always use the += operator with + this variable. Otherwise some substitutions may be + skipped.

    The remaining variables of each SUBST block are - parameterized with the identifier from the first line - (fix-paths in this case.) They can be seen as - parameters to a function call.

    + parameterized with the identifier from the first line + (fix-paths in this case.) They can be seen as + parameters to a function call.

    SUBST_STAGE.* specifies the stage at - which the replacement will take place. All combinations of - pre-, do- and - post- together with a phase name are - possible, though only few are actually used. Most commonly used - are post-patch and - pre-configure. Of these two, - pre-configure should be preferred because - then it is possible to run bmake patch and - have the state after applying the patches but before making any - other changes. This is especially useful when you are debugging - a package in order to create new patches for it. Similarly, - post-build is preferred over - pre-install, because the install phase should - generally be kept as simple as possible. When you use - post-build, you have the same files in the - working directory that will be installed later, so you can check - if the substitution has succeeded.

    + which the replacement will take place. All combinations of + pre-, do- and + post- together with a phase name are + possible, though only few are actually used. Most commonly used + are post-patch and + pre-configure. Of these two, + pre-configure should be preferred because + then it is possible to run bmake patch and + have the state after applying the patches but before making any + other changes. This is especially useful when you are debugging + a package in order to create new patches for it. Similarly, + post-build is preferred over + pre-install, because the install phase should + generally be kept as simple as possible. When you use + post-build, you have the same files in the + working directory that will be installed later, so you can check + if the substitution has succeeded.

    SUBST_MESSAGE.* is an optional text - that is printed just before the substitution is done.

    + that is printed just before the substitution is done.

    SUBST_FILES.* is the list of shell - globbing patterns that specifies the files in which the - substitution will take place. The patterns are interpreted - relatively to the WRKSRC directory.

    + globbing patterns that specifies the files in which the + substitution will take place. The patterns are interpreted + relatively to the WRKSRC directory.

    SUBST_SED.* is a list of arguments to - sed(1) that specify the actual substitution. Every sed - command should be prefixed with -e, so that - all SUBST blocks look uniform.

    + sed(1) that specify the actual substitution. Every sed + command should be prefixed with -e, so that + all SUBST blocks look uniform.

    There are some more variables, but they are so seldomly - used that they are only documented in the - mk/subst.mk file.

    + used that they are only documented in the + mk/subst.mk file.

    @@ -7283,46 +7273,49 @@ Changes to the PLIST

    17.2.1. Packages whose distfiles aren't available for plain downloading

    If you need to download from a dynamic URL you can set - DYNAMIC_MASTER_SITES and a make - fetch will call files/getsite.sh - with the name of each file to download as an argument, expecting - it to output the URL of the directory from which to download - it. graphics/ns-cult3d is an - example of this usage.

    + DYNAMIC_MASTER_SITES and a make + fetch will call files/getsite.sh + with the name of each file to download as an argument, expecting + it to output the URL of the directory from which to download + it. graphics/ns-cult3d is an + example of this usage.

    If the download can't be automated, because the user must - submit personal information to apply for a password, or must pay - for the source, or whatever, you can set - FETCH_MESSAGE to a list of lines that are - displayed to the user before aborting the build. Example:

    + submit personal information to apply for a password, or must pay + for the source, or whatever, you can set + FETCH_MESSAGE to a list of lines that are + displayed to the user before aborting the build. Example:

    -    FETCH_MESSAGE=  "Please download the files"
-    FETCH_MESSAGE+= "    "${DISTFILES:Q}
-    FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
-
    + FETCH_MESSAGE= "Please download the files" + FETCH_MESSAGE+= " "${DISTFILES:Q} + FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"." +

    17.2.2. How to handle modified distfiles with the 'old' name

    Sometimes authors of a software package make some - modifications after the software was released, and they put up a - new distfile without changing the package's version number. If a - package is already in pkgsrc at that time, the checksum will - no longer match. The contents of the new distfile should be - compared against the old one before changing anything, to make - sure the distfile was really updated on purpose, and that - no trojan horse or so crept in. - Then, the correct way to work around this is to - set DIST_SUBDIR to a unique directory name, - usually based on PKGNAME_NOREV. In case this - happens more often, PKGNAME can be used (thus - including the nbX suffix) or a date stamp - can be appended, like ${PKGNAME_NOREV}-YYYYMMDD. - Do not forget regenerating the distinfo file - after that, since it contains the DIST_SUBDIR - path in the filenames. - Furthermore, a mail to the package's authors seems appropriate - telling them that changing distfiles after releases without - changing the file names is not good practice.

    + modifications after the software was released, and they put up a + new distfile without changing the package's version number. If a + package is already in pkgsrc at that time, the checksum will + no longer match. The contents of the new distfile should be + compared against the old one before changing anything, to make + sure the distfile was really updated on purpose, and that + no trojan horse or so crept in. + Then, the correct way to work around this is to + set DIST_SUBDIR to a unique directory name, + usually based on PKGNAME_NOREV. All + DISTFILES and + PATCHFILES for this package will be put in that + subdirectory of the local distfiles directory. In case this + happens more often, PKGNAME can be used (thus + including the nbX suffix) or a date stamp + can be appended, like ${PKGNAME_NOREV}-YYYYMMDD. + Do not forget regenerating the distinfo file + after that, since it contains the DIST_SUBDIR + path in the filenames. + Furthermore, a mail to the package's authors seems appropriate + telling them that changing distfiles after releases without + changing the file names is not good practice.

    @@ -7332,209 +7325,278 @@ Changes to the PLIST

    17.3.1. Shared libraries - libtool

    pkgsrc supports many different machines, with different - object formats like a.out and ELF, and varying abilities to do - shared library and dynamic loading at all. To accompany this, - varying commands and options have to be passed to the - compiler, linker, etc. to get the Right Thing, which can be - pretty annoying especially if you don't have all the machines - at your hand to test things. The - devel/libtool pkg - can help here, as it just “knows” how to build - both static and dynamic libraries from a set of source files, - thus being platform-independent.

    -

    Here's how to use libtool in a pkg in seven simple - steps:

    + object formats like a.out and ELF, and varying abilities to do + shared library and dynamic loading at all. To accompany this, + varying commands and options have to be passed to the + compiler, linker, etc. to get the Right Thing, which can be + pretty annoying especially if you don't have all the machines + at your hand to test things. The + devel/libtool pkg + can help here, as it just “knows” how to build + both static and dynamic libraries from a set of source files, + thus being platform-independent.

    +

    Here's how to use libtool in a package in seven simple + steps:

    1. Add USE_LIBTOOL=yes to the package - Makefile.

      2. + Makefile.

    2. For library objects, use “${LIBTOOL} --mode=compile - ${CC}” in place of “${CC}”. You could even - add it to the definition of CC, if only - libraries are being built in a given Makefile. This one command - will build both PIC and non-PIC library objects, so you need not - have separate shared and non-shared library rules.

      3. + ${CC}” in place of “${CC}”. You could even + add it to the definition of CC, if only + libraries are being built in a given Makefile. This one command + will build both PIC and non-PIC library objects, so you need not + have separate shared and non-shared library rules.

    3. For the linking of the library, remove any - “ar”, “ranlib”, and “ld - -Bshareable” commands, and instead use:

      + “ar”, “ranlib”, and “ld + -Bshareable” commands, and instead use:

      -    ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} \
-        -rpath ${PREFIX}/lib -version-info major:minor
-
      + ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} \ + -rpath ${PREFIX}/lib -version-info major:minor +

      Note that the library is changed to have a - .la extension, and the objects are - changed to have a .lo - extension. Change OBJS as - necessary. This automatically creates all of the - .a, - .so.major.minor, and ELF symlinks (if - necessary) in the build directory. Be sure to include - “-version-info”, especially when major and - minor are zero, as libtool will otherwise strip off the - shared library version.

      + .la extension, and the objects are + changed to have a .lo + extension. Change OBJS as + necessary. This automatically creates all of the + .a, + .so.major.minor, and ELF symlinks (if + necessary) in the build directory. Be sure to include + “-version-info”, especially when major and + minor are zero, as libtool will otherwise strip off the + shared library version.

      From the libtool manual:

      -    So, libtool library versions are described by three integers:
+	  So, libtool library versions are described by three integers:
 
-    CURRENT
-        The most recent interface number that this library implements.
+	  CURRENT
+	  The most recent interface number that this library implements.
 
-    REVISION
-        The implementation number of the CURRENT interface.
+	  REVISION
+	  The implementation number of the CURRENT interface.
 
-    AGE
-        The difference between the newest and oldest interfaces that
-        this library implements.  In other words, the library implements
-        all the interface numbers in the range from number `CURRENT -
-        AGE' to `CURRENT'.
+	  AGE
+	  The difference between the newest and oldest interfaces that
+	  this library implements.  In other words, the library implements
+	  all the interface numbers in the range from number `CURRENT -
+	  AGE' to `CURRENT'.
 
-    If two libraries have identical CURRENT and AGE numbers, then the
-    dynamic linker chooses the library with the greater REVISION number.
-
      + If two libraries have identical CURRENT and AGE numbers, then the + dynamic linker chooses the library with the greater REVISION number. +

      The “-release” option will produce - different results for a.out and ELF (excluding symlinks) - in only one case. An ELF library of the form - “libfoo-release.so.x.y” - will have a symlink of - “libfoo.so.x.y” - on an a.out platform. This is handled - automatically.

      + different results for a.out and ELF (excluding symlinks) + in only one case. An ELF library of the form + “libfoo-release.so.x.y” + will have a symlink of + “libfoo.so.x.y” + on an a.out platform. This is handled + automatically.

      The “-rpath argument” is the install - directory of the library being built.

      + directory of the library being built.

      In the PLIST, include only the - .la file, the other files will be - added automatically.

      + .la file, the other files will be + added automatically.

    4. When linking shared object (.so) - files, i.e. files that are loaded via dlopen(3), NOT - shared libraries, use “-module - -avoid-version” to prevent them getting version - tacked on.

      + files, i.e. files that are loaded via dlopen(3), NOT + shared libraries, use “-module + -avoid-version” to prevent them getting version + tacked on.

      The PLIST file gets the - foo.so entry.

      + foo.so entry.

    5. When linking programs that depend on these libraries - before they are installed, preface - the cc(1) or ld(1) line with “${LIBTOOL} - --mode=link”, and it will find the correct - libraries (static or shared), but please be aware that - libtool will not allow you to specify a relative path in - -L (such as “-L../somelib”), because it - expects you to change that argument to be the - .la file. e.g.

      + before they are installed, preface + the cc(1) or ld(1) line with “${LIBTOOL} + --mode=link”, and it will find the correct + libraries (static or shared), but please be aware that + libtool will not allow you to specify a relative path in + -L (such as “-L../somelib”), because it + expects you to change that argument to be the + .la file. e.g.

      -    ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
-
      + ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib +

      should be changed to:

      -    ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
-
      + ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la +

      and it will do the right thing with the libraries.

    6. When installing libraries, preface the install(1) - or cp(1) command with “${LIBTOOL} - --mode=install”, and change the library name to - .la. e.g.

      + or cp(1) command with “${LIBTOOL} + --mode=install”, and change the library name to + .la. e.g.

      -    ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
-
      + ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib +

      This will install the static .a, - shared library, any needed symlinks, and run - ldconfig(8).

      + shared library, any needed symlinks, and run + ldconfig(8).

    7. In your PLIST, include only - the .la - file (this is a change from previous behaviour).

      8. + the .la + file (this is a change from previous behaviour).

    17.3.2. Using libtool on GNU packages that already support libtool

    Add USE_LIBTOOL=yes to the - package Makefile. This will override the package's own libtool - in most cases. For older libtool using packages, libtool is - made by ltconfig script during the do-configure step; you can - check the libtool script location by doing make - configure; find work*/ -name libtool.

    + package Makefile. This will override the package's own libtool + in most cases. For older libtool using packages, libtool is + made by ltconfig script during the do-configure step; you can + check the libtool script location by doing make + configure; find work*/ -name libtool.

    LIBTOOL_OVERRIDE specifies which libtool - scripts, relative to WRKSRC, to override. By - default, it is set to “libtool */libtool - */*/libtool”. If this does not match the location of the - package's libtool script(s), set it as appropriate.

    + scripts, relative to WRKSRC, to override. By + default, it is set to “libtool */libtool + */*/libtool”. If this does not match the location of the + package's libtool script(s), set it as appropriate.

    If you do not need *.a static - libraries built and installed, then use - SHLIBTOOL_OVERRIDE instead.

    + libraries built and installed, then use + SHLIBTOOL_OVERRIDE instead.

    If your package makes use of the platform-independent library - for loading dynamic shared objects, that comes with libtool - (libltdl), you should include devel/libltdl/buildlink3.mk.

    -

    Some packages use libtool incorrectly so that the package may not work or - build in some circumstances. Some of the more common errors are:

    + for loading dynamic shared objects, that comes with libtool + (libltdl), you should include devel/libltdl/buildlink3.mk.

    +

    Some packages use libtool incorrectly so that the package + may not work or build in some circumstances. Some of the more + common errors are:

    • The inclusion of a shared object (-module) as a dependent library in an - executable or library. This in itself isn't a problem if one of two things - has been done:

      + executable or library. This in itself isn't a problem if one of two things + has been done:

      1. The shared object is named correctly, i.e. - libfoo.la, not - foo.la

        2. + libfoo.la, not + foo.la

      2. The -dlopen option is used when linking an executable.

    • The use of libltdl without the correct calls to initialisation routines. - The function lt_dlinit() should be called and the macro - LTDL_SET_PRELOADED_SYMBOLS included in - executables.

      • + The function lt_dlinit() should be called and the macro + LTDL_SET_PRELOADED_SYMBOLS included in + executables.

    17.3.3. GNU Autoconf/Automake

    If a package needs GNU autoconf or automake to be executed - to regenerate the configure script and Makefile.in makefile - templates, then they should be executed in a pre-configure - target.

    + to regenerate the configure script and Makefile.in makefile + templates, then they should be executed in a pre-configure + target.

    For packages that need only autoconf:

    -    AUTOCONF_REQD=  2.50            # if default version is not good enough
-    USE_TOOLS+=     autoconf        # use "autoconf213" for autoconf-2.13
-    ...
+      AUTOCONF_REQD=  2.50            # if default version is not good enough
+      USE_TOOLS+=     autoconf        # use "autoconf213" for autoconf-2.13
+      ...
 
-    pre-configure:
-            cd ${WRKSRC}; autoconf
+      pre-configure:
+      cd ${WRKSRC}; autoconf
 
-    ...
-
    + ... +

    and for packages that need automake and autoconf:

    -    AUTOMAKE_REQD=  1.7.1           # if default version is not good enough
-    USE_TOOLS+=     automake        # use "automake14" for automake-1.4
-    ...
+      AUTOMAKE_REQD=  1.7.1           # if default version is not good enough
+      USE_TOOLS+=     automake        # use "automake14" for automake-1.4
+      ...
 
-    pre-configure:
-            cd ${WRKSRC};                          \
-            aclocal; autoheader;                   \
-            automake -a --foreign -i; autoconf
+      pre-configure:
+      cd ${WRKSRC};                          \
+      aclocal; autoheader;                   \
+      automake -a --foreign -i; autoconf
 
-    ...
-
    + ... +

    Packages which use GNU Automake will almost certainly - require GNU Make.

    + require GNU Make.

    There are times when the configure process makes - additional changes to the generated files, which then causes - the build process to try to re-execute the automake sequence. - This is prevented by touching various files in the configure - stage. If this causes problems with your package you can set - AUTOMAKE_OVERRIDE=NO in the package - Makefile.

    + additional changes to the generated files, which then causes + the build process to try to re-execute the automake sequence. + This is prevented by touching various files in the configure + stage. If this causes problems with your package you can set + AUTOMAKE_OVERRIDE=NO in the package + Makefile.

    +
    + +
    +

    +17.4. Programming languages

    +
    +

    +17.4.1. C, C++, and Fortran

    +

    Compilers for the C, C++, and Fortran languages comes with + the NetBSD base system. By default, pkgsrc assumes that a package + is written in C and will hide all other compilers (via the wrapper + framework, see Chapter 12, Buildlink methodology).

    +

    To declare which language's compiler a package needs, set + the USE_LANGUAGES variable. Allowed values + currently are “c”, “c++”, and + “fortran” (and any combination). The default is + “c”. Packages using GNU configure scripts, even if + written in C++, usually need a C compiler for the configure + phase.

    +
    +
    +

    +17.4.2. Java

    +

    If a program is written in Java, use the Java framework in + pkgsrc. The package must include + ../../mk/java-vm.mk. This Makefile fragment + provides the following variables:

    +
      +

    • USE_JAVA defines if a build + dependency on the JDK is added. If + USE_JAVA is set to “run”, then + there is only a runtime dependency on the JDK. The default is + “yes”, which also adds a build dependency on the + JDK.

      • +

    • Set USE_JAVA2 to declare that + a package needs a Java2 implementation. The supported values + are “yes”, “1.4”, and + “1.5”. “yes” accepts any Java2 + implementation, “1.4” insists on versions 1.4 or + above, and “1.5” only accepts versions 1.5 or + above. This variable is not set by default.

      • +
    +
    +
    +

    +17.4.3. Packages containing perl scripts

    +

    If your package contains interpreted perl scripts, add + “perl” to the USE_TOOLS variable + and set REPLACE_PERL to ensure that the proper + interpreter path is set. REPLACE_PERL should + contain a list of scripts, relative to WRKSRC, + that you want adjusted. Every occurrence of + */bin/perl will be replaced with the full + path to the perl executable.

    +

    If a particular version of perl is needed, set the + PERL5_REQD variable to the version number. The + default is “5.0”.

    +

    See Section 17.6.5, “Packages installing perl modules” for information + about handling perl modules.

    +
    +
    +

    +17.4.4. Other programming languages

    +

    Currently, there is no special handling for other languages + in pkgsrc. If a compiler package provides a + buildlink3.mk file, include that, otherwise + just add a (build) dependency on the appropriate compiler + package.

    -17.4. Fixing problems in the build phase

    +17.5. Fixing problems in the build phase

    The most common failures when building a package are that some platforms do not provide certain header files, functions or libraries, or they provide the functions in a library that the @@ -7543,7 +7605,7 @@ Changes to the PLIST use the missing functions or provides a replacement function.

    -17.4.1. Compiling C and C++ code conditionally

    +17.5.1. Compiling C and C++ code conditionally

    If a package already comes with a GNU configure script, the preferred way to fix the build failure is to change the configure script, not the code. In the other cases, you can @@ -7563,7 +7625,7 @@ Changes to the PLIST does not define it. Use __sun instead.

    -17.4.1.1. C preprocessor macros to identify the operating system

    +17.5.1.1. C preprocessor macros to identify the operating system

    To distinguish between 4.4 BSD-derived systems and the rest of the world, you should use the following code.

    @@ -7588,7 +7650,7 @@ Changes to the PLIST
 
 
    
 
    
-17.4.1.2. C preprocessor macros to identify the hardware architecture
    
+17.5.1.2. C preprocessor macros to identify the hardware architecture
    
 
         i386        i386, __i386, __i386__
     MIPS        __mips
@@ -7597,7 +7659,7 @@ Changes to the PLIST
 
 
    
 
    
-17.4.1.3. C preprocessor macros to identify the compiler
    
+17.5.1.3. C preprocessor macros to identify the compiler
    
 
         GCC         __GNUC__ (major version), __GNUC_MINOR__
     SunPro      __SUNPRO_C (0x570 for version 5.7)
@@ -7607,22 +7669,22 @@ Changes to the PLIST
 
 
    
 
    
-17.4.2. How to handle compiler bugs
    
+17.5.2. How to handle compiler bugs
    
 
    Some source files trigger bugs in the compiler, based on
-        combinations  of compiler version and architecture and almost
-        always relation to  optimisation being enabled.  Common symptoms
-        are gcc internal errors  or never finishing compiling a
+        combinations of compiler version and architecture and almost
+        always relation to optimisation being enabled.  Common symptoms
+        are gcc internal errors or never finishing compiling a
 	file.
    
 
    Typically, a workaround involves testing the
         MACHINE_ARCH and compiler version, disabling
         optimisation for that combination of file,
 	MACHINE_ARCH and compiler, and documenting it
-	in  pkgsrc/doc/HACKS. See that file for a
+	in pkgsrc/doc/HACKS. See that file for a
 	number of examples.
    
 
 
    
 
    
-17.4.3. Undefined reference to “...”
    
+17.5.3. Undefined reference to “...”
    
 
    This compiler error often means that a package did not
 	link to a shared library it needs. The following functions are
 	known to cause this error message over and over.
    
@@ -7678,485 +7740,477 @@ Changes to the PLIST
 
 
 
    To fix these linker errors, it is often sufficient to say
-	LIBS.OperatingSystem+=
-	-lfoo to the package
-	Makefile and then say bmake clean;
-	bmake.
    
+    LIBS.OperatingSystem+=
+    -lfoo to the package
+    Makefile and then say bmake clean;
+    bmake.
    
+
+
    
+
    
+17.5.4. Running out of memory
    
+
    Sometimes packages fail to build because the compiler runs
+    into an operating system specific soft limit.  With the
+    UNLIMIT_RESOURCES variable pkgsrc can be told
+    to unlimit the resources.  Currently, the allowed values are
+    “datasize” and “stacksize” (or both).
+    Setting this variable is similar to running the shell builtin
+    ulimit command to raise the maximum data
+    segment size or maximum stack size of a process, respectively, to
+    their hard limits.
    
 
    
 
 
    
 
    
-17.5. Fixing problems in the install phase
    
+17.6. Fixing problems in the install phase
    
 
    
 
    
-17.5.1. Creating needed directories
    
+17.6.1. Creating needed directories
    
 
    The BSD-compatible install supplied
-	with some operating systems cannot create more than one
-	directory at a time. As such, you should call
-	${INSTALL_*_DIR} like this:
    
+    with some operating systems cannot create more than one
+    directory at a time. As such, you should call
+    ${INSTALL_*_DIR} like this:
    
 
    -    ${INSTALL_DATA_DIR} ${PREFIX}/dir1
-    ${INSTALL_DATA_DIR} ${PREFIX}/dir2
-
    
+      ${INSTALL_DATA_DIR} ${PREFIX}/dir1
+      ${INSTALL_DATA_DIR} ${PREFIX}/dir2
+    
    
 
    You can also just append “dir1
-	dir2” to the
-	INSTALLATION_DIRS variable, which will
-	automatically do the right thing.
    
+    dir2” to the
+    INSTALLATION_DIRS variable, which will
+    automatically do the right thing.
    
 
 
    
 
    
-17.5.2. Where to install documentation
    
+17.6.2. Where to install documentation
    
 
    In general, documentation should be installed into
-	${PREFIX}/share/doc/${PKGBASE} or
-	${PREFIX}/share/doc/${PKGNAME} (the
-	latter includes the version number of the package).
    
+    ${PREFIX}/share/doc/${PKGBASE} or
+    ${PREFIX}/share/doc/${PKGNAME} (the latter
+    includes the version number of the package).
    
 
    Many modern packages using GNU autoconf allow to set the
-	directory where HTML documentation is installed with the
-	“--with-html-dir” option. Sometimes using this
-	flag is needed because otherwise the documentation ends up in
-	${PREFIX}/share/doc/html or other
-	places.
    
-
    An exception to the above is that library API
-	documentation generated with the textproc/gtk-doc tools, for use by
-	special browsers (devhelp) should be left at their default
-	location, which is
-	${PREFIX}/share/gtk-doc.  Such
-	documentation can be recognized from files ending in
-	.devhelp or
-	.devhelp2.  (It is also acceptable to
-	install such files in
-	${PREFIX}/share/doc/${PKGBASE} or
-	${PREFIX}/share/doc/${PKGNAME}; the
-	.devhelp* file must be directly in that
-	directory then, no additional
-	subdirectory level is allowed in this case. This is usually
-	achieved by using
-	“--with-html-dir=${PREFIX}/share/doc”.
-	${PREFIX}/share/gtk-doc is preferred
-	though.)
    
+    directory where HTML documentation is installed with the
+    “--with-html-dir” option. Sometimes using this flag
+    is needed because otherwise the documentation ends up in
+    ${PREFIX}/share/doc/html or other
+    places.
    
+
    An exception to the above is that library API documentation
+    generated with the textproc/gtk-doc tools, for use by special
+    browsers (devhelp) should be left at their default location, which
+    is ${PREFIX}/share/gtk-doc.  Such
+    documentation can be recognized from files ending in
+    .devhelp or .devhelp2.
+    (It is also acceptable to install such files in
+    ${PREFIX}/share/doc/${PKGBASE} or
+    ${PREFIX}/share/doc/${PKGNAME}; the
+    .devhelp* file must be directly in that
+    directory then, no additional subdirectory level is allowed in
+    this case. This is usually achieved by using
+    “--with-html-dir=${PREFIX}/share/doc”.
+    ${PREFIX}/share/gtk-doc is preferred
+    though.)
    
 
 
    
 
    
-17.5.3. Installing score files
    
+17.6.3. Installing score files
    
 
    Certain packages, most of them in the games category, install
-        a score file that allows all users on the system to record their
-        highscores.  In order for this to work, the binaries need to be
-        installed setgid and the score files owned by the appropriate
-        group and/or owner (traditionally the "games" user/group).  The
-        following variables, documented in more detail in
-        mk/defaults/mk.conf, control this
-        behaviour: SETGIDGAME,
-        GAMEDATAMODE, GAMEGRP,
-        GAMEMODE, GAMEOWN.
    
+    a score file that allows all users on the system to record their
+    highscores.  In order for this to work, the binaries need to be
+    installed setgid and the score files owned by the appropriate
+    group and/or owner (traditionally the "games" user/group).  The
+    following variables, documented in more detail in
+    mk/defaults/mk.conf, control this
+    behaviour: SETGIDGAME,
+    GAMEDATAMODE, GAMEGRP,
+    GAMEMODE, GAMEOWN.
    
 
    Note that per default, setgid installation of games is
-        disabled;  setting SETGIDGAME=YES will set all
-        the other variables accordingly.
    
+    disabled;  setting SETGIDGAME=YES will set all
+    the other variables accordingly.
    
 
    A package should therefor never hard code file ownership or
-        access permissions but rely on INSTALL_GAME and
-        INSTALL_GAME_DATA to set these
-        correctly.
    
+    access permissions but rely on INSTALL_GAME and
+    INSTALL_GAME_DATA to set these
+    correctly.
    
 
 
    
 
    
-17.5.4. Packages containing perl scripts
    
-
    
-        If your package contains interpreted perl scripts, set
-        REPLACE_PERL to ensure that the proper
-        interpreter path is set. REPLACE_PERL should
-        contain a list of scripts, relative to
-        WRKSRC, that you want adjusted.
    
-
    
-
    
-
    
-17.5.5. Packages with hardcoded paths to other interpreters
    
-
    
-        Your package may also contain scripts with hardcoded paths to
-        other interpreters besides (or as well as) perl.  To correct the
-        full pathname to the script interpreter, you need to set the
-        following definitions in your Makefile (we
-        shall use tclsh in this example):
    
+17.6.4. Packages with hardcoded paths to other interpreters
    
+
    Your package may also contain scripts with hardcoded paths to
+      other interpreters besides (or as well as) perl.  To correct the
+      full pathname to the script interpreter, you need to set the
+      following definitions in your Makefile (we
+    shall use tclsh in this example):
    
 
    -    REPLACE_INTERPRETER+=   tcl
-    REPLACE.tcl.old=        .*/bin/tclsh
-    REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
-    REPLACE_FILES.tcl=      # list of tcl scripts which need to be fixed,
-                            # relative to ${WRKSRC}, just as in REPLACE_PERL
-
    
+      REPLACE_INTERPRETER+=   tcl
+      REPLACE.tcl.old=        .*/bin/tclsh
+      REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
+      REPLACE_FILES.tcl=      # list of tcl scripts which need to be fixed,
+      # relative to ${WRKSRC}, just as in REPLACE_PERL
+    
    
 
    
 
    Note
    
 
    Before March 2006, these variables were called
-	_REPLACE.* and
-	_REPLACE_FILES.*.
    
+    _REPLACE.* and
+    _REPLACE_FILES.*.
    
 
    
 
 
    
 
    
-17.5.6. Packages installing perl modules
    
+17.6.5. Packages installing perl modules
    
 
    Makefiles of packages providing perl5 modules should include
-        the Makefile fragment
-        ../../lang/perl5/module.mk.  It provides a
-        do-configure target for the standard perl
-        configuration for such modules as well as various hooks to tune
-        this configuration.  See comments in this file for
-        details.
    
+    the Makefile fragment
+    ../../lang/perl5/module.mk.  It provides a
+    do-configure target for the standard perl
+    configuration for such modules as well as various hooks to tune
+    this configuration.  See comments in this file for
+    details.
    
 
    Perl5 modules will install into different places depending
-        on the version of perl used during the build process.  To
-        address this, pkgsrc will append lines to the
-        PLIST corresponding to the files listed in
-        the installed .packlist file generated by
-        most perl5 modules.  This is invoked by defining
-        PERL5_PACKLIST to a space-separated list of
-        paths to packlist files, e.g.:
    
+    on the version of perl used during the build process.  To
+    address this, pkgsrc will append lines to the
+    PLIST corresponding to the files listed in
+    the installed .packlist file generated by
+    most perl5 modules.  This is invoked by defining
+    PERL5_PACKLIST to a space-separated list of
+    paths to packlist files, e.g.:
    
 
    -    PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
-
    
+      PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
+

    The variables PERL5_SITELIB, - PERL5_SITEARCH, and - PERL5_ARCHLIB represent the three locations - in which perl5 modules may be installed, and may be used by - perl5 packages that don't have a packlist. These three - variables are also substituted for in the - PLIST.

    + PERL5_SITEARCH, and + PERL5_ARCHLIB represent the three locations + in which perl5 modules may be installed, and may be used by + perl5 packages that don't have a packlist. These three + variables are also substituted for in the + PLIST.

    -17.5.7. Packages installing info files

    +17.6.6. Packages installing info files

    Some packages install info files or use the - “makeinfo” or “install-info” - commands. INFO_FILES should be defined in - the package Makefile so that INSTALL and - DEINSTALL scripts will be generated to - handle registration of the info files in the Info directory - file. The “install-info” command used for the info - files registration is either provided by the system, or by a - special purpose package automatically added as dependency if - needed.

    + “makeinfo” or “install-info” + commands. INFO_FILES should be defined in + the package Makefile so that INSTALL and + DEINSTALL scripts will be generated to + handle registration of the info files in the Info directory + file. The “install-info” command used for the info + files registration is either provided by the system, or by a + special purpose package automatically added as dependency if + needed.

    PKGINFODIR is the directory under - ${PREFIX} where info files are primarily - located. PKGINFODIR defaults to - “info” and can be overridden by the user.

    + ${PREFIX} where info files are primarily + located. PKGINFODIR defaults to + “info” and can be overridden by the user.

    The info files for the package should be listed in the - package PLIST; however any split info files - need not be listed.

    + package PLIST; however any split info files + need not be listed.

    A package which needs the “makeinfo” command - at build time must add “makeinfo” to - USE_TOOLS in its Makefile. If a minimum - version of the “makeinfo” command is needed it - should be noted with the TEXINFO_REQD - variable in the package Makefile. By - default, a minimum version of 3.12 is required. If the system - does not provide a makeinfo command or if it - does not match the required minimum, a build dependency on the - devel/gtexinfo package will - be added automatically.

    + at build time must add “makeinfo” to + USE_TOOLS in its Makefile. If a minimum + version of the “makeinfo” command is needed it + should be noted with the TEXINFO_REQD + variable in the package Makefile. By + default, a minimum version of 3.12 is required. If the system + does not provide a makeinfo command or if it + does not match the required minimum, a build dependency on the + devel/gtexinfo package will + be added automatically.

    The build and installation process of the software provided - by the package should not use the - install-info command as the registration of - info files is the task of the package - INSTALL script, and it must use the - appropriate makeinfo command.

    + by the package should not use the + install-info command as the registration of + info files is the task of the package + INSTALL script, and it must use the + appropriate makeinfo command.

    To achieve this goal, the pkgsrc infrastructure creates - overriding scripts for the install-info and - makeinfo commands in a directory listed early - in PATH.

    + overriding scripts for the install-info and + makeinfo commands in a directory listed early + in PATH.

    The script overriding install-info has - no effect except the logging of a message. The script overriding - makeinfo logs a message and according to the - value of TEXINFO_REQD either runs the appropriate - makeinfo command or exit on error.

    + no effect except the logging of a message. The script overriding + makeinfo logs a message and according to the + value of TEXINFO_REQD either runs the appropriate + makeinfo command or exit on error.

    -17.5.8. Packages installing man pages

    +17.6.7. Packages installing man pages

    All packages that install manual pages should install them - into the same directory, so that there is one common place to - look for them. In pkgsrc, this place is - ${PREFIX}/${PKGMANDIR}, and this expression - should be used in packages. The default for - PKGMANDIR is - “man”. Another often-used - value is “share/man”.

    + into the same directory, so that there is one common place to look + for them. In pkgsrc, this place is + ${PREFIX}/${PKGMANDIR}, and this expression + should be used in packages. The default for + PKGMANDIR is + “man”. Another often-used value + is “share/man”.

    Note

    -

    The support for a custom - PKGMANDIR is far from complete.

    +

    The support for a custom PKGMANDIR + is far from complete.

    The PLIST files can just use - man/ as the top level directory for the man - page file entries, and the pkgsrc framework will convert as - needed. In all other places, the correct - PKGMANDIR must be used.

    -

    Packages that are - configured with GNU_CONFIGURE set as - “yes”, by default will use the - ./configure - --mandir switch to set where the man pages should be installed. - The path is GNU_CONFIGURE_MANDIR which defaults - to ${PREFIX}/${PKGMANDIR}. -

    -

    - Packages that use GNU_CONFIGURE but do not - use --mandir, can set CONFIGURE_HAS_MANDIR - to “no”. - Or if the ./configure script uses - a non-standard use of --mandir, you can set - GNU_CONFIGURE_MANDIR as needed. -

    + man/ as the top level directory for the man + page file entries, and the pkgsrc framework will convert as + needed. In all other places, the correct + PKGMANDIR must be used.

    +

    Packages that are + configured with GNU_CONFIGURE set as + “yes”, by default will use the + ./configure + --mandir switch to set where the man pages should be installed. + The path is GNU_CONFIGURE_MANDIR which defaults + to ${PREFIX}/${PKGMANDIR}.

    +

    Packages that use GNU_CONFIGURE but do not + use --mandir, can set CONFIGURE_HAS_MANDIR + to “no”. + Or if the ./configure script uses + a non-standard use of --mandir, you can set + GNU_CONFIGURE_MANDIR as needed.

    See Section 11.5, “Man page compression” for - information on installation of compressed manual pages. -

    + information on installation of compressed manual pages.

    -17.5.9. Packages installing GConf2 data files

    -

    - If a package installs .schemas or - .entries files, used by GConf2, - you need to take some extra steps to make sure they get registered - in the database: -

    +17.6.8. Packages installing GConf2 data files
    +

    If a package installs .schemas or + .entries files, used by GConf2, + you need to take some extra steps to make sure they get registered + in the database:

    1. Include ../../devel/GConf2/schemas.mk - instead of its buildlink3.mk file. This - takes care of rebuilding the GConf2 database at installation and - deinstallation time, and tells the package where to install - GConf2 data files using some standard configure arguments. It - also disallows any access to the database directly from the - package.

      2. + instead of its buildlink3.mk file. This + takes care of rebuilding the GConf2 database at installation and + deinstallation time, and tells the package where to install + GConf2 data files using some standard configure arguments. It + also disallows any access to the database directly from the + package.

    2. Ensure that the package installs its - .schemas files under - ${PREFIX}/share/gconf/schemas. If they get - installed under ${PREFIX}/etc, you will - need to manually patch the package.

      3. + .schemas files under + ${PREFIX}/share/gconf/schemas. If they get + installed under ${PREFIX}/etc, you will + need to manually patch the package.

    3. Check the PLIST and remove any entries under the etc/gconf - directory, as they will be handled automatically. See - Section 7.14, “How do I change the location of configuration files?” for more information.

      4. + directory, as they will be handled automatically. See + Section 7.14, “How do I change the location of configuration files?” for more information.

    4. Define the GCONF2_SCHEMAS variable in - your Makefile with a list of all - .schemas files installed by the package, if - any. Names must not contain any directories in them.

      5. + your Makefile with a list of all + .schemas files installed by the package, if + any. Names must not contain any directories in them.

    5. Define the GCONF2_ENTRIES variable in - your Makefile with a - list of all .entries files installed by the - package, if any. Names must not contain any directories in - them.

      6. + your Makefile with a + list of all .entries files installed by the + package, if any. Names must not contain any directories in + them.

    -17.5.10. Packages installing scrollkeeper data files

    -

    - If a package installs .omf files, used by - scrollkeeper, you need to take some extra steps to make sure they - get registered in the database: -

    +17.6.9. Packages installing scrollkeeper data files
    +

    If a package installs .omf files, used by + scrollkeeper, you need to take some extra steps to make sure they + get registered in the database:

    1. Include - ../../textproc/scrollkeeper/omf.mk - instead of its buildlink3.mk file. This - takes care of rebuilding the scrollkeeper database at - installation and deinstallation time, and disallows any access - to it directly from the package. -

      2. + ../../textproc/scrollkeeper/omf.mk + instead of its buildlink3.mk file. This + takes care of rebuilding the scrollkeeper database at + installation and deinstallation time, and disallows any access + to it directly from the package.

    2. Check the PLIST and remove any entries under the - libdata/scrollkeeper directory, as they - will be handled automatically.

      3. + libdata/scrollkeeper directory, as they + will be handled automatically.

    3. Remove the share/omf directory from - the PLIST. It will be handled by scrollkeeper.

      4. + the PLIST. It will be handled by scrollkeeper.

    -17.5.11. Packages installing X11 fonts

    +17.6.10. Packages installing X11 fonts

    If a package installs font files, you will need to rebuild - the fonts database in the directory where they get installed at - installation and deinstallation time. This can be automatically - done by using the pkginstall framework.

    + the fonts database in the directory where they get installed at + installation and deinstallation time. This can be automatically + done by using the pkginstall framework.

    You can list the directories where fonts are installed in the - FONTS_DIRS.type - variables, where type can be one of - “ttf”, “type1” or “x11”. - Also make sure that the database file - fonts.dir is not listed in the PLIST.

    + FONTS_DIRS.type + variables, where type can be one of + “ttf”, “type1” or “x11”. + Also make sure that the database file + fonts.dir is not listed in the PLIST.

    Note that you should not create new directories for fonts; - instead use the standard ones to avoid that the user needs to - manually configure his X server to find them.

    + instead use the standard ones to avoid that the user needs to + manually configure his X server to find them.

    -17.5.12. Packages installing GTK2 modules

    +17.6.11. Packages installing GTK2 modules

    If a package installs GTK2 immodules or loaders, you need to - take some extra steps to get them registered in the GTK2 database - properly:

    + take some extra steps to get them registered in the GTK2 database + properly:

    1. Include - ../../x11/gtk2/modules.mk instead of its - buildlink3.mk file. This takes care of - rebuilding the database at installation and deinstallation time. -

      2. -

    2. - Set GTK2_IMMODULES=YES if - your package installs GTK2 immodules.

      3. -

    3. - Set GTK2_LOADERS=YES if your package installs - GTK2 loaders.

      4. + ../../x11/gtk2/modules.mk instead of its + buildlink3.mk file. This takes care of + rebuilding the database at installation and deinstallation time.

      +

    4. Set GTK2_IMMODULES=YES if + your package installs GTK2 immodules.

      5. +

    5. Set GTK2_LOADERS=YES if your package installs + GTK2 loaders.

    6. -

      - Patch the package to not touch any of the GTK2 databases directly. - These are: - -

      +

      Patch the package to not touch any of the GTK2 + databases directly. These are:

      • libdata/gtk-2.0/gdk-pixbuf.loaders

      • libdata/gtk-2.0/gtk.immodules

      -

      -

      7. -

    7. - Check the PLIST and remove any entries under the - libdata/gtk-2.0 directory, as they will be - handled automatically.

      8. +

    8. Check the PLIST and remove + any entries under the libdata/gtk-2.0 + directory, as they will be handled automatically.

    -17.5.13. Packages installing SGML or XML data

    +17.6.12. Packages installing SGML or XML data

    If a package installs SGML or XML data files that need to be - registered in system-wide catalogs (like DTDs, sub-catalogs, - etc.), you need to take some extra steps: -

    + registered in system-wide catalogs (like DTDs, sub-catalogs, + etc.), you need to take some extra steps:

    1. Include - ../../textproc/xmlcatmgr/catalogs.mk in - your Makefile, which takes care of - registering those files in system-wide catalogs at - installation and deinstallation time.

      2. + ../../textproc/xmlcatmgr/catalogs.mk in + your Makefile, which takes care of + registering those files in system-wide catalogs at + installation and deinstallation time.

    2. Set SGML_CATALOGS to the full path of - any SGML catalogs installed by the package.

      3. + any SGML catalogs installed by the package.

    3. Set XML_CATALOGS to the full path of - any XML catalogs installed by the package.

      4. + any XML catalogs installed by the package.

    4. Set SGML_ENTRIES to individual entries - to be added to the SGML catalog. These come in groups of - three strings; see xmlcatmgr(1) for more information - (specifically, arguments recognized by the 'add' action). - Note that you will normally not use this variable.

      5. + to be added to the SGML catalog. These come in groups of + three strings; see xmlcatmgr(1) for more information + (specifically, arguments recognized by the 'add' action). + Note that you will normally not use this variable.

    5. Set XML_ENTRIES to individual entries - to be added to the XML catalog. These come in groups of three - strings; see xmlcatmgr(1) for more information (specifically, - arguments recognized by the 'add' action). Note that you will - normally not use this variable. -

      6. + to be added to the XML catalog. These come in groups of three + strings; see xmlcatmgr(1) for more information (specifically, + arguments recognized by the 'add' action). Note that you will + normally not use this variable.

    -17.5.14. Packages installing extensions to the MIME database

    +17.6.13. Packages installing extensions to the MIME database

    If a package provides extensions to the MIME database by - installing .xml files inside - ${PREFIX}/share/mime/packages, you - need to take some extra steps to ensure that the database is kept - consistent with respect to these new files: -

    + installing .xml files inside + ${PREFIX}/share/mime/packages, you + need to take some extra steps to ensure that the database is kept + consistent with respect to these new files:

    1. Include - ../../databases/shared-mime-info/mimedb.mk - (avoid using the buildlink3.mk file from - this same directory, which is reserved for inclusion from - other buildlink3.mk files). It takes - care of rebuilding the MIME database at installation and - deinstallation time, and disallows any access to it directly - from the package.

      2. + ../../databases/shared-mime-info/mimedb.mk + (avoid using the buildlink3.mk file from + this same directory, which is reserved for inclusion from + other buildlink3.mk files). It takes + care of rebuilding the MIME database at installation and + deinstallation time, and disallows any access to it directly + from the package.

    2. Check the PLIST and remove any entries under the - share/mime directory, - except for files saved under - share/mime/packages. The former are - handled automatically by - the update-mime-database program, but the latter are - package-dependent and must be removed by the package that - installed them in the first place.

      3. + share/mime directory, + except for files saved under + share/mime/packages. The former are + handled automatically by + the update-mime-database program, but the latter are + package-dependent and must be removed by the package that + installed them in the first place.

    3. Remove any share/mime/* directories - from the PLIST. They will be handled by the shared-mime-info - package.

      4. + from the PLIST. They will be handled by the shared-mime-info + package.

    -17.5.15. Packages using intltool

    +17.6.14. Packages using intltool

    If a package uses intltool during its build, include the - ../../textproc/intltool/buildlink3.mk file, - which forces it to use the intltool package provided by pkgsrc, - instead of the one bundled with the distribution file. -

    + ../../textproc/intltool/buildlink3.mk file, + which forces it to use the intltool package provided by pkgsrc, + instead of the one bundled with the distribution file.

    This tracks intltool's build-time dependencies and uses the - latest available version; this way, the package benefits of any - bug fixes that may have appeared since it was released. -

    + latest available version; this way, the package benefits of any + bug fixes that may have appeared since it was released.

    -17.5.16. Packages installing startup scripts

    +17.6.15. Packages installing startup scripts

    If a package contains a rc.d script, it won't be copied into - the startup directory by default, but you can enable it, by adding - the option PKG_RCD_SCRIPTS=YES in - /etc/mk.conf. This option will copy the scripts - into /etc/rc.d when a package is installed, and - it will automatically remove the scripts when the package is - deinstalled.

    + the startup directory by default, but you can enable it, by adding + the option PKG_RCD_SCRIPTS=YES in + /etc/mk.conf. This option will copy the scripts + into /etc/rc.d when a package is installed, and + it will automatically remove the scripts when the package is + deinstalled.

    -17.5.17. Packages installing TeX modules

    +17.6.16. Packages installing TeX modules

    If a package installs TeX packages into the texmf tree, - the ls-R database of the tree needs to be - updated.

    + the ls-R database of the tree needs to be + updated.

    Note

    Except the main TeX packages such as teTeX-texmf, - packages should install files - into PKG_LOCALTEXMFPREFIX, - not PKG_TEXMFPREFIX.

    + packages should install files + into PKG_LOCALTEXMFPREFIX, + not PKG_TEXMFPREFIX.

    1. Include - ../../print/teTeX/module.mk instead - of ../../mk/tex.buildlink3.mk. This - takes care of rebuilding the ls-R - database at installation and deinstallation time.

      2. + ../../print/teTeX/module.mk instead + of ../../mk/tex.buildlink3.mk. This + takes care of rebuilding the ls-R + database at installation and deinstallation time.

    2. If your package installs files into a texmf - tree other than the one - at PKG_LOCALTEXMFPREFIX, - set TEXMFDIRS to the list of all texmf - trees that need database update.

      + tree other than the one + at PKG_LOCALTEXMFPREFIX, + set TEXMFDIRS to the list of all texmf + trees that need database update.

      If your package also installs font map files that need - to be registered using updmap, - set TEX_FONTMAPS to the list of all - such font map files. Then updmap will - be run automatically at installation/deinstallation to - enable/disable font map files for TeX output - drivers.

      + to be registered using updmap, + set TEX_FONTMAPS to the list of all + such font map files. Then updmap will + be run automatically at installation/deinstallation to + enable/disable font map files for TeX output + drivers.

    3. Make sure that none of ls-R - databases are included in PLIST, as - they will be removed only by the teTeX-bin package.

      4. + databases are included in PLIST, as + they will be removed only by the teTeX-bin package.

    -17.5.18. Packages installing hicolor theme icons

    +17.6.17. Packages supporting running binaries in + emulation
    +

    There are some packages that provide libraries and + executables for running binaries from a one operating system + on a different one (if the latter supports it). One example + is running Linux binaries on NetBSD.

    +

    The pkgtools/rpm2pkg + helps in extracting and packaging Linux rpm packages.

    +

    The CHECK_SHLIBS can be set to no to + avoid the check-shlibs target, which tests + if all libraries for each installed executable can be found by + the dynamic linker. Since the standard dynamic linker is run, + this fails for emulation packages, because the libraries used + by the emulation are not in the standard directories.

    + +
    +

    +17.6.18. Packages installing hicolor theme icons

    If a package installs images under the - share/icons/hicolor and/or updates the - share/icons/hicolor/icon-theme.cache database, - you need to take some extra steps to make sure that the shared - theme directory is handled appropriately and that the cache - database is rebuilt:

    + share/icons/hicolor and/or updates the + share/icons/hicolor/icon-theme.cache + database, you need to take some extra steps to make sure that the + shared theme directory is handled appropriately and that the cache + database is rebuilt:

    1. Include - ../../graphics/hicolor-icon-theme/buildlink3.mk - instead of its buildlink3.mk file.

      2. -

    2. Check the PLIST and remove the entry that refers to the - theme cache.

      3. + ../../graphics/hicolor-icon-theme/buildlink3.mk.

      +

    3. Check the PLIST and remove the + entry that refers to the theme cache.

    4. Ensure that the PLIST does not remove the shared icon directories from the share/icons/hicolor hierarchy because they will be handled automatically.

      5. @@ -8167,7 +8221,7 @@ Changes to the PLIST

    -17.5.19. Packages installing desktop files

    +17.6.19. Packages installing desktop files

    If a package installs .desktop files under share/applications and these include MIME information, you need to take extra steps to ensure that they @@ -8184,6 +8238,32 @@ Changes to the PLIST print-PLIST.

    +
    +

    +17.7. Marking packages as having problems

    +

    In some cases one does not have the time to solve a problem + immediately. There are currently two ways to declare that one knows + that a package has problems.

    +
      +

    • The first way is to plainly mark it as broken. For + this, one just sets the variable BROKEN to the + reason why the package is broken (similar to the + RESTRICTED variable). A user trying to build + the package will immediately be shown this message, and the build + will not be even tried.

      • +

    • After each pkgsrc freeze period (a time when the + tree is stabilized and a new pkgsrc branch is cut), the packages + that were not building in the official branch build on the latest + NetBSD release will be marked as broken on that branch. This is + done by setting the BROKEN_IN variable to the + branch name (or appending the branch name to it). If a user tries + to build such a package and the build fails, the user gets a + message that says that the package was broken on the respective + branch(es).

      • +
    +

    Both types of packages are removed from pkgsrc in irregular + intervals.

    +

    @@ -8205,8 +8285,7 @@ Changes to the PLIST

  • Edit the Makefile as requested.

  • Fill in the DESCR file

    • -

  • Run make configure -

    • +

  • Run make configure

  • Add any dependencies glimpsed from documentation and the configure step to the package's Makefile.

    • @@ -8224,7 +8303,7 @@ Changes to the PLIST phase. mkpatches, patchdiff and pkgvi are from the pkgtools/pkgdiff - package.

    + package.

  • Look at the Makefile, fix if necessary; see Section 9.1, “Makefile”.

    • @@ -8303,11 +8382,18 @@ Changes to the PLIST runs well; see Chapter 18, Debugging and the rest of this document. Next, generate an uuencoded gzipped tar(1) archive that contains all files that make up the package. - Finally, send-pr with category - “pkg”, a synopsis which includes the package name - and version number, a short description of your package - (contents of the COMMENT variable or DESCR file are OK) and - attach the archive to your PR.

    + Finally, send this package to the pkgsrc bug tracking system, + either with the send-pr(1) command, or if you don't have + that, go to the web page + http://www.NetBSD.org/Misc/send-pr.html, + which contains some instructions and a link to a form, where you + can submit packages.

    +

    In the form of the problem report, the category should be + “pkg”, the synopsis should include the package name + and version number, and the description field should contain a + short description of your package (contents of the COMMENT + variable or DESCR file are OK). The uuencoded package data should + go into the “fix” field.

    If you want to submit several packages, please send a separate PR for each one, it's easier for us to track things that way.

    @@ -8352,70 +8438,52 @@ Changes to the PLIST

    19.4. Committing: Importing a package into CVS

    -

    - This section is only of interest for pkgsrc developers with write +

    This section is only of interest for pkgsrc developers with write access to the pkgsrc repository. Please remember that cvs imports files relative to the current working directory, and that the pathname that you give the cvs import command is so that it knows where to place the files in the repository. Newly created packages should be imported with a vendor tag of “TNF” and a release tag of - “pkgsrc-base”, e.g: -

    + “pkgsrc-base”, e.g:

         $ cd .../pkgsrc/category/pkgname
     $ cvs import pkgsrc/category/pkgname TNF pkgsrc-base
    -

    - Remember to move the directory from which you imported out of +

    Remember to move the directory from which you imported out of the way, or cvs will complain the next time you “cvs update” your source tree. Also don't forget to add the new - package to the category's Makefile. -

    -

    - The commit message of the initial import should include part of the + package to the category's Makefile.

    +

    The commit message of the initial import should include part of the DESCR file, so people reading the mailing lists know - what the package is/does. -

    -

    - For new packages, “cvs import” is preferred to “cvs + what the package is/does.

    +

    For new packages, “cvs import” is preferred to “cvs add” because the former gets everything with a single command, - and provides a consistent tag. -

    + and provides a consistent tag.

    19.5. Updating a package to a newer version

    -

    - Please always put a concise, appropriate and relevant summary of the +

    Please always put a concise, appropriate and relevant summary of the changes between old and new versions into the commit log when updating - a package. There are various reasons for this: -

    + a package. There are various reasons for this:

      -

    • - A URL is volatile, and can change over time. It may go away completely - or its information may be overwritten by newer information. -

      • -

    • - Having the change information between old and new versions in our CVS - repository is very useful for people who use either cvs or anoncvs. -

      • -

    • - Having the change information between old and new versions in our CVS +

    • A URL is volatile, and can change over time. It may go away completely + or its information may be overwritten by newer information.

      • +

    • Having the change information between old and new versions in our CVS + repository is very useful for people who use either cvs or anoncvs.

      • +

    • Having the change information between old and new versions in our CVS repository is very useful for people who read the pkgsrc-changes mailing list, so that they can make tactical decisions about when to upgrade - the package. -

      • + the package.

    -

    - Please also recognize that, just because a new version of a package +

    Please also recognize that, just because a new version of a package has been released, it should not automatically be upgraded in the CVS repository. We prefer to be conservative in the packages that are included in pkgsrc - development or beta packages are not really the best thing for most places in which pkgsrc is used. Please use your judgement about what should go into pkgsrc, and bear in mind that - stability is to be preferred above new and possibly untested features. -

    + stability is to be preferred above new and possibly untested features.

    @@ -8424,13 +8492,9 @@ Changes to the PLIST

  • Make a copy of the directory somewhere else.

  • Remove all CVS dirs.

    -

    - Alternatively to the first two steps you can also do: -

    +

    Alternatively to the first two steps you can also do:

    % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
    -

    - and use that for further work. -

    +

    and use that for further work.

  • Fix CATEGORIES and any DEPENDS paths that just did “../package” @@ -8442,8 +8506,6 @@ place.

    • % cd /usr/pkgsrc
 % grep /package */*/Makefile* */*/buildlink*
    -

    -

  • Fix paths in packages from step 5 to point to new location.

  • cvs rm (-f) the package at the old location.

    • @@ -8452,9 +8514,7 @@ place.

  • Commit the changed and removed files:

    % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
    -

    - (and any packages from step 5, of course). -

    +

    (and any packages from step 5, of course).

    • @@ -8469,36 +8529,36 @@ place.

    pkgsrc-users mailing list.

    -
    20.1. What is the difference between +
    20.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
    -
    20.2. What is the difference between +
    20.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
    -
    20.3. What is the difference between +
    20.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
    -
    20.4. What is the difference between +
    20.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and BUILDLINK_LIBS?
    -
    20.5. Why does make show-var +
    20.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
    -
    20.6. What does +
    20.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand the := inside it.
    -
    20.7. Which mailing lists are there for package +
    20.7. Which mailing lists are there for package developers?
    -
    20.8. Where is the pkgsrc +
    20.8. Where is the pkgsrc documentation?
    @@ -8507,7 +8567,7 @@ place.

    -20.1. +20.1.

    What is the difference between MAKEFLAGS, .MAKEFLAGS and @@ -8523,7 +8583,7 @@ place.

    -20.2. +20.2.

    What is the difference between MAKE, GMAKE and @@ -8541,7 +8601,7 @@ place.

    -20.3. +20.3.

    What is the difference between CC, PKG_CC and @@ -8559,7 +8619,7 @@ place.

    -20.4. +20.4.

    What is the difference between BUILDLINK_LDFLAGS, @@ -8572,7 +8632,7 @@ place.

    -20.5. +20.5.

    Why does make show-var VARNAME=BUILDLINK_PREFIX.foo @@ -8588,7 +8648,7 @@ place.

    -20.6. +20.6.

    What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I @@ -8612,7 +8672,7 @@ place.

    -20.7. +20.7.

    Which mailing lists are there for package developers?

    @@ -8637,7 +8697,7 @@ place.

    -20.8. +20.8.

    Where is the pkgsrc documentation?

    @@ -8830,24 +8890,24 @@ solution is given. After applying the solution be sure to Installs OMF files under share/omf. -See Section 17.5.10, “Packages installing scrollkeeper data files”. +See Section 17.6.9, “Packages installing scrollkeeper data files”. Installs icons under the share/icons/hicolor hierarchy or updates share/icons/hicolor/icon-theme.cache. -See Section 17.5.18, “Packages installing hicolor theme icons”. +See Section 17.6.18, “Packages installing hicolor theme icons”. Installs files under share/mime/packages. -See Section 17.5.14, “Packages installing extensions to the MIME database”. +See Section 17.6.13, “Packages installing extensions to the MIME database”. Installs .desktop files under share/applications and these include MIME information. -See Section 17.5.19, “Packages installing desktop files”. +See Section 17.6.19, “Packages installing desktop files”.
    @@ -9181,8 +9241,8 @@ details.

    22.5.1. Procedures with parameters

    In a traditional imperative programming language some of the .mk files could be described as - procedures. They take some input parameters and—after - inclusion—provide a result in output parameters. Since all + procedures. They take some input parameters and—after + inclusion—provide a result in output parameters. Since all variables in Makefiles have global scope care must be taken not to use parameter names that have already another meaning. For example, PKGNAME is a diff --git a/doc/pkgsrc.txt b/doc/pkgsrc.txt index 4ebd34584b8..8db7c89562d 100644 --- a/doc/pkgsrc.txt +++ b/doc/pkgsrc.txt @@ -296,33 +296,43 @@ II. The pkgsrc developer's guide 17.3.2. Using libtool on GNU packages that already support libtool 17.3.3. GNU Autoconf/Automake - 17.4. Fixing problems in the build phase - - 17.4.1. Compiling C and C++ code conditionally - 17.4.2. How to handle compiler bugs - 17.4.3. Undefined reference to "..." - - 17.5. Fixing problems in the install phase - - 17.5.1. Creating needed directories - 17.5.2. Where to install documentation - 17.5.3. Installing score files - 17.5.4. Packages containing perl scripts - 17.5.5. Packages with hardcoded paths to other interpreters - 17.5.6. Packages installing perl modules - 17.5.7. Packages installing info files - 17.5.8. Packages installing man pages - 17.5.9. Packages installing GConf2 data files - 17.5.10. Packages installing scrollkeeper data files - 17.5.11. Packages installing X11 fonts - 17.5.12. Packages installing GTK2 modules - 17.5.13. Packages installing SGML or XML data - 17.5.14. Packages installing extensions to the MIME database - 17.5.15. Packages using intltool - 17.5.16. Packages installing startup scripts - 17.5.17. Packages installing TeX modules - 17.5.18. Packages installing hicolor theme icons - 17.5.19. Packages installing desktop files + 17.4. Programming languages + + 17.4.1. C, C++, and Fortran + 17.4.2. Java + 17.4.3. Packages containing perl scripts + 17.4.4. Other programming languages + + 17.5. Fixing problems in the build phase + + 17.5.1. Compiling C and C++ code conditionally + 17.5.2. How to handle compiler bugs + 17.5.3. Undefined reference to "..." + 17.5.4. Running out of memory + + 17.6. Fixing problems in the install phase + + 17.6.1. Creating needed directories + 17.6.2. Where to install documentation + 17.6.3. Installing score files + 17.6.4. Packages with hardcoded paths to other interpreters + 17.6.5. Packages installing perl modules + 17.6.6. Packages installing info files + 17.6.7. Packages installing man pages + 17.6.8. Packages installing GConf2 data files + 17.6.9. Packages installing scrollkeeper data files + 17.6.10. Packages installing X11 fonts + 17.6.11. Packages installing GTK2 modules + 17.6.12. Packages installing SGML or XML data + 17.6.13. Packages installing extensions to the MIME database + 17.6.14. Packages using intltool + 17.6.15. Packages installing startup scripts + 17.6.16. Packages installing TeX modules + 17.6.17. Packages supporting running binaries in emulation + 17.6.18. Packages installing hicolor theme icons + 17.6.19. Packages installing desktop files + + 17.7. Marking packages as having problems 18. Debugging 19. Submitting and Committing @@ -965,6 +975,7 @@ Installing the bootstrap kit from source should be as simple as: # cd pkgsrc/bootstrap # ./bootstrap + See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways to get pkgsrc before bootstrapping. The given bootstrap command will use the defaults of /usr/pkg for the prefix where programs will be installed in, and / @@ -1079,6 +1090,7 @@ with the FreeBSD userland tools. There are several steps: # mv pkg_delete pkg_delete.orig # mv pkg_info pkg_info.orig + 3. An example /etc/mk.conf file will be placed in /etc/mk.conf.example file when you use the bootstrap script. @@ -1174,7 +1186,8 @@ the csh and ksh startup shortcuts) is "interix". Most systems don't have a termcap/terminfo entry for it, but the following .termcap entry provides adequate emulation in most cases: - interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi: + interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi: + 3.3.3.4. Limitations of the Interix platform @@ -1232,13 +1245,14 @@ packages currently assume that the user named "root" is the privileged user. To accommodate these, you may create such a user; make sure it is in the local group Administrators (or your language equivalent). -"pkg_add" creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the -time being, install packages as the local Administrator (or your language +pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time +being, install packages as the local Administrator (or your language equivalent), or run the following command after installing a package to work around the issue: # chmod -R g+w $PKG_DBDIR + 3.3.4. IRIX You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro @@ -1250,10 +1264,10 @@ Please note that you will need IRIX 6.5.17 or higher, as this is the earliest version of IRIX providing support for if_indextoname(3), if_nametoindex(3), etc. -At this point in time, pkgsrc only supports one ABI at a time. That is, you can -not switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit ABI. -If you start out using "abi=n32", that's what all your packages will be built -with. +At this point in time, pkgsrc only supports one ABI at a time. That is, you +cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit +ABI. If you start out using "abi=n32", that's what all your packages will be +built with. Therefore, please make sure that you have no conflicting CFLAGS in your environment or the /etc/mk.conf. Particularly, make sure that you do not try to @@ -1272,7 +1286,8 @@ for details. If you are using SGI's MIPSPro compiler, please set - PKGSRC_COMPILER= mipspro + PKGSRC_COMPILER= mipspro + in /etc/mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up passing invalid flags to the compiler. Note that bootstrap should create an @@ -1294,8 +1309,9 @@ Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested. To bootstrap using icc, assuming the default icc installation directory: - env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ - ac_cv___attribute__=yes ./bootstrap + env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ + ac_cv___attribute__=yes ./bootstrap + Note @@ -1309,13 +1325,15 @@ __attribute__ is assumed supported by the compiler. After bootstrapping, you should set PKGSRC_COMPILER in /etc/mk.conf: - PKGSRC_COMPILER= icc + PKGSRC_COMPILER= icc + The default installation directory for icc is /opt/intel_cc_80, which is also the pkgsrc default. If you have installed it into a different directory, set ICCBASE in /etc/mk.conf: - ICCBASE= /opt/icc + ICCBASE= /opt/icc + pkgsrc uses the static linking method of the runtime libraries provided by icc, so binaries can be run on other systems which do not have the shared libraries @@ -1347,16 +1365,18 @@ with the OpenBSD userland tools. There are several steps: # mv pkg_delete pkg_delete.orig # mv pkg_info pkg_info.orig + 3. An example /etc/mk.conf file will be placed in /etc/mk.conf.example file when you use the bootstrap script. OpenBSD's make program uses /etc/mk.conf as well. You can work around this by enclosing all the pkgsrc-specific parts of the file with: - .ifdef BSD_PKG_MK - # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here - .else - # OpenBSD stuff - .endif + .ifdef BSD_PKG_MK + # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here + .else + # OpenBSD stuff + .endif + 3.3.7. Solaris @@ -1410,9 +1430,10 @@ You will need at least the following packages installed (from WorkShop 5.0) You should set CC, CXX and optionally, CPP in /etc/mk.conf, e.g.: - CC= cc - CXX= CC - CPP= /usr/ccs/lib/cpp + CC= cc + CXX= CC + CPP= /usr/ccs/lib/cpp + 3.3.7.3. Buildling 64-bit binaries with SunPro @@ -1422,21 +1443,24 @@ programs in the bootstrap kit (bmake), the CFLAGS variable is not honored, even if it is set in the environment. To work around this bug, you can create a simple shell script called cc64 and put it somewhere in the PATH: - #! /bin/sh - exec /opt/SUNWspro/bin/cc -xtarget=ultra -xarch=v9 ${1+"$@"} + #! /bin/sh + exec /opt/SUNWspro/bin/cc -xtarget=ultra -xarch=v9 ${1+"$@"} + Then, pass the definition for CC in the environment of the bootstrap command: - $ cd bootstrap - $ CC=cc64 ./bootstrap + $ cd bootstrap + $ CC=cc64 ./bootstrap + After bootstrapping, there are two alternative ways, depending on whether you want to find bugs in packages or get your system ready quickly. If you just want a running system, add the following lines to your mk.conf file: - CC= cc64 - CXX= CC64 - PKGSRC_COMPILER= sunpro + CC= cc64 + CXX= CC64 + PKGSRC_COMPILER= sunpro + This way, all calls to the compiler will be intercepted by the above wrapper and therefore get the necessary ABI options automatically. (Don't forget to @@ -1445,12 +1469,13 @@ create the shell script CC64, too.) To find packages that ignore the user-specified CFLAGS and CXXFLAGS, add the following lines to your mk.conf file: - CC= cc - CXX= CC - PKGSRC_COMPILER= sunpro - CFLAGS= -xtarget=ultra -xarch=v9 - CXXFLAGS= -xtarget=ultra -xarch=v9 - LDFLAGS= -xtarget=ultra -xarch=v9 + CC= cc + CXX= CC + PKGSRC_COMPILER= sunpro + CFLAGS= -xtarget=ultra -xarch=v9 + CXXFLAGS= -xtarget=ultra -xarch=v9 + LDFLAGS= -xtarget=ultra -xarch=v9 + Packages that don't use the flags provided in the configuration file will try to build 32-bit binaries and fail during linking. Detecting this is useful to @@ -1463,8 +1488,9 @@ Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The workaround is to use another shell for the configure scripts, for example by installing shells/bash and adding the following lines to your mk.conf: - CONFIG_SHELL= ${LOCALBASE}/bin/bash - WRAPPER_SHELL= ${LOCALBASE}/bin/bash + CONFIG_SHELL= ${LOCALBASE}/bin/bash + WRAPPER_SHELL= ${LOCALBASE}/bin/bash + Then, rebuild the devel/libtool-base package. @@ -2037,6 +2063,7 @@ and run make package: # cd misc/figlet # make package + This will build and install your package (if not already done), and then build a binary package from what was installed. You can then use the pkg_* tools to manipulate it. Binary packages are created by default in /usr/pkgsrc/packages, @@ -2080,14 +2107,15 @@ mk.conf for details of the default settings. You will want to ensure that ACCEPTABLE_LICENSES meet your local policy. As used in this example, _ACCEPTABLE=yes accepts all licenses. - PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH} - WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc - BSDSRCDIR= /usr/src - BSDXSRCDIR= /usr/xsrc # for x11/xservers - OBJHOSTNAME?= yes # use work.`hostname` - FAILOVER_FETCH= yes # insist on the correct checksum - PKG_DEVELOPER?= yes - _ACCEPTABLE= yes + PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH} + WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc + BSDSRCDIR= /usr/src + BSDXSRCDIR= /usr/xsrc # for x11/xservers + OBJHOSTNAME?= yes # use work.`hostname` + FAILOVER_FETCH= yes # insist on the correct checksum + PKG_DEVELOPER?= yes + _ACCEPTABLE= yes + Some options that are especially useful for bulk builds can be found at the top lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are @@ -2126,7 +2154,7 @@ tasks at the end of the pre-build stage. If the file pre-build.local exists in usual pre-build stage. An example use of pre-build.local is to have the line: echo "I do not have enough disk space to build this pig." \ - > misc/openoffice/$BROKENF + > misc/openoffice/$BROKENF to prevent the system from trying to build a particular package which requires nearly 3 GB of disk space. @@ -2142,10 +2170,11 @@ any new instances of the shell any more). Also, if you use NetBSD earlier than 1.5, or you still want to use the pkgsrc version of ssh for some reason, be sure to install ssh before starting it from rc.local: - ( cd /usr/pkgsrc/security/ssh ; make bulk-install ) - if [ -f /usr/pkg/etc/rc.d/sshd ]; then + ( cd /usr/pkgsrc/security/ssh ; make bulk-install ) + if [ -f /usr/pkg/etc/rc.d/sshd ]; then /usr/pkg/etc/rc.d/sshd - fi + fi + Not doing so will result in you being not able to log in via ssh after the bulk build is finished or if the machine gets rebooted or crashes. You have been @@ -2165,6 +2194,7 @@ libs installed in /usr/local, etc. then become root and type: # cd /usr/pkgsrc # sh mk/bulk/build + If for some reason your last build didn't complete (power failure, system panic, ...), you can continue it by running: @@ -2258,7 +2288,7 @@ src/etc, be sure the following items are present and properly configured: 6. /usr/src (system sources, e. g. for sysutils/aperture): # ln -s ../disk1/cvs . - # ln -s cvs/src-2.0 src + # ln -s cvs/src-2.0 src 7. Create /var/db/pkg (not part of default install): @@ -2273,6 +2303,7 @@ src/etc, be sure the following items are present and properly configured: # cd /usr/sandbox/usr # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc + Do not mount/link this to the copy of your pkgsrc tree you do development in, as this will likely cause problems! @@ -2289,6 +2320,7 @@ steps: # cd /usr/sandbox/usr/pkgsrc # sh mk/bulk/do-sandbox-build + This will just jump inside the sandbox and start building. At the end of the build, mail will be sent with the results of the build. Created binary pkgs will be in /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/ @@ -2360,6 +2392,7 @@ chroot-# rm $HOME/.ssh/id-dsa* chroot-# ssh-keygen -t dsa chroot-# cat $HOME/.ssh/id-dsa.pub + Now take the output of id-dsa.pub and append it to your ~/.ssh/authorized_keys file on ftp.NetBSD.org. You can remove the key after the upload is done! @@ -2375,6 +2408,7 @@ chroot-# exit # cd /usr/sandbox/usr/pkgsrc # sh mk/bulk/do-sandbox-upload + The upload process may take quite some time. Use ls(1) or du(1) on the FTP server to monitor progress of the upload. The upload script will take care of not uploading restricted packages and putting vulnerable packages into the @@ -2383,7 +2417,7 @@ vulnerable subdirectory. After the upload has ended, first thing is to revoke ssh access: nbftp% vi ~/.ssh/authorized_keys -Gdd:x! + Gdd:x! Use whatever is needed to remove the key you've entered before! Last, move the uploaded packages out of the upload directory to have them accessible to @@ -2394,6 +2428,7 @@ nbftp% mv upload/* . nbftp% rmdir upload nbftp% chmod 755 . + 6.4. Creating a multiple CD-ROM packages collection After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set @@ -2413,6 +2448,7 @@ ISO 9660 images. # pkg_add /usr/pkgsrc/packages/All/cdpack # cdpack /usr/pkgsrc/packages/All /u2/images + If you wish to include a common set of files (COPYRIGHT, README, etc.) on each CD in the collection, then you need to create a directory which contains these files. e.g. @@ -2425,6 +2461,7 @@ files. e.g. # echo "echo Hello world" >> /tmp/common/bin/myscript # chmod 755 /tmp/common/bin/myscript + Now create the images: # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images @@ -2950,33 +2987,43 @@ Table of Contents 17.3.2. Using libtool on GNU packages that already support libtool 17.3.3. GNU Autoconf/Automake - 17.4. Fixing problems in the build phase - - 17.4.1. Compiling C and C++ code conditionally - 17.4.2. How to handle compiler bugs - 17.4.3. Undefined reference to "..." - - 17.5. Fixing problems in the install phase - - 17.5.1. Creating needed directories - 17.5.2. Where to install documentation - 17.5.3. Installing score files - 17.5.4. Packages containing perl scripts - 17.5.5. Packages with hardcoded paths to other interpreters - 17.5.6. Packages installing perl modules - 17.5.7. Packages installing info files - 17.5.8. Packages installing man pages - 17.5.9. Packages installing GConf2 data files - 17.5.10. Packages installing scrollkeeper data files - 17.5.11. Packages installing X11 fonts - 17.5.12. Packages installing GTK2 modules - 17.5.13. Packages installing SGML or XML data - 17.5.14. Packages installing extensions to the MIME database - 17.5.15. Packages using intltool - 17.5.16. Packages installing startup scripts - 17.5.17. Packages installing TeX modules - 17.5.18. Packages installing hicolor theme icons - 17.5.19. Packages installing desktop files + 17.4. Programming languages + + 17.4.1. C, C++, and Fortran + 17.4.2. Java + 17.4.3. Packages containing perl scripts + 17.4.4. Other programming languages + + 17.5. Fixing problems in the build phase + + 17.5.1. Compiling C and C++ code conditionally + 17.5.2. How to handle compiler bugs + 17.5.3. Undefined reference to "..." + 17.5.4. Running out of memory + + 17.6. Fixing problems in the install phase + + 17.6.1. Creating needed directories + 17.6.2. Where to install documentation + 17.6.3. Installing score files + 17.6.4. Packages with hardcoded paths to other interpreters + 17.6.5. Packages installing perl modules + 17.6.6. Packages installing info files + 17.6.7. Packages installing man pages + 17.6.8. Packages installing GConf2 data files + 17.6.9. Packages installing scrollkeeper data files + 17.6.10. Packages installing X11 fonts + 17.6.11. Packages installing GTK2 modules + 17.6.12. Packages installing SGML or XML data + 17.6.13. Packages installing extensions to the MIME database + 17.6.14. Packages using intltool + 17.6.15. Packages installing startup scripts + 17.6.16. Packages installing TeX modules + 17.6.17. Packages supporting running binaries in emulation + 17.6.18. Packages installing hicolor theme icons + 17.6.19. Packages installing desktop files + + 17.7. Marking packages as having problems 18. Debugging 19. Submitting and Committing @@ -3096,18 +3143,24 @@ for example from where to get it, how to configure, build, and install it. A package Makefile contains several sections that describe the package. In the first section there are the following variables, which should appear -exactly in the order given here. The ordering and grouping of variables is +exactly in the order given here. The order and grouping of the variables is mostly historical and has no further meaning. * DISTNAME is the basename of the distribution file to be downloaded from the package's website. * PKGNAME is the name of the package, as used by pkgsrc. You only need to - provide it if it differs from DISTNAME. Usually it is the directory name - together with the version number. It must match the regular expression ^ - [A-Za-z0-9][A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, - and contains only letters, digits, dashes, underscores, dots and plus - signs. + provide it if DISTNAME (which is the default) is not a good name for the + package in pkgsrc. Usually it is the pkgsrc directory name together with + the version number. It must match the regular expression ^[A-Za-z0-9] + [A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains + only letters, digits, dashes, underscores, dots and plus signs. + + * SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't + unique on a SVR4 system. The default is PKGNAME, which may be shortened + when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not + produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME + is limited to 5 characters. * CATEGORIES is a list of categories which the package fits in. You can choose any of the top-level directories of pkgsrc for it. @@ -3115,14 +3168,15 @@ mostly historical and has no further meaning. Currently the following values are available for CATEGORIES. If more than one is used, they need to be separated by spaces: - archivers cross geography meta-pkgs security - audio databases graphics misc shells - benchmarks devel ham multimedia sysutils - biology editors inputmethod net textproc - cad emulators lang news time - chat finance mail parallel wm - comms fonts math pkgtools www - converters games mbone print x11 + archivers cross geography meta-pkgs security + audio databases graphics misc shells + benchmarks devel ham multimedia sysutils + biology editors inputmethod net textproc + cad emulators lang news time + chat finance mail parallel wm + comms fonts math pkgtools www + converters games mbone print x11 + * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES are discussed in detail in Section 15.5, "The fetch phase". @@ -3161,11 +3215,11 @@ Other variables that affect the build: If a package doesn't create a subdirectory for itself (most GNU software does, for instance), but extracts itself in the current directory, you - should set WRKSRC= ${WRKDIR}. + should set WRKSRC=${WRKDIR}. If a package doesn't create a subdirectory with the name of DISTNAME but some different name, set WRKSRC to point to the proper name in ${WRKDIR}, - for example WRKSRC= ${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for + for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for other examples. The name of the working directory created by pkgsrc is taken from the @@ -3184,7 +3238,7 @@ Please pay attention to the following gotchas: * Replace /usr/local with "${PREFIX}" in all files (see patches, below). - * If the package installs any info files, see Section 17.5.7, "Packages + * If the package installs any info files, see Section 17.6.6, "Packages installing info files". 9.2. distinfo @@ -3234,14 +3288,27 @@ make a whole set of patches. You just have to backup files before you edit them to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using pkgvi again from the same package. If you upgrade a package this way, you can easily compare the new set of patches with the previously existing one with -patchdiff. +patchdiff. Copy the patches you want to use or update from the work/.newpatches +directory to patches/. When you have finished a package, remember to generate the checksums for the patch files by using the make makepatchsum command, see Section 9.2, "distinfo" . +When adding a patch that corrects a problem in the distfile (rather than e.g. +enforcing pkgsrc's view of where man pages should go), send the patch as a bug +report to the maintainer. This benefits non-pkgsrc users of the package, and +usually makes it possible to remove the patch in future version. + +If you want to share patches between multiple packages in pkgsrc, e.g. because +they use the same distfiles, set PATCHDIR to the path where the patch files can +be found, e.g.: + + PATCHDIR= ${.CURDIR}/../xemacs/patches + + Patch files that are distributed by the author or other maintainers can be -listed in $PATCHFILES. +listed in PATCHFILES. If it is desired to store any patches that should not be committed into pkgsrc, they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The @@ -3269,7 +3336,7 @@ from other OSes (e.g. Linux implementing kqueue), something that the above checks cannot take into account. Of course, checking for features generally involves more work on the -developer's side, but the resulting changes are clearner and there are chances +developer's side, but the resulting changes are cleaner and there are chances they will work on many other platforms. Not to mention that there are higher chances of being later integrated into the mainstream sources. Remember: It doesn't work unless it is right! @@ -3278,32 +3345,32 @@ Some typical examples: Table 9.1. Patching examples -+-----------------------------------------------------------------------------------------------+ -| Where | Incorrect | Correct | -|---------+------------------------------+------------------------------------------------------| -| |case ${target_os} in | | -|configure| netbsd*) have_kvm=yes ;;|AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)| -|script | *) have_kvm=no ;;| | -| | esac | | -| | | | -|---------+------------------------------+------------------------------------------------------| -| |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) | -|C source | # include | # include | -|file | #endif | #endif | -| | | | -|---------+------------------------------+------------------------------------------------------| -| |int |int | -| | monitor_file(...) | monitor_file(...) | -| | { | { | -| | #if defined(__NetBSD__) | #if defined(HAVE_KQUEUE) | -|C source | int fd = kqueue(); | int fd = kqueue(); | -|file | ... | ... | -| | #else | #else | -| | ... | ... | -| | #endif | #endif | -| | } | } | -| | | | -+-----------------------------------------------------------------------------------------------+ ++---------------------------------------------------------------------------------------------------------+ +| Where | Incorrect | Correct | +|---------+----------------------------------------+------------------------------------------------------| +| |case ${target_os} in | | +|configure| netbsd*) have_kvm=yes ;;|AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)| +|script | *) have_kvm=no ;;| | +| | esac | | +| | | | +|---------+----------------------------------------+------------------------------------------------------| +| |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) | +|C source | # include | # include | +|file | #endif | #endif | +| | | | +|---------+----------------------------------------+------------------------------------------------------| +| |int |int | +| | monitor_file(...) | monitor_file(...) | +| | { | { | +| | #if defined(__NetBSD__) | #if defined(HAVE_KQUEUE) | +|C source | int fd = kqueue(); | int fd = kqueue(); | +|file | ... | ... | +| | #else | #else | +| | ... | ... | +| | #endif | #endif | +| | } | } | +| | | | ++---------------------------------------------------------------------------------------------------------+ For more information, please read the Making packager-friendly software article @@ -3355,7 +3422,8 @@ INSTALL extraction and before files are moved in place, the second time after the files to install are moved in place. This can be used to do any custom procedures not possible with @exec commands in PLIST. See pkg_add(1) and - pkg_create(1) for more information. + pkg_create(1) for more information. See also Section 13.1, "Files and + directories outside the installation prefix". DEINSTALL @@ -3373,9 +3441,15 @@ MESSAGE can modify variables in it easily by using MESSAGE_SUBST in the package's Makefile: - MESSAGE_SUBST+= SOMEVAR="somevalue" + MESSAGE_SUBST+= SOMEVAR="somevalue" + + + replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution + is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE, + PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_GROUP. - replaces "${SOMEVAR}" with "somevalue" in MESSAGE. + You can display a different or additional files by setting the MESSAGE_SRC + variable. Its default is MESSAGE, if the file exists. ALTERNATIVES @@ -3432,11 +3506,17 @@ directory gets removed completely on clean. The default is ${.CURDIR}/work or $ 9.7. files/* If you have any files that you wish to be placed in the package prior to -configuration or building, you could place these files here and use a "${CP}" +configuration or building, you could place these files here and use a ${CP} command in the "pre-configure" target to achieve this. Alternatively, you could simply diff the file against /dev/null and use the patch mechanism to manage the creation of this file. +If you want to share files in this way with other packages, set the FILESDIR +variable to point to the other package's files directory, e.g.: + + FILESDIR=${.CURDIR}/../xemacs/files + + Chapter 10. Programming in Makefiles Table of Contents @@ -3705,7 +3785,8 @@ the PLIST file (or files, see below!). Be sure to add a RCS ID line as the first thing in any PLIST file you write: - @comment $NetBSD$ + @comment $NetBSD$ + 11.2. Semi-automatic PLIST generation @@ -3729,12 +3810,14 @@ scripting you like to it, but be careful with quoting. For example, to get all files inside the libdata/foo directory removed from the resulting PLIST: - PRINT_PLIST_AWK+= /^libdata\/foo/ { next; } + PRINT_PLIST_AWK+= /^libdata\/foo/ { next; } + And to get all the @dirrm lines referring to a specific (shared) directory converted to @comments: - PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; } + PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; } + 11.4. Variable substitution in PLIST @@ -3774,7 +3857,8 @@ If you want to change other variables not listed above, you can add variables and their expansions to this variable in the following way, similar to MESSAGE_SUBST (see Section 9.5, "Optional files"): - PLIST_SUBST+= SOMEVAR="somevalue" + PLIST_SUBST+= SOMEVAR="somevalue" + This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue". @@ -3790,7 +3874,8 @@ the PLIST file is done on a copy of it, not PLIST itself. To use one or more files as source for the PLIST used in generating the binary package, set the variable PLIST_SRC to the names of that file(s). The files are -later concatenated using cat(1), and order of things is important. +later concatenated using cat(1), and the order of things is important. The +default for PLIST_SRC is ${PKGDIR}/PLIST. 11.7. Platform-specific and differing PLISTs @@ -3819,7 +3904,8 @@ Within pkgsrc, you'll find both approaches. If a directory is shared by a few unrelated packages, it's often not worth to add an extra package to remove it. Therefore, one simply does: - @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE} + @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE} + in the PLISTs of all affected packages, instead of the regular "@dirrm" line. @@ -3836,8 +3922,9 @@ solutions are available: From now on, we'll discuss the second solution. To get an idea of the *-dirs packages available, issue: - % cd .../pkgsrc - % ls -d */*-dirs + % cd .../pkgsrc + % ls -d */*-dirs + Their use from other packages is very simple. The USE_DIRS variable takes a list of package names (without the "-dirs" part) together with the required @@ -3846,7 +3933,8 @@ version number (always pick the latest one when writing new packages). For example, if a package installs files under share/applications, it should have the following line in it: - USE_DIRS+= xdg-1.1 + USE_DIRS+= xdg-1.1 + After regenerating the PLIST using make print-PLIST, you should get the right (commented out) lines. @@ -3909,18 +3997,21 @@ The process of converting packages to use the buildlink3 framework If a dependency on a particular package is required for its libraries and headers, then we replace: - DEPENDS+= foo>=1.1.0:../../category/foo + DEPENDS+= foo>=1.1.0:../../category/foo + with - .include "../../category/foo/buildlink3.mk" + .include "../../category/foo/buildlink3.mk" + The buildlink3.mk files usually define the required dependencies. If you need a newer version of the dependency when using buildlink3.mk files, then you can define it in your Makefile; for example: - BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0 - .include "../../category/foo/buildlink3.mk" + BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0 + .include "../../category/foo/buildlink3.mk" + There are several buildlink3.mk files in pkgsrc/mk that handle special package issues: @@ -3968,32 +4059,34 @@ following command will generate a good starting point for buildlink3.mk files: % cd pkgsrc/category/pkgdir % createbuildlink >buildlink3.mk + 12.2.1. Anatomy of a buildlink3.mk file The following real-life example buildlink3.mk is taken from pkgsrc/graphics/ tiff: - # $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $ + # $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $ - BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH}+ - TIFF_BUILDLINK3_MK:= ${TIFF_BUILDLINK3_MK}+ + BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH}+ + TIFF_BUILDLINK3_MK:= ${TIFF_BUILDLINK3_MK}+ - .if !empty(BUILDLINK_DEPTH:M+) - BUILDLINK_DEPENDS+= tiff - .endif + .if !empty(BUILDLINK_DEPTH:M+) + BUILDLINK_DEPENDS+= tiff + .endif + + BUILDLINK_PACKAGES:= ${BUILDLINK_PACKAGES:Ntiff} + BUILDLINK_PACKAGES+= tiff - BUILDLINK_PACKAGES:= ${BUILDLINK_PACKAGES:Ntiff} - BUILDLINK_PACKAGES+= tiff + .if !empty(TIFF_BUILDLINK3_MK:M+) + BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1 + BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff + .endif # TIFF_BUILDLINK3_MK - .if !empty(TIFF_BUILDLINK3_MK:M+) - BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1 - BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff - .endif # TIFF_BUILDLINK3_MK + .include "../../devel/zlib/buildlink3.mk" + .include "../../graphics/jpeg/buildlink3.mk" - .include "../../devel/zlib/buildlink3.mk" - .include "../../graphics/jpeg/buildlink3.mk" + BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//} - BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//} The header and footer manipulate BUILDLINK_DEPTH, which is common across all buildlink3.mk files and is used to track at what depth we are including @@ -4115,44 +4208,45 @@ The only requirements of a builtin.mk file for pkg are: The following is the recommended template for builtin.mk files: - .if !defined(IS_BUILTIN.foo) - # - # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo" - # genuinely exists in the system or not. - # - IS_BUILTIN.foo?= no + .if !defined(IS_BUILTIN.foo) + # + # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo" + # genuinely exists in the system or not. + # + IS_BUILTIN.foo?= no + + # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package + # version can be determined. + # + . if !empty(IS_BUILTIN.foo:M[yY][eE][sS]) + BUILTIN_PKG.foo?= foo-1.0 + . endif + .endif # IS_BUILTIN.foo + + .if !defined(USE_BUILTIN.foo) + USE_BUILTIN.foo?= ${IS_BUILTIN.foo} + . if defined(BUILTIN_PKG.foo) + . for _depend_ in ${BUILDLINK_API_DEPENDS.foo} + . if !empty(USE_BUILTIN.foo:M[yY][eE][sS]) + USE_BUILTIN.foo!= \ + if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then \ + ${ECHO} "yes"; \ + else \ + ${ECHO} "no"; \ + fi + . endif + . endfor + . endif + .endif # USE_BUILTIN.foo + + CHECK_BUILTIN.foo?= no + .if !empty(CHECK_BUILTIN.foo:M[nN][oO]) + # + # Here we place code that depends on whether USE_BUILTIN.foo is set to + # "yes" or "no". + # + .endif # CHECK_BUILTIN.foo - # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package - # version can be determined. - # - . if !empty(IS_BUILTIN.foo:M[yY][eE][sS]) - BUILTIN_PKG.foo?= foo-1.0 - . endif - .endif # IS_BUILTIN.foo - - .if !defined(USE_BUILTIN.foo) - USE_BUILTIN.foo?= ${IS_BUILTIN.foo} - . if defined(BUILTIN_PKG.foo) - . for _depend_ in ${BUILDLINK_API_DEPENDS.foo} - . if !empty(USE_BUILTIN.foo:M[yY][eE][sS]) - USE_BUILTIN.foo!= \ - if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then \ - ${ECHO} "yes"; \ - else \ - ${ECHO} "no"; \ - fi - . endif - . endfor - . endif - .endif # USE_BUILTIN.foo - - CHECK_BUILTIN.foo?= no - .if !empty(CHECK_BUILTIN.foo:M[nN][oO]) - # - # Here we place code that depends on whether USE_BUILTIN.foo is set to - # "yes" or "no". - # - .endif # CHECK_BUILTIN.foo The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the base system. This should not be a base system software with similar @@ -4193,8 +4287,9 @@ neither or in both variables, then PREFER_PKGSRC has precedence over PREFER_NATIVE. For example, to require using pkgsrc versions of software for all but the most basic bits on a NetBSD system, you can set: - PREFER_PKGSRC= yes - PREFER_NATIVE= getopt skey tcp_wrappers + PREFER_PKGSRC= yes + PREFER_NATIVE= getopt skey tcp_wrappers + A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise it is simply ignored in that list. @@ -4262,14 +4357,27 @@ belong to a package. The names used in it are relative to the installation prefix (${PREFIX}), which means that it cannot register files outside this directory (absolute path names are not allowed). Despite this restriction, some packages need to install files outside this location; e.g., under ${VARBASE} or -${PKG_SYSCONFDIR}. +${PKG_SYSCONFDIR}. The only way to achieve this is to create such files during +installation time by using installation scripts. + +The generic installation scripts are shell scripts that can contain arbitrary +code. The list of scripts to execute is taken from the INSTALL_FILE variable, +which defaults to INSTALL. A similar variable exists for package removal +(DEINSTALL_FILE, whose default is DEINSTALL). These scripts can run arbitrary +commands, so they have the potential to create and manage files anywhere in the +file system. -The only way to achieve this is to create such files during installation time -by using the installation scripts. These scripts can run arbitrary commands, so -they have the potential to create and manage files anywhere in the file system. -Here is where pkginstall comes into play: it provides generic scripts to -abstract the manipulation of such files and directories based on variables set -in the package's Makefile. The rest of this section describes these variables. +Using these general installation files is not recommended, but may be needed in +some special cases. One reason for avoiding them is that the user has to trust +the packager that there is no unwanted or simply erroneous code included in the +installation script. Also, previously there were many similar scripts for the +same functionality, and fixing a common error involved finding and changing all +of them. + +The pkginstall framework offers another, standardized way. It provides generic +scripts to abstract the manipulation of such files and directories based on +variables set in the package's Makefile. The rest of this section describes +these variables. 13.1.1. Directory manipulation @@ -4792,15 +4900,17 @@ When choosing which of these variables to use, follow the following rules: The following lines are taken from pkgsrc/wm/scwm/Makefile: - EVAL_PREFIX+= GTKDIR=gtk+ - CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} - CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} - CONFIGURE_ARGS+= --enable-multibyte + EVAL_PREFIX+= GTKDIR=gtk+ + CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} + CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} + CONFIGURE_ARGS+= --enable-multibyte + Specific defaults can be defined for the packages evaluated using EVAL_PREFIX, by using a definition of the form: - GTKDIR_DEFAULT= ${LOCALBASE} + GTKDIR_DEFAULT= ${LOCALBASE} + where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair. @@ -5066,17 +5176,17 @@ For building a package, a rough equivalent of the following code is executed. .for d in ${BUILD_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \ - -f ${MAKEFILE} ${BUILD_TARGET} + -f ${MAKE_FILE} ${BUILD_TARGET} .endfor BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and -arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKEFILE +arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE and BUILD_TARGET may all be changed by the package. The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", -"make" otherwise. The default value of MAKEFILE is "Makefile", and BUILD_TARGET -defaults to "all". +"make" otherwise. The default value of MAKE_FILE is "Makefile", and +BUILD_TARGET defaults to "all". 15.13. The test phase @@ -5094,7 +5204,7 @@ consistency checks, registering the package, and so on. .for d in ${INSTALL_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \ - -f ${MAKEFILE} ${BUILD_TARGET} + -f ${MAKE_FILE} ${BUILD_TARGET} .endfor The variable's meanings are analogous to the ones in the build phase. @@ -5285,6 +5395,7 @@ clean-update # make clean CLEANDEPENDS=YES # make update + The following variables can be used either on the command line or in /etc/ mk.conf to alter the behaviour of make clean-update: @@ -5331,7 +5442,8 @@ cdrom-readme show-distfiles This target shows which distfiles and patchfiles are needed to build the - package. (DISTFILES and PATCHFILES, but not patches/*) + package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not + patches/*). show-downlevel @@ -5506,33 +5618,43 @@ Table of Contents 17.3.2. Using libtool on GNU packages that already support libtool 17.3.3. GNU Autoconf/Automake -17.4. Fixing problems in the build phase - - 17.4.1. Compiling C and C++ code conditionally - 17.4.2. How to handle compiler bugs - 17.4.3. Undefined reference to "..." - -17.5. Fixing problems in the install phase - - 17.5.1. Creating needed directories - 17.5.2. Where to install documentation - 17.5.3. Installing score files - 17.5.4. Packages containing perl scripts - 17.5.5. Packages with hardcoded paths to other interpreters - 17.5.6. Packages installing perl modules - 17.5.7. Packages installing info files - 17.5.8. Packages installing man pages - 17.5.9. Packages installing GConf2 data files - 17.5.10. Packages installing scrollkeeper data files - 17.5.11. Packages installing X11 fonts - 17.5.12. Packages installing GTK2 modules - 17.5.13. Packages installing SGML or XML data - 17.5.14. Packages installing extensions to the MIME database - 17.5.15. Packages using intltool - 17.5.16. Packages installing startup scripts - 17.5.17. Packages installing TeX modules - 17.5.18. Packages installing hicolor theme icons - 17.5.19. Packages installing desktop files +17.4. Programming languages + + 17.4.1. C, C++, and Fortran + 17.4.2. Java + 17.4.3. Packages containing perl scripts + 17.4.4. Other programming languages + +17.5. Fixing problems in the build phase + + 17.5.1. Compiling C and C++ code conditionally + 17.5.2. How to handle compiler bugs + 17.5.3. Undefined reference to "..." + 17.5.4. Running out of memory + +17.6. Fixing problems in the install phase + + 17.6.1. Creating needed directories + 17.6.2. Where to install documentation + 17.6.3. Installing score files + 17.6.4. Packages with hardcoded paths to other interpreters + 17.6.5. Packages installing perl modules + 17.6.6. Packages installing info files + 17.6.7. Packages installing man pages + 17.6.8. Packages installing GConf2 data files + 17.6.9. Packages installing scrollkeeper data files + 17.6.10. Packages installing X11 fonts + 17.6.11. Packages installing GTK2 modules + 17.6.12. Packages installing SGML or XML data + 17.6.13. Packages installing extensions to the MIME database + 17.6.14. Packages using intltool + 17.6.15. Packages installing startup scripts + 17.6.16. Packages installing TeX modules + 17.6.17. Packages supporting running binaries in emulation + 17.6.18. Packages installing hicolor theme icons + 17.6.19. Packages installing desktop files + +17.7. Marking packages as having problems 17.1. General operation @@ -5583,11 +5705,13 @@ The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of an interactive stage which will be needed, and this should be set in the package's Makefile, e.g.: - INTERACTIVE_STAGE= build + INTERACTIVE_STAGE= build + Multiple interactive stages can be specified: - INTERACTIVE_STAGE= configure install + INTERACTIVE_STAGE= configure install + 17.1.4. Handling licenses @@ -5613,23 +5737,26 @@ Denoting that a package is covered by a particular license is done by placing the license in pkgsrc/licenses and setting the LICENSE variable to a string identifying the license, e.g. in graphics/xv: - LICENSE= xv-license + LICENSE= xv-license + When trying to build, the user will get a notice that the package is covered by a license which has not been accepted: - % make - ===> xv-3.10anb9 has an unacceptable license: xv-license. - ===> To view the license, enter "/usr/bin/make show-license". - ===> To indicate acceptance, add this line to your /etc/mk.conf: - ===> ACCEPTABLE_LICENSES+=xv-license - *** Error code 1 + % make + ===> xv-3.10anb9 has an unacceptable license: xv-license. + ===> To view the license, enter "/usr/bin/make show-license". + ===> To indicate acceptance, add this line to your /etc/mk.conf: + ===> ACCEPTABLE_LICENSES+=xv-license + *** Error code 1 + The license can be viewed with make show-license, and if it is considered appropriate, the line printed above can be added to /etc/mk.conf to indicate acceptance of the particular license: - ACCEPTABLE_LICENSES+=xv-license + ACCEPTABLE_LICENSES+=xv-license + When adding a package with a new license, the license text should be added to pkgsrc/licenses for displaying. A list of known licenses can be seen in this @@ -5677,7 +5804,8 @@ set to note these restrictions: Distfiles may not be placed on FTP. Set this variable to ${RESTRICTED} if re-distribution of the source code or other distfile(s) via the Internet is - not allowed. + not allowed. If this variable is not set, the distfile(s) will be mirrored + on ftp.NetBSD.org. Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic make variables to denote restrictions is deprecated, because they unconditionally @@ -5703,7 +5831,8 @@ should be noted as a BUILD_DEPENDS. The format for a BUILD_DEPENDS and a DEPENDS definition is: - :../..// + :../..// + Please note that the "pre-req-package-name" may include any of the wildcard version numbers recognized by pkg_info(1). @@ -5711,22 +5840,26 @@ version numbers recognized by pkg_info(1). 1. If your package needs another package's binaries or libraries to build or run, and if that package has a buildlink3.mk file available, use it: - .include "../../graphics/jpeg/buildlink3.mk" + .include "../../graphics/jpeg/buildlink3.mk" + 2. If your package needs to use another package to build itself and there is no buildlink3.mk file available, use the BUILD_DEPENDS definition: - BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf + BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf + 3. If your package needs a library with which to link and again there is no buildlink3.mk file available, this is specified using the DEPENDS definition. For example: - DEPENDS+= xpm-3.4j:../../graphics/xpm + DEPENDS+= xpm-3.4j:../../graphics/xpm + You can also use wildcards in package dependences: - DEPENDS+= xpm-[0-9]*:../../graphics/xpm + DEPENDS+= xpm-[0-9]*:../../graphics/xpm + Note that such wildcard dependencies are retained when creating binary packages. The dependency is checked when installing the binary package and @@ -5739,7 +5872,8 @@ version numbers recognized by pkg_info(1). Wildcards can also be used to specify that a package will only build against a certain minimum version of a pre-requisite: - DEPENDS+= tiff>=3.5.4:../../graphics/tiff + DEPENDS+= tiff>=3.5.4:../../graphics/tiff + This means that the package will build against version 3.5.4 of the tiff library or newer. Such a dependency may be warranted if, for example, the @@ -5751,7 +5885,8 @@ version numbers recognized by pkg_info(1). ABI changes that do not prevent a package from building correctly. Such recommendations can be expressed using ABI_DEPENDS: - ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff + ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff + In addition to the above DEPENDS line, this denotes that while a package will build against tiff>=3.5.4, at least version 3.6.1 is recommended. @@ -5779,7 +5914,8 @@ version numbers recognized by pkg_info(1). variable. The print/lyx package needs to be able to execute the latex binary from the teTeX package when it runs, and that is specified: - DEPENDS+= teTeX-[0-9]*:../../print/teTeX + DEPENDS+= teTeX-[0-9]*:../../print/teTeX + The comment about wildcard dependencies from previous paragraph applies here, too. @@ -5808,11 +5944,13 @@ In this case you can set CONFLICTS to a space-separated list of packages For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus you set in pkgsrc/x11/Xaw3d/Makefile: - CONFLICTS= Xaw-Xpm-[0-9]* + CONFLICTS= Xaw-Xpm-[0-9]* + and in pkgsrc/x11/Xaw-Xpm/Makefile: - CONFLICTS= Xaw3d-[0-9]* + CONFLICTS= Xaw3d-[0-9]* + Packages will automatically conflict with other packages with the name prefix and a different version string. "Xaw3d-1.5" e.g. will automatically conflict @@ -5861,18 +5999,23 @@ a weekly cron job. When making fixes to an existing package it can be useful to change the version number in PKGNAME. To avoid conflicting with future versions by the original author, a "nb1", "nb2", ... suffix can be used on package versions by setting -PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the pkg tools. e.g. +PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools. +e.g. + + DISTNAME= foo-17.42 + PKGREVISION= 9 - DISTNAME= foo-17.42 - PKGREVISION= 9 -will result in a PKGNAME of "foo-17.42nb9". +will result in a PKGNAME of "foo-17.42nb9". If you want to use the original +value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use +PKGNAME_NOREV. When a new release of the package is released, the PKGREVISION should be removed, e.g. on a new minor release of the above package, things should be like: - DISTNAME= foo-17.43 + DISTNAME= foo-17.43 + PKGREVISION should be incremented for any non-trivial change in the resulting binary package. Without a PKGREVISION bump, someone with the previous version @@ -5882,16 +6025,19 @@ trivial that no reasonable person would want to upgrade", and this is the rough test for when increasing PKGREVISION is appropriate. Examples of changes that do not merit increasing PKGREVISION are: -Changing HOMEPAGE, MAINTAINER, or comments in Makefile. -Changing build variables if the resulting binary package is the same. -Changing DESCR. -Adding PKG_OPTIONS if the default options don't change. + Changing HOMEPAGE, MAINTAINER, + or comments in Makefile. + Changing build variables if the resulting binary package is the same. + Changing DESCR. + Adding PKG_OPTIONS if the default options don't change. + Examples of changes that do merit an increase to PKGREVISION include: -Security fixes -Changes or additions to a patch file -Changes to the PLIST + Security fixes + Changes or additions to a patch file + Changes to the PLIST + PKGREVISION must also be incremented when dependencies have ABI changes. @@ -5902,13 +6048,14 @@ replacement text varies, patches alone cannot help. This is where the SUBST framework comes in. It provides an easy-to-use interface for replacing text in files. Example: - SUBST_CLASSES+= fix-paths - SUBST_STAGE.fix-paths= pre-configure - SUBST_MESSAGE.fix-paths= Fixing absolute paths. - SUBST_FILES.fix-paths= src/*.c - SUBST_FILES.fix-paths+= scripts/*.sh - SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g' - SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g' + SUBST_CLASSES+= fix-paths + SUBST_STAGE.fix-paths= pre-configure + SUBST_MESSAGE.fix-paths= Fixing absolute paths. + SUBST_FILES.fix-paths= src/*.c + SUBST_FILES.fix-paths+= scripts/*.sh + SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g' + SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g' + SUBST_CLASSES is a list of identifiers that are used to identify the different SUBST blocks that are defined. The SUBST framework is heavily used by pkgsrc, @@ -5959,9 +6106,10 @@ information to apply for a password, or must pay for the source, or whatever, you can set FETCH_MESSAGE to a list of lines that are displayed to the user before aborting the build. Example: - FETCH_MESSAGE= "Please download the files" - FETCH_MESSAGE+= " "${DISTFILES:Q} - FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"." + FETCH_MESSAGE= "Please download the files" + FETCH_MESSAGE+= " "${DISTFILES:Q} + FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"." + 17.2.2. How to handle modified distfiles with the 'old' name @@ -5972,13 +6120,14 @@ checksum will no longer match. The contents of the new distfile should be compared against the old one before changing anything, to make sure the distfile was really updated on purpose, and that no trojan horse or so crept in. Then, the correct way to work around this is to set DIST_SUBDIR to a unique -directory name, usually based on PKGNAME_NOREV. In case this happens more -often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can -be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget regenerating the -distinfo file after that, since it contains the DIST_SUBDIR path in the -filenames. Furthermore, a mail to the package's authors seems appropriate -telling them that changing distfiles after releases without changing the file -names is not good practice. +directory name, usually based on PKGNAME_NOREV. All DISTFILES and PATCHFILES +for this package will be put in that subdirectory of the local distfiles +directory. In case this happens more often, PKGNAME can be used (thus including +the nbX suffix) or a date stamp can be appended, like ${PKGNAME_NOREV} +-YYYYMMDD. Do not forget regenerating the distinfo file after that, since it +contains the DIST_SUBDIR path in the filenames. Furthermore, a mail to the +package's authors seems appropriate telling them that changing distfiles after +releases without changing the file names is not good practice. 17.3. Fixing problems in the configure phase @@ -5993,7 +6142,7 @@ devel/libtool pkg can help here, as it just "knows" how to build both static and dynamic libraries from a set of source files, thus being platform-independent. -Here's how to use libtool in a pkg in seven simple steps: +Here's how to use libtool in a package in seven simple steps: 1. Add USE_LIBTOOL=yes to the package Makefile. @@ -6006,8 +6155,9 @@ Here's how to use libtool in a pkg in seven simple steps: 3. For the linking of the library, remove any "ar", "ranlib", and "ld -Bshareable" commands, and instead use: - ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} \ - -rpath ${PREFIX}/lib -version-info major:minor + ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} \ + -rpath ${PREFIX}/lib -version-info major:minor + Note that the library is changed to have a .la extension, and the objects are changed to have a .lo extension. Change OBJS as necessary. This @@ -6018,22 +6168,23 @@ Here's how to use libtool in a pkg in seven simple steps: From the libtool manual: - So, libtool library versions are described by three integers: + So, libtool library versions are described by three integers: - CURRENT - The most recent interface number that this library implements. + CURRENT + The most recent interface number that this library implements. - REVISION - The implementation number of the CURRENT interface. + REVISION + The implementation number of the CURRENT interface. - AGE - The difference between the newest and oldest interfaces that - this library implements. In other words, the library implements - all the interface numbers in the range from number `CURRENT - - AGE' to `CURRENT'. + AGE + The difference between the newest and oldest interfaces that + this library implements. In other words, the library implements + all the interface numbers in the range from number `CURRENT - + AGE' to `CURRENT'. + + If two libraries have identical CURRENT and AGE numbers, then the + dynamic linker chooses the library with the greater REVISION number. - If two libraries have identical CURRENT and AGE numbers, then the - dynamic linker chooses the library with the greater REVISION number. The "-release" option will produce different results for a.out and ELF (excluding symlinks) in only one case. An ELF library of the form @@ -6058,18 +6209,21 @@ Here's how to use libtool in a pkg in seven simple steps: (such as "-L../somelib"), because it expects you to change that argument to be the .la file. e.g. - ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib + ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib + should be changed to: - ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la + ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la + and it will do the right thing with the libraries. 6. When installing libraries, preface the install(1) or cp(1) command with "$ {LIBTOOL} --mode=install", and change the library name to .la. e.g. - ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib + ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib + This will install the static .a, shared library, any needed symlinks, and run ldconfig(8). @@ -6119,27 +6273,29 @@ executed in a pre-configure target. For packages that need only autoconf: - AUTOCONF_REQD= 2.50 # if default version is not good enough - USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13 - ... + AUTOCONF_REQD= 2.50 # if default version is not good enough + USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13 + ... - pre-configure: - cd ${WRKSRC}; autoconf + pre-configure: + cd ${WRKSRC}; autoconf + + ... - ... and for packages that need automake and autoconf: - AUTOMAKE_REQD= 1.7.1 # if default version is not good enough - USE_TOOLS+= automake # use "automake14" for automake-1.4 - ... + AUTOMAKE_REQD= 1.7.1 # if default version is not good enough + USE_TOOLS+= automake # use "automake14" for automake-1.4 + ... + + pre-configure: + cd ${WRKSRC}; \ + aclocal; autoheader; \ + automake -a --foreign -i; autoconf - pre-configure: - cd ${WRKSRC}; \ - aclocal; autoheader; \ - automake -a --foreign -i; autoconf + ... - ... Packages which use GNU Automake will almost certainly require GNU Make. @@ -6149,7 +6305,56 @@ automake sequence. This is prevented by touching various files in the configure stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE= NO in the package Makefile. -17.4. Fixing problems in the build phase +17.4. Programming languages + +17.4.1. C, C++, and Fortran + +Compilers for the C, C++, and Fortran languages comes with the NetBSD base +system. By default, pkgsrc assumes that a package is written in C and will hide +all other compilers (via the wrapper framework, see Chapter 12, Buildlink +methodology). + +To declare which language's compiler a package needs, set the USE_LANGUAGES +variable. Allowed values currently are "c", "c++", and "fortran" (and any +combination). The default is "c". Packages using GNU configure scripts, even if +written in C++, usually need a C compiler for the configure phase. + +17.4.2. Java + +If a program is written in Java, use the Java framework in pkgsrc. The package +must include ../../mk/java-vm.mk. This Makefile fragment provides the following +variables: + + * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is + set to "run", then there is only a runtime dependency on the JDK. The + default is "yes", which also adds a build dependency on the JDK. + + * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The + supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2 + implementation, "1.4" insists on versions 1.4 or above, and "1.5" only + accepts versions 1.5 or above. This variable is not set by default. + +17.4.3. Packages containing perl scripts + +If your package contains interpreted perl scripts, add "perl" to the USE_TOOLS +variable and set REPLACE_PERL to ensure that the proper interpreter path is +set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that +you want adjusted. Every occurrence of */bin/perl will be replaced with the +full path to the perl executable. + +If a particular version of perl is needed, set the PERL5_REQD variable to the +version number. The default is "5.0". + +See Section 17.6.5, "Packages installing perl modules" for information about +handling perl modules. + +17.4.4. Other programming languages + +Currently, there is no special handling for other languages in pkgsrc. If a +compiler package provides a buildlink3.mk file, include that, otherwise just +add a (build) dependency on the appropriate compiler package. + +17.5. Fixing problems in the build phase The most common failures when building a package are that some platforms do not provide certain header files, functions or libraries, or they provide the @@ -6157,7 +6362,7 @@ functions in a library that the original package author didn't know. To work around this, you can rewrite the source code in most cases so that it does not use the missing functions or provides a replacement function. -17.4.1. Compiling C and C++ code conditionally +17.5.1. Compiling C and C++ code conditionally If a package already comes with a GNU configure script, the preferred way to fix the build failure is to change the configure script, not the code. In the @@ -6174,7 +6379,7 @@ the compiler that is used. For example, if you want to conditionally compile code on Solaris, don't use __sun__, as the SunPro compiler does not define it. Use __sun instead. -17.4.1.1. C preprocessor macros to identify the operating system +17.5.1.1. C preprocessor macros to identify the operating system To distinguish between 4.4 BSD-derived systems and the rest of the world, you should use the following code. @@ -6197,19 +6402,19 @@ macros. OpenBSD __OpenBSD__ Solaris sun, __sun -17.4.1.2. C preprocessor macros to identify the hardware architecture +17.5.1.2. C preprocessor macros to identify the hardware architecture i386 i386, __i386, __i386__ MIPS __mips SPARC sparc, __sparc -17.4.1.3. C preprocessor macros to identify the compiler +17.5.1.3. C preprocessor macros to identify the compiler GCC __GNUC__ (major version), __GNUC_MINOR__ SunPro __SUNPRO_C (0x570 for version 5.7) SunPro C++ __SUNPRO_CC (0x580 for version 5.8) -17.4.2. How to handle compiler bugs +17.5.2. How to handle compiler bugs Some source files trigger bugs in the compiler, based on combinations of compiler version and architecture and almost always relation to optimisation @@ -6220,7 +6425,7 @@ Typically, a workaround involves testing the MACHINE_ARCH and compiler version, disabling optimisation for that combination of file, MACHINE_ARCH and compiler, and documenting it in pkgsrc/doc/HACKS. See that file for a number of examples. -17.4.3. Undefined reference to "..." +17.5.3. Undefined reference to "..." This compiler error often means that a package did not link to a shared library it needs. The following functions are known to cause this error message over @@ -6247,21 +6452,31 @@ and over. To fix these linker errors, it is often sufficient to say LIBS.OperatingSystem+ = -lfoo to the package Makefile and then say bmake clean; bmake. -17.5. Fixing problems in the install phase +17.5.4. Running out of memory + +Sometimes packages fail to build because the compiler runs into an operating +system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be +told to unlimit the resources. Currently, the allowed values are "datasize" and +"stacksize" (or both). Setting this variable is similar to running the shell +builtin ulimit command to raise the maximum data segment size or maximum stack +size of a process, respectively, to their hard limits. + +17.6. Fixing problems in the install phase -17.5.1. Creating needed directories +17.6.1. Creating needed directories The BSD-compatible install supplied with some operating systems cannot create more than one directory at a time. As such, you should call ${INSTALL_*_DIR} like this: - ${INSTALL_DATA_DIR} ${PREFIX}/dir1 - ${INSTALL_DATA_DIR} ${PREFIX}/dir2 + ${INSTALL_DATA_DIR} ${PREFIX}/dir1 + ${INSTALL_DATA_DIR} ${PREFIX}/dir2 + You can also just append "dir1 dir2" to the INSTALLATION_DIRS variable, which will automatically do the right thing. -17.5.2. Where to install documentation +17.6.2. Where to install documentation In general, documentation should be installed into ${PREFIX}/share/doc/$ {PKGBASE} or ${PREFIX}/share/doc/${PKGNAME} (the latter includes the version @@ -6282,7 +6497,7 @@ then, no additional subdirectory level is allowed in this case. This is usually achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/ gtk-doc is preferred though.) -17.5.3. Installing score files +17.6.3. Installing score files Certain packages, most of them in the games category, install a score file that allows all users on the system to record their highscores. In order for this to @@ -6297,30 +6512,25 @@ SETGIDGAME=YES will set all the other variables accordingly. A package should therefor never hard code file ownership or access permissions but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly. -17.5.4. Packages containing perl scripts - -If your package contains interpreted perl scripts, set REPLACE_PERL to ensure -that the proper interpreter path is set. REPLACE_PERL should contain a list of -scripts, relative to WRKSRC, that you want adjusted. - -17.5.5. Packages with hardcoded paths to other interpreters +17.6.4. Packages with hardcoded paths to other interpreters Your package may also contain scripts with hardcoded paths to other interpreters besides (or as well as) perl. To correct the full pathname to the script interpreter, you need to set the following definitions in your Makefile (we shall use tclsh in this example): - REPLACE_INTERPRETER+= tcl - REPLACE.tcl.old= .*/bin/tclsh - REPLACE.tcl.new= ${PREFIX}/bin/tclsh - REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed, - # relative to ${WRKSRC}, just as in REPLACE_PERL + REPLACE_INTERPRETER+= tcl + REPLACE.tcl.old= .*/bin/tclsh + REPLACE.tcl.new= ${PREFIX}/bin/tclsh + REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed, + # relative to ${WRKSRC}, just as in REPLACE_PERL + Note Before March 2006, these variables were called _REPLACE.* and _REPLACE_FILES.*. -17.5.6. Packages installing perl modules +17.6.5. Packages installing perl modules Makefiles of packages providing perl5 modules should include the Makefile fragment ../../lang/perl5/module.mk. It provides a do-configure target for the @@ -6333,14 +6543,15 @@ to the PLIST corresponding to the files listed in the installed .packlist file generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to a space-separated list of paths to packlist files, e.g.: - PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist + PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist + The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent the three locations in which perl5 modules may be installed, and may be used by perl5 packages that don't have a packlist. These three variables are also substituted for in the PLIST. -17.5.7. Packages installing info files +17.6.6. Packages installing info files Some packages install info files or use the "makeinfo" or "install-info" commands. INFO_FILES should be defined in the package Makefile so that INSTALL @@ -6375,7 +6586,7 @@ message. The script overriding makeinfo logs a message and according to the value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on error. -17.5.8. Packages installing man pages +17.6.7. Packages installing man pages All packages that install manual pages should install them into the same directory, so that there is one common place to look for them. In pkgsrc, this @@ -6403,7 +6614,7 @@ use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed. See Section 11.5, "Man page compression" for information on installation of compressed manual pages. -17.5.9. Packages installing GConf2 data files +17.6.8. Packages installing GConf2 data files If a package installs .schemas or .entries files, used by GConf2, you need to take some extra steps to make sure they get registered in the database: @@ -6430,7 +6641,7 @@ take some extra steps to make sure they get registered in the database: .entries files installed by the package, if any. Names must not contain any directories in them. -17.5.10. Packages installing scrollkeeper data files +17.6.9. Packages installing scrollkeeper data files If a package installs .omf files, used by scrollkeeper, you need to take some extra steps to make sure they get registered in the database: @@ -6446,7 +6657,7 @@ extra steps to make sure they get registered in the database: 3. Remove the share/omf directory from the PLIST. It will be handled by scrollkeeper. -17.5.11. Packages installing X11 fonts +17.6.10. Packages installing X11 fonts If a package installs font files, you will need to rebuild the fonts database in the directory where they get installed at installation and deinstallation @@ -6460,7 +6671,7 @@ Note that you should not create new directories for fonts; instead use the standard ones to avoid that the user needs to manually configure his X server to find them. -17.5.12. Packages installing GTK2 modules +17.6.11. Packages installing GTK2 modules If a package installs GTK2 immodules or loaders, you need to take some extra steps to get them registered in the GTK2 database properly: @@ -6483,7 +6694,7 @@ steps to get them registered in the GTK2 database properly: 5. Check the PLIST and remove any entries under the libdata/gtk-2.0 directory, as they will be handled automatically. -17.5.13. Packages installing SGML or XML data +17.6.12. Packages installing SGML or XML data If a package installs SGML or XML data files that need to be registered in system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some @@ -6509,7 +6720,7 @@ extra steps: (specifically, arguments recognized by the 'add' action). Note that you will normally not use this variable. -17.5.14. Packages installing extensions to the MIME database +17.6.13. Packages installing extensions to the MIME database If a package provides extensions to the MIME database by installing .xml files inside ${PREFIX}/share/mime/packages, you need to take some extra steps to @@ -6530,7 +6741,7 @@ ensure that the database is kept consistent with respect to these new files: 3. Remove any share/mime/* directories from the PLIST. They will be handled by the shared-mime-info package. -17.5.15. Packages using intltool +17.6.14. Packages using intltool If a package uses intltool during its build, include the ../../textproc/ intltool/buildlink3.mk file, which forces it to use the intltool package @@ -6540,7 +6751,7 @@ This tracks intltool's build-time dependencies and uses the latest available version; this way, the package benefits of any bug fixes that may have appeared since it was released. -17.5.16. Packages installing startup scripts +17.6.15. Packages installing startup scripts If a package contains a rc.d script, it won't be copied into the startup directory by default, but you can enable it, by adding the option @@ -6548,7 +6759,7 @@ PKG_RCD_SCRIPTS=YES in /etc/mk.conf. This option will copy the scripts into / etc/rc.d when a package is installed, and it will automatically remove the scripts when the package is deinstalled. -17.5.17. Packages installing TeX modules +17.6.16. Packages installing TeX modules If a package installs TeX packages into the texmf tree, the ls-R database of the tree needs to be updated. @@ -6574,15 +6785,28 @@ into PKG_LOCALTEXMFPREFIX, not PKG_TEXMFPREFIX. 3. Make sure that none of ls-R databases are included in PLIST, as they will be removed only by the teTeX-bin package. -17.5.18. Packages installing hicolor theme icons +17.6.17. Packages supporting running binaries in emulation + +There are some packages that provide libraries and executables for running +binaries from a one operating system on a different one (if the latter supports +it). One example is running Linux binaries on NetBSD. + +The pkgtools/rpm2pkg helps in extracting and packaging Linux rpm packages. + +The CHECK_SHLIBS can be set to no to avoid the check-shlibs target, which tests +if all libraries for each installed executable can be found by the dynamic +linker. Since the standard dynamic linker is run, this fails for emulation +packages, because the libraries used by the emulation are not in the standard +directories. + +17.6.18. Packages installing hicolor theme icons If a package installs images under the share/icons/hicolor and/or updates the share/icons/hicolor/icon-theme.cache database, you need to take some extra steps to make sure that the shared theme directory is handled appropriately and that the cache database is rebuilt: - 1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk instead of its - buildlink3.mk file. + 1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk. 2. Check the PLIST and remove the entry that refers to the theme cache. @@ -6592,7 +6816,7 @@ that the cache database is rebuilt: The best way to verify that the PLIST is correct with respect to the last two points is to regenerate it using make print-PLIST. -17.5.19. Packages installing desktop files +17.6.19. Packages installing desktop files If a package installs .desktop files under share/applications and these include MIME information, you need to take extra steps to ensure that they are @@ -6606,6 +6830,26 @@ registered into the MIME database: The best way to verify that the PLIST is correct with respect to the last point is to regenerate it using make print-PLIST. +17.7. Marking packages as having problems + +In some cases one does not have the time to solve a problem immediately. There +are currently two ways to declare that one knows that a package has problems. + + * The first way is to plainly mark it as broken. For this, one just sets the + variable BROKEN to the reason why the package is broken (similar to the + RESTRICTED variable). A user trying to build the package will immediately + be shown this message, and the build will not be even tried. + + * After each pkgsrc freeze period (a time when the tree is stabilized and a + new pkgsrc branch is cut), the packages that were not building in the + official branch build on the latest NetBSD release will be marked as broken + on that branch. This is done by setting the BROKEN_IN variable to the + branch name (or appending the branch name to it). If a user tries to build + such a package and the build fails, the user gets a message that says that + the package was broken on the respective branch(es). + +Both types of packages are removed from pkgsrc in irregular intervals. + Chapter 18. Debugging To check out all the gotchas when building a package, here are the steps that I @@ -6713,10 +6957,16 @@ Section 6.3.8, "Uploading results of a bulk build". First, check that your package is complete, compiles and runs well; see Chapter 18, Debugging and the rest of this document. Next, generate an uuencoded gzipped tar(1) archive that contains all files that make up the -package. Finally, send-pr with category "pkg", a synopsis which includes the -package name and version number, a short description of your package (contents -of the COMMENT variable or DESCR file are OK) and attach the archive to your -PR. +package. Finally, send this package to the pkgsrc bug tracking system, either +with the send-pr(1) command, or if you don't have that, go to the web page +http://www.NetBSD.org/Misc/send-pr.html, which contains some instructions and a +link to a form, where you can submit packages. + +In the form of the problem report, the category should be "pkg", the synopsis +should include the package name and version number, and the description field +should contain a short description of your package (contents of the COMMENT +variable or DESCR file are OK). The uuencoded package data should go into the +"fix" field. If you want to submit several packages, please send a separate PR for each one, it's easier for us to track things that way. @@ -7066,19 +7316,19 @@ Table 21.1. PLIST handling for GNOME packages +-----------------------------------------------------------------------------+ | If the package... | Then... | |-------------------------------------------+---------------------------------| -| |See Section 17.5.10, "Packages | +| |See Section 17.6.9, "Packages | |Installs OMF files under share/omf. |installing scrollkeeper data | | |files". | |-------------------------------------------+---------------------------------| -|Installs icons under the share/icons/ |See Section 17.5.18, "Packages | +|Installs icons under the share/icons/ |See Section 17.6.18, "Packages | |hicolor hierarchy or updates share/icons/ |installing hicolor theme icons". | |hicolor/icon-theme.cache. | | |-------------------------------------------+---------------------------------| -| |See Section 17.5.14, "Packages | +| |See Section 17.6.13, "Packages | |Installs files under share/mime/packages. |installing extensions to the MIME| | |database". | |-------------------------------------------+---------------------------------| -|Installs .desktop files under share/ |See Section 17.5.19, "Packages | +|Installs .desktop files under share/ |See Section 17.6.19, "Packages | |applications and these include MIME |installing desktop files". | |information. | | +-----------------------------------------------------------------------------+ -- cgit v1.2.3