developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
in the process. (More information on tech-pkg.)
Bump PKGREVISION and BUILDLINK_DEPENDS of all packages using libtool and
installing .la files.
Bump PKGREVISION (only) of all packages depending directly on the above
via a buildlink3 include.
curses.buildlink2.mk. This was wrong because we _really_ do want to
express that we want _n_curses when we include the buildlink2.mk file.
We should have a better way to say that the NetBSD curses doesn't
quite work well enough. In fact, it's far better to depend on ncurses
by default, and exceptionally note when it's okay to use NetBSD curses
for specific packages. We will look into this again in the future.
INCOMPAT_GETTEXT that are analogous to INCOMPAT_ICONV and contain lists of
shell wildcards intended to match against ${MACHINE_PLATFORM}. These
variables are used to note those platforms that have the named packages in
the base system but are incompatible in some way from the pkgsrc version
of the same package. Change INCOMPAT_CURSES to have the same sematics as
above. These variables allow much greater precision in specifying which
platforms have broken (for the purposes of pkgsrc) versions of software in
the base system that must be ignored.
The buildlink.mk files for these packages define private _INCOMPAT_*
versions of these variables, and they contain the default lists of
platforms that are known to have incompatible software bits.
This addresses pkg/17775 submitted by Julien T. Letessier
<julien.letessier at sun dot com>.
