NetBSD Foundation Membership still pending.) This stack was written by
Iain under sponsorship from Itronix Inc.
The stack includes support for rfcomm networking (networking via your
bluetooth enabled cell phone), hid devices (keyboards/mice), and headsets.
Drivers for both PCMCIA and USB bluetooth controllers are included.
like this, where a user may well want to install one of these but not the
other.
To allow syspkg to be used for its intended purpose here, carefully split
out ipfilter and pf from the main {base,comp,man,misc}-net{,util}-* packages
(something which was partially done for ipf, but not done for pf in the
past).
This way, a user can pkg_delete *-{ipf,pf}-*, and not have utilities,
libraries, man pages, examples, or default /etc files for the packet filter
they don't like.
a file that has end-user configuration to be unconditionally removed.
Instead, remove the entry from the set list, and add a note to UPDATING
reminding users of MKUPDATE=yes to manually rectify the problem in
their DESTDIR.
The "named" fix in postinstall(8) will migrate /etc/namedb/named.conf
to /etc/named.conf if the latter doesn't exist.
(The need for these style of migrations was why I implemented postinstall(8)
in the first place.)
named(8) looks for it. You can now really get a caching name server
by simply setting "named=yes" in "/etc/rc.conf" as documented in
The NetBSD Guide. This fixes PR bin/30662 by Christian Hattemer.
appeared and whether it's really part of pf or not is still unclear. Looking
at the other *BSDs it seems that they have left out spamd when importing pf,
and now we do that too. Also, the name conflicted with another more popular
used tool, after the rename to pfspamd it was left with completely unusable
documentation which apparently no-one wanted to fix.
A port of the latest spamd will be imported into pkgsrc soon.
Suggested by several people, no objections on last proposal on tech-userlevel.
headers and LKM.
Add MKPF; if set to no, don't build and install the pf(4) programs,
headers, LKM and spamd.
Both options default to yes, so nothing changed in the default build.
Reviewed by lukem.
in src/Makefile installs it (thus, being more consistent).
Should fix "./build.sh install=/" installation of /etc/release.
Requested by Hubert Feyrer (amongst others).
Hopefully I didn't make too much of a hash of the postinstall support for
this; it currently installs the file if there's none in the destination,
and elsewise notes if the CVS version differs (or is missing) but doesn't
try to fix that.
* Add an optional third field to the sets file which is a list of
comma separated keywords that control if the line is printed.
Currently supported keywords
kerberos4 ${MKKERBEROS4} != no
kerberos ${MKKERBEROS} != no
lint ${MKLINT} != no
obsolete ${obsolete} != 0.
In this case, non obsolete files are not printed.
(This will allow future support for builds with variables such as
MKHESIOD and MKYP set to "no".)
* Use sh(1)'s getopts where appropriate, and otherwise cleanup the
various scripts.
* Move defaults for sets.subr from sets.defaults into sets.subr.
Move replicated code for determining stuff such as shlibs type
from various scripts into sets.subr.
* Merge the obsolete.*, krb.*, krb4.* and lint.* into the appropriate
main lists with the relevant third field keyword(s).
isn't enabled.
This is how the rc.d system works in conjunction with our current build
and install system; all the rc.d scripts are installed even if the
subsystems they control are not.
and without Kerberos 4 & 5 (MKKERBEROS=no). Previously checkflist
complained of missing files.
* move kerberos- and kerberos 4-only files into new flists,
distrib/sets/lists/*/krb.*
* make the flist generators grok MKKERBEROS{,4} variables
* fix Makefiles which treat MKKERBEROS=no as MKKERBEROS5=no.
9 out of 10 experts agree that it is ludicrous to build w/
KERBEROS4 and w/o KERBEROS5.
* fix header files, also, which treat MKKERBEROS=no as MKKERBEROS5=no.
* omit some Kerberos-only subdirectories from the build as
MKKERBEROS{,4} indicate
(I acknowledge the sentiment that flists are the wrong way to go,
and that the makefiles should produce the metalog directly. That
sounds to me like the right way to go, but I am not prepared to do
revamp all the makefiles. While my approach is expedient, it fits
painlessly within the current build architecture until we are
delivered from flist purgatory, and it does not postpone our
delivery. Fair enough?)
