> Because of this `mirror' of information, point 6 is needed to keep the two
> configurations in sync.

I haven't been following this well, so please ignore me if I'm going over 
old ground.  I appologize in advance and hope this will be helpful.

Here's my real question:  the purpose of rc.conf.d is to permit heavy-fisted 
editing by the pkg system.  Under your plan, 'virc -s' guarantees a successful 
unattended merge of these changes into the rc.conf text file.  bsd.pkg.mk 
will presumably call 'virc -s' immediately after a heavy-fisted change.

So, why bother?  Why not make 'virc -s' part of the pkg system?  If you can 
write a '-s' tool that works, you have completely eliminated the reason 
people wanted the separate files in the first place.

Does '-s' actually work?  It must use magic comments to separate sections 
of rc.conf, or something like that, right?  Just as effectively, rc.conf 
might be written in a grammar more restrictive than a shell script that 
enforces sectioning and thus attributes each changeable region to a named tool 
or rc.conf.d file.  grammars conducive simultaneously to machines and humans 
are readily devisable, and it sounds like you've already made one to get 
virc working.

If you can do this, wouldn't it work just as well to write a 'virc' tool that 
exports the necessary heavy-handed filesystem operations to the pkg system 
as needed?  You can even give them the same names if that makes you feel warm 
and fuzzy:

  virc cat \> fooconfig            -> create or overwrite conf.d file
  virc cat fooconfig               -> copy out fooconfig
  virc rm fooconfig                -> delete conf.d file
  virc lock/unlock fooconfig       -> to make multiple calls to virc atomic

How is this different from editing real files in the filesystem, and then
calling 'virc -s'?  Of course, virc could do more, like tweak individual
variable names--common domain-specific tweaks that the pkg system would
have to do with sed and awk in the rc.conf.d plan.

It seems to me better to put the damned machine behind a Layer of Abstraction 
and Isolation, not the user.


CVS and Coda have shown that merging two independently changed copies of 
something together is necessarily ambiguous, and requires manual intervention 
to happen sanely.  The normal solution to this is, ``never copy information.''
master.passwd is a carefully-controlled exception.  virc may evolve as 
another exception, but its task is more difficult, as the following analogies 
show.

   master.passwd      ::      rc.conf.d      (authoritative.)
   spwd.db, pwd.db    ::      rc.conf        (copy.  authoritative->copy is 
                                              guaranteed successful, just 
                                              like 'make' dependency tree)

   virc -s            ::      vipw      -> propogates information forward 
                                           from the authoritative source
   virc               ::      chpass    -> always updates master.passwd 
                                           after editing the copy

virc is a lot harder to pull off than chpass, because chpass has one isolated 
machine-originated database transaction, and virc lets you edit rc.conf so it 
must be able to deal with any change to a free-form text file.

I thought about this proposed virc scheme and wrote a much longer earlier 
draft email about it, but the main points now seem to be:

  o it sounds really cool.
  o it sounds like it does everything it needs to.
  o it sounds like it does a lot more than it needs to, for foolish 
    linguistic and political reasons.