Commit graph

18 commits

Author SHA1 Message Date
joerg
3602c0d28e Don't require pkg_delete or pkg_info -r to list packages in full
topological sort for the make update list. This breaks naturally when
new dependencies are introduced that are also in the list scheduled for
later installation. Reported by David Holland.
2009-05-16 01:27:30 +00:00
joerg
3e9de36e25 make update might be called without having the package installed, so
check for the presence before trying to extract dependencies.
2009-03-07 19:36:31 +00:00
joerg
5f28d6bebf Use pkg_info -r if present and fall back to pkg_delete for pkg_install
before 20090225. Intermediate versions get an explicit error.
The building of the recursive dependency was broken as the new
pkg_delete would stop without recursing and the target dependend on that
behavior. Reported by David Holland.
2009-03-05 23:07:15 +00:00
joerg
056616878d Prefer package-destdir as default for update with USE_DESTDIR. 2008-04-07 13:31:15 +00:00
rillig
66736dde43 Replaced _PKG_SILENT and _PKG_DEBUG with RUN. 2008-02-07 21:36:13 +00:00
rillig
ceae47166c Replaced ${_PKG_SILENT}${_PKG_DEBUG} with ${RUN}, since it is shorter.
Removed unnecessary braces around a single pipeline. Also removed the
||true, since awk is very unlikely to fail.
2007-09-07 16:47:05 +00:00
rillig
6f5e31989b pkg_info -qR doesn't give the same results as pkg_delete -n. 2007-09-07 11:14:10 +00:00
obache
72267a276f Correct typo, really fixes PR 36940. 2007-09-07 10:57:35 +00:00
rillig
9082111f79 pkg_info needs at least one package name. Fixes PR 36940. 2007-09-07 10:38:44 +00:00
rillig
8485c5f6cb One line of code can say as much as ten. 2007-09-06 08:28:01 +00:00
rillig
af6cc8cfa0 Why do things in a simple way when there is a complicated alternative? 2007-09-06 08:24:12 +00:00
rillig
11142e502a Suppress the message that ".DDIR is up-to-date" by introducing a .PHONY
target.
2006-10-05 12:56:27 +00:00
jlam
c489860d62 Whenever we invoke a recursive make, we need to ensure that the proper
environment ${PKGSRC_MAKE_ENV} is also passed along.  Create a
convenience variable RECURSIVE_MAKE that does exactly this and that
can be used in place of MAKE when invoking make recursively.

Use RECURSIVE_MAKE everywhere in pkgsrc/mk that we invoke make
recursively.
2006-07-27 21:46:45 +00:00
tron
6e1ed39e5d 1.) Remove all instances of '@${WARNING_MSG} "Warning: ...' which resulted
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".
2006-06-07 10:04:03 +00:00
jlam
3fbe129b69 Use PHASE_MSG, STEP_MSG, WARNING_MSG, and ERROR_MSG in place of ECHO_MSG
in various places.
2006-06-05 22:49:44 +00:00
jlam
aa5856070f Move definitions for UPDATE_TARGET and DEPENDS_TARGET closer to where
they are used.  Also, move UPDATE_RUNNING into the install module where
it is used, and make it "private" by prepending with an underscore.
2006-06-05 17:21:54 +00:00
jlam
ff4b082f6f Move some "update"-only variables from bsd.pkg.mk to bsd.pkg.update.mk. 2006-06-04 08:25:52 +00:00
jlam
e5eb2c56af First pass at implementing support for package system flavors other
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.
2006-06-03 23:11:42 +00:00