On Thu, Aug 22, 2002 at 08:44:04AM -0400, Matt Zimmerman wrote:
> On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote:
> 
> > This terse reply is obviously inappropriate.  If you are annoyed, stop
> > writing.
> 
> No less appropriate than your one-line dismissal of a reasonable and tactful
> response.

So let me get this straight.  You equate "shut up" with a request for
concrete examples.  How unfortunate.

> 
> > I was asking for real examples in order to discuss how the case of bind
> > and db.root is *not* a member of that set and how there may be a genuine
> > problem with the handling of installing over missing configuration files.
> 
> Are you saying that you think that the situation with this particular
> conffile is different enough, and that there are enough other similar
> conffiles, that it justifies different handling by dpkg?  If so, I think
> that I would disagree.
> 
> In the particular case of BIND, it is entirely reasonable to move the entire
> configuration somewhere else (such as into a chroot) and remove /etc/bind
> and its contents.  It would be confusing to have them reappear when BIND is
> upgraded.

The idea is that db.root is a different kind of file.  Most of the
time, configuration files reflect the personality of the user's
machine.  db.root contains information about the root name servers.  I
would differentiate the presence of this information on a user's
machine with the application of that information.  It has a closer
relationship to terminfo files or the POSIX timezone files than the
global bash rc file.
        
> 
> > As far as I can tell there is no way to pass --force-confmiss to dpkg
> > when using apt-get.  Perhaps this is the only real omission.  
> 
> man 5 apt.conf, search for 'dpkg', 6th match.

That's a global change.  Someone else pointed out that it can be
passed with -o.

> 
> > Still, breaking bind's access to root name servers is particularly
> > troublesome because it may tend to break all net access.  It may be
> > worthwhile to remove db.root from the list of configuration files.
> > Especially, because this list isn't something anyone should need to
> > change.
> 
> The conffile system does nothing to break BIND's access to root nameservers;
> this only happens if an administrator explicitly removes db.root.  If this
> was an accident, they need to reinstall with --force-confmiss.  If not, then
> their change is preserved as it should be.  What purpose would be served by
> making db.root not a conffile?

Albeit, this isn't a grave consideration, but one that make repairing
a broken name server a little easier.  Because --force-confmiss isn't
a very desirable switch to use, because there is no compelling reason
to keep db.root a configuration file, and because making this change
would make restoring a missing db.root simple it seems that real
question is qhy not?.


Reply via email to