Chapter 6. Frequently Asked Questions

Table of Contents

6.1. Is there a mailing list for pkg-related discussion?
6.2. Where's the pkgviews documentation?
6.3. Utilities for package management (pkgtools)
6.4. How to use pkgsrc as non-root
6.5. How can I install/use XFree86 from pkgsrc?
6.6. How can I install/use X.org from pkgsrc?
6.7. How to fetch files from behind a firewall
6.8. How do I tell make fetch to do passive FTP?
6.9. How to fetch all distfiles at once
6.10. What does “Don't know how to make /usr/share/tmac/tmac.andoc” mean?
6.11. What does “Could not find bsd.own.mk” mean?
6.12. Using 'sudo' with pkgsrc
6.13. Configuration files handling and placement
6.14. Automated security checks

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.

6.1. Is there a mailing list for pkg-related discussion?

Yes, 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/.

6.2. Where's the pkgviews documentation?

Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.

6.3. Utilities for package management (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 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):

OS tool augmentation (automatically installed when needed):

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:

Utilities for people maintaining pkgsrc (or more obscure pkg utilities)

6.4. How to use pkgsrc as non-root

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.

6.5. How can I install/use XFree86 from pkgsrc?

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
    

6.6. How can I install/use X.org from pkgsrc?

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
    

6.7. How to fetch files from behind a firewall

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/

6.8. How do I tell make fetch to do passive FTP?

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.

6.9. How to fetch all distfiles at once

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

6.10. 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.

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.

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

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).

6.12. Using 'sudo' with pkgsrc

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
    

6.13. Configuration files handling and placement

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:

  1. 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.

  2. PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which the configuration files for a particular package may be found. Defaults to ${SYSCONFBASE}.

  3. 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.

  4. 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.

6.14. Automated security checks

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:

  1. 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

  2. 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

===========================================================================