the example mk.conf for bulk builds, since these are now set by the
bulk build machinery itself. This allows an /etc/mk.conf file to be
shared between ordinary builds and bulk builds.
definition.
INTERACTIVE_STAGE can take any of the values: fetch, configure, build and
install
Multiple values are allowed: e.g. INTERACTIVE_STAGE= configure install
Explain INTERACTIVE_STAGE and its use in documentation.
Patches provided by Chris Pinnock (cjep@netbsd.org).
(1) Admins want to create users/groups on their own (pkg/17183).
(2) Admins don't want packages to setup an initial configuration.
The bsd.pkg.install.mk-generated INSTALL/DEINSTALL scripts have been
modified to check certain PKG_* environment variables to tune their
behaviour. This works whether installing from "make install" or from a
binary package.
PKG_CREATE_USERGROUP indicates whether the INSTALL script should
automatically add any needed users/groups to the system using
useradd/groupadd. It is either YES or NO, and defaults to YES.
PKG_CONFIG indicates whether the INSTALL/DEINSTALL scripts should do
automatic config file and directory handling, or if it should
merely inform the admin of the list of required files and
directories needed to use the package. It is either YES or NO,
and defaults to YES.
The make(1) variable INSTALL_RCD_SCRIPTS is removed. The package rc.d
script is now handled like other config files for the package, and is
copied into place if PKG_CONFIG=YES.
The default values above reflect the current behaviour. Setting
PKG_CREATE_USERGROUP=NO solves problem (1), and setting PKG_CONFIG=NO
solves problem (2).
To simply matters for users installing directly from pkgsrc, these
variables may also be defined in /etc/mk.conf, but behaviour at deinstall
time may be surprising. It is *HIGHLY* recommended that these values be
set in the shell environment instead.
the system applies both ways, i.e., don't set LOCALBASE to where you have
your system files, *and vice versa*, as this repeatetly has lead to
problems (see PRs 15999 and 16029 for the latest examples).
Section 10, and also explain there about _FETCH_MESSAGE. There are a few
things in Section 10 which would probably be better in Section 2, but that
would entail some major churning, which I'm not prepared to do.
If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES
and a 'make fetch' will call files/getsite.sh with the name of each file
to download as an argument, expecting it to output the URL of the directory
from which to download it. graphics/ns-cult3d is an example of this usage.
autoreconf will call aclocal if necessary and as this is part of automake
so its wrong to describe it as the autoconf only option. Change autoreconf
to autoconf.
Also explictly mark the automake example as "automake and autoconf".
If set, the first component of the hostname (up to the first '.', if any),
will be appended to "work." to form the WRKDIR_BASENAME.
OBJHOSTNAME takes precedence over OBJMACHINE.
references of the pkglint package.
_PKGSRCDIR is an internal definition in bsd.pkg.mk, and a few packages
which would like to refer to other packages in the build tree. It should
not be set by users, but neither should it stop a user from building a
package if it is defined, so make it obvious that this is the case.
Syntax:
MASTER_SITES_completefilename= http://specific.master/site
and similarly for PATCH_SITES.
Convert print/ghostscript-nox11 and x11/kterm to take advantage of this.
pkgsrc. Instead, a new variable PKGREVISION is invented that can get
bumped independent of DISTNAME and PKGNAME.
Example #1:
DISTNAME= foo-X.Y
PKGREVISION= Z
=> PKGNAME= foo-X.YnbZ
Example #2:
DISTNAME= barthing-X.Y
PKGNAME= bar-X.Y
PKGREVISION= Z
=> PKGNAME= bar=X.YnbZ (!)
On subsequent changes, only PKGREVISION needs to be bumped, no more risk
of getting DISTNAME changed accidentally.
