Ondřej Surý <ond...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wql5tiph....@windlord.stanford.edu
