The package textproc/hs-cgrep does not install a Haskell library. This
was unexpected to mk/haskell.mk, which generated an obviously wrong PLIST
file for that package, and for 3 other packages.
Noticed by wiz.
This is intended to reduce the log output on ftp.NetBSD.org when
fetching all distfiles.
Also, we call the target in basically every step of package creation
(extract, patch, configure, build, install, package) - perhaps we should trim
this down some more.
There are still some packages that fail the strict SUBST check. These
packages should nevertheless be built using the default pkgsrc
configuration, at least in the stable 2020Q2 branch. After 2020Q2 has
been switched, the strict SUBST checks will be activated again in the
default configuration.
To avoid bmake warnings because of duplicate class names, the :O:u
modifier had been added in r1.66 on 2020-03-21. This had the side effect
that the subst classes are now applied in alphabetical order instead of
declaration order.
For this to actually matter, there must be a file that is affected by two
different subst classes and in which the substitutions depend on each
other or prevent each other. Chances for that are pretty low.
The order is intentionally documented as being unspecified, to allow for
future modifications, just in case that a bmake variable modifier is
invented that filters for duplicates without requiring the duplicates to
be adjacent to each other. In that situation, it would be nicer to
switch back to declaration order instead of alphabetical.
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>
Just in case any of these tools defines some command line arguments. The
correct path had already been used before since both env and sh are added
to USE_TOOLS in bsd.pkg.mk.
There is no evidence that any shell needs the empty string literal in
'for i in "" $var' to loop over a simple variable. This would only be
necessary if the shell code were generated by a preprocessor such as
bmake or autoconf, and the list of items might end up empty. In such a
case, the empty string literal prevents to generate 'for i in ; do',
which would produce a syntax error.
This assignment has popped up various times in the pkglint output, even
though it is defined in the infrastructure and not in a specific package.
Since there is no need to have this duplicate assignment, it is removed.
The general rule is that a SUBST_SED that contains _any_ identity
substitution may leave files unmodified, no matter if there are other
substitutions as well.
When RUN includes the -u shell option (see the pkgsrc guide, section
bulk.var.shvar), there is a stray "requires: parameter not set" error.
This error doesn't make the build fail immediately since it is on the
left-hand side of a pipe, where the exit status is ignored. It would
fail if the shell for bmake were set to bash and its option "pipefail"
were enabled.
For USE_LANGUAGES there is already a pkglint warning, but for GCC_REQD it
is missing. It's better to have this check directly in the
infrastructure since it is more reliable.
This check is disabled by default, to not cause any new breakage.
It should be enabled in bulk builds.
Right now, users who install the pkg-vulnerabilities database find that
the vast majority of packages fail to build, penalizing them too severely.
Package auditing can still be done via "pkg_admin audit".
Alternatively, the previous behaviour can be restored with
ALLOW_VULNERABLE_PACKAGES=no in mk.conf.
Additionally, bmake-ify the check.mk logic. It was easier to do this,
as the package relied on a single long ${RUN} command.
Proposed on tech-pkg, with no objections to the idea of changing the
default, just the method of doing so.
Before, relative paths had been stored as-is. This affected those
packages that defined PATCHDIR or FILESDIR as relative directory instead
of prefixing it with ${.CURDIR}.
Since there are already several other paths that are interpreted relative
to the package directory (CONFLICTS, DEPENDS), allow PATCHDIR and
FILESDIR to be specified as relative paths, too. This makes the package
Makefiles a bit shorter.
The rewritten check for unknown configure options already checks for
options that are not defined anywhere. After that, the configure scripts
don't need to check for these options anymore since all remaining options
are known to the package, in at least one of its configure scripts.
The previous implementation could not reliably detect outdated configure
options. This was apparent in devel/gettext-tools, where the option
--with-included-libcroco had become unknown between May 2019 and May
2020, but the check was not run.
The behavior is the same in the pkgsrc default configuration. Only if
GNU_CONFIGURE_STRICT=yes, the new check is activated and will make
packages fail that previously succeeded to build. Since that variable is
not widely known, there won't be much sudden breakage, if any.
This makes the SUBST blocks stricter than before, to detect outdated or
unnecessary definitions.
Filename patterns that are not affected by any of the SUBST_SED
expressions make the build fail. It is still ok if only some of the
files from a pattern are affected and some aren't.
The latest bulk build shows that most of the build failures are fixed.
The packages that fail in that build are mostly due to other failures,
like missing C headers, wrong PLIST files, unresolved references at link
time. There may be a few packages that still fail because of this, but
these are near the leaves of the dependency tree.
https://mail-index.netbsd.org/pkgsrc-bulk/2020/05/14/msg018919.html
