The ${PLIST} target must run after all the pre/do/post-install targets
were run (they may generate ${PLIST_SRC}!).
This whole code-path should use the make dependency system, not fork
make(1) over and over again.
* In real-su-install, do not call "make ${PLIST}" manually, but rather depend
on the ${PLIST} file being there for the do-su-install target.
* Break out shlib-handlink from real-su-install, and put it into target
do-shlib-handling, which will either touch then PLIST (when called via
the ${PLIST} target) or do the necessary steps to setup shared library
handling (creating symlinks on ELF, running ldconfig on a.out, etc.,
when called via real-su-install)
* Removed some unnecessary tests (check if $PLIST is there when it
can be assumed to be there, ...)
long time. Oh well.)
* Only replace the value of PATH for "PATH", not any variable whose name
starts with PATH (like PKGPATH :-)
Hinted by Jason R. Mastaler <jason@mastaler.com> on tech-pkg.
Let's take timidity, which needs ncurses and tk. By setting
NEED_NCURSES=1 and adding it to MAKEFLAGS, all other required pkgs
automagically depend on ncurses - tk, tcl (which is slurped in by
tk), ...
I now remember why I felt there was something wrong with the fix in PR
11433: it calls some target with PACKAGE_DEPENDS_WITH_PATTERNS=false, and
this will cause problems when someone has a different version installed
than what's currently in pkgsrc.
This was also what the XXX was for that I couldn't remember - all
dependencies were found installed at the time that the
print-pkg-size-depends target gets called, and as such we can call
run-depends list with the PACKAGE_DEPENDS_QUICK switch (to first print our
direct dependencies, and then look at their @pkgdep lines to get all their
depends - no need for recursion, as well store all a pkg's depends in it's
@pkgdep lines!). Using that, we can call "pkg_info -e" on all the patterns
to expand them to match what's really installed on the system, then make
that list unique (so that e.g. foo-1.0 and foo-* gets to the same pkg
twice, and then sorted out). After that we can calculate it's size as
before using "pkg-info -s".
Using this method is also a whole lot faster (due to no recursion).
via a tmp file. Also, there's no need to excape any possible HTML chars
(there won't be any in a PKGNAME).
Noted in PR 11462 by Jeremy C. Reed <reed@reedmedia.net>
the new version of xpkgwedge. Changes from xpkgwedge 0.4:
* Redefine ImakeCmd to "imake -I$(PREFIX)/lib/X11/config" to
pick up X11 config files in $(PREFIX)/lib/X11/config before the
ones in the standard X11 tree.
* Install a program called "pkgxmkmf" that's actually xmkmf, but
checks in $(PREFIX)/lib/X11/config before the standard X11 config
directory.
* Create the host.def file in $(PREFIX)/lib/X11/config instead of
always in ${X11BASE}/lib/X11/config.
The benefits of this are:
1) xpkgwedge can now install into $(PREFIX) instead of always into
$(X11BASE).
2) Keeps the X11 tree "pure", and doesn't affect people who want
to run xmkmf and not include all the xpkgwedge stuff, even if
it's installed.
3) Packages that install config files (lesstif, xview-config) can
now do so in $(PREFIX).
4) People only have to use 'pkgxmkmf' instead of 'xmkmf', and
(hopefully) no other changes, if they want to use the config
files in xpkgwedge'd packages.
jdk 1.1.8 and the blackdown-jre 1.2 will work (and make the version just *,
not 1.1.*). This is a precursor to native JDK 1.2 support. Leave the
preference of the dependency to use the native jdk 1.1.
XXX: There should be a standard location not specific to PKG_JAVA for Java
packages, and there is no particular need for a DEPENDS on the JVM for
most packages (even an external-to-tree JVM is typically happy with the code).
This per-VM PREFIX, and particularly configurable JAVA_HOME, is not clean.
