INSTALLATION_DIRS, as well as all occurrences of ${PREFIX}/man with
${PREFIX}/${PKGMANDIR}.
Fixes PR 35265, although I did not use the patch provided therein.
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.
And always is defined as share/examples/rc.d
which was the default before.
This rc.d scripts are not automatically added to PLISTs now also.
So add to each corresponding PLIST as required.
This was discussed on tech-pkg in late January and late April.
Todo: remove the RCD_SCRIPTS_EXAMPLEDIR uses in MESSAGES and elsewhere
and remove the RCD_SCRIPTS_EXAMPLEDIR itself.
under share/examples/rc.d. The variable name already was named
RCD_SCRIPTS_EXAMPLEDIR.
This is from ideas from Greg Woods and others.
Also bumped PKGREVISION for all packages using RCD_SCRIPTS mechanism
(as requested by wiz).
The wrapper will correctly set the CPP environment variable to a
stat((2)able path to a C preprocessor, then rely on the PATH to
find and invoke the real rpcgen.
Remove NO_EXPORT_CPP in package Makefiles where it was used just to
avoid problems with rpcgen. The build system now just does the right
thing automatically without needing package-specific knowledge.
This fixes PR pkg/27272.
the RCD_SCRIPTS rc.d script(s) to the PLIST.
This GENERATE_PLIST idea is part of Greg A. Woods'
PR #22954.
This helps when the RC_SCRIPTS are installed to
a different ${RCD_SCRIPTS_EXAMPLEDIR}. (Later,
the default RCD_SCRIPTS_EXAMPLEDIR will be changed
to be more clear that they are the examples.)
These patches also remove the etc/rc.d/ scripts from PLISTs
(of packages that use RCD_SCRIPTS). (This also removes
now unused references from openssh* makefiles. Note that
qmail package has not been changed yet.)
I have been doing automatic PLIST registration for RC_SCRIPTS
for over a year. Not all of these packages have been tested,
but many have been tested and used.
Somethings maybe to do:
- a few packages still manually install the rc.d scripts to
hard-coded etc/rc.d. These need to be fixed.
- maybe remove from mk/${OPSYS}.pkg.dist mtree specifications too.
* Use NetBSD's getpass() function instead of the homegrown one, as the
homegrown one doesn't seem to hide the password when it is being entered.
* Add a rc.d style script to start cfsd, and also install the documentation
for the filesystem.
* Rename c* commands to cfs_* to avoid conflicts with coda programs with
a similar name.
homegrown one doesn't seem to hide the password when it is being entered.
* Add a rc.d style script to start cfsd, and also install the documentation
for the filesystem.
* Rename c* commands to cfs_* to avoid conflicts with coda programs with
a similar name.
CFS pushes encryption services into the UN*X file system. It supports
secure storage at the system level through a standard UN*X file system
interface to encrypted files. Users associate a cryptographic key with the
directories they wish to protect. Files in these directories (as well as
their pathname components) are transparently encrypted and decrypted with
the specified key without further user intervention; cleartext is never
stored on a disk or sent to a remote file server. CFS employs a novel
combination of DES stream and codebook cipher modes to provide high
security with good performance on a modern workstation. CFS can use any
available file system for its underlying storage without modification,
including remote file servers such as NFS. System management functions,
such as file backup, work in a normal manner and without knowledge of the
key.
packages collection.
CFS is an encrypting file system for Unix-like OSs. It uses NFS as
its interface, and so is reasonably portable. The FS code dates back
to 1989, and the crypto to 1992, so it is showing signs of age. This
code should be regarded as completely unsupported; a complete rewrite
will follow eventually.
Please don't download this code if you're in a place that's forbidden
(under US or local law) to export cryptographic software from the US
to, or if you're on the State Department's "Denied Persons List." If
you aren't sure, ask a good lawyer.
