Age | Commit message (Collapse) | Author | Files | Lines |
|
that are outside of ${LOCALBASE} belong to the package that lists them.
If the directory already exists before the package is installed, then
we don't presume ownership of the directory.
This addresses pkg/18383 by Grant Beattie.
|
|
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.
|
|
(approved by jlam).
|
|
|
|
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.
|
|
readable way of print messages.
|
|
/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.
|
|
|
|
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=/.
|
|
exists on the system. We still make noise about directories in
MAKE_DIRS_PERMS because those directories must have special permissions
that the admin should check, even if they do exist.
|
|
directories if they still exist after we try to remove them.
|
|
used in the scripts.
|
|
the same case insensitive multiple choice that the equivalents from
the environment support
|
|
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.
|
|
|
|
tell user where the example file is located. Patch provided by Stoned
Elipot <seb@netbsd.org> in private e-mail.
|
|
something to replace for each of those things in the header.
|
|
are two distinct shell words.
Reviewed by Johnny C. Lam.
|
|
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.
|
|
now work on Darwin, and then the discussion about allowing spaces in
user/group names, make these scripts work even if the inputs contain
spaces. Yes, this is overkill, but after doing all of the work, I didn't
want to waste it.
|
|
|
|
so that the general INSTALL/DEINSTALL scripts can manage these extra files
and directories.
|
|
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.
|
|
|
|
the package has been deleted.
|
|
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.
|