| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Also, move the interactive check into a separate target as a prelude
to removing the recursive make for invoking "real-install".
|
|
in error message like 'WARNING: Warning: ...'.
2.) Replace "WARN_MSG" with "WARNING_MSG" which makes the "make package"
target work again for restricted packages like "acroread7".
|
|
bsd.pkg.mk. They didn't actually need to be defined in bsd.prefs.mk,
just somewhere before the "main" bsd.<phase>.mk files were included.
This moves some conditional (?=) definitions back into bsd.pkg.mk so
they won't conflict with any conditional definitions in package
Makefiles.
This should fix the "checksum" problems in lang/php-gd as noted here:
http://mail-index.netbsd.org/pkgsrc-users/2006/06/05/0012.html
where EXTRACT_SUFX had the wrong value due to the order in while *.mk
files were included.
|
|
|
|
in various places.
|
|
if PKG_SKIP_REASON or PKG_FAIL_REASON is defined. This commit adds
!target(...) guards around those target definitions to avoid "duplicate
target definition" warnings.
|
|
they are used. Also, move UPDATE_RUNNING into the install module where
it is used, and make it "private" by prepending with an underscore.
|
|
than pkgsrc's current one. This is an important lead-up to any project
that redesigns the pkg_* tools in that it doesn't tie us to past design
(mis)choices. This commit mostly deals with rearranging code, although
there was a considerable amount of rewriting done in cases where I
thought the code was somewhat messy and was difficult to understand.
The design I chose for supporting multiple package system flavors is
that the various depends, install, package, etc. modules would define
default targets and variables that may be overridden in files from
pkgsrc/mk/flavor/${PKG_FLAVOR}. The default targets would do the
sensible thing of doing nothing, and pkgsrc infrastructure would rely
on the appropriate things to be defined in pkgsrc/mk/flavor to do the
real work. The pkgsrc/mk/flavor directory contains subdirectories
corresponding to each package system flavor that we support. Currently,
I only have "pkg" which represents the current pkgsrc-native package
flavor. I've separated out most of the code where we make assumptions
about the package system flavor, mostly either because we directly
use the pkg_* tools, or we make assumptions about the package meta-data
directory, or we directly manipulate the package meta-data files, and
placed it into pkgsrc/mk/flavor/pkg.
There are several new modules that have been refactored out of bsd.pkg.mk
as part of these changes: check, depends, install, package, and update.
Each of these modules has been slimmed down by rewriting them to avoid
some recursive make calls. I've also religiously documented which
targets are "public" and which are "private" so that users won't rely
on reaching into pkgsrc innards to call a private target.
The "depends" module is a complete overhaul of the way that we handle
dependencies. There is now a separate "depends" phase that occurs
before the "extract" phase where dependencies are installed. This
differs from the old way where dependencies were installed just before
extraction occurred. The reduce-depends.mk file is now replaced by
a script that is invoked only once during the depends phase and is
used to generate a cookie file that holds the full set of reduced
dependencies. It is now possible to type "make depends" in a package
directory and all missing dependencies will be installed.
Future work on this project include:
* Resolve the workflow design in anticipation of future work on
staged installations where "package" conceptually happens before
"install".
* Rewrite the buildlink3 framework to not assume the use of the
pkgsrc pkg_* tools.
* Rewrite the pkginstall framework to provide a standard pkg_*
tool to perform the actions, and allowing a purely declarative
file per package to describe what actions need to be taken at
install or deinstall time.
* Implement support for the SVR4 package flavor. This will be
proof that the appropriate abstractions are in place to allow
using a completely different set of package management tools.
|
|
pkginstall framework).
|
|
UNIX systems which caused recursive script invocations to not work.
Patch from Georg Schwarz in private email.
|
|
to break.
|
|
used by the various scriptlets. Also, consistently use the idiom of
creating a temporary directory with mode 700 and creating temporary
files underneath that directory to avoid race conditions.
|
|
for by running it through a separate FILES_SUBST_SED filter. This fixes
the case where the user wasn't being created if USERGROUP_PHASE was
defined.
|
|
determines the users and/or groups don't exist. This makes "make clean"
work properly for non-root users.
|
|
|
|
USERGROUP_PHASE is defined.
|
|
matches ${PKGBASE}, then use "${PKGBASE} user", otherwise we use
"${PKGBASE} $user user".
|
|
${PKG_SYSCONFDIR} if PKG_SYSCONFSUBDIR is defined and non-empty. A
package may now set PKG_SYSCONFDIR_PERMS to an "owner group mode"
triplet, which defaults to "${ROOT_USER} ${ROOT_GROUP} 755".
|
|
|
|
precedes the user and group.
|
|
is used in either the user or group name due to some bizarro set of
circumstances.
|
|
where they don't verify that any pre-existing config files and
directories have the correct permissions. For example, if you are
upgrading a package to a newer version and the config files and
directories used by the package need to have different permissions
than in previous versions of the package, then the new package may
fail to work because it can't access pre-existing files and directories.
This commit improves on this by doing the following:
(1) Teach the +FILES and +DIRS scriptlets two new actions "PERMS" and
"CHECK-PERMS". "PERMS" fixes permissions on existing files and
directories. "CHECK-PERMS" will verify those same bits and warn
the user when they are wrong. The "CHECK-PERMS" actions for the
two scriptlets are run immediately after the "ADD" actions.
(2) Add a new variable PKG_CONFIG_PERMS that controls whether the
"PERMS" action will automatically fix permissions. PKG_CONFIG_PERMS
is only consulted if PKG_CONFIG is "yes". PKG_CONFIG_PERMS can
be set in the shell environment when running pkg_add, e.g.:
export PKG_CONFIG=yes
export PKG_CONFIG_PERMS=yes
pkg_add /path/to/binary/package.tgz
The default value of PKG_CONFIG_PERMS embedded into the +INSTALL
script may also be set in /etc/mk.conf. This value defaults to
"no", so that by default, the +INSTALL script will not modify or
destroy any existing configuration files or directories.
The +INSTALL script will now always warn you if there are files or
directories whose permissions differ from what the package is expecting
to use, and if PKG_CONFIG_PERMS is set to "yes", then it will go ahead
and fix those permissions for you automatically.
|
|
|
|
provided in PR pkg/33346 by Yoshito Komatsu.
|
|
(1) Allow specifying the numeric UID and GID for users and groups in
/etc/mk.conf by setting PKG_UID.<user> and PKG_GID.<group> to
those values. If these values are specified, then the +USERGROUP
script will verify that existing users and groups match the
requested UIDs and GIDs for the package, and otherwise create them
with these UIDs and GIDs. For example:
PKG_UID.courier= 10001
PKG_GID.mail= 6
In this example, the courier-authlib binary package will be created
to use uid 10001 for the "courier" user and gid 6 for the "mail"
group.
(2) Allow a package to request that users and groups be created prior
to configuring or building a package by setting USERGROUP_PHASE
to "configure" or "build". Because the reason for this is typically
to hardcode the UIDs and GIDs of requested users and groups directly
into the package's executables, these hardcoded values will be
automatically determined and put into the +USERGROUP script. For
example:
USERGROUP_PHASE= configure
PKG_GROUPS= qmail nofiles
PKG_USERS+= qmaill:nofiles
PKG_USERS+= qmailq:qmail
In this example, the users and groups are created before the
configure phase when building qmail, and the qmail binary package's
+INSTALL script will try to create (or verify) users and groups
with the same UIDs and GIDs that were used during the build.
As part of these changes, the format for PKG_USERS and PKG_GROUPS has
changed -- the optional parts of the corresponding entries are no
longer used and cannot be specified. Instead, the following variables
should be set:
PKG_GID.<group> is the group's numeric GID.
PKG_UID.<user> is the user's numeric UID.
PKG_GECOS.<user> is the user's description.
PKG_HOME.<user> is the user's home directory.
PKG_SHELL.<user> is the user's login shell.
A separate commit will follow which will fix all packages that set
PKG_USERS and PKG_GROUPS to use the new syntax and variables.
|
|
the PLISTs, drop support for listing info files in INFO_FILES. The
INFO_FILES variable is now strictly defined/undefined.
|
|
(1) Don't claim to be adding and removing the info file if it does
exist at all.
(2) Always try to create and remove the directory containing the "dir"
index file to avoid failures.
|
|
directory containing the "dir" file that is updated. This allows
packages to install info files in one place but update the dir file
in a separate location.
|
|
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.
|
|
to understand.
|
|
|
|
variables are empty.
|
|
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.
|
|
needed by fonts/intlfonts, ok@ jlam.
|
|
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.
|
|
Thomas Klausner.
|
|
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.
|
|
|
|
|
