About shells/services automatic changes

[Julio Merino <jmmv84%gmail.com@localhost>]

Hello,

During the last few days, I've been working on a "etcutils" package
that contains a couple of scripts: services(8) and shells(8) which, as
you can deduce from the name, provide a programmatic way to modify the
services(5) and shells(5) databases respectively.  If you are
wondering: these are plain shell scripts; no dependencies required.

The idea behind creating these standalone scripts is to remove logic
from the package install scripts to modify shells(5) and to add, to
the pkginstall framework, support to update services(5) automatically.
 (Actually, this all started with my desire to allow FAM to register
its service automatically into /etc/services.  But then I thought I
could also extend this to /etc/shells.)

Why do I want to remove logic from package install scripts?

* The package install scripts are ugly.  It's hard to follow them.  I
don't want to think of adding any robust mechanism to update
more-complex files such as services(5) in them.
* Keeping the code out of the package install scripts means that a
machine has a single copy that comes from a single package.
Security-concerned administrators can review this single copy once,
and then have less work in reviewing the actions of the package
install scripts (because they will be shorter/simpler).
* Having the logic in a standalone tool means that administrators can
also manually make use of this functionality :-)
* Easier to test.  I have a good set of automated tests for this new
etcutils package.  I'm kinda scared to even think about how to write
these against the pkgsrc scripts.

Here is my plan:

1) Release etcutils.
2) Import etcutils into pkgsrc.
3) Let people test the tools for a couple of days, if they want.
4) Update the pkginstall shells script to use these tools.  (Yup, this
means shell packages depend on etcutils.)
5) Add new pkginstall functionality to deal with /etc/services.
6) Swipe over pkgsrc to remove all manual handling of /etc/services
and use the new frameworky stuff.  (There are not that many
instances.)

The only point that may raise concern is 4.  1-3 do not affect you at
all if you don't want to, and 5-6 is something good to have but that
will be optional (as all automation in pkgsrc).

Comments?  Thanks!

-- 
Julio Merino