Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)
Ondřej Surý <ondrej@sury.org> writes:
> On Tue, Oct 22, 2013, at 16:29, Simon McVittie wrote:
>> On 22/10/13 14:43, Ondřej Surý wrote:
>>> The proposed names are:
>>> authoritative-name-server - authoritative domain name server
>>> recursive-name-server - recursive domain name server
>>> Any objections?
>> If you depend on one of these, what functionality can you rely on
>> having "out of the box"? What packages do you expect to benefit from
>> having these virtual packages to depend on?
> Break free from the technical aspect of resolving dependencies. The
> virtual package name can be useful for people wanting to install
> authoritative name server, so they get a list of package that provide
> the functionality.
I don't think that's a good idea for the authoritative DNS server. That
sort of application seems better handled through debtags.
The purpose of a virtual package is to satisfy a dependency, which means
it needs to provide some piece of functionality via a standard interface
so that any package that depends (or recommends, etc.) on it knows that,
when it is installed, it can be used according to that interface.
mail-transport-agent is the canonical example, with the requirements of
that interface spelled out in Policy.
While I wouldn't want to reject any virtual package that isn't documented
in Policy, my ideal would be for any virtual package used across the
archive (as opposed to among a cooperating set of packages) to be able to
document the interface provided to the same level of formality that
mail-transport-agent is documented.
This is possible for recursive-name-server. You can say that, if
installed, it provides a service on UDP (and TCP? you should say, since
it has implications for what packages can provide this virtual package)
port 53 to at least localhost that's capable of resolving DNS names from
either (by default) the root DNS servers or from locally-configured roots.
However, an authoritative DNS server serves a zone, and the configuration
of that zone has to be part of the interface for a virtual package to be
meaningful. The only reason I can think of for a package to depend on an
authoritative DNS server is if it needs to publish DNS names, and to do
that it needs to know where to put the zone files, which means that a
virtual package specification would require a standardized location and
format for zone files. While you could do that if you wished, I think
that's going to be quite a lot of work and of dubious benefit,
particularly since I think packages that want to publish things in DNS are
rare and also a little dubious. (If anything should stay under the
control of the local system administrator, it's the contents of their DNS
zone.)
Accordingly, I agree in theory with the virtual package for the recursive
DNS server, although it would be ideal if we could document the
specification in Policy at the same time. But I don't think the virtual
package for an authoritative DNS server makes much sense. If you just
want to make it easier for users to find an authoritative DNS server to
install, debtags seems like a reasonable solution to that problem.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: