Age | Commit message (Collapse) | Author | Files | Lines |
|
Again, anybody's feedback (success or failure) will be appreciated.
|
|
shells to /etc/shells.
This feature can be disabled by setting PKG_REGISTER_SHELLS to NO in
/etc/mk.conf.
An excerpt from Packages.txt, section 10.28:
10.28 Packages providing login shells
=====================================
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 also must include
"../../mk/bsd.pkg.install.mk" prior to the inclusion of bsd.pkg.mk to use the
automatically generated INSTALL/DEINSTALL scripts.
An example taken from shells/zsh:
PKG_SHELL= ${PREFIX}/bin/zsh
.include "../../mk/bsd.pkg.install.mk"
The shell is registered into /etc/shells file automatically in the
post-install target by the INSTALL script generated by bsd.pkg.install.mk and
removed in the deinstall target by the DEINSTALL script.
|
|
${RCD_SCRIPTS_DIR} as it's not used at all.
|
|
the package Makefile.
|
|
meant to be setuid-root, and should be used as follows:
SPECIAL_PERMS+= /path/to/suidroot ${SETUID_ROOT_PERMS}
|
|
make dependencies to ensure that the actual scripts are up-to-date if the
sources are changed.
|
|
dependencies to deal with changes in the source rc.d script file (this is
possible now that some variables have moved to bsd.prefs.mk from
bsd.pkg.mk).
|
|
|
|
|
|
SPECIAL_PERMS are lists that look like:
file user group mode
At post-install time, file (it may be a directory) is changed to be
owned by user:group with mode permissions.
SPECIAL_PERMS should be used primarily to change permissions of files or
directories listed in the PLIST. This may be used to make certain files
set-uid or to change the ownership or a directory.
Packages that install setuid executables should list them in SPECIAL_PERMS
so that the correct user and group will be used for file ownership, even
if the uid/gid changes between the package creation and the package
installation.
|
|
_PKG_DEBUG_SCRIPT when running the INSTALL/DEINSTALL scripts so that they
may be easier to debug.
|
|
do make it, make it with the same permissions as outlined in the *.pkg.dist
files.
|
|
${SH}. Enables rc.d script portability for non-NetBSD systems.
as discussed with jlam.
|
|
/etc/rc.d. This is controlled by the new variable PKG_RCD_SCRIPTS which
may be set in /etc/mk.conf or in the shell environment in which the
INSTALL script is executed. PKG_RCD_SCRIPTS only takes effect if
${PKG_CONFIG} == "YES" and defaults to NO.
|
|
RCD_SCRIPTS. From the comments in bsd.pkg.install.mk:
# rc.d scripts are automatically generated and installed into the rc.d
# scripts example directory at the post-install step. The following
# variables are relevent to this process:
#
# RCD_SCRIPTS lists the basenames of the rc.d scripts
#
# RCD_SCRIPT_SRC.<script> the source file for <script>; this will
# be run through FILES_SUBST to generate
# the rc.d script
#
# RCD_SCRIPTS_EXAMPLEDIR the directory in which to install the
# example rc.d scripts
#
# If the source rc.d script is not present, then the automatic handling
# doesn't occur.
|
|
exists, then use it as the default value of DEINSTALL_EXTRA_TMPL or
INSTALL_EXTRA_TMPL.
|
|
of the example rc.d scripts for a package. This defaults to
${PREFIX}/etc/rc.d, but may be reset for those odd packages, e.g. qmail,
that set LOCALBASE=/.
|
|
(1) do the work of not being so noisy for /etc and /etc/rc.d in the
scripts themselves, and
(2) make PKG_SYSCONFBASE and PKG_SYSCONFDIR usable from within
the INSTALL/DEINSTALL scripts by putting them in the header.
This preserves the ability for a single binary package to be used for both
PKG_CONFIG=yes or PKG_CONFIG=no.
|
|
|
|
Prevents warning on deinstall "remove /etc/rc.d" if no rc.d scripts
are provided for the package and PKG_CONFIG=no.
|
|
defaults for the INSTALL/DEINSTALL scripts. The environment variables of
the same name take precedence during installation of a binary package.
|
|
(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.
|
|
|
|
|
|
|
|
relevant code in this file.
|
|
|
|
expect it to contain the list of example rc.d scripts.
|
|
fact that they don't do anything unless the appropriate variables are set
in rc.conf, people really dislike the warning emitted at startup. For
users that do want the pkg_* tools to handle automatically copying and
removing the rc.d scripts, the mk.conf variable to set is
INSTALL_RCD_SCRIPTS=YES.
|
|
|
|
|
|
|
|
currently only occurs for packages that use bsd.pkg.install.mk.
There are two new targets, pre-install-script and post-install-script, that
default to doing nothing. The order of targets called for a "make install"
is:
pre-install-script
pre-install
do-install
post-install
post-install-script
The new targets are defined in bsd.pkg.install.mk to call the INSTALL
script with the PRE-INSTALL and POST-INSTALL options.
|
|
PKG_USERS represents the users to create for the package. It is a
space-separated list of elements of the form
user:group[:[userid][:[descr][:[home][:shell]]]]
Only the user and group are required; everything else is optional,
but the colons must be in the right places when specifying optional
bits. Note that if the description contains spaces, then spaces
should be double backslash-escaped, e.g.
foo:foogrp::The\\ Foomister
PKG_GROUPS represents the groups to create for the package. It is a
space-separated list of elements of the form
group[:groupid]
Only the group is required; the groupid is optional.
This solves the problem of what to do when there is more than one user or
group needed for a package, e.g. qmail. Also add a bit more error-checking
to the INSTALL/DEINSTALL scripts.
|
|
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.
PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which the
configuration files for a particular package may be found.
PKG_SYSCONFDIR.${PKGBASE} overrides the value of ${PKG_SYSCONFDIR} for a
particular package.
Users will typically want to set PKG_SYSCONFBASE to /etc, or accept the
default location of ${PREFIX}/etc.
This obsoletes the use of CONFDIR, which was active for only 6 days, so no
need to have a workaround to still accept old CONFDIR settings.
|
|
|
|
|
|
names of the scripts and is no longer a MLINKS-type variable. The scripts
are copied into ${RCD_SCRIPTS_DIR} which defaults to /etc/rc.d for now.
It's unclear if Linux/Solaris would set RCD_SCRIPTS_DIR to something else.
|
|
but the user isn't prompted to customize the files at post-install time.
|
|
many of the tasks that need to be done when package is installed or
deinstalled:
* creating user/group for the package,
* creating and removing directories with special permissions and
ownership,
* copying config files to their final locations, and removing them
at deinstall time if they don't differ from the example ones,
* reminding the package admin of files he may want to customize or
of files/directories he may want to remove.
|