Subject: Re: Posible virc(8) implementation
To: Scott Aaron Bamford <firstname.lastname@example.org>
From: Miles Nordin <carton@Ivy.NET>
Date: 05/03/2000 18:31:45
> 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
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
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
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.