that is a purely user-settable variable to represent the relative
path under ${PREFIX} where info files are stored and "dir" files
are managed. PKGINFODIR defaults to "info". INFO_DIR still works,
but will be obsoleted after the 2006Q1 branch.
* Modify GNU_CONFIGURE_INFODIR to only honor ${PKGINFODIR} if the
package installs directly into ${PREFIX} and not some subdirectory
under ${PREFIX}. This fixes packages that don't really honor
$(infodir) all that well, and also avoids PLIST problems relating
to directory removal for those packages.
* Since the majority of Emacs Lisp packages use GNU_CONFIGURE, just
set GNU_CONFIGURE_INFODIR directly to ${EMACS_INFOPREFIX}, which is
the Emacs-distro-specific location for info files. Also pass
EMACS_INFOPREFIX through PLIST_SUBST for PLIST substitution.
* INFO_FILES should be defined if the package installs info files.
If the info files are not listed in the PLIST, then INFO_FILES
must list the filenames for the info files installed by the package,
which are assumed to be located in ${PREFIX}/${PKGINFODIR}.
* The plist module can now better detect info files listed in PLISTs
and exports a command to the pkginstall module to append info file
names to the +INFO_FILES scriptlet at install-time.
* The print-PLIST target is updated to properly list info files in
the auto-generated PLIST.
* The check-files code is updated to skip all "dir" Info database files.
and rc.d scripts so that we source the latest makevars.mk file and
get the latest set of cached variables. This fixes problems where
BUILDLINK_PREFIX.* wasn't being expanded correctly when substituting
into an INSTALL script.
INSTALL/DEINSTALL and rc.d scripts, regardless of whether NO_BUILD is
defined or not.
We do this by renaming the main "build" target to "_build", and creating
a new "build" target that has "_build" and "pkginstall" as dependencies.
This allows the "build" and "install" targets to be consecutive, so
no changes in behavior are visible to the user.
Because the pkginstall targets are no longer run within the protection
of the locks during the build phase, we need to manage locking within
a new "pkginstall" target.
scripts are generated. The various scriptlets in pkgsrc/mk/install
are now full templates that can be combined to form the INSTALL and
DEINSTALL scripts. All of the templates have either leading or trailing
blank lines so that when they are concatentated, the full INSTALL and
DEINSTALL scripts will still be easy to read.
All of the generated template sources for the INSTALL and DEINSTALL
scripts are now stored in ${WRKDIR}/.pkginstall for local consistency
and have been renamed so that they are not dot-files.
The "data" for the +* scriptlets are now generated in a separate step
and instead of being appended to the unpacked scriptlet are now appended
to the INSTALL script itself. When the scriptlets are unpacked, the
corresponding data lines for each scriptlet are pulled out of the
INSTALL script and put into the unpacked scriptlets. This makes it
easy to append more data lines during the install phase without needing
to regenerate the INSTALL script.
INSTALL/DEINSTALL script creation within pkgsrc.
If an INSTALL or DEINSTALL script is found in the package directory,
it is automatically used as a template for the pkginstall-generated
scripts. If instead, they should be used simply as the full scripts,
then the package Makefile should set INSTALL_SRC or DEINSTALL_SRC
explicitly, e.g.:
INSTALL_SRC= ${PKGDIR}/INSTALL
DEINSTALL_SRC= # emtpy
As part of the restructuring of the pkginstall framework internals,
we now *always* generate temporary INSTALL or DEINSTALL scripts. By
comparing these temporary scripts with minimal INSTALL/DEINSTALL
scripts formed from only the base templates, we determine whether or
not the INSTALL/DEINSTALL scripts are actually needed by the package
(see the generate-install-scripts target in bsd.pkginstall.mk).
In addition, more variables in the framework have been made private.
The *_EXTRA_TMPL variables have been renamed to *_TEMPLATE, which are
more sensible names given the very few exported variables in this
framework. The only public variables relating to the templates are:
INSTALL_SRC INSTALL_TEMPLATE
DEINSTALL_SRC DEINSTALL_TEMPLATE
HEADER_TEMPLATE
The packages in pkgsrc have been modified to reflect the changes in
the pkginstall framework.
drop pkginstall.mk, which did the same thing. Also, rework some of
the targets so that we avoid needing to inspect *_MEMBERS variables
within make -- we defer the check to the shell code invoked by the
targets.
All changes are internal and don't affect existing packages in a
visible way.
scriptlet to manage the info-file registration. The new scriptlet's
template is install/info-files. Remove obsolete texinfo.mk and
install/install-info.
No changes to package Makefiles are necessary -- the re-implementation
is internal to pkgsrc infrastructure.
if no other packages are using them, but if no other "software" is using
them. Just in case, they are using a user and/or group without a package
using it.
to be used so that +INSTALL and +DEINSTALL scripts are generated.
This can be used in cases where it's not possible or not desirable to
use the auto-detection mechanism to decide whether the pkginstall
framework is needed.
PKG_UPDATE_FONTS_DB=no in the environment or /etc/mk.conf. This can
be beneficial when installing large numbers of fonts packages into
the same directories as it avoids destroying and recreating the same
database files over and over again. This might make it possible
someday to run fc-cache, which is sometimes very time-consuming, from
the +FONTS script automatically.
framework should be used. This is implemented by creating a small
file mk/install/pkginstall.mk that guards the implementation makefile
mk/install/bsd.pkginstall.mk. This guard file just checks whether
one of the pkginstall-related variables is non-empty, and if so, then
the implementation file is automatically included. This completely
deprecates USE_PKGINSTALL, which no longer has any affect in pkgsrc.
pkginstall framework:
* Rewrite the mk/install/fonts script fragment as a scriptlet that's
generated by the +INSTALL script during package installation.
* Rename the FONTS_<TYPE>_DIRS variables to FONTS_DIRS.<type> to
be more consistent with how "families" of variables are currently
named in pkgsrc.
* Rewrite mk/fonts.mk so that it's implemented in terms of the new
functionality in the pkginstall framework. This file will be
obsoleted in the near future after packages have been transitioned
to use the new functionality in the pkginstall framework. Currently,
packages will continue to work with no changes.
Integrating the fonts-handling into the pkginstall framework has the
benefit of generating a +FONTS scriptlet that may be run independently
of the +INSTALL scripts to (idempotently) update the fonts databases
and fix package installation errors.
${PKG_SYSCONFDIR} to not be automatically creates/refcounted by the
+DIRS script for packages that only set CONF_FILES_PERMS and not
CONF_FILES or PKG_SYSCONFSUBDIR, e.g. security/sudo. This caused
problems when PKG_SYSCONFBASE was set to a non-default directory that
didn't pre-exist, e.g. PKG_SYSCONFBASE=/etc/pkg. Problem noted by
<jmmv>.
There is a default implementation of the shell functions adduser()
and addgroup() used by the +USERGROUP script that uses NetBSD/Solaris-style
useradd(8) and groupadd(8) commands. A platform may override those
functions by creating pkgsrc/mk/install/usergroupfuncs.${OPSYS}. This
fixes PR pkg/23061.
backslashes anymore. A single backslash is enough. Changed the
definition in all affected packages. For those that are not caught, an
additional check is placed into bsd.pkginstall.mk.
REQD_FILES, REQD_FILES_PERMS, REQD_FILES_MODE
REQD_DIRS, REQD_DIRS_PERMS
These are the same as the CONF_* variables, except the files and
directories listed in REQD_* are always copied over, created or removed
(taking into account if there are user modifications from the originals,
etc.) regardless of the value of PKG_CONFIG.
The implementation involved pushing the knowledge of PKG_CONFIG,
PKG_RCD_SCRIPTS, PKG_CREATE_USERGROUP, and PKG_REGISTER_SHELLS into
the individual helper scripts. The helper scripts are now always
invoked by the +INSTALL and +DEINSTALL scripts. The +DIRS and +FILES
script have been enhanced to understand a new "f" flag that means
"force" to ignore the value of PKG_CONFIG and PKG_RCD_SCRIPTS.
Lastly, the +FILES script has been taught a new "r" flag just for rc.d
scripts and the +RCD_SCRIPTS script is now unnecessary.
as the INSTALL and DEINSTALL scripts no longer distinguish between
the two types of files. Drop SUPPORT_FILES{,_PERMS} and modify the
packages in pkgsrc accordingly.
outputs 2, but 0 would be expected. That means that the arguments to set
-- must never be empty. I added the necessary checks. I also used
for...done loops instead of set, as they are simpler and don't use
global variables.
function that does the same. The Solaris /bin/sh does not know this type
of substitution. Now we could only have problems with /bin/sh which do
not know functions, but as we are using shell functions in many other
places, this should be fine.
config files, directories, rc.d scripts, etc., use relative paths as
much as possible to avoid hard-coding the ${PREFIX}-location in which
the files should be installed. Where full paths are specified, if
the path is within ${PREFIX}, then automatically strip off the ${PREFIX}
part when creating the entries for the helper scripts. Also, modify
the helper scripts to understand that relative paths should be considered
to be relative to ${PKG_PREFIX}.
+SHELL.
* Turn PKG_REGISTER_SHELLS into a variable that can be set in the shell
environment so that admins can make a choice when installing from
binary packages.
* PKG_SHELL is now a list of paths, and if the path is relative, then it
is taken to be relative to ${PREFIX}. Convert packages that set
PKG_SHELL to take advantage of this new feature by changing the full
paths to the shells into relative paths.
if an untested command fails (see sh(1), "-e errexit"). Do this by
changing lines that look like:
test expression && command
to
test ! expression || command
so that the statement list always returns 0. Also, back out revision
1.38 of pkgsrc/mk/install/install and modify the if-test to branch
correctly if +USERGROUP doesn't exist.
syntax errors (and unchanged example files to be left behind) on Interix;
it probably causes a problem on others.
(This test appears to work around a case where two files were exactly the
same by inode, and have the script *not* delete the file in that case.
I'm not exactly sure why that is desirable at all.)
+RCD_SCRIPTS, and +PERMS subscripts to handle copying config files
and rc.d scripts, and setting special permissions on files. The +FILES
and +RCD_SCRIPTS are basically identical except for different embedded
packets of data, and they feature reference-counting for the files in
case multiple packages share the same config file.
Garbage-collect unused functions and definitions in the install scripts
now that the subscripts are self-contained.
now simply make ${PKG_REFCOUNT_DBDIR} always be ${PKG_DBDIR}.refcount
so that it always follows the location of ${PKG_DBDIR}. This preserves
the ability for PKG_DBDIR (and PKG_REFCOUNT_DBDIR) to be different on
different machines despite using the same binary packages.
CHECK-REMOVE. The users and groups are now printed on the same line
with whitespace separating the entries (for easy copy-and-pasting info
commands), and wrapping to successive lines if we overflow the length
of the current line.
script that is unpacked by the +INSTALL script at PRE-INSTALL time
before any other actions take place, and invoke +USERGROUP to create
any necessary users and groups. Remove the now-unused code for
PKG_USERS and PKG_GROUPS from the install and deinstall templates.
We also reference count the users and groups and store the reference
counts in ${PKG_DBDIR}/.refcount/{users,groups}. This allows multiple
packages to register that they use same users and groups, and allows
+USERGROUP to be invoked at any time to repair an installed package.
Also fix the install and deinstall templates to invoke the CHECK-*
actions with ${PKG_METADATA_DIR} so that the correct PKGNAME can be
derived. This fixes the weird messages asking the user to create
directories for ".pkgdb" during a "make install".
of directories needed for the proper functioning of each package.
The +INSTALL script unpacks a +DIRS script that adds and removes
directories. The +DIRS script entirely encapsulates the directory
creation and removal, and completely replaces the code in the
mk/install/install and mk/install/deinstall templates that handled
{MAKE,OWN}_DIRS and {MAKE,OWN}_DIRS_PERMS.
The +DIRS script is meant to be executed from within the package
meta-data directory, e.g. /var/db/pkg/<pkgname>. It's usage is:
./+DIRS ADD|REMOVE|CHECK-ADD|CHECK-REMOVE
The ADD and REMOVE actions cause the necessary directories to be added
or removed from the system. The CHECK-ADD and CHECK-REMOVE actions
print out informative messages prompting the user to either create or
remove some necessary directories.
The behaviour of "ADD" is such that if the directory already exists
on the system and is not already ref-counted, then that directory is
marked as "pre-existing". On "REMOVE", pre-existing directories are
left untouched on the filesystem.
At any time, the root user can sanity-check the directories needed by
packages by invoking all of the +DIRS scripts with the "CHECK-ADD"
action. If there are missing directories, then invoking all of the
+DIRS scripts with the "ADD" action will ensure that any missing
directories are created.
The reference counts database is stored in ${PKG_DBDIR}/.refcount.
The reference counts related to directories managed by the +DIRS script
are stored in ${PKG_DBDIR}/.refcount/dirs. If the directory reference
counts database is removed, then invoking all of the +DIRS scripts
with the "ADD" action will reconstruct the database; however, directories
may be marked as being pre-existing, so they won't be removed at
package de-installation (although a message will be displayed informing
the user that those directories can be removed).
Previously, ttmkfdir's output was redirected to fonts.dir,
while the correct behaviour is to let it create fonts.scale
and then let mkfontdir merge fonts.scale into fonts.dir.
type1 handling had a similar problem.
Get the wanted behaviour by automatically appending the contents of
FONTS_TTF_DIRS and FONTS_TYPE1_DIRS to FONTS_X11_DIRS.
Also, save a subshell in install/fonts while there.
Bump PKGREVISION for all affected packages.
jmmv@ says ok.
and groupadd commands won't follow the calling conventions of the
NetBSD useradd/groupadd. Modify the INSTALL scripts to *never* create
users or groups if there is no available ${USERADD} or ${GROUPADD}
command, but will warn the user of users and groups that need to be
created before the package can be installed.
${PREFIX}. It is not an absolute path because with the automatic
addition of the entry to the PLIST would be bogus if someone
defined it to some RCD_SCRIPTS_EXAMPLEDIR outside of PREFIX.
(This may cause multiple rc.d directories if there are multiple
PREFIXes, but I think that is fine.)
Note that at this time, this doesn't change the RCD_SCRIPTS_EXAMPLEDIR
default directory. This will change soon.
Most of this has been in use for over a year.
Also some of this is from Greg Woods. Thank you Greg.
I will next update a few other references to RCD_SCRIPTS_EXAMPLEDIR.
This way font directories are not automatically removed; the package must
define OWN_DIRS if it wants them to be deleted during deinstallation.
This is done to avoid removal of standard font directories (those that
appear in *.dist files).
* Ensure that VIEW-INSTALL is called after _all_ POST-INSTALL actions
(including any in the INSTALL_EXTRA_TMPL file) by moving the call to
a file that is included after all other INSTALL templates.
* Ensure that VIEW-DEINSTALL is called before _all_ DEINSTALL actions
(including any in the DEINSTALL_EXTRA_TMPL file) by moving the call to
a file that is included before all other DEINSTALL templates.
config directory matches the config directory for the dependency
listed in CONF_DEPENDS. Use symlinks to physically point the
package's config directory to the dependency's config directory, and
handle all of this in the INSTALL/DEINSTALL scripts.
Also make the INSTALL/DEINSTALL scripts a bit smarter about not
copying files and not removing files if the source and destination
file locations point to the same thing.
PKG_SYSCONFBASE when they want PKG_SYSCONFDIR stripped of
PKG_SYSCONFSUBDIR. This makes PKG_SYSCONFBASE=/etc work with pkgviews by
installing all config files into /etc/packages/<pkg> instead of
occasionally putting some directly into /etc.
Also only create PKG_SYSCONFDIR if we're actually going to copy config
files.
file exist when installing a package and it does not contain at
least one line starting with '*' then remove it and let install-info
create a new one.
This should address PR pkg/22555 from reed@.
directory file remove it if it is empty i.e. if it contains only one
menu/entry line i.e. only one line starting with '*'.
This allow INFO_DIR to be set to a package specific directory while
not registering in the PLIST the Info directory file (${INFOR_DIR}/dir).
Registering such an Info directory file in the PLIST is not really
possible as a md5 signature of it holding the registered info entries
would be stored in PKG_DBDIR. At deinstall time this signature would not be
matched because the DEINSTALL script would have modified it by
un-registering the info files from it. Hence the package removal would
be reported as incomplete...
You are probably right if this looks like a hack to you...
makeinfo commands.
The goal of the new framework is twofold:
- reduce the number of '@exec' and '@unexec' in PLIST by
using INSTALL/DEINSTALL scripts to handle entries addition/removal
Info directory file.
- achieve lighter dependencies by avoiding unnecessary run-time
dependency on the gtexinfo package and if needed with the help of the
standalone install-info command provided by the recently imported package
pkgtools/pkg_install-info.
A package must be sightly updated to use this new framework and
must define the variable USE_NEW_TEXINFO. This variable will
be removed from the pkgsrc tree when all package would have been
updated.
For details see section 10.24 of Packages.txt, comments in
mk/{texinfo.mk,buildlink2/bsd.buildlink2.mk} and upcoming mail to
<tech-pkg at netbsd dot org>.
fonts.dir, fonts.scale and Fontmap files (depending on the font type) in
the right directories at (de)install time. Support included for TrueType,
Type1 and standard X11 fonts.
Reviewed by jlam.
we can more accurately determine if we "own" a directory. Ownership is
determined by seeing if the directory doesn't exist before the package is
installed.
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.
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.
/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.
(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.
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.
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.
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.
