The variable names are typically mentioned in one of these styles:
# Package-settable variables:
#
# VARNAME
# Description
# Package-settable variables:
#
# VARNAME
# Description
Lines that are indented with two tabs contain text. And if one of these
lines starts with a variable name, it is just a coincidence. A practical
example of this happening is in mk/misc/developer.mk 1.24, where PKGNAME
starts a line of description.
PKG_VERBOSE.
PKG_VERBOSE currently is mostly used consistently in order to pass the `-v'
option to various commands (FETCH_CMD, PATCH, plist/doc-compress,
pkg_delete(1)).
It is also used internally (and a bit less consistently) in other cases to
provide more information mostly useful only for debugging.
ok <bsiegert>
look for print/texlive/*.mk files for help.
Now documentation regarding TeX packages for pkgsrc MAINTAINERs and
developers is easily accessible via the "help" target.
ok wiz@
package creation.
There are very few things in pkgsrc that needs more than one hour per
process on decently fast hardware, so setting that as (soft) limit for
bulk builds avoids the infinite loops seen in some other packages. There
are a few select exceptions, i.e. flightgear-data needs more than one
hour for pkg_create when using xz. This flag allows selectively giving
those places more time without wasting resources in the broken cases.
discussion on tech-pkg.
BROKEN_ON_PLATFORM and NOT_FOR_PLATFORM are the same, except that
(now) BROKEN_ON_PLATFORM sets PKG_FAIL_REASON and NOT_FOR_PLATFORM
sets PKG_SKIP_REASON. BROKEN_EXCEPT_FOR_PLATFORM and ONLY_FOR_PLATFORM
correspond in the same way.
The idea is that going forward we will distinguish unbuildable
packages that theoretically ought to be fixed (these are BROKEN) from
packages where it doesn't make sense to build (these are NOT_FOR)...
examples of the former include most non-64-bit-clean packges; examples
of the latter include OS-specific language bindings.
A general review of the uses of NOT_FOR_PLATFORM and ONLY_FOR_PLATFORM
(converting many of them to BROKEN...) is coming up.
Similarly, a general review of the uses of PKG_FAIL_REASON and
PKG_SKIP_REASON is coming up.
For this to become useful, pbulk needs to be taught to report failing
and skipped packages differently - the idea is that failing packages
should be reported up front and skipped packages don't need to be. This
has not been done yet, but one set of things at a time...
running "bmake help topic=:index" now. This change is in preparation of
importing this help into the pkgsrc guide. There are still too many
false positives to be useful.
