On Sun, Jul 28, 2002 at 12:27:38PM +0100, Mark Brown wrote: > I wouldn't say so. For example, a C compiler ought to provide > /usr/bin/cc in some form or another,
You're talking about an alternative for /usr/bin/cc. A thing that compiles C source code into object files is a C compiler regardless of where its binary lives or what it's called. > a mail transport agent ought to provide a /usr/sbin/sendmail > implementation Only if policy says so. In and of itself this isn't a requirement mandated by the fact that "Provides: mail-transport-agent" is in a package's control data. > and a web server ought to serve things out of /var/www by default. Purely an FHS issue. A web server is a thing that speaks HTTP over a network interface (which may be virtualized). By the way, the virtual package name for a web server is "httpd". > Other virtual packages appear to be more about ensuring that only one > package tries to use a given resource at one time. There's no fundamental reason you couldn't have multiple MTAs listening on different ports, or different web servers on different ports. I don't think that is possible in the former case due to /usr/sbin/sendmail, but that's something we decided to do and not an inherent restriction imposed by the MTAs themselves. I suggest folks simply read Policy 7.4 and understand virtual packages for what they are: no less, and *no more*. However, I give up. Unless the maintainers of the various and sundry DHCP client packages in Debian decide to cooperate there's no way that #154142 can be solved in a way that makes both the submitter and the maintainer happy. Every time a new DHCP client is packaged for Debian a bug will have to be filed against etherconf wailing that some person's favorite DHCP client is unfairly discriminated against. (And worse, when a DCHP client package dies, etherconf will refer to a nonexistent one.) The package's Depends: line will get longer and longer for no particularly good reason, except that some folks have these mystical notions about what a virtual package is good for. I expect you to be calling for the removal of a great many virtual packages listed in /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz, because they define an insufficiently strict interface. "pdf-viewer" for instance. What possible good is that? It doesn't tell you what it's called or what options to give it! It doesn't even say if you feed the "pdf-viewer" input on standard in or if it takes the input as argument on its command line! And Lord knows we have to be sure that only one "pdf-viewer" is installed at a time; there are precious resources that are monopolized by such tools. We need to be enhancing the user experience in Debian by doing away with these meaningless virtual packages! -- G. Branden Robinson | Somebody once asked me if I thought Debian GNU/Linux | sex was dirty. I said, "It is if [EMAIL PROTECTED] | you're doing it right." http://people.debian.org/~branden/ | -- Woody Allen
pgpByEzsDh7yI.pgp
Description: PGP signature
