Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Sun, Jul 28, 2002 at 12:57:19PM -0500, Branden Robinson wrote:
> On Sun, Jul 28, 2002 at 12:27:38PM +0100, Mark Brown wrote:
> > 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.
Yet irrespective of policy any package not providing /usr/sbin/sendmail
and claiming to be a mail-transport-agent is going to break a fair chunk
of the packages which declare a dependency on that virtual package since
they declare the dependency because they need to use that interface.
This is one of the reasons why we specify what a package must do to be
considered a mail-transport-agent.
> There's no fundamental reason you couldn't have multiple MTAs listening
> on different ports, or different web servers on different ports. I
I agree. I think it would be a good thing if this were well supported
by the packages providing servers.
> I suggest folks simply read Policy 7.4 and understand virtual packages
> for what they are: no less, and *no more*.
I've read it before, I've just re-read it and I still don't see why
you'd want to be having packages satisfy dpkg dependencies when they
don't satisfy the actual dependencies.
> 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,
You still have this problem every time a package implements this virtual
package with a new interface.
> 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.
It's more mystical notions about what the dependency information we
provide for packages is good for.
> "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
If you were to really push for something I'd suggest that the interface
a pdf-viewer should provide is that we normally use for handling MIME
but that's not really the point and doesn't apply to a lot of the other
virtual packages. These are like news-reader where the idea appears to
be that a user will use the package for themselves ("This package will
be pretty useless unless you can view PDFs - I suggest you have a PDF
viewer installed"). I'm rather ambivalent about the usefulness of this
given the difficulty in implementing user interfaces for suggests and
recommends but that's another matter. dhcp-client really doesn't seem
like it's going to be used like that - the context that sparked its
request certainly isn't one where that's the case.
It's not about asking for publication ready standards documents for
virtual packages. Adding "supported by ifupdown" as was suggested would
do everything that's being asked for if it's how dhcp-client is supposed
to be used.
Having said all that, given the enthusiasm with which your formal
proposal has been greeted I guess I'm just misunderstanding why we have
dependencies.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: