Table of Contents
This section contains hints, tips & tricks on special things in pkgsrc that we didn't find a better place for in the previous chapters, and it contains items for both pkgsrc users and developers.
Yes, <tech-pkg@NetBSD.org>
is the list for discussing package related issues. To
subscribe do:
%
echo subscribe tech-pkg | mail majordomo@NetBSD.org
An archive of the list is available at http://mail-index.NetBSD.org/tech-pkg/.
Pkgviews is tightly integrated with buildlink. You can
find a pkgviews User's guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG
.
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 and when they
might be useful, and not to duplicate the documentation that
comes with each package.
Utilities used by pkgsrc (automatically installed when needed):
pkgtools/x11-links: symlinks for use by buildlink
OS tool augmentation (automatically installed when needed):
pkgtools/digest: calculates SHA1 checksums (and other kinds)
pkgtools/libnbcompat: compat library for pkg tools
pkgtools/mtree: installed on non-BSD systems due to lack of native mtree
pkgtools/pkg_install: up-to-date replacement for /usr/sbin/pkg_install, or for use on operating systems where pkg_install is not present
Utilities used by pkgsrc (not automatically installed):
pkgtools/pkg_tarup: create a binary package from an already-installed package. used by 'make replace' to save the old package
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)
devel/cpuflags: will determine the best compiler flags to optimise code for your current CPU and compiler.
Utilities for keeping track of installed packages, being up to date, etc:
pkgtools/pkg_chk: installs pkg_chk, which reports on packages whose installed versions do not match the latest pkgsrc entries
pkgtools/pkgdep: makes dependency graphs of packages, to aid in choosing a strategy for updating
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)
pkgtools/pkgsurvey: report what packages you have installed
Utilities for people maintaining or creating individual packages:
pkgtools/pkgdiff: automate making and maintaining patches for a package (includes pkgdiff, pkgvi, mkpatches, ...)
pkgtools/rpm2pkg, pkgtools/url2pkg: aids in converting to pkgsrc
pkgtools/gensolpkg: convert pkgsrc to a Solaris package
Utilities for people maintaining pkgsrc (or more obscure pkg utilities)
pkgtools/pkgconflict: find packages that conflict but aren't marked as such
pkgtools/pkg_comp: build packages in a chrooted area
pkgtools/libkver: spoof kernel version for chrooted cross builds
If you want to use pkgsrc as non-root user, you can set some variables to make pkgsrc work under these conditions. Please see this message for more details.
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
:
X11_TYPE=XFree86
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
:
X11_TYPE=xorg
If you are sitting behind a firewall which does not allow direct connections to Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This is done using an environment variable in the form of a URL e.g. in Amdahl, the machine “orpheus.amdahl.com” is one of the firewalls, and it uses port 80 as the proxy port number. So the proxy environment variables are:
ftp_proxy=ftp://orpheus.amdahl.com:80/ 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:
${LOCALBASE}/bin/ftp /usr/bin/ftp
On a default NetBSD installation, this will be
/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
.
Having that option present will prevent /usr/bin/ftp
from falling back to active
transfers.
You 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 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 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 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
At work:
%
sh /tmp/fetch.sh
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 mirror-distfiles
If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}
, then you can
get everything by running:
%
make fetch NO_SKIP=yes
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.
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
.
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
comp.tgz
is part of every
NetBSD release. Get the one that corresponds to your release
(determine via uname
-r).
When installing packages as non-root user and using the
just-in-time su(1) feature of pkgsrc, it can become annoying
to type in the root password for each required package
installed. To avoid this, the sudo package can be used, which
does password caching over a limited time. To use it, install
sudo (either as binary package or from 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 .endif
The global variable PKG_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.
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 customized
in various ways:
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
.
PKG_SYSCONFSUBDIR
is
the subdirectory of PKG_SYSCONFBASE
under which the
configuration files for a particular package may be
found. Defaults to ${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_SYSCONFDIR.${PKG_SYSCONFVAR}
overrides the value of ${PKG_SYSCONFDIR}
for packages with
the same value for PKG_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 install KDE config files.
Programs' configuration directory should be defined during
the configure stage. Packages that use GNU autoconf can
usually do this by using the “--sysconfdir” parameter, but this brings
some problems as we will see 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.
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
element of the pair specifies the file inside the examples
directory (registered by PLIST
)
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
automatically generated scripts. The automatic copying of
config files can be toggled by setting the environment
variable PKG_CONFIG
prior to
package installation.
Here is an example, taken from mail/mutt/Makefile:
EGDIR= ${PREFIX}/share/doc/mutt/samples CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
As 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.
Please be aware that there can often be bugs in third-party software, and some of these bugs can leave a machine vulnerable to exploitation by attackers. In an effort to lessen the exposure, the NetBSD packages team maintains a database of known-exploits to packages which have at one time been included in pkgsrc. The database can be downloaded automatically, and a security audit of all packages installed on a system can take place. To do this, install the security/audit-packages package. It has two components:
“download-vulnerability-list”, an easy way to download a list of the security vulnerabilities information. This list is kept up to date by the NetBSD security officer and the NetBSD packages team, and is distributed from the NetBSD ftp server:
ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities
“audit-packages”, an easy way to audit the current machine, checking each vulnerability which is known. If a vulnerable package is installed, it will be shown by output to stdout, including a description of the type of vulnerability, and a URL containing more information.
Use of the audit-packages package is strongly recommended!
The following message is displayed as part of the audit-packages installation procedure:
=========================================================================== $NetBSD: faq.xml,v 1.1.1.1 2004/10/21 14:27:43 grant Exp $ You may wish to have the vulnerabilities file downloaded daily so that it remains current. This may be done by adding an appropriate entry to the root users crontab(5) entry. For example the entry # download vulnerabilities file 0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1 will update the vulnerability list every day at 3AM. You may wish to do this more often than once a day. In addition, you may wish to run the package audit from the daily security script. This may be accomplished by adding the following lines to /etc/security.local if [ -x ${PREFIX}/sbin/audit-packages ]; then ${PREFIX}/sbin/audit-packages fi ===========================================================================