`install' with USE_DESTDIR=yes.
This changes prevent to unwanted overwite of existing binary packages with
test installation (`stage-install', `replace' & `undo-replace', and so on).
To do both `install' and `package', you can still use `package-install' target,
same as USE_DESTDIR=no.
This is from Anton Panev's GSoC 2011 project to add RPM and DPKG
support to pkgsrc. (I am not adding that further support in this
commit.)
This is just a rename of the existing functionality. Now it will
be easy to test the GSoC work by simply putting in a single
directory (such as "rpm" or "deb"). See
http://addpackageforma.sourceforge.net/ for some details.
This is from Anton's CVS, but I made some minor changes:
- changed plural pkgformats to singular pkgformat (to be consistent)
- fixed a few places (in comments) that were missed
- catch up on some additions to flavor not in the pkgforma cvs:
PKGSRC_SETENV and _flavor-destdir-undo-replace and
undo-destdir-replace-install.
Packages may set PKG_DESTDIR_SUPPORT to either "destdir" or
"user-destdir" to flag support for this, following the same
rules as PKG_INSTALLATION_TYPES (e.g. define before first include
of bsd.prefs.mk).
The user activates it via USE_DESTDIR. When set to "yes",
packages with "user-destdir" are handled as "destdir".
The installation of the package will not go to ${LOCALBASE},
but a subdirectory of ${WRKDIR} instead. pre/post install scripts are
not run and the package is not registered either. A binary package
can be created instead to be installed normally with pkg_add.
For "user-destdir" packages, everything is run as normal user and
ownership is supposed to be correctled by pkg_create later. Since
the current pkg_install code uses pax and it doesn't allow overwriting
owners, this does not work yet.
For "destdir" packages, installation, packaging and cleaning is run as
root.
This commit does not change the handling of DEPENDS_TARGET or
bin-install to allow recursive usage.
are run with elevated privileges. Remove MAKE_PACKAGE_AS_ROOT
for now, since it is not sure whether the functionality in the current
form will stay and developers should spend time on the destdir support
instead.
package needs to be packed by root or whether the unprivileged user can
do that as well. Most packages don't need root privileges, but the
default value is nevertheless "yes" to not break too many existing
packages.
pkgsrc users are encouraged to add the following to their mk.conf:
MAKE_PACKAGES_AS_ROOT?= no
The "?=" operator here is important because after the testing phase,
this variable is only intended to be set by packages. If "=" would be
used instead, packages could not override the value.
when passing through the barrier. This ensures the PATH (passed via
PKGSRC_MAKE_ENV) is correctly set for all phases after the barrier.
This fixes a bug in "interactive" pkgsrc use, where if you have no
work directory and type "make build && make install", then the "install"
step does not have a PATH set to include all the wrapper and tools
directories.
target in that it installs the currently-built software into the
filesystem. In that case where "replace" is specified as a target on
the command line, make "replace" and not "install" be the source target
for "package".
Also, place the "replace" target between the "install" and "package"
targets in _BARRIER_POST_TARGETS as it should be legal to do those
steps in that order (but not in another order).
These changes make the following work:
make replace package
In this example, the currently installed package will be replaced and
the newly-installed software will be packaged, all within the same
make process.
introducing the concept of a "barrier". We separate the user-invokable
targets into ones that must happen before the barrier, and ones that
must happen after the barrier. The ones that happen after the barrier
are run in a sub-make process. In this case, the targets that must
be run after the barrier are from the "wrapper" step and beyond. We
rewrite the various "flow" targets, e.g. wrapper, configure, build,
etc., so that they of the right form to use the barrier target.
This now completely removes the concept of PKG_PHASE from pkgsrc. It
is replaced with the concept of "before" and "after" the barrier, and
this state can be checked by testing for the existence of the barrier
cookie file. Because we've removed most of the recursive makes, there
is now nowhere to hook the PKG_ERROR_HANDLER.* commands, so remove
them for now.
As part of this commit, put back the logic that conditionalized the
sources for the various cookie files. Because the sources are all
"phony" targets, they were always run, regardless of whether or not
the cookie file already existed. Now, if a cookie file exists, then
that entire phase associated with that cookie file is skipped.
Lastly, fix a thinko in configure/bsd.configure.mk where setting
NO_CONFIGURE in a package Makefile would manage to skip the "wrapper"
step altogether. Fix this by correctly noting "wrapper" and not
"patch" as the preceding step to "configure".
of the logic from fetch/fetch.mk into flavor/pkg/check.mk, so that
check-vulnerable can be used as a source target.
Make check-vulnerable a source target for every phase of the build
workflow, which ensures that it is always run if the user starts a
new phase from the command line.
Fix the cookie-generation targets so that they don't append, only
overwrite to the cookie file. This works around potential problems
due to recursive makes.
Move the cookie checks so that they surround the corresponding phase
target. The presence of the cookie should now inform the make process
to avoid doing any processing of phases that occur before the phase
corresponding to the cookie.
which are invoked in recursive make calls for the "install" and
"package" targets respectvely. These recursive make calls prevent
the top-level make from seeing all of the targets and computing a full
dependency graph, so it becomes possible for some targets to be invoked
more than once. This change passes enough information along to the
recursive make calls and ensures that the source targets for the real-*
targets are only invoked once.
are generated for a target and output them all at once at the conclusion
of the target's invocation. The implementation is in bsd.pkg.error.mk,
which defines a macro target "error-check" that will print out any
non-empty warning and error files in ${WARNING_DIR} and ${ERROR_DIR}
and exit appropriately if there were errors.
Convert some targets that were just long sequences of ${ERROR_MSG} or
${WARNING_MSG} within a single shell statement to use the new delayed
error output via error-check.
Modify the compiler "fail" wrappers for C++ and Fortran to be less
verbose during invocation. Instead collect the warnings and only
print them at the end of the completed phase, e.g. after "configure"
and/or "build" completes.
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".
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.
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.
