rather than trying to consolidate into a single fnmatch. There aren't that
many of them, and it will aid the integration of cwrappers which doesn't
support globs.
Base xsrc on netbsd-5 has not really worked with pkgsrc for a while,
because various programs need newer versions of various X pieces. The
2014Q2 official bulk builds are missing about 1500 packages as a
result of this. Therefore, switch to modular on netbsd-5 (as netbsd-4
has been for a very long time), which should result in more useful
binary packages for netbsd-5 for 2014Q3.
(There is a notion of updating netbsd-5 base xsrc to more modern xorg.
If that happens, and there's a 5.x formal release, and builds show
that pkgsrc with native succeeds on it, this can perhaps be flipped
back. Odds are that's not going to happen, and it's overwhelmingly
unlikely to happen soon.)
Anyone who prefers to stay with native can set X11_TYPE=native in
mk.conf.
Note that this is about pkgsrc and specifically the default
dependencies for pkgsrc programs that use X11, so the native servers
are unaffected and can be run from /usr/X11R7, the same as they are
now, without any changes being necessary. (This message is in fact
being typed on a system with a native server, native xterm and modular
libs for pkgsrc.)
Discussed on tech-pkg, tech-x11 multiple times over the last 6 months
or so, and specifically encouraged by wiz@.
a blanket removal of any long options, richard@ is concerned this may affect
packages which use the long options now available in newer SunOS ld.
Whilst here, transform --rpath to -R, used by a few packages.
noticed by diger in pkgsrc-users@.
While here, enable useradd only for the case groupadd exists,
because former useradd is interactive command, not usable with pkgsrc framework.
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.
figure out the target architecture based on the objects so we need to
explicitly set it.
This allows bootstrap --abi=32 to complete successfully on x86_64.
that location in the new find-headers infrastructure when they have not
been installed into /usr/include.
This allows us to remove the hardcoded builtins, as they can now be
correctly determined automatically.
are instead moved to SDK-specific locations. This breaks many builtin checks
which assume headers are in a fixed place.
Rather than trying to dig around finding where Xcode.app might be installed,
just override IS_BUILTIN for libraries that we know exist.
This file is from libtool-1.x, which is not in pkgsrc any longer
(using libtool-2.x since 2009). Also, it was only used for packages
using autoconf-2.13 AND libtool; I found three packages in pkgsrc with
that combination, and all of them still build on NetBSD-6.99.24/amd64
after this change.
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.
per-platform default. Previously PREFER.<pkg> was used, and as that
has the highest precedence it meant the defaults could not be overridden
with the PREFER_PKGSRC and PREFER_NATIVE user variables.
While here, set the openssl default for SunOS back to pkgsrc, now that
users who wish to use the builtin can do so via PREFER_NATIVE=openssl.
so that they are correctly calculated as independent.
This avoids issues in bulk builds where the package version was taking
precedence and causing the wrong user package to be depended upon.
substitutions will not be correct.
Fixes issue with ABI=64 where /usr/lib/amd64 was being exposed, but
packages will need to be rebuilt for the change to take effect.
hierarchy.
This values should be generated from output of some commands,
but I cannot find the rule.
Tested on armel and x86_64 Debian GNU/Linux environment.
The values are shown in http://wiki.debian.org/Multiarch/Tuples .
