From 6ec562cf9148820f09fbc58d5e9839b83f3b28de Mon Sep 17 00:00:00 2001
From: xtraeme Table of Contents
-
-
Makefile
distinfo
work*
files/*
-
PLIST
+ generationPLIST_SRC
-
buildlink3.mk
+ filesbuiltin.mk
+ files
-
Once the software has been built, it is manipulated with - the pkg_* tools so that - installation and de-installation, printing of an inventory - of all installed packages and retrieval of one-line - comments or more verbose descriptions are all simple.
+ the pkg_* + tools so that installation and de-installation, printing of + an inventory of all installed packages and retrieval of + one-line comments or more verbose descriptions are all + simple.pkgsrc currently contains several thousand packages, including:
@@ -814,32 +831,32 @@ alink="#0000FF">www/apache - The Apache web - server
+ class="pkgname">www/apache - The Apache web + serverwww/mozilla - The Mozilla web - browser
+ class="pkgname">www/mozilla - The Mozilla web + browsermeta-pkgs/gnome - The GNOME - Desktop Environment
+ class="pkgname">meta-pkgs/gnome - The GNOME + Desktop Environmentmeta-pkgs/kde3 - The K Desktop - Environment
+ class="pkgname">meta-pkgs/kde3 - The K Desktop + EnvironmentA set of files and building instructions that describe what's necessary to build a certain piece of software using pkgsrc. Packages are traditionally - stored under /usr/pkgsrc.
+ stored under/usr/pkgsrc
.
/usr/pkgsrc/distfiles
.
A set of binaries built with pkgsrc from a
- distfile and stuffed together in a single .tgz file so it can be installed on
- machines of the same machine architecture without the
- need to recompile. Packages are usually generated in
- /usr/pkgsrc/packages; there
- is also an archive on .tgz file so it can be
+ installed on machines of the same machine
+ architecture without the need to recompile. Packages
+ are usually generated in /usr/pkgsrc/packages
; there is also
+ an archive on ftp.NetBSD.org.
When giving examples for commands, shell prompts are used to show if the command should/can be issued as root, or if “normal” user - privileges are sufficient. We use a # for root's shell prompt, and a $ for users' shell prompt, assuming they use - the C-shell or tcsh.
+ privileges are sufficient. We use a#
for root's shell prompt, and a
+ $
for users' shell prompt,
+ assuming they use the C-shell or tcsh.
@@ -1088,13 +1106,13 @@ alink="#0000FF">
Table of Contents
To get pkgsrc going, you need to get the pkgsrc.tar.gz file from ftp.NetBSD.org and unpack it into - /usr/pkgsrc.
+ target="_top">ftp.NetBSD.org and unpack it into +/usr/pkgsrc
.
in it, see the examples in /usr/share/examples/supfiles, and that - the /usr/pkgsrc directory - exists. Then, simply run sup -v - /path/to/your/supfile.
+in it, see the examples in /usr/share/examples/supfiles
, and that
+ the /usr/pkgsrc
directory
+ exists. Then, simply run sup -v /path/to/your/supfile
.
-% setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot -% setenv CVS_RSH ssh -% cd /usr -% cvs checkout -P pkgsrc -- -
This will create the pkgsrc - directory in your /usr, and all - the package source will be stored under /usr/pkgsrc. To update pkgsrc after the - initial checkout, make sure you have CVS_RSH set as above, then do:
+%
setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot
+%
setenv CVS_RSH ssh
+%
cd /usr
+%
cvs checkout -P pkgsrc
+
+
+ This will create the pkgsrc
directory in your /usr
, and all the package source will
+ be stored under /usr/pkgsrc
. To update pkgsrc after the
+ initial checkout, make sure you have CVS_RSH
set as above, then do:
-% cd /usr/pkgsrc -% cvs -q update -dP +%
cd /usr/pkgsrc
+%
cvs -q update -dP
Please also note that it is possible to have multiple @@ -1440,30 +1465,30 @@ release=pkgsrc
Table of Contents
Installing the bootstrap kit should be as simple as:
-# env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc -# cd pkgsrc/bootstrap -# ./bootstrap +#
env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
+#
cd pkgsrc/bootstrap
+#
./bootstrap
See Chapter 2,
Where to get pkgsrc 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
+ 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 it's internal bookkeeping.
However, these can also be set using command-line
parameters.
Create the disk image:
-# cd pkgsrc/bootstrap -# ./ufsdiskimage create ~/Documents/NetBSD 512 # megabytes - season to taste -# ./ufsdiskimage mount ~/Documents/NetBSD -# sudo chown `id -u`:`id -g` /Volumes/NetBSD +#
cd pkgsrc/bootstrap
+#
./ufsdiskimage create ~/Documents/NetBSD 512
# megabytes - season to taste +#
./ufsdiskimage mount ~/Documents/NetBSD
+#
sudo chown `id -u`:`id -g` /Volumes/NetBSD
That's it!
@@ -1649,26 +1675,26 @@ release=pkgsrcBy 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.
+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.
-# ./bootstrap --pkgdbdir=/usr/pkg/pkgdb --pkgsrcdir=/Volumes/ufs/pkgsrc +#
./bootstrap --pkgdbdir=/usr/pkg/pkgdb --pkgsrcdir=/Volumes/ufs/pkgsrc
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
+ /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”
@@ -1703,8 +1729,8 @@ release=pkgsrc
FreeBSD stores its ports pkg database in
- /var/db/pkg. It is
+ /var/db/pkg
. It is
therefore recommended that you choose a different
- location (e.g. /usr/pkgdb) by using the
+ location (e.g. /usr/pkgdb
) by using the
--pkgdbdir option to the bootstrap script.
-# 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 +#
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
An example /etc/mk.conf file will be placed - in /etc/mk.conf.example - file when you use the bootstrap script.
+An example /etc/mk.conf
file will be
+ placed in /etc/mk.conf.example
file when
+ you use the bootstrap script.
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
+ 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/.
Therefore, please make sure that you have no
- conflicting CFLAGS in your
- environment or the /etc/mk.conf. Particularly, make sure
+ 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!
/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
+ WRKOBJDIR
to a local
directory, as it appears that IRIX linker occasionally
runs into issues when trying to link over a network
mounted filesystem.
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
+ Please see pkgsrc/mk/defaults/mk.conf
and, of
course, your compilers man pages for details.
OpenBSD stores its ports pkg database in
- /var/db/pkg. It is
+ /var/db/pkg
. It is
therefore recommended that you choose a different
- location (e.g. /usr/pkgdb) by using the
+ location (e.g. /usr/pkgdb
) by using the
--pkgdbdir option to the bootstrap script.
-# 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 +#
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
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 +
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:
@@ -2049,8 +2077,8 @@ release=pkgsrc @@ -2094,8 +2122,8 @@ release=pkgsrc@@ -2109,23 +2137,23 @@ release=pkgsrc lang/gcc or install a binary - gcc package, then remove gcc used during - bootstrapping. + class="pkgname">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.
+ target= + "_top">http://www.sun.com/bigadmin/common/freewareSearch.html.@@ -2201,32 +2230,32 @@ CFLAGS= -xtarget=ultra -xarch=v9@@ -2156,10 +2184,10 @@ release=pkgsrc-You should set CC, - CXX and optionally, - CPP in /etc/mk.conf, eg.
+You should set
CC
, +CXX
and optionally, +CPP
in/etc/mk.conf
, eg.CC= cc CXX= CC @@ -2174,9 +2202,10 @@ CFLAGS= -xtarget=ultra -xarch=v9Whichever compiler you use, please ensure the compiler tools and your $prefix are in your - PATH. This includes - /usr/ccs/{bin,lib} and eg. - /usr/pkg/{bin,sbin}.
+PATH
. This includes +/usr/ccs/{bin,lib}
and + eg./usr/pkg/{bin,sbin}
.
Precompiled packages are stored on ftp.NetBSD.org
- and its mirrors in the directory /pub/NetBSD/packages for anonymous FTP
- access. Please pick the right subdirectory there as
- indicated by uname
- -p. In that directory, there is a
+ and its mirrors in the directory /pub/NetBSD/packages
for anonymous
+ FTP access. Please pick the right subdirectory there as
+ indicated by uname
+ -p. In that directory, there is a
subdirectory for each category plus a subdirectory
- All which includes the actual
- binaries in .tgz files. The
- category subdirectories use symbolic links to those
- files (this is the same directory layout as in
- /usr/pkgsrc/packages).
All
which includes the
+ actual binaries in .tgz
+ files. The category subdirectories use symbolic links
+ to those files (this is the same directory layout as in
+ /usr/pkgsrc/packages
).
This same directory layout applies for CDROM
distributions, only that the directory may be rooted
- somewhere else, probably somewhere below /cdrom. Please consult your CDROMs
+ somewhere else, probably somewhere below /cdrom
. Please consult your CDROMs
documentation for the exact location.
If you have the files on a CDROM or downloaded them to your hard disk, youcan install them with the - following command (be sure tosu to root first):
+ following command (be sure tosu to root first):-# pkg_add /path/to/package.tgz +#
pkg_add /path/to/package.tgz
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:
+ you can do this automatically by giving + pkg_add + an FTP URL:-# pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSvers>/<arch>/All/package.tgz +#
pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSvers>/<arch>/All/package.tgz
If there is any doubt, the uname utility can be used to determine the <OSvers>, and <arch> by - running uname - -rp.
+ running uname + -rp.Also note that any prerequisite packages needed to run the package in question will be installed, too, assuming they are present where you install from.
After you've installed packages, be sure to have - /usr/pkg/bin in your - PATH so you can actually start - the just installed program.
+/usr/pkg/bin
in your
+ PATH
so you can actually
+ start the just installed program.
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, MASTER_SORT_REGEX and INET_COUNTRY definitions. This may save - some of your bandwidth and time.
+ a look atpkgsrc/mk/defaults/mk.conf
to find
+ some examples - in particular, look for the
+ MASTER_SORT
, MASTER_SORT_REGEX
and INET_COUNTRY
definitions. This may
+ save some of your bandwidth and time.
You can change these settings either in your shell's
environment, or, if you want to keep the settings, by
- editing the /etc/mk.conf
+ editing the /etc/mk.conf
file, and adding the definitions there.
If you don't have a permanent Internet connection and you want to know which files to download, - make fetch-list - will tell you what you'll need. Put these distfiles - into /usr/pkgsrc/distfiles.
+ make + fetch-list will tell you what you'll + need. Put these distfiles into/usr/pkgsrc/distfiles
.
Assuming that the distfile has been fetched (see previous section), become root and change into the - relevant directory and running make. For example, type
+ relevant directory and running make. For example, type-% cd misc/figlet -% make +%
cd misc/figlet
+%
make
at the shell prompt to build the various components of the package, and
-# make install +#
make install
to install the various components into the correct @@ -2467,35 +2499,39 @@ CFLAGS= -xtarget=ultra -xarch=v9 logs.
The program is installed under the default root of
- the packages tree - /usr/pkg.
- Should this not conform to your tastes, set the
- LOCALBASE variable in your
+ the packages tree - /usr/pkg
. Should this not conform to
+ your tastes, set the LOCALBASE
variable in your
environment, and it will use that value as the root of
- your packages tree. So, to use /usr/local, set LOCALBASE=/usr/local in your
+ your packages tree. So, to use /usr/local
, set LOCALBASE=/usr/local
in your
environment. Please note that you should use a
directory which is dedicated to packages and not shared
- with other programs (ie, do not try and use LOCALBASE=/usr). Also, you should not
- try to add any of your own files or directories (such
- as src/, obj/, or pkgsrc/) below the LOCALBASE tree. This is to prevent
+ with other programs (ie, do not try and use
+ LOCALBASE=/usr
). Also, you
+ should not try to add any of your own files or
+ directories (such as src/
, obj/
, or pkgsrc/
) below the LOCALBASE
tree. This is to prevent
possible conflicts between programs and other files
installed by the package system and whatever else may
have been installed there.
Some packages look in /etc/mk.conf to alter some +
Some packages look in /etc/mk.conf
to alter some
configuration options at build time. Have a look at
- pkgsrc/mk/defaults/mk.conf to
- get an overview of what will be set there by default.
- Environment variables such as LOCALBASE can be set in /etc/mk.conf to save having to remember
- to set them each time you want to use pkgsrc.
pkgsrc/mk/defaults/mk.conf
to get an
+ overview of what will be set there by default.
+ Environment variables such as LOCALBASE
can be set in /etc/mk.conf
to save having to
+ remember to set them each time you want to use
+ pkgsrc.
Occasionally, people want to “look under the covers” to see what @@ -2511,11 +2547,13 @@ CFLAGS= -xtarget=ultra -xarch=v9 "http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current"> make(1) command - with PKG_DEBUG_LEVEL=2, - then a huge amount of information will be - displayed. For example,
+ withPKG_DEBUG_LEVEL=2
, then a huge
+ amount of information will be displayed. For
+ example,
-make patch PKG_DEBUG_LEVEL=2
+make patch PKG_DEBUG_LEVEL=2
will show all the commands that are invoked, @@ -2525,19 +2563,20 @@ CFLAGS= -xtarget=ultra -xarch=v9
If you want to know the value of a certain - make(1) definition, then the VARNAME definition should be used, - in conjunction with the show-var target. e.g. to - show the expansion of the VARNAME definition should be + used, in conjunction with the show-var target. + e.g. to show the expansion of the make(1) - variable DISTFILES:
+ variableDISTFILES
:
-% make show-var VARNAME=LOCALBASE +%
make show-var VARNAME=LOCALBASE
/usr/pkg -% +%
BINPKG_SITES
, which defaults to
+ ftp.NetBSD.org. Any flags that should be added to
+
pkg_add(1) can be put
- into BIN_INSTALL_FLAGS. See
- pkgsrc/mk/defaults/mk.conf
- for more details.
+ into BIN_INSTALL_FLAGS
.
+ See pkgsrc/mk/defaults/mk.conf
for more
+ details.
A final word of warning: If you setup a system that
- has a non-standard setting for LOCALBASE, be sure to set that before
+ has a non-standard setting for LOCALBASE
, be sure to set that before
any packages are installed, as you can not use several
directories for the same purpose. Doing so will result
in pkgsrc not being able to properly detect your
installed packages, and fail miserably. Note also that
precompiled binary packages are usually built with the
- default LOCALBASE of
- /usr/pkg, and that you should
- not install any
- if you use a non-standard LOCALBASE.
LOCALBASE
of
+ /usr/pkg
, and that you
+ should not
+ install any if you use a non-standard LOCALBASE
.
PKGSRC_COMPILER
:This is a list of values specifying the chain @@ -2608,33 +2649,33 @@ CFLAGS= -xtarget=ultra -xarch=v9
distcc: +
distcc
:
distributed C/C++ (chainable)
ccache: +
ccache
:
compiler cache (chainable)
gcc: GNU C/C++ - Compiler
+gcc
: GNU
+ C/C++ Compiler
mipspro: +
mipspro
:
Silicon Graphics, Inc. MIPSpro
(n32/n64)
mipspro: +
mipspro
:
Silicon Graphics, Inc. MIPSpro (o32)
sunpro: +
sunpro
:
Microsystems, Inc. WorkShip/Forte/Sun ONE
Studio
The default is “gcc”. You can use
- ccache and/or distcc with an appropriate
- PKGSRC_COMPILER setting,
- e.g. “ccache gcc”. This
+ "quote">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.
GCC_REQD
:This specifies the minimum version of GCC to @@ -2684,10 +2726,10 @@ CFLAGS= -xtarget=ultra -xarch=v9
Table of Contents
To create a binary package, change into the - appropriate directory in pkgsrc, and run make package:
+ appropriate directory in pkgsrc, and run + make + package:-# cd misc/figlet -# 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
+ 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.
You may want to set things in /etc/mk.conf. Look at pkgsrc/mk/defaults/mk.conf for +
You may want to set things 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 ACCEPTABLE_LICENSES meet your local
+ policy. As used in this example, _ACCEPTABLE=yes
accepts all licenses.
PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH} @@ -2878,17 +2921,17 @@ _ACCEPTABLE= yes -In pkgsrc/mk/bulk, copy - build.conf-example to - build.conf and edit it, - following the comments in that file. This is the +
In
+ cvs + update.pkgsrc/mk/bulk
, + copybuild.conf-example
+ tobuild.conf
and edit + it, following the comments in that file. This is the config file that determines where log files are generated after the build, where to mail the build report to, where your pkgsrc tree is located and @@ -2896,33 +2939,34 @@ _ACCEPTABLE= yes "http://netbsd.gw.com/cgi-bin/man-cgi?su+8+NetBSD-current"> su(8) to to do a - cvs update.
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:
+ pre-build stage. If the filepre-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." \ - > pkgsrc/games/crafty-book-enormous/$BROKENF +#
echo "I do not have enough disk space to build this pig." \ + > pkgsrc/games/crafty-book-enormous/$BROKENF
to prevent the system from trying to build a @@ -2935,30 +2979,31 @@ _ACCEPTABLE= yes
-As /usr/pkg will be +
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 /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
+ /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:
rc.local
:
( cd /usr/pkgsrc/security/ssh ; make bulk-install ) if [ -f /usr/pkg/etc/rc.d/sshd ]; then @@ -2976,8 +3021,8 @@ fi @@ -2996,35 +3041,35 @@ fiBe sure to remove all other things that might interfere with builds, like some libs installed in - /usr/local, etc. then become - root and type:
+/usr/local
, etc. then + become root and type:-# cd /usr/pkgsrc -# sh mk/bulk/build +#
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:
-# sh mk/bulk/build restart +#
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.
+ specified byFTP
in the +build.conf
file.
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.
+ directory specified in thebuild.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.
+ 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.
The first step is to set up a chroot sandbox, e.g.
- /usr/sandbox. This can be
+ /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 +
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
+ doing a make distribution
+ DESTDIR=/usr/sandbox in /usr/src/etc
, be sure the following
items are present and properly configured:
Kernel
-# cp /netbsd /usr/sandbox +#
cp /netbsd /usr/sandbox
/dev/*
+/dev/*
-# cd /usr/sandbox/dev ; sh MAKEDEV all +#
cd /usr/sandbox/dev ; sh MAKEDEV all
/etc/resolv.conf +
/etc/resolv.conf
(for security/smtpd and
- mail):
-# cp /etc/resolv.conf /usr/sandbox/etc +#
cp /etc/resolv.conf /usr/sandbox/etc
Working(!) mail config (hostname, sendmail.cf):
-# cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail +#
cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
/etc/localtime (for
- /etc/localtime
+ (for security/smtpd):
-# ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime +#
ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
/usr/src (system +
/usr/src
(system
sources, for sysutils/aperture,
- net/ppp-mppe):
-# ln -s ../disk1/cvs . -# ln -s cvs/src-1.6 src +#
ln -s ../disk1/cvs .
+#
ln -s cvs/src-1.6 src
Create /var/db/pkg - (not part of default install):
+Create /var/db/pkg
(not part of
+ default install):
-# mkdir /usr/sandbox/var/db/pkg +#
mkdir /usr/sandbox/var/db/pkg
Create /usr/pkg (not - part of default install):
+Create /usr/pkg
+ (not part of default install):
-# mkdir /usr/sandbox/usr/pkg +#
mkdir /usr/sandbox/usr/pkg
Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:
+Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc
:
-# cd /usr/sandbox/usr -# cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P 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 @@ -3264,32 +3307,33 @@ fi
Make /usr/sandbox/usr/pkgsrc/packages - and .../distfiles point - somewhere appropriate. NFS- and/or nullfs-mounts - may come in handy!
+Make /usr/sandbox/usr/pkgsrc/packages
+ and .../distfiles
+ point somewhere appropriate. NFS- and/or
+ nullfs-mounts may come in handy!
Edit /etc/mk.conf,
- see Edit /etc/mk.conf
, see Section 5.3.1.1,
“/etc/mk.conf”.
Adjust mk/bulk/build.conf to suit your +
Adjust mk/bulk/build.conf
to suit your
needs.
If you have set CVS_USER in build.conf, make sure that - account exists and can do a cvs ${CVS_FLAGS} update +
If you have set CVS_USER
in build.conf
, make sure that
+ account exists and can do a cvs ${CVS_FLAGS} update
properly!
When the chroot sandbox is setup, you can start the build with the following steps:
-# cd /usr/sandbox/usr/pkgsrc -# sh mk/bulk/do-sandbox-build +#
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
+ be in /usr/sandbox/usr/pkgsrc/packages
(wherever that points/mounts to/from).
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 defining SPECIFIC_PKGS in /etc/mk.conf, the variables
+ packages in pkgsrc, thepkgsrc/mk/bulk/build
script may be
+ used to build a subset of the packages contained in
+ pkgsrc. By setting defining SPECIFIC_PKGS
in /etc/mk.conf
, the variables
One use of this is to do a bulk build with
- SPECIFIC_PKGS in a chroot
+ 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
@@ -3379,39 +3423,40 @@ fi
upload binary pkgs built by bulk builds to
ftp.NetBSD.org.
First, 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:
+First, 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=$CVS_USER@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
Please use appropviate values for "pkgsrc-200xQ4", "NetBSD-a.b.c" and "arch" here. If your login on - ftp.NetBSD.org is different from CVS_USER, write your login directly into - the variable, e.g. my local account is "feyrer", but - for my login "hubertf", I use:
+ ftp.NetBSD.org is different fromCVS_USER
, 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 +
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/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
- Please note that /pub/NetBSD/packages is only +
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.
/pub/pkgsrc
.
Before uploading the binary pkgs, ssh authentication needs to be setup next. This example shows how to setup @@ -3419,26 +3464,26 @@ nbftp% 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!
+#
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-# ssh ftp.NetBSD.org date +chroot-#
ssh ftp.NetBSD.org date
Use "-l yourNetBSDlogin" here as appropriate!
@@ -3446,12 +3491,12 @@ chroot-# 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 +chroot-#
exit
+#
cd /usr/sandbox/usr/pkgsrc
+#
sh mk/bulk/do-sandbox-upload
The upload process may take quite some time. Use @@ -3461,20 +3506,22 @@ chroot-# After the upload has ended, first thing is to revoke ssh access:
-nbftp% vi ~/.ssh/authorized_keys
+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:
+ theupload
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%cd /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch
+nbftp%mv upload/* .
+nbftp%rmdir upload
+nbftp%chmod 755 .
Complete documentation for cdpack is found in the cdpack(1) manpage. 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.
+ 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 +#
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
+ (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 +#
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
Now create the images:
-# cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images +-#
cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
Each image will contain README, COPYING, and bin/myscript in their root +
Each image will contain README
, COPYING
, and bin/myscript
in their root
directories.
Table of Contents
Yes, <tech-pkg@NetBSD.org> +
Yes, <tech-pkg@NetBSD.org>
is the list for discussing package related issues. To
subscribe do:
-% echo subscribe tech-pkg | mail majordomo@NetBSD.org
+%
echo subscribe tech-pkg | mail majordomo@NetBSD.org
An archive of the list is available at chmod 755 .
Pkgviews is tightly integrated with buildlink. You can - find a pkgviews User's guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.
+ find a pkgviews User's guide inpkgsrc/mk/buildlink3/PKGVIEWS_UG
.
The pkgsrc/pkgtools +
The pkgsrc/pkgtools
directory pkgtools contains a number of useful utilities
for both users and developers of pkgsrc. This section
attempts only to make the reader aware of the utilities
@@ -3703,8 +3757,8 @@ nbftp% chmod 755 .
pkgtools/x11-links: symlinks - for use by buildlink
+ class="pkgname">pkgtools/x11-links: symlinks + for use by buildlinkpkgtools/digest: calculates - SHA1 checksums (and other kinds)
+ class="pkgname">pkgtools/digest: calculates + SHA1 checksums (and other kinds)pkgtools/libnbcompat: compat - library for pkg tools
+ class="pkgname">pkgtools/libnbcompat: compat + library for pkg toolspkgtools/mtree: installed on - non-BSD systems due to lack of native mtree
+ class="pkgname">pkgtools/mtree: installed on + non-BSD systems due to lack of native mtreepkgtools/pkg_install: - up-to-date replacement for - /usr/sbin/pkg_install, or for use on operating - systems where pkg_install is not present
+ class="pkgname">pkgtools/pkg_install: + up-to-date replacement for /usr/sbin/pkg_install, + or for use on operating systems where pkg_install + is not presentpkgtools/pkg_tarup: create a - binary package from an already-installed - package. used by 'make replace' to save the old - package
+ class="pkgname">pkgtools/pkg_tarup: create a + binary package from an already-installed package. + used by 'make replace' to save the old packagepkgtools/dfdisk: adds extra - functionality to pkgsrc, allowing it to fetch - distfiles from multiple locations. It currently - supports the following methods: multiple CD-ROMs - and network FTP/HTTP connections.
+ class="pkgname">pkgtools/dfdisk: adds extra + functionality to pkgsrc, allowing it to fetch + distfiles from multiple locations. It currently + supports the following methods: multiple CD-ROMs + and network FTP/HTTP connections.pkgtools/xpkgwedge: put X11 - packages someplace else (enabled by default)
+ class="pkgname">pkgtools/xpkgwedge: put X11 + packages someplace else (enabled by default)devel/cpuflags: will - determine the best compiler flags to optimise - code for your current CPU and compiler.
+ class="pkgname">devel/cpuflags: will determine + the best compiler flags to optimise code for your + current CPU and compiler.pkgtools/pkg_chk: installs - pkg_chk, which reports on packages whose - installed versions do not match the latest - pkgsrc entries
+ class="pkgname">pkgtools/pkg_chk: installs + pkg_chk, which reports on packages whose installed + versions do not match the latest pkgsrc entriespkgtools/pkgdep: makes - dependency graphs of packages, to aid in - choosing a strategy for updating
+ class="pkgname">pkgtools/pkgdep: makes + dependency graphs of packages, to aid in choosing a + strategy for updatingpkgtools/pkgdepgraph: make - graph from above (uses graphviz)
+ class="pkgname">pkgtools/pkgdepgraph: make + graph from above (uses graphviz)pkgtools/pkglint: This - provides two distinct abilities: check a pkgsrc - entry for correctness (pkglint) check for and - remove out-of-date distfiles and binary packages - (lintpkgsrc)
+ class="pkgname">pkgtools/pkglint: This provides + two distinct abilities: check a pkgsrc entry for + correctness (pkglint) check for and remove + out-of-date distfiles and binary packages + (lintpkgsrc)pkgtools/pkgsurvey: report - what packages you have installed
+ class="pkgname">pkgtools/pkgsurvey: report what + packages you have installedpkgtools/pkgdiff: automate - making and maintaining patches for a package - (includes pkgdiff, pkgvi, mkpatches, ...)
+ class="pkgname">pkgtools/pkgdiff: automate + making and maintaining patches for a package + (includes pkgdiff, pkgvi, mkpatches, ...)pkgtools/rpm2pkg, pkgtools/url2pkg: aids in - converting to pkgsrc
+ class="pkgname">pkgtools/rpm2pkg, pkgtools/url2pkg: aids in + converting to pkgsrcpkgtools/gensolpkg: convert - pkgsrc to a Solaris package
+ class="pkgname">pkgtools/gensolpkg: convert + pkgsrc to a Solaris packagepkgtools/pkgconflict: find - packages that conflict but aren't marked as - such
+ class="pkgname">pkgtools/pkgconflict: find + packages that conflict but aren't marked as + suchpkgtools/pkg_comp: build - packages in a chrooted area
+ class="pkgname">pkgtools/pkg_comp: build + packages in a chrooted areapkgtools/libkver: spoof - kernel version for chrooted cross builds
+ class="pkgname">pkgtools/libkver: spoof kernel + version for chrooted cross buildsBy default resuming transferencies in pkgsrc is
+ disabled, but you can enable this feature adding the
+ option PKG_RESUME_TRANSFERS=YES
into
+ mk.conf
, if a previous
+ transfer wasn't completed, it will try to resume it
+ saving your bandwidth.
For example, if you want to use wget
to resume downloads, you'll have
+ to use something like:
+ FETCH_CMD=wget + .if defined(FETCH_CMD) && ${FETCH_CMD} == "wget" + FETCH_BEFORE_ARGS=--passive-ftp + FETCH_RESUME_ARGS=-c + FETCH_OUTPUT_ARGS=-O + .endif + ++ +
Don't forget to set FETCH_RESUME_ARGS
and FETCH_OUTPUT_ARGS
if you are not using
+ default values.
If you want to use XFree86 from pkgsrc instead of your - system's own X11 (/usr/X11R6, - /usr/openwin, ...), you will - have to add the following lines into mk.conf:
+ system's own X11 (/usr/X11R6
, /usr/openwin
, ...), you will have to
+ add the following line into mk.conf
:
X11_TYPE=XFree86 @@ -3961,17 +4052,18 @@ nbftp% chmod 755 .
If you want to use X.org from pkgsrc instead of your - system's own X11 (/usr/X11R6, - /usr/openwin, ...) you will - have to add the following lines into mk.conf:
+ system's own X11 (/usr/X11R6
, /usr/openwin
, ...) you will have to add
+ the following line into mk.conf
:
X11_TYPE=xorg @@ -3983,7 +4075,7 @@ nbftp% chmod 755 . @@ -4008,33 +4100,33 @@ http_proxy=http://orpheus.amdahl.com:80/This depends on which utility is used to retrieve - distfiles. From bsd.pkg.mk, - FETCH_CMD is assigned the first - available command from the following list:
+ distfiles. Frombsd.pkg.mk
, +FETCH_CMD
is assigned the + first available command from the following list:${LOCALBASE}/bin/ftp /usr/bin/ftpOn a default NetBSD installation, this will be - /usr/bin/ftp, which +
+/usr/bin/ftp
, which automatically tries passive connections first, and falls back to active connections if the server refuses to do passive. For the other tools, add the following to your - /etc/mk.conf file: PASSIVE_FETCH=1./etc/mk.conf
file: +PASSIVE_FETCH=1
. -Having that option present will prevent /usr/bin/ftp from falling back to active - transfers.
+Having that option present will prevent
/usr/bin/ftp
from falling back to + active transfers.@@ -4042,7 +4134,7 @@ ${LOCALBASE}/bin/ftp @@ -4050,57 +4142,59 @@ ${LOCALBASE}/bin/ftp@@ -4109,7 +4203,7 @@ ${LOCALBASE}/bin/ftpYou would like to download all the distfiles in a single batch from work or university, where you can't run - a make fetch. There - is an archive of distfiles on make + fetch. There is an archive of distfiles + on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
-The answer here is to do a make fetch-list in /usr/pkgsrc or one of it's +
The answer here is to do a make fetch-list in
/usr/pkgsrc
or one of it's subdirectories, carry the resulting list to your machine at work/school and use it there If you don't have a NetBSD-compatible ftp(1) (like lukemftp) at work, don't - forget to set FETCH_CMD to + forget to setFETCH_CMD
to something that fetches a URL:At home:
-% cd /usr/pkgsrc -% make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh -% scp /tmp/fetch.sh work:/tmp +%
cd /usr/pkgsrc
+%
make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
+%
scp /tmp/fetch.sh work:/tmp
At work:
-% sh /tmp/fetch.sh +-%
sh /tmp/fetch.sh
then tar up /tmp/distfiles - and take it home.
+then tar up
/tmp/distfiles
and take it home.If you have a machine running NetBSD, and you want to get all distfiles (even ones that aren't for your machine architecture), you can do so by using the above-mentioned - make fetch-list - approach, or fetch the distfiles directly by running:
+ make + fetch-list approach, or fetch the + distfiles directly by running:-% make mirror-distfiles +-%
make mirror-distfiles
If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can - get everything by running:
+If you even decide to ignore
NO_{SRC,BIN}_ON_{FTP,CDROM}
, then you + can get everything by running:-% make fetch NO_SKIP=yes +%
make fetch NO_SKIP=yes
@@ -4119,22 +4213,21 @@ ${LOCALBASE}/bin/ftp6.10. What does + "id2585163" id="id2585163">6.11. What does “Don't know how to make /usr/share/tmac/tmac.andoc” mean?
When compiling the pkgtools/pkg_install package, you - get the error from make that it doesn't know how to - make /usr/share/tmac/tmac.andoc? This - indicates that you don't have installed the - “text” set on - your machine (nroff, ...). It is recommended to do - that to format manpages.
+ class="pkgname">pkgtools/pkg_install package, you get + the error from make that it doesn't know how to make +/usr/share/tmac/tmac.andoc
? + This indicates that you don't have installed the + “text” set on your + machine (nroff, ...). It is recommended to do that to + format manpages.In the case of the pkgtools/pkg_install package, you - can get away with setting NOMAN=YES either in the environment or - in /etc/mk.conf.
+ class="pkgname">pkgtools/pkg_install package, you can + get away with settingNOMAN=YES
either in the environment or + in/etc/mk.conf
.@@ -4142,27 +4235,28 @@ ${LOCALBASE}/bin/ftp-You didn't install the compiler set, comp.tgz, when you installed your NetBSD - machine. Please get it and install it, by extracting it - in /:
+You didn't install the compiler set,
comp.tgz
, when you installed your + NetBSD machine. Please get it and install it, by + extracting it in/
:-# cd / -# tar --unlink -zxvpf .../comp.tgz +-#
cd /
+#
tar --unlink -zxvpf .../comp.tgz
comp.tgz is part of every - NetBSD release. Get the one that corresponds to your - release (determine via uname - -r).
+
comp.tgz
is part of + every NetBSD release. Get the one that corresponds to + your release (determine via uname -r).@@ -4170,7 +4264,7 @@ ${LOCALBASE}/bin/ftp @@ -4184,9 +4278,9 @@ ${LOCALBASE}/bin/ftp use it, install sudo (either as binary package or from security/sudo) and then put the - following into your /etc/mk.conf: + class="pkgname">security/sudo) and then put the + following into your-/etc/mk.conf
:.if exists(/usr/pkg/bin/sudo) SU_CMD=/usr/pkg/bin/sudo /bin/sh -c @@ -4201,79 +4295,80 @@ ${LOCALBASE}/bin/ftpThe global variable PKG_SYSCONFBASE (and some others) can be - set by the system administrator in /etc/mk.conf to define the place where +
The global variable
+ go toPKG_SYSCONFBASE
(and some others) can be + set by the system administrator in/etc/mk.conf
to define the place where configuration files get installed. Therefore, packages must be adapted to support this feature. Keep in mind that you should only install files that are strictly necessary in the configuration directory, files that can - go to $PREFIX/share should go - there.$PREFIX/share
should + go there.We will take a look at available variables first - (bsd.pkg.mk contains more - information). PKG_SYSCONFDIR is - where the configuration files for a package may be found - (that is, the full path, e.g. /etc or /usr/pkg/etc). This value may be + (
bsd.pkg.mk
contains more + information).PKG_SYSCONFDIR
+ is where the configuration files for a package may be + found (that is, the full path, e.g./etc
or/usr/pkg/etc
). This value may be customized in various ways:@@ -4287,28 +4382,30 @@ ${LOCALBASE}/bin/ftp now. When you change this pathname in packages, you should not allow them to install files in that directory directly. Instead they need to install those files under - share/examples/${PKGNAME} so - PLIST can register them. +
- -
PKG_SYSCONFBASE is the - main config directory under which all package +
+ typically want to set it to
PKG_SYSCONFBASE
is + the main config directory under which all package configuration files are to be found. Users will - typically want to set it to /etc, or accept the default - location of $PREFIX/etc./etc
, or accept the default + location of$PREFIX/etc
.- -
PKG_SYSCONFSUBDIR is - the subdirectory of PKG_SYSCONFBASE under which the +
+ found. Defaults to
PKG_SYSCONFSUBDIR
+ is the subdirectory ofPKG_SYSCONFBASE
under which the configuration files for a particular package may be - found. Defaults to ${SYSCONFBASE}.${SYSCONFBASE}
.- -
PKG_SYSCONFVAR is the - special suffix used to distinguish any overriding - values for a particular package (see next item). It - defaults to ${PKGBASE}, - but for a collection of related packages that - should all have the same PKG_SYSCONFDIR value, it can be set - in each of the package Makefiles to a common - value.
+
PKG_SYSCONFVAR
is + the special suffix used to distinguish any + overriding values for a particular package (see + next item). It defaults to${PKGBASE}
, but for a collection + of related packages that should all have the same +PKG_SYSCONFDIR
value, + it can be set in each of the package Makefiles to a + common value.- -
PKG_SYSCONFDIR.${PKG_SYSCONFVAR} - overrides the value of ${PKG_SYSCONFDIR} for packages with - the same value for PKG_SYSCONFVAR.
+
PKG_SYSCONFDIR.${PKG_SYSCONFVAR}
+ overrides the value of${PKG_SYSCONFDIR}
for packages + with the same value forPKG_SYSCONFVAR
.As an example, all the various KDE packages may - want to set PKG_SYSCONFVAR - to “kde” so - admins can set PKG_SYSCONFDIR.kde in /etc/mk.conf to define where to + want to set
PKG_SYSCONFVAR
to + “kde” so + admins can setPKG_SYSCONFDIR.kde
in/etc/mk.conf
to define where to install KDE config files.share/examples/${PKGNAME}
+ soPLIST
can register + them.Once you have the required configuration files in - place (under the share/examples - directory) the variable CONF_FILES should be set to copy them into - PKG_SYSCONFDIR. The contents of - this variable is formed by pairs of filenames; the first + place (under the
share/examples
directory) the variable +CONF_FILES
should be set to + copy them intoPKG_SYSCONFDIR
. The contents of this + variable is formed by pairs of filenames; the first element of the pair specifies the file inside the - examples directory (registered by PLIST) and the second element specifies + examples directory (registered byPLIST
) and the second element specifies the target file. This is done this way to allow binary packages to place files in the right directory using - INSTALL/DEINSTALL scripts which are created - automatically. The package Makefile must also set USE_PKGINSTALL=YES to use these +INSTALL
/DEINSTALL
scripts which are created + automatically. The packageMakefile
must also setUSE_PKGINSTALL=YES
to use these automatically generated scripts. The automatic copying of config files can be toggled by setting the environment - variable PKG_CONFIG prior to + variablePKG_CONFIG
prior to package installation.Here is an example, taken from mail/mutt/Makefile:
@@ -4318,12 +4415,13 @@ CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/MuttrcAs you can see, this package installs configuration - files inside EGDIR, which are - registered by PLIST. After - that, the variable CONF_FILES - lists the installed file first and then the target file. - Users will also get an automatic message when files are - installed using this method.
+ files insideEGDIR
, which + are registered byPLIST
. + After that, the variableCONF_FILES
lists the installed file + first and then the target file. Users will also get an + automatic message when files are installed using this + method.@@ -4332,7 +4430,7 @@ CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc@@ -4349,8 +4447,8 @@ CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc this, install the security/audit-packages package. - It has two components: + class="pkgname">security/audit-packages package. It + has two components:@@ -4819,41 +4928,41 @@ fi@@ -4365,8 +4463,8 @@ CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities
+ target= + "_top">ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities- @@ -4438,26 +4536,28 @@ fi
- @@ -4466,25 +4566,28 @@ fi
- -
-
- 8.1. RCS +
- 8.1. RCS ID
-- 8.2. - Semi-automatic PLIST generation
+- 8.2. + Semi-automatic
PLIST
+ generation- 8.3. - Tweaking output of make print-PLIST
+ Tweaking output of make + print-PLIST- 8.4. Variable substitution in PLIST
-- 8.5. +
- 8.5. Manpage-compression
-- 8.6. - Changing PLIST source with PLIST_SRC
+- 8.6. + Changing PLIST source with
-PLIST_SRC
- 8.7. +
- 8.7. Platform specific and differing PLISTs
@@ -4499,36 +4602,40 @@ fi- @@ -4540,12 +4647,12 @@ fi
-
- 9.1. +
- 9.1. Converting packages to use buildlink3
-- 9.2. - Writing buildlink3.mk files
+- 9.2. + Writing
buildlink3.mk
+ files- -
- 9.3. - Writing builtin.mk files
+- 9.3. + Writing
builtin.mk
+ files
- 9.3.1. Anatomy of a builtin.mk - file
+ "#id2588578">9.3.1. Anatomy of abuiltin.mk
file- 9.3.2. Global preferences for native + "#id2588873">9.3.2. Global preferences for native or pkgsrc software
- @@ -4557,7 +4664,7 @@ fi
- 11.1. Program location
-- 11.2. +
- 11.2. Main targets
-
- 12.1. +
- 12.1. General operation
- -
- 12.1.1. How to pull in variables + "#id2590972">12.1.1. How to pull in variables from /etc/mk.conf
- 12.1.2. Restricted + "#id2591124">12.1.2. Restricted packages
- 12.1.4. Handling conflicts with + "#id2591639">12.1.4. Handling conflicts with other packages
- 12.1.5. Packages that cannot or + "#id2591757">12.1.5. Packages that cannot or should not be built
- 12.1.6. Packages which should not be + "#id2591783">12.1.6. Packages which should not be deleted, once installed
- 12.1.8. How to handle compiler + "#id2591875">12.1.8. How to handle compiler bugs
- 12.1.9. How to handle incrementing + "#id2591897">12.1.9. How to handle incrementing versions when fixing an existing package
- 12.1.10. Portability of + "#id2591946">12.1.10. Portability of packages
- 12.2. +
- 12.2. Possible downloading issues
- -
- 12.3. +
- 12.3. Configuration gotchas
- @@ -4645,65 +4752,65 @@ fi libtool
- 12.3.2. Using libtool on GNU + "#id2592593">12.3.2. Using libtool on GNU packages that already support libtool
- 12.3.3. GNU + "#id2592677">12.3.3. GNU Autoconf/Automake
- 12.4. +
-- 12.4. Building considerations
- 12.4.1. CPP defines
+ "#id2592793">12.4.1. CPP defines- 12.5. +
- 12.5. Package specific actions
- -
- 12.5.1. Package configuration + "#id2592826">12.5.1. Package configuration files
- 12.5.2. User + "#id2592929">12.5.2. User interaction
- 12.5.3. Handling + "#id2593042">12.5.3. Handling licenses
- 12.5.4. Creating an account from a + "#id2593193">12.5.4. Creating an account from a package
- 12.5.5. Installing score + "#id2593392">12.5.5. Installing score files
- 12.5.6. Packages providing login + "#id2593435">12.5.6. Packages providing login shells
- 12.5.7. Packages containing perl + "#id2593493">12.5.7. Packages containing perl scripts
- 12.5.8. Packages with hardcoded + "#id2593511">12.5.8. Packages with hardcoded paths to other interpreters
- 12.5.9. Packages installing perl + "#id2593532">12.5.9. Packages installing perl modules
- 12.5.11. Packages installing GConf2 + "#id2593752">12.5.11. Packages installing GConf2 data files
- 12.5.12. Packages installing + "#id2593852">12.5.12. Packages installing scrollkeeper data files
- 12.5.13. Packages installing X11 + "#id2593904">12.5.13. Packages installing X11 fonts
- 12.5.14. Packages installing GTK2 + "#id2593950">12.5.14. Packages installing GTK2 modules
- 12.5.15. Packages installing SGML or + "#id2594020">12.5.15. Packages installing SGML or XML data
- 12.5.16. Packages installing + "#id2594140">12.5.16. Packages installing extensions to the MIME database
- 12.5.17. Packages using + "#id2594347">12.5.17. Packages using intltool
- 12.6. +
- 12.6. Feedback to the author
@@ -4753,17 +4860,17 @@ fi- @@ -4786,26 +4893,28 @@ fi
- 7.1. Makefile
+ "#components.Makefile">7.1.Makefile
- 7.2. distinfo
+ "#components.distinfo">7.2.distinfo
- 7.3. patches/*
-- 7.4. Other +
- 7.4. Other mandatory files
- 7.5. Optional files
-- 7.6. - work*
+- 7.6. +
-work*
- 7.7. - files/*
+- 7.7. +
files/*
Building, installation and creation of a binary - package are all controlled by the package's Makefile.
- -There is a Makefile for each - package. This file includes the standard bsd.pkg.mk file (referenced as ../../mk/bsd.pkg.mk), which sets all the - definitions and actions necessary for the package to - compile and install itself. The mandatory variables are - the DISTNAME which specifies the - base name of the distribution file to be downloaded from - the site on the Internet, MASTER_SITES which specifies that site, - CATEGORIES which denotes the - categories into which the package falls, PKGNAME which is the name of the package, - the MAINTAINER's name, and the - COMMENT variable, which should - contain a one-line description of the package (the - package name should not appear, it will be added - automatically). The maintainer variable is there so that - anyone who quibbles with the (always completely correct) - decisions taken by the guy who maintains the package can - complain vigorously, or send chocolate as a sign of - appreciation.
- -The MASTER_SITES may be set - to one of the predefined sites:
+ package are all controlled by the package'sMakefile
. + +There is a
+ +Makefile
for + each package. This file includes the standard +bsd.pkg.mk
file (referenced + as../../mk/bsd.pkg.mk
), + which sets all the definitions and actions necessary for + the package to compile and install itself. The mandatory + variables are theDISTNAME
+ which specifies the base name of the distribution file to + be downloaded from the site on the Internet,MASTER_SITES
which specifies that site, +CATEGORIES
which denotes the + categories into which the package falls,PKGNAME
which is the name of the + package, theMAINTAINER
's + name, and theCOMMENT
+ variable, which should contain a one-line description of + the package (the package name should not appear, it will + be added automatically). The maintainer variable is there + so that anyone who quibbles with the (always completely + correct) decisions taken by the guy who maintains the + package can complain vigorously, or send chocolate as a + sign of appreciation.The
MASTER_SITES
may be + set to one of the predefined sites:${MASTER_SITE_APACHE} ${MASTER_SITE_DEBIAN} @@ -4890,15 +4999,15 @@ fi "margin-left: 0.5in; margin-right: 0.5in;">-Note
-MASTER_SITE_SUBDIR has been - deprecated and should no - longer be used.
+-
MASTER_SITE_SUBDIR
has + been deprecated and should + no longer be used.If the package has multiple DISTFILES or multiple PATCHFILES from different sites, set - SITES_foo to a list of URI's +
If the package has multiple
@@ -4909,14 +5018,14 @@ SITES_foo-file.tar.gz=http://www.somewhere.com/somehow/ \ http://www.somewhereelse.com/mirror/somehow/DISTFILES
or multiplePATCHFILES
from different sites, set +SITES_foo
to a list of URI's where file “foo” may be found. “foo” includes the suffix, e.g.Note that the normal default setting of DISTFILES must be made explicit if you +
Note that the normal default setting of
DISTFILES
must be made explicit if you want to add to it (rather than replace it), as you usually would.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 @@ -4933,14 +5042,14 @@ converters games mbone print x11@@ -4998,45 +5107,48 @@ converters games mbone print x11 distributed by the author. This ensures that the distfile retrieved from the Internet has not been corrupted during transfer or altered by a malign force to introduce a - security hole. It is generated using the make makesum command. The digest - algorithm used was, at one stage, md5, but that was felt - lacking compared to sha1, and so sha1 is now the default + security hole. It is generated using the + make + makesum command. The digest algorithm + used was, at one stage, md5, but that was felt lacking + compared to sha1, and so sha1 is now the default algorithm. The distfile size is also generated and stored in new distinfo files. The pkgtools/digest utility calculates - all of the digests in the distinfo file, and it - provides various different algorithms. At the current - time, the algorithms provided are: md5, rmd160, sha1, sha256, sha384 and sha512. + class="pkgname">pkgtools/digest utility calculates + all of the digests in the distinfo file, and it provides + various different algorithms. At the current time, the + algorithms provided are: md5, rmd160, sha1, sha256, sha384 and sha512.
- -
Add MANCOMPRESSED if - manpages are installed in compressed form by the - package; see comment in bsd.pkg.mk.
+Add
MANCOMPRESSED
+ if manpages are installed in compressed form by the + package; see comment inbsd.pkg.mk
.- -
Replace /usr/local +
Replace
@@ -4955,24 +5064,24 @@ converters games mbone print x11/usr/local
with “${PREFIX}” in all files (see patches, below).- -
Set MAINTAINER to be - yourself. If you really can't maintain the package - for future updates, set it to Set
+ "mailto:tech-pkg@NetBSD.org">tech-pkg@NetBSD.org>.MAINTAINER
to + be yourself. If you really can't maintain the + package for future updates, set it to<tech-pkg@NetBSD.org>
.If a home page for the software in question - exists, add the variable HOMEPAGE right after MAINTAINER. The value of this + exists, add the variable
HOMEPAGE
right afterMAINTAINER
. The value of this variable should be the URL for the home page.- -
@@ -4986,8 +5095,8 @@ converters games mbone print x11Be sure to set the COMMENT variable to a short +
Be sure to set the
COMMENT
variable to a short description of the package, not containing the pkg's name.Some packages have different sets of distfiles on a per architecture basis, 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.
+ class="pkgname">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 message digest/checksum for all the official - patches found in the patches/ - directory (see patches/ directory (see Section 7.3, “patches/*”) for the package is also - stored in the distinfo file. - This is a message digest/checksum of all lines in the - patch file except the NetBSD RCS Id. This file is - generated by invoking make - makepatchsum (or make - mps if you're in a hurry).
+ stored in thedistinfo
+ file. This is a message digest/checksum of all lines in + the patch file except the NetBSD RCS Id. This file is + generated by invoking make + makepatchsum (or make mps if you're in a + hurry).@@ -5060,14 +5172,15 @@ converters games mbone print x11 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. - -@@ -5132,7 +5248,7 @@ converters games mbone print x11 @@ -5140,8 +5256,8 @@ converters games mbone print x11The 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 +
+ +patch-aa
is applied before +patch-ab
, etc.The
@@ -5080,49 +5193,52 @@ converters games mbone print x11patch-*
files should + be in diff + -bu format, and apply without a fuzz to + avoid problems. (To force patches to apply with fuzz you + can setPATCH_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.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 pkgdiff from the pkgtools/pkgdiff package to avoid - these problems.
+ class="pkgname">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.
+ 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 make + makepatchsum command, see Section 7.2, - “distinfo”.
+ “distinfo
”.Patch files that are distributed by the author or - other maintainers can be listed in $PATCHFILES.
+ 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 + 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 + stored inside these dirs (also known as$LOCALPATCHES/$PKGPATH
). For example if + you want to keep a private patch forpkgsrc/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.--
- DESCR
+DESCR
- -
A multi-line description of the piece of @@ -5152,8 +5268,8 @@ converters games mbone print x11 everything that you write here.
- PLIST
+PLIST
This file governs the files that are installed @@ -5183,8 +5299,8 @@ converters games mbone print x11
@@ -5256,57 +5372,60 @@ MESSAGE_SUBST+= SOMEVAR="somevalue"-
- INSTALL
+INSTALL
- -
This shell script is invoked twice by PLIST. See - PLIST. + See pkg_add(1) and @@ -5207,8 +5323,8 @@ converters games mbone print x11 more information.
- DEINSTALL
+DEINSTALL
- -
This script is executed before and after any @@ -5227,8 +5343,8 @@ converters games mbone print x11 more information.
- MESSAGE
+MESSAGE
Display this file after installation of the @@ -5236,16 +5352,16 @@ converters games mbone print x11 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:
+ easily by usingMESSAGE_SUBST
in the package's +Makefile
:MESSAGE_SUBST+= SOMEVAR="somevalue"replaces "${SOMEVAR}" with “somevalue” in MESSAGE.
+ "quote">somevalue” inMESSAGE
.When you type make - the distribution files are unpacked into this directory. - It can be removed by running make clean. Besides the sources, - this directory is also used to keep various timestamp +
When you type make the distribution files are + unpacked into this directory. It can be removed by + running make + clean. Besides the sources, this + directory is also used to keep various timestamp files.
If a package doesn't create a subdirectory for itself (like GNU software does, for instance), but extracts itself in the current directory, you should set - WRKSRC accordingly, e.g. +
+ class="pkgname">editors/sam again, but the quick + answer is:WRKSRC
accordingly, e.g. editors/sam again, but the quick - answer is:WRKSRC= ${WRKDIR}-Please note that the old NO_WRKSUBDIR has been deprecated and +
Please note that the old
+ class="pkgname">lang/tcl and x11/tk for examples, and here is + another one:NO_WRKSUBDIR
has been deprecated and should not be used. Also, if your package doesn't create - a subdir with the name of DISTNAME but some different name, set - WRKSRC to point to the proper - name in ${WRKDIR}. See - DISTNAME but some different name, set +WRKSRC
to point to the + proper name in${WRKDIR}
. + See lang/tcl and x11/tk for examples, and here is - another one:WRKSRC= ${WRKDIR}/${DISTNAME}/unixThe name of the working directory created by pkgsrc is - work by default. If the same - pkgsrc tree should be used on several different - platforms, the variable OBJMACHINE can be set in /etc/mk.conf to +
+work
by default. If the + same pkgsrc tree should be used on several different + platforms, the variableOBJMACHINE
can be set in /etc/mk.conf to attach the platform to the directory name, e.g. - work.i386 or work.sparc.work.i386
orwork.sparc
. @@ -5326,9 +5446,9 @@ WRKSRC= ${WRKDIR}/${DISTNAME}/unix "quote">${CP}
/dev/null
and use the patch mechanism
+ to manage the creation of this file.
@@ -5346,25 +5466,28 @@ WRKSRC= ${WRKDIR}/${DISTNAME}/unix
Table of Contents
PLIST
+ generationPLIST_SRC
The PLIST file contains a +
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 ${PREFIX} directory it's been installed
+ in) plus some additional statements - see the
pkg_create(1) manpage for
a full list. This chapter addresses some issues that need
- attention when dealing with the PLIST file (or files, see below!).
PLIST
file (or files, see below!).
Be sure to add a RCS ID line as the first thing in any - PLIST file you write:
+PLIST
file you write:
@comment $NetBSD$@@ -5408,17 +5531,17 @@ WRKSRC= ${WRKDIR}/${DISTNAME}/unix
You can use the make - print-PLIST command to output a PLIST that - matches any new files since the package was extracted. - See You can use the make + print-PLIST command to output a PLIST + that matches any new files since the package was + extracted. See Section 11.3, “Other helpful targets” for more information on this target.
@@ -5431,8 +5554,8 @@ WRKSRC= ${WRKDIR}/${DISTNAME}/unixThe 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
+ you may have noticed that make print-PLIST outputs a set
+ of @comment
s 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 +
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 +
And to get all the @dirrm
lines referring to a specific (shared) directory
- converted to @comments:
@comment
s:
PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; } @@ -5491,9 +5614,9 @@ WRKSRC= ${WRKDIR}/${DISTNAME}/unix-
- ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
+${MACHINE_ARCH}
,${MACHINE_GNU_ARCH}
- -
Some packages like emacs and perl embed @@ -5501,66 +5624,67 @@ WRKSRC= ${WRKDIR}/${DISTNAME}/unix built on into the pathnames where they install their file. 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.
+ “${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 + "quote">
$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}
+${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:
+ variables in thePLIST
:
- -
${OPSYS} - output - of “uname - -s”
+
${OPSYS}
- + output of “uname + -s”- -
${LOWER_OPSYS} - - lowercase common name (eg. - “solaris”)
+
${LOWER_OPSYS}
- lowercase + common name (eg. “solaris”)- -
${OS_VERSION} - - “uname - -r”
+
${OS_VERSION}
+ - “uname + -r”- ${PKGLOCALEDIR}
+${PKGLOCALEDIR}
Packages that install locale files should list @@ -5570,21 +5694,21 @@ WRKSRC= ${WRKDIR}/${DISTNAME}/unix "quote">share/locale/de/LC_MESSAGES/...”. This properly handles the fact that different operating systems expect locale files to be either - in share or lib by default.
+ inshare
or +lib
by default.For a complete list of values which are replaced by - default, please look in bsd.pkg.mk (and search for 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 MESSAGE_SUBST (see Section 7.5, “Optional files”):
@@ -5602,24 +5726,24 @@ PLIST_SUBST+= SOMEVAR="somevalue"Manpages 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 manpages 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 (inbsd.own.mk
), and uncompressed + otherwise. To handle this in thePLIST
file, the suffix + “.gz” is + appended/removed automatically for manpages according to +MANZ
andMANCOMPRESSED
being set or not, see + above for details. This modification of thePLIST
file is done on a copy of it, not +PLIST
itself.@@ -5627,17 +5751,17 @@ PLIST_SUBST+= SOMEVAR="somevalue"-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). +
To use one or more files as source for the +
@@ -5647,7 +5771,7 @@ PLIST_SUBST+= SOMEVAR="somevalue" @@ -5661,25 +5785,26 @@ PLIST_SUBST+= SOMEVAR="somevalue"PLIST
used in generating + the binary package, set the variablePLIST_SRC
to the names of that file(s). The files are later concatenated using cat(1), and order of things is important.-
- -
PLIST.common
+
PLIST.common
- -
PLIST.${OPSYS}
+
PLIST.${OPSYS}
- -
PLIST.common_end
+
PLIST.common_end
If PLIST.${OPSYS} exists, - these files are used instead of PLIST. This allows packages which behave - in this way to be handled gracefully. Manually overriding - PLIST_SRC for other more exotic - uses is also possible.
+If
PLIST.${OPSYS}
+ exists, these files are used instead ofPLIST
. This allows packages which + behave in this way to be handled gracefully. Manually + overridingPLIST_SRC
for + other more exotic uses is also possible.@@ -5724,9 +5849,9 @@ PLIST_SUBST+= SOMEVAR="somevalue" textproc/scrollkeeper, which - removes the shared directory share/omf. + class="pkgname">textproc/scrollkeeper, which + removes the shared directory@@ -5787,32 +5913,38 @@ PLIST_SUBST+= SOMEVAR="somevalue"share/omf
.@@ -5740,35 +5865,36 @@ PLIST_SUBST+= SOMEVAR="somevalue" 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 */*-dirsTheir use from other packages is very simple. The - USE_DIRS variable takes a list - of package names (without 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 writting new packages).
For example, if a package installs files under - share/applications, it should - have the following line in it:
+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.
+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 +
Note that, even if your package is using
+ part and pkgsrc (in particular,$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.mk/dirs.mk
) will take care of it.Table of Contents
buildlink3.mk
+ filesBUILDLINK_DEPENDS.pkg
in
+ buildlink3.mk
filesbuiltin.mk
+ filesbuiltin.mk
fileSymlink headers and libraries for dependencies - into BUILDLINK_DIR, which by - default is a subdirectory of WRKDIR.
+ intoBUILDLINK_DIR
,
+ which by default is a subdirectory of WRKDIR
.
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.
+ 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.
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 --
+ 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.
Set USE_BUILDLINK3 to - “yes”.
+Set USE_BUILDLINK3
+ to “yes”.
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
+ sure is the check ${WRKDIR}/.work.log
to see if the
wrappers are being invoked.
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 +
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”.
pkgname
”.
Remember that only the buildlink3.mk files that you list
+ "emphasis">only the buildlink3.mk
files that you list
in a package's Makefile are added as dependencies
for that package.
There are several buildlink3.mk files in pkgsrc/mk that handle special package +
There are several buildlink3.mk
files in pkgsrc/mk
that handle special package
issues:
bdb.buildlink3.mk +
bdb.buildlink3.mk
chooses either the native or a pkgsrc Berkeley DB
- implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.
BDB_ACCEPTED
and BDB_DEFAULT
.
curses.buildlink3.mk
- If the system comes with neither Curses nor
- NCurses, this will take care to install the
- curses.buildlink3.mk
If the
+ system 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 +
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.
motif.buildlink3.mk
- checks for a system-provided Motif installation or
- adds a dependency on motif.buildlink3.mk
checks for a
+ system-provided Motif installation or adds a
+ dependency on x11/lesstif or x11/openmotif;
ossaudio.buildlink3.mk - defines several variables that may be used by - packages that use the Open Sound System (OSS) - API;
+ossaudio.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.3 or 7.4, whichever - is found installed. See the file for more - information.
+pgsql.buildlink3.mk
will accept
+ 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 pthread.buildlink3.mk
uses the
+ value of 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.buildlink3.mk
+ uses the value of XAW_TYPE
to choose a particular
+ Athena widgets library.
The comments in those buildlink3.mk files provide a more +
The comments in those buildlink3.mk
files provide a more
complete description of how to use them properly.
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.
+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, +
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:
buildlink3.mk
files:
-% cd pkgsrc/category/pkgdir -% createbuildlink -3 >buildlink3.mk +%
cd pkgsrc/
category
/pkgdir
+%
createbuildlink -3 >buildlink3.mk
The following real-life example buildlink3.mk is taken from pkgsrc/graphics/tiff:
+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 $ @@ -6081,84 +6220,88 @@ BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff 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 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
+ 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.
+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
+ inclusion and controls how the dependency on pkg
is added. Several
important variables are set in the section:
BUILDLINK_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 the last change in the - major number of a shared library or that had a - major API change.
+BUILDLINK_DEPENDS.
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 the last change in the major number of a
+ shared library or that had a major API
+ change.pkg
BUILDLINK_PKGSRCDIR.pkg is the - location of the pkg pkgsrc +
BUILDLINK_PKGSRCDIR.
is the
+ location of the pkg
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 +
BUILDLINK_DEPMETHOD.
(not
+ shown above) controls whether we use pkg
BUILD_DEPENDS
or DEPENDS
to add the dependency on
+ pkg
.
+ The build dependency is selected by setting
+ BUILDLINK_DEPMETHOD.
to
“build”.
By default, the full dependency is used.pkg
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 +
BUILDLINK_INCDIRS.
and
+ pkg
BUILDLINK_LIBDIRS.
+
(not shown above)
+ are lists of subdirectories of pkg
${BUILDLINK_PREFIX.
to
+ add to the header and library search paths. These
default to “include” and
“lib”
@@ -6166,17 +6309,18 @@ BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//}
pkg
}
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.
+BUILDLINK_CPPFLAGS.
(not
+ shown above) is the list of preprocessor flags to
+ add to pkg
CPPFLAGS
,
+ which are passed on to the configure and build
+ phases. The “-I” option should be avoided
+ and instead be handled using BUILDLINK_INCDIRS.
as
+ above.pkg
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
+ symlinked into ${BUILDLINK_DIR}
and how their names
are transformed during the symlinking:
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.
(not
+ shown above) is a shell glob pattern relative to
+ pkg
${BUILDLINK_PREFIX.
to be
+ symlinked into pkg
}${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 +
BUILDLINK_FILES_CMD.
(not
+ shown above) is a shell pipeline that outputs to
+ stdout a list of files relative to pkg
${BUILDLINK_PREFIX.
. 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}.pkg
}
${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 ${BUILDLINK_PREFIX.pkg} on stdout. - By default for overwrite packages, BUILDLINK_CONTENTS_FILTER.pkg outputs the - contents of the include - and lib directories in - the package +CONTENTS, - and for pkgviews packages, it outputs any libtool - archives in lib +
BUILDLINK_CONTENTS_FILTER.
(not
+ shown above) is a filter command that filters
+ pkg
+CONTENTS
input
+ into a list of files relative to ${BUILDLINK_PREFIX.
on
+ stdout. By default for overwrite packages,
+ pkg
}BUILDLINK_CONTENTS_FILTER.
+ outputs the contents of the pkg
include
and lib
directories in the package
+ +CONTENTS
, and for
+ pkgviews packages, it outputs any libtool
+ archives in lib
directories.
BUILDLINK_TRANSFORM.pkg (not shown - above) is a list of sed arguments used to +
BUILDLINK_TRANSFORM.
(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".pkg
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.
There are two situations that require increasing the - dependency listed in BUILDLINK_DEPENDS.pkg after a package - update:
+ dependency listed inBUILDLINK_DEPENDS.pkg
after a
+ package update:
In these cases, BUILDLINK_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_DEPENDS.pkg adjusted, too. 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.
+In these cases, BUILDLINK_DEPENDS.
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 pkg
PKGREVISION
s increased and, if they
+ have buildlink3.mk
files,
+ their BUILDLINK_DEPENDS.
adjusted, too. 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.
+ pkg
Please take careful consideration before adjusting
- BUILDLINK_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. See Section 12.1.3,
- “Handling dependencies” and BUILDLINK_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. See Section
+ 12.1.3, “Handling dependencies” and
+ Chapter 9,
Buildlink methodology for more information
about dependencies on other packages, including the
- BUILDLINK_RECOMMENDED and
- RECOMMENDED definitions.
BUILDLINK_RECOMMENDED
and
+ RECOMMENDED
+ definitions.
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.
+ base system. Aside from abuildlink3.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:
+pkg
are:
It should set USE_BUILTIN.pkg to either - “yes” or - “no” after - it is included.
+It should set USE_BUILTIN.
to
+ either “yes”
+ or “no”
+ after it is included.pkg
It should not override any - USE_BUILTIN.pkg which is - already set before the builtin.mk file is included.
+USE_BUILTIN.pkg
which is
+ already set before the builtin.mk
file is included.
It should be written to allow multiple inclusion. This is very important and takes - careful attention to Makefile coding.
+ careful attention toMakefile
coding.
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 +
The first section sets IS_BUILTIN.
depending on
+ if pkg
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.
to the
+ version of pkg
pkg
in the base system
+ if it exists (if IS_BUILTIN.
is
“yes”). This
- variable is only used internally within the builtin.mk file.pkg
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_DEPENDS.pkg. This is typically - done by comparing BUILTIN_PKG.pkg against each of the - dependencies in BUILDLINK_DEPENDS.pkg. USE_BUILTIN.pkg builtin.mk file.
+ +The third section sets USE_BUILTIN.
and is
+ required in all
+ pkg
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_DEPENDS.
. This is
+ typically done by comparing pkg
BUILTIN_PKG.
against each
+ of the dependencies in pkg
BUILDLINK_DEPENDS.
.
+ pkg
USE_BUILTIN.
must be set to the correct
- value by the end of the builtin.mk file. Note that USE_BUILTIN.pkg may be
+ value by the end of the pkg
builtin.mk
file. Note that
+ USE_BUILTIN.
may be
“yes” even if
- IS_BUILTIN.pkg is
+ pkg
IS_BUILTIN.
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.pkg
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 +
The last section is guarded by CHECK_BUILTIN.
, and
+ includes code that uses the value of pkg
USE_BUILTIN.
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).pkg
${BUILDLINK_DIR}
(via BUILDLINK_FILES.pkg
).
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
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 @@ -6545,10 +6701,10 @@ CHECK_BUILTIN.foo?= no
A package must have a builtin.mk file to be listed in - PREFER_NATIVE, otherwise it is - simply ignored in that list.
+ "emphasis">must have abuiltin.mk
file to be listed in
+ PREFER_NATIVE
, otherwise
+ it is simply ignored in that list.
Table of Contents
bsd.options.mk
Many packages have the ability to be built to support
- different sets of features. bsd.options.mk is a framework in pkgsrc
+ different sets of features. bsd.options.mk
is a framework in pkgsrc
that provides generic handling of those options that
determine different ways in which the packages can be
built. It's possible for the user to specify exactly which
@@ -6591,17 +6747,17 @@ CHECK_BUILTIN.foo?= no
Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of +
Global default options are listed in PKG_DEFAULT_OPTIONS
, which is a list of
the options that should be built into every package if
that option is supported. This variable should be set in
- /etc/mk.conf.
/etc/mk.conf
.
The following example shows how bsd.options.mk should be use in a package - Makefile, or in a file, e.g. - options.mk, that is included by - the main package Makefile.
+The following example shows how bsd.options.mk
should be use in a
+ package Makefile
, or in a
+ file, e.g. options.mk
, that
+ is included by the main package Makefile
.
# Global and legacy options .if defined(WIBBLE_USE_OPENLDAP) && !empty(WIBBLE_USE_OPENLDAP:M[yY][eE][sS]) @@ -6662,12 +6820,12 @@ CONFIGURE_ARGS+= --enable-sasl=${BUILDLINK_PREFIX.sasl}The first section only exists if you are converting a package that had its own ad-hoc options handling to use - bsd.options.mk. It converts +
+bsd.options.mk
. It converts global or legacy options variables into an equivalent - PKG_OPTIONS.pkg value. These sections - will be removed over time as the old options are in turn - deprecated and removed.PKG_OPTIONS.
value. These + sections will be removed over time as the old options are + in turn deprecated and removed.pkg
The second section contains the information about which build options are supported by the package, and any @@ -6676,33 +6834,33 @@ CONFIGURE_ARGS+= --enable-sasl=${BUILDLINK_PREFIX.sasl}
@@ -6734,22 +6892,22 @@ CONFIGURE_ARGS+= --enable-sasl=${BUILDLINK_PREFIX.sasl}
- -
PKG_OPTIONS_VAR is a - list of the name of the
PKG_OPTIONS_VAR
is + a list of the name of the make(1) variables that contain the options the user wishes to select. The recommended value is “PKG_OPTIONS.pkg” but - any package-specific value may be used. This + "quote">PKG_OPTIONS.pkg
” + but any package-specific value may be used. This variable should be set in a package Makefile.- -
PKG_SUPPORTED_OPTIONS - is a list of build options supported by the - package. This variable should be set in a package - Makefile.
+
PKG_SUPPORTED_OPTIONS
is a list of + build options supported by the package. This + variable should be set in a package Makefile.- -
${PKG_OPTIONS_VAR} (the - variables named in PKG_OPTIONS_VAR) are variables that - list the selected build options and override any - default options given in PKG_DEFAULT_OPTIONS. If any of the +
@@ -6722,8 +6880,8 @@ CONFIGURE_ARGS+= --enable-sasl=${BUILDLINK_PREFIX.sasl} -
${PKG_OPTIONS_VAR}
+ (the variables named inPKG_OPTIONS_VAR
) are variables + that list the selected build options and override + any default options given inPKG_DEFAULT_OPTIONS
. If any of the options begin with a “-”, then that option is always removed from the selected build options, e.g.This variable should be set in /etc/mk.conf.
+This variable should be set in
/etc/mk.conf
.
- -
PKG_OPTIONS contains - the list of the selected build options, properly - filtered to remove unsupported and duplicate - options.
+
PKG_OPTIONS
+ contains the list of the selected build options, + properly filtered to remove unsupported and + duplicate options.The remaining sections contain the logic that is specific to each option. There should be a check for - every option listed in PKG_SUPPORTED_OPTIONS, and there should be - clear documentation on what turning on the option will do - in the comments preceding each section. The correct way - to check for an option is to check whether it is listed - in PKG_OPTIONS.
+ every option listed inPKG_SUPPORTED_OPTIONS
, and there should + be clear documentation on what turning on the option will + do in the comments preceding each section. The correct + way to check for an option is to check whether it is + listed inPKG_OPTIONS
. @@ -6771,7 +6929,7 @@ CONFIGURE_ARGS+= --enable-sasl=${BUILDLINK_PREFIX.sasl}
pkgsrc/mk/bsd.pkg.mk
.
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 +
The automatic variable PREFIX always points to
- the location where the current pkg will be
- installed. When referring to a pkg's own
+ LOCALBASE is where all
- non-X11 pkgs are installed. If you need to
+ X11BASE is where the
- actual X11 distribution (from xsrc, etc.) is
+ X11 based are special in that they may be
- installed in either X11BASE or LOCALBASE. Usually, X11 packages should be installed under
- LOCALBASE whenever
- possible. Note that you will need to set USE_X11 in them to request the
- presence of X11 and to get the right compilation
- flags.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 PREFIX needs to
+ be put into the various places in the program's source
+ where paths to these files are encoded. See Section 7.3,
“patches/*” and
PREFIX
always
+ points to the location where the current 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 “
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
@@ -6860,101 +7018,104 @@ CONFIGURE_ARGS+= --enable-sasl=${BUILDLINK_PREFIX.sasl}
X11BASE
or LOCALBASE
.LOCALBASE
whenever
+ possible. Note that you will need to set
+ USE_X11
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
+ 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
+ they must be placed under X11BASE
. To accomplish this, set
+ either USE_X11BASE
or
+ USE_IMAKE
in your
package.
Some notes: USE_X11 and
- USE_X11BASE are mutually
- exclusive. 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 use
- both
- ${X11BASE} and ${LOCALBASE}. To force installation
- of all X11 packages in LOCALBASE, the Some notes: USE_X11
+ and USE_X11BASE
are
+ mutually exclusive. 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
+ use both
+ ${X11BASE}
and
+ ${LOCALBASE}
. To
+ force installation of all X11 packages in
+ LOCALBASE
, the
+ pkgtools/xpkgwedge is
- enabled by default.
X11PREFIX should be +
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
+ 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 “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
+ 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:
+The following lines are taken from pkgsrc/wm/scwm/Makefile
:
-EVAL_PREFIX+= GTKDIR=gtk+ +EVAL_PREFIX+= GTKDIR=gtk+ CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \ --with-gtk-prefix="${GTKDIR}" \ --enable-multibyte
Specific defaults can be defined for the
- packages evaluated using EVAL_PREFIX, by using a definition
+ packages evaluated using EVAL_PREFIX
, by using a definition
of the form:
GTKDIR_DEFAULT= ${LOCALBASE}-
where GTKDIR +
where GTKDIR
corresponds to the first definition in the
- EVAL_PREFIX pair.
EVAL_PREFIX
pair.
Within ${PREFIX}, +
Within ${PREFIX}
,
packages should install files according to hier(7),
with the exception that manual pages go into
- ${PREFIX}/man, not
- ${PREFIX}/share/man.
${PREFIX}/man
, not
+ ${PREFIX}/share/man
.
The main targets used during the build process defined - in bsd.pkg.mk are:
+ inbsd.pkg.mk
are:
This will check if the file(s) given in the - variables DISTFILES and - PATCHFILES (as defined in - the package's Makefile) are present on the local - system in /usr/pkgsrc/distfiles. If they are - not present, an attempt will be made to fetch them - using commands of the form:
+ variablesDISTFILES
+ and PATCHFILES
(as
+ defined in the package's Makefile) are present on
+ the local system in /usr/pkgsrc/distfiles
. If they
+ are not present, an attempt will be made to fetch
+ them using commands of the form:
${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
where ${site} varies through several - possibilities in turn: first, MASTER_SITE_OVERRIDE is tried, then - the sites specified in either SITES_file if defined, else - MASTER_SITES or PATCH_SITES, as applies, then - finally the value of MASTER_SITE_BACKUP. The order of all - except the first can be optionally sorted by the - user, via setting either MASTER_SORT_AWK or MASTER_SORT_REGEX.
+ possibilities in turn: first,MASTER_SITE_OVERRIDE
is tried,
+ then the sites specified in either SITES_file
if defined, else
+ MASTER_SITES
or
+ PATCH_SITES
, as
+ applies, then finally the value of MASTER_SITE_BACKUP
. The order of
+ all except the first can be optionally sorted by
+ the user, via setting either MASTER_SORT_AWK
or MASTER_SORT_REGEX
.
When the distfiles are present on the local system, they need to be extracted, as they are usually in the form of some compressed archive - format, most commonly .tar.gz.
+ format, most commonly.tar.gz
.
If only some of the distfiles need to be uncompressed, the files to be uncompressed should - be put into EXTRACT_ONLY.
- -If the distfiles are not in .tar.gz format, they can be - extracted by setting either EXTRACT_SUFX, or EXTRACT_CMD, EXTRACT_BEFORE_ARGS and EXTRACT_AFTER_ARGS. In the former - case, pkgsrc knows how to extract a number of - suffixes (.tar.gz, - .tgz, .tar.gz2, .tbz, .tar.Z, .tar, .shar.gz, .shar.bz2, .shar.Z, .shar, .Z, .bz2 - and .gz; see the - definition of the various DECOMPRESS_CMD variables bsd.pkg.mk for a complete list). - Here's an example on how to use the other variables - for a program that comes with a compressed shell - archive whose name ends in .msg.gz:
+ be put intoEXTRACT_ONLY
.
+
+ If the distfiles are not in .tar.gz
format, they can be
+ extracted by setting either EXTRACT_SUFX
, or EXTRACT_CMD
, EXTRACT_BEFORE_ARGS
and
+ EXTRACT_AFTER_ARGS
. In
+ the former case, pkgsrc knows how to extract a
+ number of suffixes (.tar.gz
, .tgz
, .tar.gz2
, .tbz
, .tar.Z
, .tar
, .shar.gz
, .shar.bz2
, .shar.Z
, .shar
, .Z
, .bz2
and .gz
; see the definition of the
+ various DECOMPRESS_CMD
+ variables bsd.pkg.mk
+ for a complete list). Here's an example on how to
+ use the other variables for a program that comes
+ with a compressed shell archive whose name ends in
+ .msg.gz
:
EXTRACT_SUFX= .msg.gz EXTRACT_CMD= zcat @@ -7073,18 +7235,20 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
After extraction, all the patches named by the
- PATCHFILES, those present
- in the patches subdirectory of the package as well
- as in $LOCALPATCHES/$PKGPATH (e.g. /usr/local/patches/graphics/png)
- are applied. Patchfiles ending in .Z or .gz
- are uncompressed before they are applied, files
- ending in .orig or
- .rej are ignored. Any
- special options to patch(1) can be handed in
- PATCH_DIST_ARGS. See
- PATCHFILES, those
+ present in the patches subdirectory of the package
+ as well as in $LOCALPATCHES/$PKGPATH (e.g.
+ /usr/local/patches/graphics/png
)
+ are applied. Patchfiles ending in .Z
or .gz
are uncompressed before they
+ are applied, files ending in .orig
or .rej
are ignored. Any special
+ options to patch(1) can be handed in PATCH_DIST_ARGS
. See Section 7.3,
“patches/*” for more details.
If the program's distfile contains its own
configure script, this can be invoked by setting
- HAS_CONFIGURE. If the
+ HAS_CONFIGURE
. If the
configure script is a GNU autoconf script,
- GNU_CONFIGURE should be
- specified instead. In either case, any arguments to
- the configure script can be specified in the
- CONFIGURE_ARGS variable,
- and the configure script's name can be set in
- CONFIGURE_SCRIPT if it
- differs from the default “GNU_CONFIGURE should
+ be specified instead. In either case, any arguments
+ to the configure script can be specified in the
+ CONFIGURE_ARGS
+ variable, and the configure script's name can be
+ set in CONFIGURE_SCRIPT
if it differs
+ from the default “configure”. Here's an example
from the sysutils/top package:
HAS_CONFIGURE= yes CONFIGURE_SCRIPT= Configure @@ -7132,34 +7297,34 @@ CONFIGURE_ARGS+= netbsd13If the program uses an Imakefile for configuration, the appropriate steps can be invoked - by setting USE_IMAKE to - “YES”. (If - you only want the package installed in $X11PREFIX but xmkmf not being run, - set USE_X11BASE - instead!)
+ by settingUSE_IMAKE
+ to “YES”. + (If you only want the package installed in +$X11PREFIX
but xmkmf + not being run, setUSE_X11BASE
instead!)
Once configuration has taken place, the software
- will be built by invoking $MAKE_PROGRAM on $MAKEFILE with $BUILD_TARGET as the target to
- build. The default MAKE_PROGRAM is “gmake” if USE_GNU_TOOLS contains
+ will be built by invoking $MAKE_PROGRAM
on $MAKEFILE
with $BUILD_TARGET
as the target to
+ build. The default MAKE_PROGRAM
is
+ “gmake” if
+ USE_GNU_TOOLS
contains
“make”,
“make”
- otherwise. MAKEFILE is set
- to “MAKEFILE is
+ set to “Makefile” by default, and
- BUILD_TARGET defaults to
- “all”. Any
- of these variables can be set in the package's
+ BUILD_TARGET
defaults
+ to “all”.
+ Any of these variables can be set in the package's
Makefile to change the default build process.
Once the build stage has completed, the final step is to install the software in public directories, so users can access the programs and - files. As in the build-target, $MAKE_PROGRAM is invoked on - $MAKEFILE here, but with - the $INSTALL_TARGET - instead, the latter defaulting to - “install” - (plus “install.man”, if USE_IMAKE is set).
+ files. As in the build-target,$MAKE_PROGRAM
is invoked on
+ $MAKEFILE
here, but
+ with the $INSTALL_TARGET
instead, the
+ latter defaulting to “install” (plus
+ “install.man”, if USE_IMAKE
is set).
If no target is specified, the default is “build”. If a subsequent stage is requested, all prior stages are made: - e.g. make build will - also perform the equivalent of:
+ e.g. make + build will also perform the equivalent + of:make fetch make checksum @@ -7241,9 +7408,9 @@ make build
If you did a make - install and you noticed some file was - not installed properly, you can repeat the +
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.
@@ -7259,8 +7426,8 @@ make buildPKG_VERBOSE
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,
+ make deinstall
+ DEINSTALLDEPENDS=1 is done in
+ pkgsrc/x11/kde
,
this is likely to remove whole KDE. Works by
adding “-R” to the make deinstall and
- make install
- (or whatever UPDATE_TARGET
- is set to) for these packages.
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
+ 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.
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!
+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!
The following variables can be used either on - the command line or in /etc/mk.conf to alter the behaviour - of make - update:
+ the command line or in/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,
+ 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 @@ -7366,27 +7536,28 @@ make build "quote">clean-update” target below) or you may run into troubles with old source code still lying around on your next - make or - make - update.
+ make or + make + update.REINSTALL
Deinstall each package before installing
- (making DEPENDS_TARGET). This may be
+ (making 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 @@ -7394,14 +7565,14 @@ make build 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).
+ prerequisite packages. Only setDEPENDS_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 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).
+ 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 usedNOCLEAN
).
If you 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 + 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 + 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 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:
+ the command line or in/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 +
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).
This target generates a README.html file, which can be +
This target generates a README.html
file, which can be
viewed using a browser such as www/mozilla or www/links. The generated
- files contain references to any packages which
- are in the PACKAGES
- directory on the local host. The generated files
- can be made to refer to URLs based on FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if
- I wanted to generate README.html files which pointed
- to binary packages on the local machine, in the
- directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost
- and FTP_PKG_URL_DIR=/usr/packages.
- The ${PACKAGES}
- directory and its subdirectories will be
- searched for all the binary packages.
PACKAGES
directory on
+ the local host. The generated files can be made to
+ refer to URLs based on FTP_PKG_URL_HOST
and FTP_PKG_URL_DIR
. For example, if I
+ wanted to generate README.html
files which pointed
+ to binary packages on the local machine, in the
+ directory /usr/packages
, set FTP_PKG_URL_HOST=file://localhost
+ and FTP_PKG_URL_DIR=/usr/packages
. The
+ ${PACKAGES}
directory
+ and its subdirectories will be searched for all the
+ binary packages.
Use this target to create a file README-all.html which contains a +
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
+ This file is compiled from the pkgsrc/*/README.html
files, so be
sure to run this after a make readme.
README.html
files, and can be
+ made to refer to URLs based on CDROM_PKG_URL_HOST
and
+ CDROM_PKG_URL_DIR
.
This target shows which distfiles and patchfiles - are needed to build the package. (DISTFILES and PATCHFILES, but not patches/*)
+ are needed to build the package. (DISTFILES
and PATCHFILES
, but not patches/*
)
This target shows which installed packages match
- the current package's DEPENDS. Useful if out of date
+ the current package's DEPENDS
. Useful if out of date
dependencies are causing build problems.
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.
+ default ifPKG_DEVELOPER
is set in
+ /etc/mk.conf
.
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
+ 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.
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
+ PLIST
, as the
“find
-newer” command used by this target
won't catch them!
See Section 8.3, - “Tweaking output of make - print-PLIST” for more information on this - target.
+ “Tweaking output of make + print-PLIST” for more + information on this target.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 it's depends, if PKG_DEPENDS is set properly. See
+ (and it's depends, if PKG_DEPENDS
is set properly. See
Section 5.3.1,
“Configuration”. After creating the
@@ -7664,9 +7840,9 @@ make build
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
pkg_add(1). If
- not, make
- bulk-package will be executed, but the
- installed binary not be removed.
A binary package is considered “upto-date” @@ -7679,9 +7855,9 @@ make build
None of the package's files (Makefile, ...) were modified - since it was built.
+None of the package's files (Makefile
, ...) were
+ modified since it was built.
Table of Contents
The problem with package-defined variables that can
- be overridden via MAKECONF or
- /etc/mk.conf is that MAKECONF
+ or /etc/mk.conf
is that
+
make(1) expands a
variable as it is used, but evaluates preprocessor like
statements (.if, .ifdef and .ifndef) as they are read.
- So, to use any variable (which may be set in /etc/mk.conf) in one of the .if*
- statements, the file /etc/mk.conf must be included before
+ So, to use any variable (which may be set in
+ /etc/mk.conf
) in one of
+ the .if* statements, the file /etc/mk.conf
must be included before
that .if* statement.
Rather than have a number of ad-hoc ways of - including /etc/mk.conf, - should it exist, or MAKECONF, - should it exist, include the pkgsrc/mk/bsd.prefs.mk file in the - package Makefile before any preprocessor-like .if, - .ifdef, or .ifndef statements:
+ including/etc/mk.conf
,
+ should it exist, or MAKECONF
, should it exist, include the
+ pkgsrc/mk/bsd.prefs.mk
+ file in the package Makefile before any
+ preprocessor-like .if, .ifdef, or .ifndef
+ statements:
.include "../../mk/bsd.prefs.mk" @@ -7940,31 +8118,31 @@ make build .endif-
If you wish to set the CFLAGS variable in /etc/mk.conf please make sure to +
If you wish to set the CFLAGS
variable in /etc/mk.conf
please make sure to
use:
CFLAGS+= -your -flags-
Using CFLAGS= (i.e. without
- the “+”) may
- lead to problems with packages that need to add their
- own flags. Also, you may want to take a look at the
- Using CFLAGS=
(i.e.
+ without the “+”)
+ may lead to problems with packages that need to add
+ their own flags. Also, you may want to take a look at
+ the devel/cpuflags package if you're
- interested in optimization for the current CPU.
RESTRICTED
+RESTRICTED
This variable should be set whenever a restriction exists (regardless of its kind). Set @@ -7987,50 +8165,52 @@ CFLAGS+= -your -flags
NO_BIN_ON_CDROM
+NO_BIN_ON_CDROM
Binaries may not be placed on CD-ROM. Set this
- variable to ${RESTRICTED} whenever a binary
+ variable to ${RESTRICTED}
whenever a binary
package may not be included on a CD-ROM.
NO_BIN_ON_FTP
+NO_BIN_ON_FTP
Binaries may not be placed on an FTP server.
- Set this variable to ${RESTRICTED} whenever a binary
+ Set this variable to ${RESTRICTED}
whenever a binary
package may not not be made available on the
Internet.
NO_SRC_ON_CDROM
+NO_SRC_ON_CDROM
Distfiles may not be placed on CD-ROM. Set
- this variable to ${RESTRICTED} if re-distribution
+ this variable to ${RESTRICTED}
if re-distribution
of the source code or other distfile(s) is not
allowed on CD-ROMs.
NO_SRC_ON_FTP
+NO_SRC_ON_FTP
Distfiles may not be placed on FTP. Set this
- variable to ${RESTRICTED} if re-distribution
+ variable to ${RESTRICTED}
if re-distribution
of the source code or other distfile(s) via the
Internet is not allowed.
Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic make +
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!
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, as well as
- dependencies via buildlink3.mk, which is the preferred
+ dependency. pkgsrc supports the BUILD_DEPENDS
and DEPENDS
definitions, as well as
+ dependencies via buildlink3.mk
, which is the preferred
way to handle dependencies, and which uses the
variables named above. See Chapter 9,
@@ -8061,21 +8241,21 @@ CFLAGS+= -your -flags
information.
The basic difference between the two variables is as
- follows: The DEPENDS
+ 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,
+ 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.
+BUILD_DEPENDS
.
- The format for a BUILD_DEPENDS and a DEPENDS definition is:
+The format for a BUILD_DEPENDS
and a DEPENDS
definition is:
<pre-req-package-name>:../../<category>/<pre-req-package>@@ -8093,9 +8273,9 @@ CFLAGS+= -your -flags
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:
+ that package has abuildlink3.mk
file available,
+ use it:
.include "../../graphics/jpeg/buildlink3.mk" @@ -8104,10 +8284,10 @@ CFLAGS+= -your -flags
If your package needs to use another package - to build itself and there is no buildlink3.mk file available, use - the BUILD_DEPENDS - definition:
+ to build itself and there is nobuildlink3.mk
file available,
+ use the BUILD_DEPENDS
definition:
BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf@@ -8115,16 +8295,15 @@ BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
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. An example of
- this is the buildlink3.mk file available,
+ this is specified using the DEPENDS
definition. An example
+ of this is the print/lyx package, which
- uses the xpm library, version 3.4j to
- build:
DEPENDS+= xpm-3.4j:../../graphics/xpm@@ -8149,7 +8328,7 @@ DEPENDS+= xpm-[0-9]*:../../graphics/xpm ambiguous matches such as “tk-postgresql” matching a “tk-*” - DEPENDS. +
DEPENDS
.
Wildcards can also be used to specify that a package will only build against a certain minimum @@ -8171,19 +8350,20 @@ DEPENDS+= tiff>=3.5.4:../../graphics/tiff such as security updates or ABI changes that do not prevent a package from building correctly. Such recommendations can be expressed using - RECOMMENDED:
+RECOMMENDED
:
RECOMMENDED+= tiff>=3.6.1:../../graphics/tiff-
In addition to the above DEPENDS line, this denotes that +
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. RECOMMENDED
- entries will be turned into dependencies unless
- explicitly ignored (in which case a warning will
- be printed). Packages that are built with
+ recommended. RECOMMENDED
entries will be
+ turned into dependencies unless explicitly
+ ignored (in which case a warning will be
+ printed). 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
@@ -8192,7 +8372,7 @@ RECOMMENDED+= tiff>=3.6.1:../../graphics/tiff
For security fixes, please update the package
vulnerabilities file as well as setting
- RECOMMENDED, see
+ If your package needs some executable to be
able to run correctly and if there's agail no
- buildlink3.mk file,
- this is specified using the DEPENDS variable. The buildlink3.mk file,
+ this is specified using the RECOMMENDED
, see
Section 12.1.7, “Handling packages with
@@ -8203,15 +8383,14 @@ RECOMMENDED+= tiff>=3.6.1:../../graphics/tiff
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@@ -8227,9 +8406,9 @@ DEPENDS+= teTeX-[0-9]*:../../print/teTeX "quote">do-configure” target print/ghostscript5 package (it - relies on the jpeg sources being present in source - form during the build): + class="pkgname">print/ghostscript5 package (it + relies on the jpeg sources being present in source form + during the build):
if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \ cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract; \ @@ -8245,29 +8424,29 @@ pre-clean: cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean-
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 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.
In this case you can set CONFLICTS to a space separated list of +
In this case you can set CONFLICTS
to a space separated list of
packages (including version string) your package
conflicts with.
For example x11/Xaw3d and x11/Xaw-Xpm install provide the - same shared library, thus you set in pkgsrc/x11/Xaw3d/Makefile:
+ class="pkgname">x11/Xaw3d and x11/Xaw-Xpm install provide the + same shared library, thus you set inpkgsrc/x11/Xaw3d/Makefile
:
CONFLICTS= Xaw-Xpm-[0-9]*-
and in pkgsrc/x11/Xaw-Xpm/Makefile:
+and in pkgsrc/x11/Xaw-Xpm/Makefile
:
CONFLICTS= Xaw3d-[0-9]*@@ -8314,8 +8493,8 @@ CONFLICTS= Xaw3d-[0-9]*
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. 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
+ 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.
+ 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.
IGNORE is deprecated +
IGNORE
is deprecated
because it didn't provide enough information to
determine whether the build should fail.
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
+ has been installed, the When a vulnerability is found, this should be noted
- in localsrc/security/advisories/pkg-vulnerabilities,
+ in 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
localsrc/security/advisories/pkg-vulnerabilities
,
and after the commit of that file, it should be copied
- to both /pub/NetBSD/packages/distfiles/pkg-vulnerabilities
- and /pub/NetBSD/packages/distfiles/vulnerabilities
- on ftp.NetBSD.org using localsrc/security/advisories/Makefile.
- In addition, if a buildlink3.mk file exists for an
- affected package, bumping PKGREVISION and creating a corresponding
- BUILDLINK_RECOMMENDED.pkg entry should be
- considered. See /pub/NetBSD/packages/distfiles/pkg-vulnerabilities
+ and /pub/NetBSD/packages/distfiles/vulnerabilities
+ on ftp.NetBSD.org using localsrc/security/advisories/Makefile
.
+ In addition, if a buildlink3.mk
file exists for an
+ affected package, bumping PKGREVISION
and creating a
+ corresponding BUILDLINK_RECOMMENDED.
entry should
+ be considered. See Chapter 9,
Buildlink methodology for more information
- about writing buildlink3.mk
- files and BUILDLINK_*
- definitions.pkg
buildlink3.mk
files and BUILDLINK_*
definitions.
Also, if the fix should be applied to the stable pkgsrc branch, be sure to submit a pullup request!
@@ -8408,8 +8589,8 @@ CONFLICTS= Xaw3d-[0-9]*Typically a workaround involves testing the
- MACHINE_ARCH and compiler
+ MACHINE_ARCH
and compiler
version, disabling optimisation for that
- file/MACHINE_ARCH/compiler
- combination, and documenting it in pkgsrc/doc/HACKS. See that file for a
+ file/MACHINE_ARCH
/compiler
+ combination, and documenting it in pkgsrc/doc/HACKS
. See that file for a
number of examples!
When making fixes to an existing package it can be
- useful to change the version number in PKGNAME. To avoid conflicting with
+ 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 pkg tools. e.g.
DISTNAME= foo-17.42 PKGREVISION= 9-
will result in a PKGNAME of
- “will result in a PKGNAME
of “foo-17.42nb9”.
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@@ -8475,8 +8656,8 @@ DISTNAME= foo-17.43
The BSD-compatible install supplied with some +
The BSD-compatible install supplied with some operating systems will not perform more than one operation at a time. As such, you should call “${INSTALL}”, @@ -8518,7 +8699,7 @@ ${INSTALL_DATA_DIR} ${PREFIX}/dir2
@@ -8528,8 +8709,8 @@ ${INSTALL_DATA_DIR} ${PREFIX}/dir2If 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. 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
- macro which displays a message explaining the
- situation. _FETCH_MESSAGE must
- be executable shell commands, not just a message.
- (Generally, it executes ${ECHO}). As of this writing, the
+ can set _FETCH_MESSAGE
to
+ a macro which displays a message explaining the
+ situation. _FETCH_MESSAGE
+ must be executable shell commands, not just a message.
+ (Generally, it executes ${ECHO}
). As of this writing, the
following packages use this: audio/realplayer, cad/simian, devel/ipv6socket, emulators/vmware-module,
- fonts/acroread-jpnfont, sysutils/storage-manager,
- www/ap-aolserver, www/openacs. Try to be
- consistent with them.
/pub/NetBSD/packages/distfiles
directory. Furthermore, a mail to the package's author
seems appropriate making sure the distfile was really
updated on purpose, and that no trojan horse or so
@@ -8621,8 +8801,8 @@ ${INSTALL_DATA_DIR} ${PREFIX}/dir2
@@ -8649,11 +8829,11 @@ ${INSTALL_DATA_DIR} ${PREFIX}/dir2
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.
+ class="pkgname">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:
@@ -8661,8 +8841,9 @@ ${INSTALL_DATA_DIR} ${PREFIX}/dir2Add USE_LIBTOOL=yes - to the package Makefile.
+Add USE_LIBTOOL=yes
to the package
+ Makefile.
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.
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 “.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
@@ -8743,27 +8924,30 @@ dynamic linker chooses the library with the greater REVISION number.
argument” is the install directory
of the library being built.
In the PLIST, - include all of the .a, - .la, and .so, .so.major and - .so.major.minor files.
+In the PLIST
,
+ include all of the .a
, .la
, and .so
, .so.
and
+ major
.so.
+ files.major
.minor
When linking shared object (.so) files, i.e. files that are +
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.
The PLIST file gets - the foo.so entry.
+The PLIST
file
+ gets the foo.so
+ entry.
.la
file. e.g.
${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} -osomeprog
../somelib/somelib.la
and it will do the right thing with the @@ -8813,14 +8997,14 @@ ${LIBTOOL} --mode=link ${CC} -o cp(1) command with “${LIBTOOL} --mode=install”, and change the - library name to .la. - e.g.
+ library name to.la
. e.g.
${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib-
This will install the static .a, shared library, any needed +
This will install the static In your PLIST,
- include all of the .a,
- .la, and .so, .so.CURRENT and .so.CURRENT.REVISION files (this
- is a change from the previous behaviour). In your .a
, shared library, any needed
symlinks, and run
PLIST
,
+ include all of the .a
, .la
, and .so
, .so.CURRENT
and .so.CURRENT.REVISION
files
+ (this is a change from the previous
+ behaviour).
Add USE_LIBTOOL=yes to the - package Makefile. This will override the package's own - libtool in most cases. For older libtool using +
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.
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.
- -If you do not need *.a + 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.
If you do not need *.a
static libraries built and installed, then use
- SHLIBTOOL_OVERRIDE
+ 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 - the libtool buildlink3.mk (and set USE_BUILDLINK3=YES).
+ the libtool buildlink3.mk (and setUSE_BUILDLINK3=YES
).
Some packages use libtool incorrectly so that the package may not work or build in some circumstances. @@ -8894,8 +9081,9 @@ ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
The shared object is named correctly, - i.e. libfoo.la, - not foo.la
+ i.e.libfoo.la
, not
+ foo.la
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
+ LTDL_SET_PRELOADED_SYMBOLS
included in executables.
pkgsrc/mk/autoconf.mk
and
+ pkgsrc/mk/automake.mk
to
+ help dealing with these tools. See comments in these
+ files for details.
For packages that need only autoconf:
@@ -8970,16 +9158,16 @@ pre-configure:Packages which use GNU Automake will almost certainly require GNU Make, but that's automatically - provided for you in mk/automake.mk.
+ provided for you inmk/automake.mk
.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 + problems with your package you can set
AUTOMAKE_OVERRIDE=NO
in the package Makefile.
To test whether you are working on a 4.4 BSD-derived
system, you should use the BSD definition, which is
- defined in <sys/param.h> on said
+ defined in <sys/param.h>
on said
systems.
#include <sys/param.h> @@ -9039,7 +9227,7 @@ pre-configure: @@ -9049,78 +9237,81 @@ pre-configure:Packages should be taught to look for their - configuration files in ${PKG_SYSCONFDIR}, which is passed + configuration files in
${PKG_SYSCONFDIR}
, which is passed through to the configure and build processes. - PKG_SYSCONFDIR may be +PKG_SYSCONFDIR
may be customized in various ways by setting other make variables:
- -
PKG_SYSCONFBASE is - the main config directory under which all package - configuration files are to be found. This - defaults to ${PREFIX}/etc, but may be - overridden in /etc/mk.conf.
+
PKG_SYSCONFBASE
+ is the main config directory under which all + package configuration files are to be found. This + defaults to${PREFIX}/etc
, but may be + overridden in/etc/mk.conf
.- -
PKG_SYSCONFSUBDIR is - the subdirectory of PKG_SYSCONFBASE under which the +
+ all be found under the
PKG_SYSCONFSUBDIR
+ is the subdirectory ofPKG_SYSCONFBASE
under which the configuration files for a particular package may be found, e.g. the Apache configuration files may - all be found under the httpd/ subdirectory of ${PKG_SYSCONFBASE}. This should be - set in the package Makefile.httpd/
subdirectory of +${PKG_SYSCONFBASE}
. + This should be set in the package Makefile.- -
By default, PKG_SYSCONFDIR is set to - ${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}, - but this may be overridden by setting PKG_SYSCONFDIR.${PKG_SYSCONFVAR} - for a particular package, where PKG_SYSCONFVAR defaults to - ${PKGBASE}. This is not - meant to be set by a package Makefile, but is +
By default,
PKG_SYSCONFDIR
is set to +${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}
, + but this may be overridden by setting +PKG_SYSCONFDIR.${PKG_SYSCONFVAR}
+ for a particular package, wherePKG_SYSCONFVAR
defaults to +${PKGBASE}
. This is + not meant to be set by a package Makefile, but is reserved for users who wish to override the - PKG_SYSCONFDIR setting - for a particular package with a special +PKG_SYSCONFDIR
+ setting for a particular package with a special location.The only variables that users should customize are - PKG_SYSCONFBASE and PKG_SYSCONFDIR.${PKG_SYSCONFVAR}. Users - will typically want to set PKG_SYSCONFBASE to /etc, or to accept the default location - of ${PREFIX}/etc.
+PKG_SYSCONFBASE
and +PKG_SYSCONFDIR.${PKG_SYSCONFVAR}
. + Users will typically want to setPKG_SYSCONFBASE
to/etc
, or to accept the default + location of${PREFIX}/etc
.
The INTERACTIVE_STAGE +
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.
Makefile
. e.g.
INTERACTIVE_STAGE= build@@ -9169,8 +9360,8 @@ INTERACTIVE_STAGE= configure install
Placing a certain package under a certain license - works by setting the LICENSE - variable to a string identifying the license, e.g. in - LICENSE variable to a string + identifying the license, e.g. in graphics/graphviz:
+ class="pkgname">graphics/graphviz:LICENSE= graphviz-license@@ -9204,7 +9395,8 @@ LICENSE= graphviz-license that the package underlies a license which he hasn't accepted (yet):
-% make +-%
make
===> graphviz-1.12 has an unacceptable license: graphviz-license. ===> To build this package, add this line to your /etc/mk.conf: ===> ACCEPTABLE_LICENSES+=graphviz-license @@ -9212,39 +9404,39 @@ LICENSE= graphviz-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:
+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+=graphviz-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.
+ license text should be added topkgsrc/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
.
Is there is a really pressing need to accept all licenses at once, like when trying to download or mirror all distfiles or doing a bulk build to test if all packages in pkgsrc build, this can be - done by setting _ACCEPTABLE=yes.
+ done by setting_ACCEPTABLE=yes
.
There are two make variables used to control the
creation of package-specific groups and users at
- pre-install time. The first is PKG_GROUPS, which is a list of
+ pre-install time. The first is PKG_GROUPS
, which is a list of
group[:groupid] elements, where the groupid is
- optional. The second is PKG_USERS, which is a list of elements
+ optional. The second is PKG_USERS
, which is a list of elements
of the form:
user:group[:[userid][:[description][:[home][:shell]]]] @@ -9278,27 +9470,28 @@ user:group[:[userid][:[description][:[home][:shell]]]]
By default, a new user will have home directory - /nonexistent, and login shell - /sbin/nologin unless they are - specified as part of the user element.
- -The package Makefile must - also set USE_PKGINSTALL=YES. - This will cause the users and groups to be created at - pre-install time, and the admin will be prompted to - remove them at post-deinstall time. Automatic creation - of the users and groups can be toggled on and off by - setting the PKG_CREATE_USERGROUP variable prior to - package installation.
+/nonexistent
, and login
+ shell /sbin/nologin
+ unless they are specified as part of the user
+ element.
+
+ The package Makefile
+ must also set USE_PKGINSTALL=YES
. This will cause
+ the users and groups to be created at pre-install time,
+ and the admin will be prompted to remove them at
+ post-deinstall time. Automatic creation of the users
+ and groups can be toggled on and off by setting the
+ PKG_CREATE_USERGROUP
+ variable prior to package installation.
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
+ is 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.
+ ownership or access permissions but rely on +INSTALL_GAME
and
+ INSTALL_GAME_DATA
to set
+ these correctly.
If the purpose of the package is to provide a login - shell, the variable PKG_SHELL - should contain the full pathname of the shell - executable installed by this package. The package - Makefile must also set - USE_PKGINSTALL=YES to use the - automatically generated INSTALL/DEINSTALL scripts.
+ shell, the variablePKG_SHELL
should contain the full
+ pathname of the shell executable installed by this
+ package. The package Makefile
must also set USE_PKGINSTALL=YES
to use the
+ automatically generated INSTALL
/DEINSTALL
scripts.
An example taken from shells/zsh:
@@ -9357,39 +9552,39 @@ user:group[:[userid][:[description][:[home][:shell]]]] PKG_SHELL= ${PREFIX}/bin/zsh-
The shell is registered into /etc/shells file automatically in the - post-install target by the generated INSTALL script and removed in the - deinstall target by the DEINSTALL script.
+The shell is registered into /etc/shells
file automatically in the
+ post-install target by the generated INSTALL
script and removed in the
+ deinstall target by the DEINSTALL
script.
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.
+ setREPLACE_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.
Makefile
(we
+ shall use tclsh in this example):
REPLACE_INTERPRETER+= tcl _REPLACE.tcl.old= .*/bin/tclsh @@ -9415,43 +9610,43 @@ user:group[:[userid][:[description][:[home][:shell]]]]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.
+ 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.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.:
+ thePLIST
corresponding + to the files listed in the installed.packlist
file generated by most + perl5 modules. This is invoked by definingPERL5_PACKLIST
to a space-separated + list of paths to packlist files, e.g.:PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist-The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB represent the three +
The variables
+ for in thePERL5_SITELIB
,PERL5_SITEARCH
, andPERL5_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.PLIST
.
is considered to be installed in the directory - ${PREFIX}/${INFO_DIR},
+${PREFIX}/${INFO_DIR}
,
is registered in the Info directory file - ${PREFIX}/${INFO_DIR}/dir,
+${PREFIX}/${INFO_DIR}/dir
,
and must be listed as a filename in the - INFO_FILES variable in - the package Makefile.
+INFO_FILES
variable
+ in the package Makefile.
INFO_DIR defaults to +
INFO_DIR
defaults to
“info” and can
- be overridden in the package Makefile. INSTALL and DEINSTALL scripts will be generated to
- handle registration of the info files in the Info
+ be overridden in the package Makefile. 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
@@ -9506,72 +9701,75 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
A package which needs the “makeinfo” command at build time
- must define the variable USE_MAKEINFO in its Makefile. If a
+ must define the variable USE_MAKEINFO
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
+ 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
- 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.
+ 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.
- -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 USE_MAKEINFO and TEXINFO_REQD either run the appropriate - makeinfo command or - exit on error.
+ creates overriding scripts for the install-info and + makeinfo + commands in a directory listed early inPATH
.
+
+ 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
+ USE_MAKEINFO
and
+ TEXINFO_REQD
either run
+ the appropriate makeinfo command or exit on
+ error.
If a package installs .schemas or .entries files, used by GConf2, you +
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:
Include ../../devel/GConf2/schemas.mk - instead of its buildlink3.mk file. This takes +
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
@@ -9582,11 +9780,11 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
Ensure that the package installs its
- .schemas files under
- ${PREFIX}/share/gconf/schemas. If
- they get installed under ${PREFIX}/etc, you will need to
+ .schemas
files
+ under ${PREFIX}/share/gconf/schemas
.
+ If they get installed under ${PREFIX}/etc
, you will need to
manually patch the package.
Check the PLIST and remove any entries under the etc/gconf directory, as they will be handled automatically. See - Section 6.13, “Configuration files + "6.14. Configuration files handling and placement"> + Section 6.14, “Configuration files handling and placement” for more information.
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.
+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.
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.
+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.
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:
+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:
Include ../../textproc/scrollkeeper/omf.mk - instead of its buildlink3.mk file. This takes +
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
@@ -9652,15 +9852,15 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
Check the PLIST and remove any entries under
- the libdata/scrollkeeper directory,
+ the libdata/scrollkeeper
directory,
as they will be handled automatically.
Remove the share/omf - directory from the PLIST. It will be handled by - scrollkeeper.
+Remove the share/omf
directory from the
+ PLIST. It will be handled by scrollkeeper.
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 mk/fonts.mk, which you need to include - in your Makefile.
+ This can be automatically done by usingmk/fonts.mk
, which you need to
+ include in your Makefile
.
When the file is included, you can list the
- directories where fonts are installed in the FONTS_type_DIRS variables,
- where type can be
- one of “TTF”,
+ directories where fonts are installed in the
+ FONTS_
+ variables, where type
_DIRStype
can be one of
+ “TTF”,
“TYPE1” or
“X11”. Also make
- sure that the database file fonts.dir is not listed in the
+ sure that the database file fonts.dir
is not listed in the
PLIST.
Note that you should not create new directories for @@ -9706,8 +9908,8 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
Include ../../x11/gtk2/modules.mk instead - of its buildlink3.mk - file. This takes care of rebuilding the database - at installation and deinstallation time.
+Include ../../x11/gtk2/modules.mk
+ instead of its buildlink3.mk
file. This takes
+ care of rebuilding the database at installation
+ and deinstallation time.
Set GTK2_IMMODULES=YES if your package - installs GTK2 immodules.
+Set GTK2_IMMODULES=YES
if your
+ package installs GTK2 immodules.
Set GTK2_LOADERS=YES - if your package installs GTK2 loaders.
+Set GTK2_LOADERS=YES
if your package
+ installs GTK2 loaders.
libdata/gtk-2.0/gdk-pixbuf.loaders
+libdata/gtk-2.0/gdk-pixbuf.loaders
libdata/gtk-2.0/gtk.immodules
+libdata/gtk-2.0/gtk.immodules
Check the PLIST and remove any entries under
- the libdata/gtk-2.0
+ the libdata/gtk-2.0
directory, as they will be handled
automatically.
Include ../../textproc/xmlcatmgr/catalogs.mk - in your Makefile, which - takes care of registering those files in +
Include ../../textproc/xmlcatmgr/catalogs.mk
+ in your Makefile
,
+ which takes care of registering those files in
system-wide catalogs at installation and
deinstallation time.
Set SGML_CATALOGS to - the full path of any SGML catalogs installed by - the package.
+Set SGML_CATALOGS
+ to the full path of any SGML catalogs installed
+ by the package.
Set XML_CATALOGS to - the full path of any XML catalogs installed by +
Set XML_CATALOGS
+ to the full path of any XML catalogs installed by
the package.
Set SGML_ENTRIES to - individual entries to be added to the SGML +
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'
@@ -9817,8 +10021,8 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
Set XML_ENTRIES to - individual entries to be added to the XML +
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'
@@ -9833,42 +10037,44 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
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:
+ 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:
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 +
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.
Check the PLIST and remove any entries under
- the share/mime
+ the share/mime
directory, except for files saved
- under share/mime/packages. The former
+ under share/mime/packages
. The former
are handled automatically by the
update-mime-database program, but the later are
package-dependent and must be removed by the
@@ -9877,9 +10083,9 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
Remove any share/mime/* directories from the - PLIST. They will be handled by the +
Remove any share/mime/*
directories from
+ the PLIST. They will be handled by the
shared-mime-info package.
If a package uses intltool during its build, include
- the ../../textproc/intltool/buildlink3.mk
+ 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.
Be sure to set PKG_DEVELOPER=1 in /etc/mk.conf
+Be sure to set PKG_DEVELOPER=1
in /etc/mk.conf
Install pkgtools/url2pkg, create a - directory for a new package, change into it, then - run url2pkg:
+ class="pkgname">pkgtools/url2pkg, create a + directory for a new package, change into it, then run + url2pkg:-% mkdir /usr/pkgsrc/category/examplepkg -% cd /usr/pkgsrc/category/examplepkg -% url2pkg http://www.example.com/path/to/distfile.tar.gz +%
mkdir /usr/pkgsrc/
+category
/examplepkg
%
cd /usr/pkgsrc/
+category
/examplepkg
%
url2pkg http://www.example.com/path/to/distfile.tar.gz
Edit the Makefile as +
Edit the Makefile
as
requested.
Fill in the DESCR +
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.
+ and the configure step to the package'sMakefile
.
Make the package compile, doing multiple rounds of
-% make -% pkgvi ${WRKSRC}/some/file/that/does/not/compile -% mkpatches -% patchdiff -% mv ${WRKDIR}/.newpatches/* patches -% make mps -% make clean +%
make
+%
pkgvi ${WRKSRC}/some/file/that/does/not/compile
+%
mkpatches
+%
patchdiff
+%
mv ${WRKDIR}/.newpatches/* patches
+%
make mps
+%
make clean
Doing as non-root user will ensure that no files are modified that shouldn't be, especially during the - build phase. mkpatches, patchdiff and pkgvi are from the mkpatches, + patchdiff and + pkgvi + are from the pkgtools/pkgdiff package.
+ class="pkgname">pkgtools/pkgdiff package.Look at the Makefile, - fix if necessary; see Section 7.1, - “Makefile”.
+Look at the Makefile
, fix if necessary; see
+ Section 7.1,
+ “Makefile
”.
Generate a PLIST:
+Generate a PLIST
:
-# make install -# make print-PLIST >PLIST -# make deinstall -# make install -# make deinstall -- -
You usually need to be root to do this. Look if there are
+#
make install
+#
make print-PLIST >PLIST
+#
make deinstall
+#
make install
+#
make deinstall
+
+
+
You usually need to be root
to do this. Look if there are
any files left:
-# make print-PLIST +#
make print-PLIST
If this reveals any files that are missing in - PLIST, add them.
+PLIST
, add them.
Now that the PLIST is - OK, install the package again and make a binary +
Now that the PLIST
+ is OK, install the package again and make a binary
package:
-# make reinstall -# make package +#
make reinstall
+#
make package
Delete the installed package:
-# pkg_delete blub +#
pkg_delete blub
Repeat the above make - print-PLIST command, which shouldn't find - anything now:
+Repeat the above make print-PLIST command, + which shouldn't find anything now:
-# make print-PLIST +#
make print-PLIST
Reinstall the binary package:
-# pkgadd .../blub.tgz +#
pkgadd .../blub.tgz
Run pkglint - from Run pkglint from pkgtools/pkglint, and fix the - problems it reports:
+ class="pkgname">pkgtools/pkglint, and fix the + problems it reports:-# pkglint +#
pkglint
Table of Contents
% cd .../pkgsrc/category/pkgname % cvs import pkgsrc/category/pkgname TNF pkgsrc-base @@ -10259,18 +10472,19 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist 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 category'sMakefile
.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.
+ include part of theDESCR
+ file, so people reading the mailing lists know what the + package is/does.Please note all package updates/additions 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 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, in @@ -10288,7 +10502,7 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
@@ -10339,7 +10553,7 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist @@ -10357,34 +10571,35 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlistAlternatively to the first two steps you can also do:
-% cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package +%
cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
and use that for further work.
Fix CATEGORIES and any
- DEPENDS paths that just
- did “Fix CATEGORIES
and
+ any DEPENDS
paths that
+ just did “../package” instead of
“../../category/package”.
cvs import - the modified package in the new place.
+cvs + import the modified package in the + new place.
Check if any package depends on it:
-% cd /usr/pkgsrc -% grep /package */*/Makefile* */*/buildlink* +%
cd /usr/pkgsrc
+%
grep /package */*/Makefile* */*/buildlink*
cvs rm (-f) - the package at the old location.
+cvs rm + (-f) the package at the old + location.
Remove from oldcategory/Makefile.
+Remove from oldcategory/Makefile
.
Add to newcategory/Makefile.
+Add to newcategory/Makefile
.
Commit the changed and removed files:
-% cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile +%
cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
(and any packages from step 5, of course).
@@ -10438,43 +10654,45 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlistTable of Contents
We checked to find a piece of software that wasn't in the packages collection, and picked GNU bison. Quite why someone - would want to have bison - when Berkeley yacc is - already present in the tree is beyond us, but it's useful for - the purposes of this exercise.
+ would want to have bison when Berkeley + yacc is already + present in the tree is beyond us, but it's useful for the + purposes of this exercise.The NetBSD package system comes with pkgtools/pkglint which helps to - check the contents of these files. After installation - it is quite easy to use, just change to the directory - of the package you wish to examine and execute - pkglint:
+ class="pkgname">pkgtools/pkglint which helps to check + the contents of these files. After installation it is + quite easy to use, just change to the directory of the + package you wish to examine and execute + pkglint:-$ pkglint +$
pkglint
OK: checking ./DESCR. OK: checking Makefile. OK: checking distinfo. @@ -10572,8 +10793,8 @@ looks fine.Depending on the supplied command line arguments (see pkglint(1)) more verbose checks will be performed. Use - e.g. pkglint -v for a - very verbose check.
+ e.g. pkglint + -v for a very verbose check.
Create the directory where the package lives, plus any auxiliary directories:
-# cd /usr/pkgsrc/lang -# mkdir bison -# cd bison -# mkdir patches -- -
Create Makefile, DESCR and PLIST
- (see # Create Generate the checksum of the distfile into distinfo: Generate the checksum of the distfile into Now compile: Everything seems OK, so install the files: You can now use bison, and also - if you decide so -
- remove it with pkg_delete
- bison. Should you decide that you want a binary
- package, do this now:cd /usr/pkgsrc/lang
+#
mkdir bison
+#
cd bison
+#
mkdir patches
+
+
+ Makefile
,
+ DESCR
and PLIST
(see
Chapter 7, Package components - files, directories and
contents) then continue with fetching the
distfile:
-# make fetch
+
- #
make fetch
>> bison-1.25.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
@@ -10625,16 +10846,17 @@ Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via f
Successfully retrieved file.
distinfo
:
-# make makesum
+
#
make makesum
-# make
+
#
make
>> Checksum OK for bison-1.25.tar.gz.
===> Extracting for bison-1.25
===> Patching for bison-1.25
@@ -10689,8 +10911,8 @@ sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s
-# make install
+
#
make install
>> Checksum OK for bison-1.25.tar.gz.
===> Installing for bison-1.25
sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
@@ -10706,12 +10928,12 @@ cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr
-# make package +#
make package
>> Checksum OK for bison-1.25.tar.gz. ===> Building package for bison-1.25 Creating package bison-1.25.tgz @@ -10722,8 +10944,8 @@ Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'Now that you don't need the source and object files any more, clean up:
-# make clean +#
make clean
===> Cleaning for bison-1.25
-# make +#
make
===> Checking for vulnerabilities in figlet-2.2.1nb2 => figlet221.tar.gz doesn't seem to exist on this system. => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/. @@ -10833,9 +11056,9 @@ gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\" -DDEFAULTFONTFILE=\"standard chmod a+x figlet gcc -O2 -o chkfont chkfont.c => Unwrapping files-to-be-installed. -# -# make install +#
+#
make install
===> Checking for vulnerabilities in figlet-2.2.1nb2 ===> Installing for figlet-2.2.1nb2 install -d -o root -g wheel -m 755 /usr/pkg/bin @@ -10850,7 +11073,7 @@ cp fonts/*.flf /usr/pkg/share/figlet cp fonts/*.flc /usr/pkg/share/figlet cp figlet.6 /usr/pkg/man/man6 ===> Registering installation for figlet-2.2.1nb2 -# +#
-# make package +#
make package
===> Checking for vulnerabilities in figlet-2.2.1nb2 ===> Packaging figlet-2.2.1nb2 ===> Building binary package for figlet-2.2.1nb2 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz Using SrcDir value of /usr/pkg Registering depends:. -# +#
If necessary, create a symlink ln -s `uname -m` `uname -p` (amiga - -> m68k, ...)
+If necessary, create a symlink ln -s `uname -m` `uname -p` + (amiga -> m68k, ...)
Table of Contents
The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several files +
The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files
, and several files
are created from it:
pkgsrc/doc/pkgsrc.txt, - which replaces pkgsrc/Packages.txt
+pkgsrc/doc/pkgsrc.txt
, which
+ replaces pkgsrc/Packages.txt
pkgsrc/doc/pkgsrc.html
+pkgsrc/doc/pkgsrc.html
http://www.NetBSD.org/Documentation/pkgsrc/: +
http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.pdf:
+ http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.ps:
+ http://www.NetBSD.org/Documentation/pkgsrc/
:
the documentation on the NetBSD website will be built
from pkgsrc and kept up to date on the web server
itself. This means you
http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.pdf
:
PDF version of the pkgsrc guide.http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.ps
:
PostScript version of the pkgsrc guide.
pkgsrc/meta-pkgs/netbsd-doc
and
+ pkgsrc/meta-pkgs/netbsd-doc-print
.
Edit the XML file(s) in pkgsrc/doc/guide/files.
+Edit the XML file(s) in pkgsrc/doc/guide/files
.
Run make extract - && make do-lint in pkgsrc/doc/guide to check the XML - syntax, and fix it if needed.
+Run make extract
+ && make do-lint in
+ pkgsrc/doc/guide
to
+ check the XML syntax, and fix it if needed.
Run make in - pkgsrc/doc/guide to build - the HTML and ASCII version.
+Run make in pkgsrc/doc/guide
to build the HTML
+ and ASCII version.
If all is well, run make - install-doc to put the generated files - into pkgsrc/doc.
+If all is well, run make install-doc to put the
+ generated files into pkgsrc/doc
.
cvs commit - pkgsrc/doc/guide/files
+cvs commit + pkgsrc/doc/guide/files
cvs commit -m re-generate - pkgsrc/doc/pkgsrc.{html,txt}
+cvs commit -m + re-generate + pkgsrc/doc/pkgsrc.{html,txt}
Until the webserver on www.NetBSD.org is really updated automatically to pick up changes to the - pkgsrc guide automatically, also run make install-htdoc - HTDOCSDIR=../../../htdocs (or similar, - adjust HTDOCSDIR!).
+ pkgsrc guide automatically, also run + make install-htdoc + HTDOCSDIR=../../../htdocs (or + similar, adjustHTDOCSDIR
!).
cvs commit - htdocs/Documentation/pkgsrc
+cvs commit + htdocs/Documentation/pkgsrc