From e8385e01f6ad7ae7027f465069105b595fa14cc3 Mon Sep 17 00:00:00 2001 From: rillig Date: Thu, 11 Jan 2007 03:48:18 +0000 Subject: regen --- doc/pkgsrc.html | 358 +++++++++++++++++++++++++++++++++----------------------- doc/pkgsrc.txt | 261 ++++++++++++++++++++++++----------------- 2 files changed, 363 insertions(+), 256 deletions(-) (limited to 'doc') diff --git a/doc/pkgsrc.html b/doc/pkgsrc.html index 895db5ee925..bf6df613aae 100644 --- a/doc/pkgsrc.html +++ b/doc/pkgsrc.html @@ -186,8 +186,11 @@
10.2. distinfo
10.3. patches/*
-
10.3.1. Patching guidelines
-
10.3.2. Feedback to the author
+
10.3.1. Structure of a single patch file
+
10.3.2. Creating patch files
+
10.3.3. Sources where the patch files come from
+
10.3.4. Patching guidelines
+
10.3.5. Feedback to the author
10.4. Other mandatory files
10.5. Optional files
@@ -444,7 +447,7 @@
C.4. misc: Miscellaneous things
C.5. packages*: Binary packages
C.6. current, -200xQy: +pkgsrc-200xQy: source packages
D. Editing guidelines for the pkgsrc guide
@@ -649,7 +652,7 @@ minutes!

The pkgsrc user's guide, describes how one can use one of the packages in the Package Collection, either by installing a precompiled binary package, - or by building one's own copy using the NetBSD package system. + or by building one's own copy using the NetBSD package system. The second part, The pkgsrc developer's guide, explains how to prepare a package so it can be easily built by other NetBSD users without knowing about the package's building details. The third part, @@ -898,7 +901,7 @@ and dashes.

quarterly basis from the current branch and only gets modified for security updates. The names of the stable branches are built from the year and the quarter, for example - 2006Q1.

+ 2006Q3.

The second step is to decide how you want to download pkgsrc. You can get it as a tar file, via SUP, or via CVS. All three ways are described here.

@@ -912,8 +915,8 @@ and dashes.

The tar file for the current branch is in the directory current and is called pkgsrc.tar.gz. It is autogenerated daily.

-

The tar file for the stable branch 2006Q1 is in the - directory 2006Q1 and is also called pkgsrc.tar.gz.

+

The tar file for the stable branch 2006Q3 is in the + directory pkgsrc-2006Q3 and is also called pkgsrc-2006Q3.tar.gz.

After downloading the tar file, change to the directory where you want to have pkgsrc. This is usually /usr. Then, run gzcat @@ -960,7 +963,7 @@ and dashes.

/usr. In that directory you run the checkout command, which is cvs -q checkout -P pkgsrc for the current branch and cvs -q - checkout -rpkgsrc-2006Q1 -P pkgsrc for the stable + checkout -rpkgsrc-2006Q3 -P pkgsrc for the stable branch. This command will create a directory called pkgsrc with all the pkgsrc files in it.

@@ -1013,7 +1016,7 @@ and dashes.

by adding the option “-A” after the “update” keyword. To switch from the current branch back to the stable branch, add the - “-rpkgsrc-2006Q1” option.

+ “-rpkgsrc-2006Q3” option.

@@ -1166,9 +1169,9 @@ directory on ftp.NetBSD.org.

Interix 3.5 -20051010 -binary kit -binary packages +20061106 +binary kit +  IRIX 6.5 n32-bit ABI @@ -1196,7 +1199,7 @@ directory on ftp.NetBSD.org.

OpenBSD 3.5/i386 -20040507 +20040703 binary kit   @@ -1208,7 +1211,7 @@ directory on ftp.NetBSD.org.

Slackware Linux 9/i386 -20031023 +20040703 binary kit   @@ -1226,9 +1229,9 @@ directory on ftp.NetBSD.org.

Solaris 9/sparc -20041208 -binary kit -binary packages +20060713 +binary kit +  Solaris 9/i386 @@ -1395,9 +1398,12 @@ file and inspect the contents before extracting it. 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.)

+

Services for Unix 3.5 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, but other parts of libc may also be lacking.)

+

Services for Unix Applications (aka SUA) is an integrated component + of Windows Server 2003 R2 and Windows Vista. As of this writing, SUA's + Interix 5.x subsystem not been tested with pkgsrc.

3.3.3.1. When installing Interix/SFU

@@ -1428,6 +1434,16 @@ file and inspect the contents before extracting it. 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.

+

In addition to the hotfix noted above, it may be necessary to + disable Data Execution Prevention entirely to make Interix functional. + This may happen only with certain types of CPUs; the cause is not fully + understood at this time. If gcc or other applications still segfault + repeatedly after installing one of the hotfixes note above, the + following option can be added to the appropriate "boot.ini" line on the + Windows boot drive: /NoExecute=AlwaysOff + (WARNING, this will disable DEP completely, which may be a security + risk if applications are often run as a user in the Administrators + group!)

@@ -1493,11 +1509,6 @@ file and inspect the contents before extracting it. 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.

  • X11 acceleration:

    @@ -1596,7 +1607,7 @@ file and inspect the contents before extracting it. 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 + but want to make sure that MIPSPro is used, please set your PATH to not include the location of gcc (often /usr/freeware/bin), and (important) pass the '--preserve-path' flag.

    @@ -1721,7 +1732,7 @@ file and inspect the contents before extracting it. 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.

    +

    Binary packages of gcc can be found through http://www.sunfreeware.com/.

    • @@ -1749,7 +1760,7 @@ file and inspect the contents before extracting it.

    -3.3.7.3. Buildling 64-bit binaries with SunPro

    +3.3.7.3. Building 64-bit binaries with SunPro

    Building 64-bit binaries is a little trickier. First, you need to bootstrap pkgsrc in 64-bit mode. One problem here is that while building one of the programs in the bootstrap kit @@ -2008,13 +2019,13 @@ and you can still use binary packages from someone else.

    FTP site at ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/vulnerabilities.

    - Through security/audit-packages, + Through security/audit-packages, this list can be downloaded automatically, and a security audit of all packages installed on a system can take place.

    - There are two components to + There are two components to security/audit-packages. The first component, “download-vulnerability-list”, is for downloading the list of vulnerabilities from the NetBSD FTP site. The second @@ -2036,7 +2047,7 @@ and you can still use binary packages from someone else.

    4.1.6. Finding if newer versions of your installed packages are in pkgsrc

    - Install pkgtools/pkglint and run + Install pkgtools/pkglint and run lintpkgsrc with the “-i” argument to check if your packages are up-to-date, e.g.

    @@ -2137,7 +2148,7 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10.00 and adding the definitions there.

    If a package depends on many other packages (such as - meta-pkgs/kde3), the build process may + meta-pkgs/kde3), the build process may alternate between periods of downloading source, and compiling. To ensure you have all the source downloaded initially you can run the command: @@ -2352,7 +2363,10 @@ works.

    and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/.

  • BINPKG_SITES: - List of sites carrying binary pkgs.

    • + List of sites carrying binary pkgs. rel and + arch are replaced with OS + release (“2.0”, etc.) and architecture + (“mipsel”, etc.).

  • ACCEPTABLE_LICENSES: List of acceptable licenses. Whenever you try to build a package whose license is not in this list, you will get an error message @@ -2383,10 +2397,7 @@ works.

  • LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See Section 10.3, “patches/*” for more - information. rel and - arch are replaced with OS - release (“2.0”, etc.) and architecture - (“mipsel”, etc.).

    • + information.

  • PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style Makefile. If this is not set, @@ -2649,7 +2660,8 @@ PKG_OPTIONS.apache= suexec 6.3.1. Configuration

    • -6.3.1.1. build.conf

    +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 @@ -2709,11 +2721,11 @@ PKG_OPTIONS.apache= suexec 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 + (pkgsrc/mk/check/check-files.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 + (pkgsrc/mk/check/check-interpreter.mk) can be set to “yes” to check that the installed “#!”-scripts will find their interpreter.

    • @@ -2730,7 +2742,8 @@ PKG_OPTIONS.apache= suexec

    -6.3.1.3. pre-build.local

    +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 @@ -2972,17 +2985,17 @@ PKG_OPTIONS.apache= suexec

    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", +

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

    Please use appropriate values for "packages-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
    +
    RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/packages-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
    +
    nbftp% mkdir -p -m 750 /pub/NetBSD/packages/packages-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 @@ -3024,7 +3037,7 @@ chroot-# exit upload directory to have them accessible to everyone:

    -nbftp% cd /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch
+nbftp% cd /pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch
 nbftp% mv upload/* .
 nbftp% rmdir upload
 nbftp% chmod 755 .
@@ -3102,7 +3115,7 @@ are:
    
     LOCALBASE=              /usr/pkg
     PKG_SYSCONFBASE=        /usr/pkg/etc
     VARBASE=                /var
-    PKGDBDIR=               /var/db/pkg
+    PKG_DBDIR=              /var/db/pkg

    In unprivileged mode (when pkgsrc has been installed as any other user), the default locations are:

    @@ -3110,7 +3123,7 @@ user), the default locations are:

    LOCALBASE= ${HOME}/pkg PKG_SYSCONFBASE= ${HOME}/pkg/etc VARBASE= ${HOME}/pkg/var - PKGDBDIR= ${HOME}/pkg/var/db/pkg + PKG_DBDIR= ${HOME}/pkg/var/db/pkg

    What these four directories are for, and what they look like is explained below.

    @@ -3133,7 +3146,8 @@ itself.

    -7.1. File system layout in ${LOCALBASE}

    +7.1. File system layout in ${LOCALBASE} +

    The following directories exist in a typical pkgsrc installation in ${LOCALBASE}.

    @@ -3198,7 +3212,8 @@ installation.

    -7.2. File system layout in ${VARBASE}

    +7.2. File system layout in ${VARBASE} +
    db/pkg (the usual location of ${PKG_DBDIR})
    @@ -3378,7 +3393,7 @@ them by setting UNPRIVILEGED_USER and bootstrap script will ease non-root configuration when given the “--ignore-user-check” flag, as it will choose and use multiple default directories under ~/pkg as the -installation targets. These directories can be overriden by the +installation targets. These directories can be overridden by the “--prefix” flag provided by the script, as well as some others that allow finer tuning of the tree layout.

    @@ -3684,8 +3699,11 @@ anymore, you can remove that file and run cvs -q u
    10.2. distinfo
    10.3. patches/*
    -
    10.3.1. Patching guidelines
    -
    10.3.2. Feedback to the author
    +
    10.3.1. Structure of a single patch file
    +
    10.3.2. Creating patch files
    +
    10.3.3. Sources where the patch files come from
    +
    10.3.4. Patching guidelines
    +
    10.3.5. Feedback to the author
    10.4. Other mandatory files
    10.5. Optional files
    @@ -4225,8 +4243,11 @@ everything worked.

    10.2. distinfo
    10.3. patches/*
    -
    10.3.1. Patching guidelines
    -
    10.3.2. Feedback to the author
    +
    10.3.1. Structure of a single patch file
    +
    10.3.2. Creating patch files
    +
    10.3.3. Sources where the patch files come from
    +
    10.3.4. Patching guidelines
    +
    10.3.5. Feedback to the author
    10.4. Other mandatory files
    10.5. Optional files
    @@ -4244,7 +4265,8 @@ files involved which are described in the following sections.

    -10.1. Makefile

    +10.1. Makefile +

    Building, installation and creation of a binary package are all controlled by the package's Makefile. The Makefile describes various things about @@ -4382,7 +4404,8 @@ sections.

    -10.2. distinfo

    +10.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 @@ -4405,29 +4428,55 @@ sections.

    10.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 +

    Many packages still don't work out-of-the box on the various + platforms that are supported by pkgsrc. Therefore, a number of custom + patch files are needed to make the package work. These patch files are + found in the patches/ directory.

    +

    In the patch phase, these patches are + applied to the files in WRKSRC directory after + extracting them, in alphabetic + order, so patch-aa is applied before patch-ab, etc.

    +
    +

    +10.3.1. Structure of a single patch file

    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.

    -

    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.

    -

    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 + problems. (To force patches to apply with fuzz you can set + PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch + should contain only changed for a single file, and no file should be + patched by more than one patch file. This helps to keep future + modifications simple.

    +

    Each patch file is structured as follows: In the first line, + there is the RCS Id of the patch itself. The second line should be + empty for aesthetic reasons. After that, there should be a comment for + each change that the patch does. There are a number of standard + cases:

    +
      +

    • Patches that replace the == + operator for test(1) with = in shell scripts + should contain a reference to , to avoid + redundant explanations.

      • +

    • Patches for commonly known vulnerabilities should + mention the vulnerability ID (CAN, CVE).

      • +

    • Patches that change source code should mention the + platform and other environment (for example, the compiler) that the + patch is needed for.

      • +
    +

    In all other cases, the patch should be commented so that any + developer who knows the code of the application can make some use of + the patch. Special care should be taken for the upstream developers, + since we generally want that they accept our patches, so we have less + work in the future.

    +
    +
    +

    +10.3.2. Creating patch files

    +

    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.

    + pkgdiff command 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 @@ -4448,13 +4497,17 @@ sections.

    maintainer. This benefits non-pkgsrc users of the package, and usually makes it possible to remove the patch in future version.

    +
    +
    +

    +10.3.3. Sources where the patch files come from

    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.

    @@ -4471,9 +4524,10 @@ sections.

    files in the named directory are expected to be patch files, and they are applied after pkgsrc patches are applied.

    +

    -10.3.1. Patching guidelines

    +10.3.4. Patching guidelines

    When fixing a portability issue in the code do not use preprocessor magic to check for the current operating system nor platform. Doing so hurts portability to other platforms because @@ -4575,7 +4629,7 @@ sections.

    -10.3.2. Feedback to the author

    +10.3.5. Feedback to the author

    Always, always, always feed back any portability fixes or improvements you do to a package to the mainstream developers. @@ -4583,8 +4637,8 @@ sections.

    and to ensure that future versions can be built out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will get the fixes straight from the packaged code.

    -

    This generally involves cleaning up the patches as described - in the following section (because sometimes the patches that are +

    This generally involves cleaning up the patches + (because sometimes the patches that are added to pkgsrc are quick hacks), filling bug reports in the appropriate trackers for the projects and working with the mainstream authors to accept your changes. It is @@ -4711,7 +4765,8 @@ sections.

    -10.6. work*

    +10.6. work* +

    When you type make, the distribution files are unpacked into the directory denoted by WRKDIR. It can be removed by running @@ -4724,7 +4779,8 @@ sections.

    -10.7. files/*

    +10.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 @@ -5076,7 +5132,8 @@ sections.

    -12.3. Tweaking output of make print-PLIST

    +12.3. Tweaking output of make print-PLIST +

    If you have used any of the *-dirs packages, as explained in Section 12.8, “Sharing directories between packages”, you may have noticed that make print-PLIST outputs a set of @@ -5172,7 +5229,8 @@ sections.

    -12.6. Changing PLIST source with PLIST_SRC

    +12.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). @@ -5354,7 +5412,7 @@ sections.

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

  • pgsql.buildlink3.mk will accept - either Postgres 7.4, 8.0, or 8.1, whichever is found installed. See + either Postgres 8.0, 8.1, or 8.2, 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 @@ -6056,7 +6114,7 @@ not specified.

         group
    -

    The numeric GID of the group may be set by defining +

    The numeric GID of the group may be set by defining PKG_GID.group.

    If a package needs to create the users and groups at an earlier stage, then it can set USERGROUP_PHASE to @@ -6143,7 +6201,8 @@ This variable should be set in /etc/mk.conf.

    -15.2. Converting packages to use bsd.options.mk

    +15.2. Converting packages to use bsd.options.mk +

    The following example shows how bsd.options.mk should be used by the hypothetical ``wibble'' package, either in the package @@ -6476,7 +6535,7 @@ support.” The file is sorted by option names.

    package.

    WRKDIR

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

    @@ -6565,6 +6624,7 @@ support.” The file is sorted by option names.

    ${MASTER_SITE_DEBIAN} ${MASTER_SITE_FREEBSD} ${MASTER_SITE_FREEBSD_LOCAL} + ${MASTER_SITE_GENTOO} ${MASTER_SITE_GNOME} ${MASTER_SITE_GNU} ${MASTER_SITE_GNUSTEP} @@ -6586,8 +6646,8 @@ support.” The file is sorted by option names.

    Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP contains backup sites - for packages that are maintained in ftp://ftp.NetBSD.org:/pub/NetBSD/packages/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local - package source distributions that are maintained in ftp://ftp.NetBSD.org:/pub/NetBSD/packages/distfiles/LOCAL_PORTS/.

    + for packages that are maintained in ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local + package source distributions that are maintained in ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/LOCAL_PORTS/.

    If you choose one of these predefined sites, you may want to specify a subdirectory of that site. Since these macros may expand to more than one actual site, you @@ -6605,7 +6665,7 @@ support.” The file is sorted by option names.

    16.5.2. How are the files fetched?

    The fetch phase makes sure that all the distfiles exist in a local directory - (DISTDIR), which can be set by the pkgsrc + (DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they are fetched using commands of the form

    @@ -6647,7 +6707,7 @@ support.” The file is sorted by option names.
    
     EXTRACT_ONLY variable to the list of those
     files.
    
 
    Extracting the files is usually done by a little
-    program, mk/scripts/extract, which
+    program, mk/extract/extract, which
     already knows how to extract various archive formats, so most
     likely you will not need to change anything here. But if you
     need, the following variables may help you:
    
@@ -6655,10 +6715,11 @@ support.” The file is sorted by option names.
    
 
    EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}
    
 
    Use these variables to override the default
       options for an extract command, which are defined in
-      mk/scripts/extract.
    
+      mk/extract/extract.
    
 
    EXTRACT_USING
    
 
    This variable can be set to
-      pax, tar or an
+      gtar, nbtar (which is the
+      default value), pax, or an
       absolute pathname pointing to the command with which tar
       archives should be
       extracted.
    
@@ -7107,7 +7168,7 @@ support.” The file is sorted by option names.
    
 
    
 
    Update the installation of the current package.  This
 	  differs from update in that it does not replace dependent
-	  packages.  You will need to install pkgsrc/pkgtools/pkg_tarup for this
+	  packages.  You will need to install pkgtools/pkg_tarup for this
 	  target to work.
    
 
    Be careful when using this
 	  target! There are no guarantees that dependent
@@ -7445,7 +7506,8 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
 
    
 
    
-18.1.2. How to pull in user-settable variables from mk.conf
    
+18.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
@@ -7589,7 +7651,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    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
+	whenever a binary package may not be made available
 	on the Internet.
  • @@ -7694,7 +7756,7 @@ TOOLS_PLATFORM.true?= true # shell builtin 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 + 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:

    @@ -7984,7 +8046,7 @@ TOOLS_PLATFORM.true?= true # shell builtin 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 + 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 @@ -8430,13 +8492,13 @@ TOOLS_PLATFORM.true?= true # shell builtin possibility. That compiler cannot handle the following code:

         extern int extern_func(int);
-    
+
     static inline int
     inline_func(int x)
     {
         return extern_func(x);
     }
-    
+
     int main(void)
     {
         return 0;
@@ -8827,8 +8889,8 @@ of functions.
    
 
    
 
    
 18.6.14. Packages using intltool
    
-
    If a package uses intltool during its build, include the
-    ../../textproc/intltool/buildlink3.mk file,
+
    If a package uses intltool during its build, add
+    intltool to the USE_TOOLS,
     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
@@ -9041,7 +9103,7 @@ of functions.

  • Reinstall the binary package:

    -
    # pkgadd .../examplepkg.tgz
    +
    # pkg_add .../examplepkg.tgz

  • Play with it. Make sure everything works.

  • @@ -9108,7 +9170,7 @@ of functions.

    20.3. General notes when adding, updating, or removing packages

    Please note all package additions, updates, moves, and - removals in pkgsrc/doc/CHANGES. It's very + removals in pkgsrc/doc/CHANGES-YYYY. It's very important to keep this file up to date and conforming to the existing format, because it will be used by scripts to automatically update pages on www.NetBSD.org and other @@ -9118,15 +9180,15 @@ of functions.

    there.

    When the PKGREVISION of a package is bumped, the change should appear in - pkgsrc/doc/CHANGES if it is security + pkgsrc/doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps that result from a dependency being updated should not be mentioned. In all other cases it's the developer's decision.

    There is a make target that helps in creating proper - CHANGES entries: make + CHANGES-YYYY entries: make changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The general - usage is to first make sure that your CHANGES + usage is to first make sure that your CHANGES-YYYY file is up-to-date (to avoid having to resolve conflicts later-on) and then to cd to the package directory. For package updates, make changes-entry is enough. @@ -9135,7 +9197,7 @@ of functions.

    "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in /etc/mk.conf if your local login name is not the same as your NetBSD login name. Don't forget to commit - the changes to pkgsrc/doc/CHANGES!

    + the changes to pkgsrc/doc/CHANGES-YYYY!

    @@ -9231,36 +9293,36 @@ place.

    • pkgsrc-users mailing list.

    -
    21.1. What is the difference between +
    21.1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
    -
    21.2. What is the difference between +
    21.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
    -
    21.3. What is the difference between +
    21.3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
    -
    21.4. What is the difference between +
    21.4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and BUILDLINK_LIBS?
    -
    21.5. Why does make show-var +
    21.5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
    -
    21.6. What does +
    21.6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand the := inside it.
    -
    21.7. Which mailing lists are there for package +
    21.7. Which mailing lists are there for package developers?
    -
    21.8. Where is the pkgsrc +
    21.8. Where is the pkgsrc documentation?
    21.9. I have a little time to kill. What shall I @@ -9272,7 +9334,7 @@ do? -21.1. +21.1.

    What is the difference between MAKEFLAGS, .MAKEFLAGS and @@ -9288,7 +9350,7 @@ do? -21.2. +21.2.

    What is the difference between MAKE, GMAKE and @@ -9306,7 +9368,7 @@ do? -21.3. +21.3.

    What is the difference between CC, PKG_CC and @@ -9324,7 +9386,7 @@ do? -21.4. +21.4.

    What is the difference between BUILDLINK_LDFLAGS, @@ -9337,7 +9399,7 @@ do? -21.5. +21.5.

    Why does make show-var VARNAME=BUILDLINK_PREFIX.foo @@ -9353,7 +9415,7 @@ do? -21.6. +21.6.

    What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I @@ -9377,7 +9439,7 @@ do? -21.7. +21.7.

    Which mailing lists are there for package developers?

    @@ -9402,7 +9464,7 @@ do? -21.8. +21.8.

    Where is the pkgsrc documentation?

    @@ -9439,7 +9501,7 @@ do?

  • Some parts of pkgsrc are only “implicitly documented”, that is the documentation exists only in the mind of the developer who wrote the code. To get this - information, use the the cvs annotate command + information, use the cvs annotate command to see who has written it and ask on the tech-pkg mailing list, so that others can find your questions later (see above). To be sure that the @@ -9450,7 +9512,7 @@ do? -21.9. +21.9.

    I have a little time to kill. What shall I do?

    @@ -9458,7 +9520,7 @@ do?

    -

    This is not really an FAQ yet, but here's the answer +

    This is not really an FAQ yet, but here's the answer anyway.

    • Run pkg_chk -N (from the @@ -9582,7 +9644,8 @@ USE_TOOLS+=gmake specify any dependency in your package and that the version requirements are all correct.

      • -

    • If the package uses intltool, be sure to include the pkgsrc/textproc/intltool/buildlink3.mk file +

    • If the package uses intltool, be sure to add + intltool to the USE_TOOLS to handle dependencies and to force the package to use the latest available version.

    • @@ -9727,14 +9790,14 @@ followed:

      Generate a patch from the modified meta packages and extract the list of "new" lines. This will provide you an outline on what packages need to be updated in pkgsrc and in what order:

      -
      % cvs diff gnome-devel gnome-base gnome | grep '^+D' >todo.txt
      +
      % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt

    • For major desktop updates it is recommended to zap all your installed packages and start over from scratch at this point.

    • Now comes the longest step by far: iterate over the contents of todo.txt and update the packages listed in it in order. For major desktop updates none of these should be - commited until the entire set is completed because there are chances + committed until the entire set is completed because there are chances of breaking not-yet-updated packages.

    • Once the packages are up to date and working, commit them to the tree one by one with appropriate log messages. At the end, @@ -9749,7 +9812,7 @@ followed:

      GNOME is a very big component in pkgsrc which approaches 100 packages. Please, it is very important that you always, always, always feed back any portability -fixes you do to a GNOME package to the mainstream developers (see Section 10.3.2, “Feedback to the author”). This is the only way to get +fixes you do to a GNOME package to the mainstream developers (see Section 10.3.5, “Feedback to the author”). This is the only way to get their attention on portability issues and to ensure that future versions can be built out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further updates are. Those developers in charge of @@ -9766,7 +9829,7 @@ issues. While the FreeBSD GNOME people are doing a great job in porting GNOME to their operating system, the official GNOME sources are now plagued by conditionals that check for __FreeBSD__ and similar macros. This hurts portability. Please see our patching -guidelines (Section 10.3.1, “Patching guidelines”) for more +guidelines (Section 10.3.4, “Patching guidelines”) for more details.

    • @@ -10039,8 +10102,9 @@ details.

    are loaded and gives reasons for that order.

    -23.6.1. The order in bsd.prefs.mk

    -

    The very first action in bsd.pkg.mk +23.6.1. The order in bsd.prefs.mk +

    +

    The very first action in bsd.prefs.mk is to define some essential variables like OPSYS, OS_VERSION and MACHINE_ARCH.

    @@ -10066,11 +10130,12 @@ details.

    -23.6.2. The order in bsd.pkg.mk

    +23.6.2. The order in bsd.pkg.mk +

    First, bsd.prefs.mk is loaded.

    Then, the various *-vars.mk files are loaded, which fill default values for those variables that have - not been defined by the the package. These variables may later + not been defined by the package. These variables may later be used even in unrelated files.

    Then, the file bsd.pkg.error.mk provides the target error-check that is added @@ -10212,7 +10277,7 @@ details.

    MyOS in this example), you need to touch the following files:

    -
    bootstrap/mods/mk/MyOS.sys.mk
    +
    pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk

    This file contains some basic definitions, for example the name of the C compiler.

    @@ -10224,19 +10289,19 @@ details.

    MACHINE_ARCH, OBJECT_FMT, APPEND_ELF, and the other variables that appear in this file.

    -
    mk/platform/MyOS.mk
    +
    mk/platform/MyOS.mk

    This file contains the platform-specific definitions that are used by pkgsrc. Start by copying one of the other files and edit it to your needs.

    -
    mk/platform/MyOS.pkg.dist
    +
    mk/platform/MyOS.pkg.dist

    This file contains a list of directories, together with their permission bits and ownership. These directories will be created automatically with every package that does not explicitly set NO_MTREE. There have been some discussions about whether this file is needed at all, but with no result.

    -
    mk/platform/MyOS.x11.dist
    +
    mk/platform/MyOS.x11.dist

    Just copy one of the pre-existing x11.dist files to your MyOS.x11.dist.

    @@ -10247,7 +10312,7 @@ details.

    narrow limit on the line length they can process. Therefore pkgsrc brings its own tools, which can be enabled here.

    -
    mk/tools/MyOS.mk
    +
    mk/tools/tools.MyOS.mk

    This file defines the paths to all the tools that are needed by one or the other package in pkgsrc, as well as by pkgsrc itself. Find out where these tools are on your @@ -10330,7 +10395,8 @@ details.

    -A.1.4. Checking a package with pkglint

    +A.1.4. Checking a package with pkglint +

    The NetBSD package system comes with pkgtools/pkglint which helps to check the contents of these @@ -10580,7 +10646,7 @@ Registering depends:.

    C.4. misc: Miscellaneous things
    C.5. packages*: Binary packages
    C.6. current, -200xQy: +pkgsrc-200xQy: source packages
    @@ -10643,7 +10709,7 @@ source packages

    C.6. current, -200xQy: +pkgsrc-200xQy: source packages

    These directories contain the “real” pkgsrc, that is the files that define how to create binary packages from diff --git a/doc/pkgsrc.txt b/doc/pkgsrc.txt index 820333b9dd0..018bb1ea1c5 100644 --- a/doc/pkgsrc.txt +++ b/doc/pkgsrc.txt @@ -169,8 +169,11 @@ II. The pkgsrc developer's guide 10.2. distinfo 10.3. patches/* - 10.3.1. Patching guidelines - 10.3.2. Feedback to the author + 10.3.1. Structure of a single patch file + 10.3.2. Creating patch files + 10.3.3. Sources where the patch files come from + 10.3.4. Patching guidelines + 10.3.5. Feedback to the author 10.4. Other mandatory files 10.5. Optional files @@ -429,7 +432,7 @@ C. Directory layout of the pkgsrc FTP server C.3. iso: Currently empty C.4. misc: Miscellaneous things C.5. packages*: Binary packages - C.6. current, 200xQy: source packages + C.6. current, pkgsrc-200xQy: source packages D. Editing guidelines for the pkgsrc guide @@ -801,7 +804,7 @@ Before you download any pkgsrc files, you should decide whether you want the current branch or the stable branch. The latter is forked on a quarterly basis from the current branch and only gets modified for security updates. The names of the stable branches are built from the year and the quarter, for example -2006Q1. +2006Q3. The second step is to decide how you want to download pkgsrc. You can get it as a tar file, via SUP, or via CVS. All three ways are described here. @@ -815,8 +818,8 @@ described in detail in Appendix C, Directory layout of the pkgsrc FTP server. The tar file for the current branch is in the directory current and is called pkgsrc.tar.gz. It is autogenerated daily. -The tar file for the stable branch 2006Q1 is in the directory 2006Q1 and is -also called pkgsrc.tar.gz. +The tar file for the stable branch 2006Q3 is in the directory pkgsrc-2006Q3 and +is also called pkgsrc-2006Q3.tar.gz. After downloading the tar file, change to the directory where you want to have pkgsrc. This is usually /usr. Then, run gzcat pkgsrc.tar.gz | tar xf - to @@ -850,7 +853,7 @@ Or, the same for the bourne shell: Then, you change to the directory where you want to have your copy of pkgsrc. In most cases this is /usr. In that directory you run the checkout command, which is cvs -q checkout -P pkgsrc for the current branch and cvs -q checkout --rpkgsrc-2006Q1 -P pkgsrc for the stable branch. This command will create a +-rpkgsrc-2006Q3 -P pkgsrc for the stable branch. This command will create a directory called pkgsrc with all the pkgsrc files in it. 2.2. Keeping pkgsrc up-to-date @@ -891,7 +894,7 @@ When updating pkgsrc, the CVS program keeps track of the branch you selected. But if you, for whatever reason, want to switch from the stable branch to the current one, you can do it by adding the option "-A" after the "update" keyword. To switch from the current branch back to the stable branch, add the -"-rpkgsrc-2006Q1" option. +"-rpkgsrc-2006Q3" option. 2.2.2.2. What happens to my changes when updating? @@ -966,7 +969,7 @@ Table 3.1. Binary kits and available packages |-----------------------------------+---------------+----------+---------------| |FreeBSD 5.3/i386 |20050119 |binary kit| | |-----------------------------------+---------------+----------+---------------| -|Interix 3.5 |20051010 |binary kit|binary packages| +|Interix 3.5 |20061106 |binary kit| | |-----------------------------------+---------------+----------+---------------| |IRIX 6.5 n32-bit ABI |20040911 |binary kit|binary packages| |-----------------------------------+---------------+----------+---------------| @@ -976,17 +979,17 @@ Table 3.1. Binary kits and available packages |-----------------------------------+---------------+----------+---------------| |OpenBSD 3.3/i386 |20030503 |binary kit| | |-----------------------------------+---------------+----------+---------------| -|OpenBSD 3.5/i386 |20040507 |binary kit| | +|OpenBSD 3.5/i386 |20040703 |binary kit| | |-----------------------------------+---------------+----------+---------------| |Slackware Linux 8.1/i386 |20030417 |binary kit| | |-----------------------------------+---------------+----------+---------------| -|Slackware Linux 9/i386 |20031023 |binary kit| | +|Slackware Linux 9/i386 |20040703 |binary kit| | |-----------------------------------+---------------+----------+---------------| |Solaris 8/sparc |20050220 |binary kit| | |-----------------------------------+---------------+----------+---------------| |Solaris 8/i386 |20050220 |binary kit| | |-----------------------------------+---------------+----------+---------------| -|Solaris 9/sparc |20041208 |binary kit|binary packages| +|Solaris 9/sparc |20060713 |binary kit| | |-----------------------------------+---------------+----------+---------------| |Solaris 9/i386 |20030411 |binary kit| | +------------------------------------------------------------------------------+ @@ -1137,9 +1140,13 @@ 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.) +Services for Unix 3.5 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, but +other parts of libc may also be lacking.) + +Services for Unix Applications (aka SUA) is an integrated component of Windows +Server 2003 R2 and Windows Vista. As of this writing, SUA's Interix 5.x +subsystem not been tested with pkgsrc. 3.3.3.1. When installing Interix/SFU @@ -1176,6 +1183,15 @@ 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. +In addition to the hotfix noted above, it may be necessary to disable Data +Execution Prevention entirely to make Interix functional. This may happen only +with certain types of CPUs; the cause is not fully understood at this time. If +gcc or other applications still segfault repeatedly after installing one of the +hotfixes note above, the following option can be added to the appropriate +"boot.ini" line on the Windows boot drive: /NoExecute=AlwaysOff (WARNING, this +will disable DEP completely, which may be a security risk if applications are +often run as a user in the Administrators group!) + 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 @@ -1238,10 +1254,6 @@ desiring to make the most of Interix. 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. - * X11 acceleration: Because Interix runs in a completely different NT subsystem from Win32 @@ -1329,7 +1341,7 @@ 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 +to make sure that MIPSPro is used, please set your PATH to not include the location of gcc (often /usr/freeware/bin), and (important) pass the '--preserve-path' flag. @@ -1448,8 +1460,7 @@ 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. -Binary packages of gcc can be found through http://www.sun.com/bigadmin/common/ -freewareSearch.html. +Binary packages of gcc can be found through http://www.sunfreeware.com/. 3.3.7.2. If you are using Sun WorkShop @@ -1470,7 +1481,7 @@ You should set CC, CXX and optionally, CPP in /etc/mk.conf, e.g.: CPP= /usr/ccs/lib/cpp -3.3.7.3. Buildling 64-bit binaries with SunPro +3.3.7.3. Building 64-bit binaries with SunPro Building 64-bit binaries is a little trickier. First, you need to bootstrap pkgsrc in 64-bit mode. One problem here is that while building one of the @@ -1940,7 +1951,8 @@ each variable's intent. distfiles/${DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$ {DIST_SUBDIR}/. - * BINPKG_SITES: List of sites carrying binary pkgs. + * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced + with OS release ("2.0", etc.) and architecture ("mipsel", etc.). * ACCEPTABLE_LICENSES: List of acceptable licenses. Whenever you try to build a package whose license is not in this list, you will get an error message @@ -1962,8 +1974,7 @@ XXX tree. It is possible to have many pkgsrc tree instances.) * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See - Section 10.3, "patches/*" for more information. rel and arch are replaced - with OS release ("2.0", etc.) and architecture ("mipsel", etc.). + Section 10.3, "patches/*" for more information. * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking @@ -2218,11 +2229,11 @@ Some other options are scattered in the pkgsrc infrastructure: 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. + * CHECK_FILES (pkgsrc/mk/check/check-files.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. + * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to + "yes" to check that the installed "#!"-scripts will find their interpreter. * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before installing it. Note that some packages make heavy use of "good" random @@ -2449,19 +2460,19 @@ 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 +RSYNC_DST=ftp.NetBSD.org:/pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch/upload -Please use appropriate values for "pkgsrc-200xQy", "NetBSD-a.b.c" and "arch" +Please use appropriate values for "packages-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 +RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/packages-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 +nbftp% mkdir -p -m 750 /pub/NetBSD/packages/packages-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 @@ -2507,7 +2518,7 @@ 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% cd /pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch nbftp% mv upload/* . nbftp% rmdir upload nbftp% chmod 755 . @@ -2574,7 +2585,7 @@ default locations are: LOCALBASE= /usr/pkg PKG_SYSCONFBASE= /usr/pkg/etc VARBASE= /var - PKGDBDIR= /var/db/pkg + PKG_DBDIR= /var/db/pkg In unprivileged mode (when pkgsrc has been installed as any other user), the default locations are: @@ -2582,7 +2593,7 @@ default locations are: LOCALBASE= ${HOME}/pkg PKG_SYSCONFBASE= ${HOME}/pkg/etc VARBASE= ${HOME}/pkg/var - PKGDBDIR= ${HOME}/pkg/var/db/pkg + PKG_DBDIR= ${HOME}/pkg/var/db/pkg What these four directories are for, and what they look like is explained below. @@ -2834,7 +2845,7 @@ UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively. As regards bootstrapping, please note that the bootstrap script will ease non-root configuration when given the "--ignore-user-check" flag, as it will choose and use multiple default directories under ~/pkg as the installation -targets. These directories can be overriden by the "--prefix" flag provided by +targets. These directories can be overridden by the "--prefix" flag provided by the script, as well as some others that allow finer tuning of the tree layout. 8.5. How to resume transfers when fetching distfiles? @@ -3092,8 +3103,11 @@ Table of Contents 10.2. distinfo 10.3. patches/* - 10.3.1. Patching guidelines - 10.3.2. Feedback to the author + 10.3.1. Structure of a single patch file + 10.3.2. Creating patch files + 10.3.3. Sources where the patch files come from + 10.3.4. Patching guidelines + 10.3.5. Feedback to the author 10.4. Other mandatory files 10.5. Optional files @@ -3592,8 +3606,11 @@ Table of Contents 10.2. distinfo 10.3. patches/* - 10.3.1. Patching guidelines - 10.3.2. Feedback to the author + 10.3.1. Structure of a single patch file + 10.3.2. Creating patch files + 10.3.3. Sources where the patch files come from + 10.3.4. Patching guidelines + 10.3.5. Feedback to the author 10.4. Other mandatory files 10.5. Optional files @@ -3737,26 +3754,47 @@ not lost. 10.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. +Many packages still don't work out-of-the box on the various platforms that are +supported by pkgsrc. Therefore, a number of custom patch files are needed to +make the package work. These patch files are found in the patches/ directory. + +In the patch phase, these patches are applied to the files in WRKSRC directory +after extracting them, in alphabetic order, so patch-aa is applied before +patch-ab, etc. + +10.3.1. Structure of a single patch file 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. +PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changed for +a single file, and no file should be patched by more than one patch file. This +helps to keep future modifications simple. -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. +Each patch file is structured as follows: In the first line, there is the RCS +Id of the patch itself. The second line should be empty for aesthetic reasons. +After that, there should be a comment for each change that the patch does. +There are a number of standard cases: + + * Patches that replace the == operator for test(1) with = in shell scripts + should contain a reference to , to avoid redundant explanations. + + * Patches for commonly known vulnerabilities should mention the vulnerability + ID (CAN, CVE). + + * Patches that change source code should mention the platform and other + environment (for example, the compiler) that the patch is needed for. + +In all other cases, the patch should be commented so that any developer who +knows the code of the application can make some use of the patch. Special care +should be taken for the upstream developers, since we generally want that they +accept our patches, so we have less work in the future. + +10.3.2. Creating patch files 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. +NetBSD CVS tree. Use the pkgdiff command 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 @@ -3775,13 +3813,14 @@ 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. +10.3.3. Sources where the patch files come from + 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. @@ -3794,7 +3833,7 @@ 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. -10.3.1. Patching guidelines +10.3.4. Patching guidelines When fixing a portability issue in the code do not use preprocessor magic to check for the current operating system nor platform. Doing so hurts portability @@ -3853,7 +3892,7 @@ For more information, please read the Making packager-friendly software article to package; all the suggestions in it were collected from our experience in pkgsrc work, so they are possibly helpful when creating patches too. -10.3.2. Feedback to the author +10.3.5. Feedback to the author Always, always, always feed back any portability fixes or improvements you do to a package to the mainstream developers. This is the only way to get their @@ -3861,12 +3900,12 @@ attention on portability issues and to ensure that future versions can be built out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will get the fixes straight from the packaged code. -This generally involves cleaning up the patches as described in the following -section (because sometimes the patches that are added to pkgsrc are quick -hacks), filling bug reports in the appropriate trackers for the projects and -working with the mainstream authors to accept your changes. It is extremely -important that you do it so that the packages in pkgsrc are kept simple and -thus further changes can be done without much hassle. +This generally involves cleaning up the patches (because sometimes the patches +that are added to pkgsrc are quick hacks), filling bug reports in the +appropriate trackers for the projects and working with the mainstream authors +to accept your changes. It is extremely important that you do it so that the +packages in pkgsrc are kept simple and thus further changes can be done without +much hassle. Support the idea of free software! @@ -4509,7 +4548,7 @@ issues: * oss.buildlink3.mk defines several variables that may be used by packages that use the Open Sound System (OSS) API. - * pgsql.buildlink3.mk will accept either Postgres 7.4, 8.0, or 8.1, whichever + * pgsql.buildlink3.mk will accept either Postgres 8.0, 8.1, or 8.2, whichever is found installed. See the file for more information. * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native @@ -5420,7 +5459,7 @@ PKGPATH 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 + place. The distfiles are extracted to this directory. It also contains temporary directories and log files used by the various pkgsrc frameworks, like buildlink or the wrappers. @@ -5492,6 +5531,7 @@ packages. The names of the variables should speak for themselves. ${MASTER_SITE_DEBIAN} ${MASTER_SITE_FREEBSD} ${MASTER_SITE_FREEBSD_LOCAL} + ${MASTER_SITE_GENTOO} ${MASTER_SITE_GNOME} ${MASTER_SITE_GNU} ${MASTER_SITE_GNUSTEP} @@ -5513,9 +5553,9 @@ packages. The names of the variables should speak for themselves. Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP -contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org: -/pub/NetBSD/packages/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local -package source distributions that are maintained in ftp://ftp.NetBSD.org:/pub/ +contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org/ +pub/NetBSD/packages/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local +package source distributions that are maintained in ftp://ftp.NetBSD.org/pub/ NetBSD/packages/distfiles/LOCAL_PORTS/. If you choose one of these predefined sites, you may want to specify a @@ -5531,8 +5571,8 @@ Note the trailing slash after the subdirectory name. 16.5.2. How are the files fetched? The fetch phase makes sure that all the distfiles exist in a local directory -(DISTDIR), which can be set by the pkgsrc user). If the files do not exist, -they are fetched using commands of the form +(DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they +are fetched using commands of the form ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS} @@ -5560,7 +5600,7 @@ as they usually come in the form of some compressed archive format. By default, all DISTFILES are extracted. If you only need some of them, you can set the EXTRACT_ONLY variable to the list of those files. -Extracting the files is usually done by a little program, mk/scripts/extract, +Extracting the files is usually done by a little program, mk/extract/extract, which already knows how to extract various archive formats, so most likely you will not need to change anything here. But if you need, the following variables may help you: @@ -5568,12 +5608,13 @@ may help you: EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO} Use these variables to override the default options for an extract command, - which are defined in mk/scripts/extract. + which are defined in mk/extract/extract. EXTRACT_USING - This variable can be set to pax, tar or an absolute pathname pointing to - the command with which tar archives should be extracted. + This variable can be set to gtar, nbtar (which is the default value), pax, + or an absolute pathname pointing to the command with which tar archives + should be extracted. If the extract program doesn't serve your needs, you can also override the EXTRACT_CMD variable, which holds the command used for extracting the files. @@ -5931,7 +5972,7 @@ replace Update the installation of the current package. This differs from update in that it does not replace dependent packages. You will need to install - pkgsrc/pkgtools/pkg_tarup for this target to work. + pkgtools/pkg_tarup for this target to work. Be careful when using this target! There are no guarantees that dependent packages will still work, in particular they will most certainly break if @@ -6342,7 +6383,7 @@ set to note these restrictions: * 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 + {RESTRICTED} whenever a binary package may not be made available on the Internet. * NO_SRC_ON_CDROM @@ -7321,9 +7362,9 @@ ensure that the database is kept consistent with respect to these new files: 18.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. +If a package uses intltool during its build, add intltool to the USE_TOOLS, +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 @@ -7499,7 +7540,7 @@ what was explained in the previous sections, only with some debugging aids. * Reinstall the binary package: - # pkgadd .../examplepkg.tgz + # pkg_add .../examplepkg.tgz * Play with it. Make sure everything works. @@ -7556,26 +7597,26 @@ details. 20.3. General notes when adding, updating, or removing packages Please note all package additions, updates, moves, and removals in pkgsrc/doc/ -CHANGES. It's very important to keep this file up to date and conforming to the -existing format, because it will be used by scripts to automatically update -pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/doc/ -TODO file and remove the entry for the package you updated or removed, in case -it was mentioned there. +CHANGES-YYYY. It's very important to keep this file up to date and conforming +to the existing format, because it will be used by scripts to automatically +update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/ +doc/TODO file and remove the entry for the package you updated or removed, in +case it was mentioned there. When the PKGREVISION of a package is bumped, the change should appear in pkgsrc -/doc/CHANGES if it is security related or otherwise relevant. Mass bumps that -result from a dependency being updated should not be mentioned. In all other -cases it's the developer's decision. +/doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps +that result from a dependency being updated should not be mentioned. In all +other cases it's the developer's decision. -There is a make target that helps in creating proper CHANGES entries: make +There is a make target that helps in creating proper CHANGES-YYYY entries: make changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The -general usage is to first make sure that your CHANGES file is up-to-date (to -avoid having to resolve conflicts later-on) and then to cd to the package +general usage is to first make sure that your CHANGES-YYYY file is up-to-date +(to avoid having to resolve conflicts later-on) and then to cd to the package directory. For package updates, make changes-entry is enough. For new packages, or package moves or removals, set the CTYPE variable on the command line to "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in /etc/mk.conf if your local login name is not the same as your NetBSD login name. Don't -forget to commit the changes to pkgsrc/doc/CHANGES! +forget to commit the changes to pkgsrc/doc/CHANGES-YYYY! 20.4. Committing: Importing a package into CVS @@ -7766,8 +7807,8 @@ pkgsrc-users mailing list. * Some parts of pkgsrc are only "implicitly documented", that is the documentation exists only in the mind of the developer who wrote the - code. To get this information, use the the cvs annotate command to - see who has written it and ask on the tech-pkg mailing list, so that + code. To get this information, use the cvs annotate command to see + who has written it and ask on the tech-pkg mailing list, so that others can find your questions later (see above). To be sure that the developer in charge reads the mail, you may CC him or her. @@ -7879,9 +7920,9 @@ the minimum required tools: you did not miss to specify any dependency in your package and that the version requirements are all correct. - * If the package uses intltool, be sure to include the pkgsrc/textproc/ - intltool/buildlink3.mk file to handle dependencies and to force the package - to use the latest available version. + * If the package uses intltool, be sure to add intltool to the USE_TOOLS to + handle dependencies and to force the package to use the latest available + version. * If the package uses gtk-doc (a documentation generation utility), do not add a dependency on it. The tool is rather big and the distfile should come @@ -7997,14 +8038,14 @@ In order to update the GNOME components in pkgsrc to a new stable release "new" lines. This will provide you an outline on what packages need to be updated in pkgsrc and in what order: - % cvs diff gnome-devel gnome-base gnome | grep '^+D' >todo.txt + % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt 5. For major desktop updates it is recommended to zap all your installed packages and start over from scratch at this point. 6. Now comes the longest step by far: iterate over the contents of todo.txt and update the packages listed in it in order. For major desktop updates - none of these should be commited until the entire set is completed because + none of these should be committed until the entire set is completed because there are chances of breaking not-yet-updated packages. 7. Once the packages are up to date and working, commit them to the tree one @@ -8017,7 +8058,7 @@ In order to update the GNOME components in pkgsrc to a new stable release GNOME is a very big component in pkgsrc which approaches 100 packages. Please, it is very important that you always, always, always feed back any portability fixes you do to a GNOME package to the mainstream developers (see -Section 10.3.2, "Feedback to the author"). This is the only way to get their +Section 10.3.5, "Feedback to the author"). This is the only way to get their attention on portability issues and to ensure that future versions can be built out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further updates are. Those developers in charge of issuing major GNOME updates will be @@ -8034,7 +8075,7 @@ Also, please avoid using preprocessor magic to fix portability issues. While the FreeBSD GNOME people are doing a great job in porting GNOME to their operating system, the official GNOME sources are now plagued by conditionals that check for __FreeBSD__ and similar macros. This hurts portability. Please -see our patching guidelines (Section 10.3.1, "Patching guidelines") for more +see our patching guidelines (Section 10.3.4, "Patching guidelines") for more details. Part III. The pkgsrc infrastructure internals @@ -8255,8 +8296,8 @@ reasons for that order. 23.6.1. The order in bsd.prefs.mk -The very first action in bsd.pkg.mk is to define some essential variables like -OPSYS, OS_VERSION and MACHINE_ARCH. +The very first action in bsd.prefs.mk is to define some essential variables +like OPSYS, OS_VERSION and MACHINE_ARCH. Then, the user settings are loaded from the file specified in MAKECONF. If the bmake command from pkgsrc is used, MAKECONF defaults to ${prefix}/etc/mk.conf. @@ -8280,8 +8321,8 @@ earlier phases of a package build. First, bsd.prefs.mk is loaded. Then, the various *-vars.mk files are loaded, which fill default values for -those variables that have not been defined by the the package. These variables -may later be used even in unrelated files. +those variables that have not been defined by the package. These variables may +later be used even in unrelated files. Then, the file bsd.pkg.error.mk provides the target error-check that is added as a special dependency to all other targets that use DELAYED_ERROR_MSG or @@ -8398,7 +8439,7 @@ pkgsrc even more portable. To port pkgsrc to a new operating system (called MyOS in this example), you need to touch the following files: -bootstrap/mods/mk/MyOS.sys.mk +pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk This file contains some basic definitions, for example the name of the C compiler. @@ -8432,7 +8473,7 @@ mk/tools/bootstrap.mk (1) that have a narrow limit on the line length they can process. Therefore pkgsrc brings its own tools, which can be enabled here. -mk/tools/MyOS.mk +mk/tools/tools.MyOS.mk This file defines the paths to all the tools that are needed by one or the other package in pkgsrc, as well as by pkgsrc itself. Find out where these @@ -8742,7 +8783,7 @@ C.2. distfiles: The distributed source files C.3. iso: Currently empty C.4. misc: Miscellaneous things C.5. packages*: Binary packages -C.6. current, 200xQy: source packages +C.6. current, pkgsrc-200xQy: source packages As in other big projects, the directory layout of pkgsrc is quite complex for newbies. This chapter explains where you find things on the FTP server. The @@ -8789,7 +8830,7 @@ collection. It has a directory called All which contains all binary packages. Besides that, there are various category directories that contain symbolic links to the real binary packages. -C.6. current, 200xQy: source packages +C.6. current, pkgsrc-200xQy: source packages These directories contain the "real" pkgsrc, that is the files that define how to create binary packages from source archives. -- cgit v1.2.3