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?.
