EARLY_PRINT_PLIST_AWK is like PRINT_PLIST_AWK but operates before the
file/directory lists are sorted.
Discussed on tech-pkg@ mainly to address `print-PLIST' order problems for
Python 3 packages:
<https://mail-index.NetBSD.org/tech-pkg/2020/05/27/msg023249.html>
While here, add more verbose documentation on PLIST_SUBST since the way
from the package's PLIST file to the +PLIST file can easily be confused
with the other way round, which is handled by print-PLIST.
Up to now, there was a central list of variable name patterns that
defined whether a variable was printed as a sorted list, as a list or as
a single value.
Now each variable group decides on its own which of the variables are
printed in which way, using the usual glob patterns. This is more
flexible since different files sometimes differ in their naming
conventions.
Two variable groups are added: license (for everything related to
LICENSE) and go (for lang/go).
This is based on the decision The NetBSD Foundation made in 2008 to
do so, which was already applied to src.
This change has been applied to code which is likely not in other
repositories.
ok board@, reviewed by riastradh@
Introduce Icon Theme cache handling framework
Icon Theme cache files are used by GTK+ and maintained with the
gtk-update-icon-cache tool. Each Icon Theme package duplicates
its own maintainance scripts: only the specified icon theme directory
differs. With this framework, if packages have ICON_THEMES=yes,
associated icon themes will be detected and their cache files will
be maintained automatically.
Change cache handling behaviour as follows:
* Icon theme caches will be updated if either gtk2+ or gtk3+
gtk-update-icon-cache tool is available.
* With installation of gtk2+ package, not only hicolor icon theme but
also any other icon theme cache files will be updated.
* Prevent removal of icon caches at deinstall, gtk3+ may be installed and
using them.
* Ditto with gtk3+, gtk2+ may not be installed now, so caches must be
maintained by gtk3+.
In particular:
OS_VERSION
MACHINE_GNU_PLATFORM
MACHINE_ARCH
MACHINE_GNU_ARCH
LOWER_OS_VERSION
Reason: Only very few packages really need these, many other have false
positives.
Ok jperkin@
* HASKELL_ENABLE_LIBRARY_PROFILING and HASKELL_ENABLE_HADDOCK_DOCUMENTATION
are "User-settable variables", not "Package-settable variables".
* Change to HASKELL_ENABLE_HADDOCK_DOCUMENTATION=yes by default.
* Add HASKELL_ENABLE_SHARED_LIBRARY("yes" by default), to enable shlib support.
* Add support for dynamically conditional PLIST entries handling for
HASKELL_ENABLE_SHARED_LIBRARY and HASKELL_ENABLE_LIBRARY_PROFILING.
discussed with pho@ and szptvlfn@.
SMF is the Service Management Facility, the default init system in
Solaris and derivatives since version 10. This adds "smf" to the list
of supported INIT_SYSTEM types, and makes it the default init system on
platforms where it is available.
Packages can introduce SMF support by providing a manifest file, by
default located in ${FILESDIR}/smf/manifest.xml but manifests under
${WRKSRC} can be used too if the package source includes one.
SMF method scripts are supported too if required, using SMF_METHODS in a
similar manner to RCD_SCRIPTS.
Many parts of the SMF infrastructure are configurable, see mk/smf.mk for
the full details.
* dll may be in ${PREFIX}/bin instead of ${PREFIX}/lib.
* dll name may be cygXXX.dll instead of libXXX.dll.
* versioning name may be foo-X.Y.Z.dll instead of foo.X.Y.Z.dll.
catman pages are installed with a suffix which matches their section
instead of the default '.0'.
Enable it by default on SunOS, which requires that particular layout.
By default pkgsrc uses LOCABASE/gnu as a prefix for packages to install
native versions of GNU tools, which are them symbolically linked back to
the 'g' versions of the files in LOCALBASE, and users can then add
LOCALBASE/gnu/bin to PATH to pick up those tools.
On systems where the GNU environment is desired, PKGGNUDIR now allows
users to install the non-'g' files directly into LOCALBASE, making them
the default without having to alter PATH, whilst retaining the 'g' files
in order to ensure dependencies and tool paths remain the same.
