coda/lwp may be built and run. "lwp" needs custom pmap handling in assy
language. Only "lwp" is needed to build and run a coda server; client's
also need to have the MI CODA filesystem enabled. In fact, it seems
that sparc64 has the CODA file system even the assembler in "lwp" is
only for sparc, and mac68k is the only m68k port with the CODA filesystem,
but such would be cumbersome to express with the present framework.
that depend it, as suggested by wrstuden. The reason is so that older
binary packages which were linked against an a.out shared lib won't have
their package dependencies satisfied by the latest package, which has no
shared libraries. There's no help for old ELF packages, unfortunately.
from the middle of root-install until the end of fake-pkg target. At
the end of the fake-pkg target, the package has been registered using
pkg_create(1), and so it's possible to use relational comparisons of
the version numbers, thereby making it possible to use the information
from the standard vulnerabilities file.
This addresses PR 11077.
but since none of the NetBSD packages which link in xforms seem to
use the gl_{get,set}_canvas*() and gl_win*() functions, simply extend
the present ELF hack to a.out, for now. That is, disable the shared
{,x}forms library the hard way, by deleting it after installation.
It stinks, I know. Close PR pkg/10560.
odd numbers for 'development' versions...
lintpkgsrc:
Rename set_pkgsrcdir to parse_mk_conf, and also extract PACKAGES as well
as PKGSRCDIR. Update check_prebuilt_packages to handle the new package data
structure that allos mulitple versions of the same package to be valid
(for -current packages etc) - Missed in previous changes.
can either be defined or not. This governs the installation of the
floppyd binary in the mtools package. The floppyd program needs
the SM and ICE libs from the X11 distribution to link (floppyd's
authorisation model to enable remote access to floppy drives closely
resembles that of X11's xauth model). Modify the mtools Makefile
accordingly.
I wonder if we couldn't automate this a bit by searching for -L in all
patch files and giving an alarm if there's no -Wl,-R nearby ...
Might be something for pkglint.
* pull comments from head of patch files into the files they patch
That way they don't get overwritten, don't need manual work to be
included in the next update, and are visible in the patched files.
