Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Sun, 28 Jul 2002, Branden Robinson <branden@debian.org> 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.
Ummm.....if a C compiler doesn't support a /usr/bin/cc which supports -o
and -c, it shouldn't "Provide: c-compiler"
> > 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.
Policy refers to the FHS, and the FHS says "sendmail or compatible programs
should provide /u/s/sm [and symlink deprecated /u/l/sm to it]".
> There's no fundamental reason you couldn't have multiple MTAs listening
> on different ports
Being an MTA has nothing to do with listening on port 25, and everything
to do with supplying a /u/s/sm
> "pdf-viewer" for instance. What possible good is that? It doesn't tell
> you what it's called or what options to give it!
You don't need to: you can get that information out of the MIME support
it has to include. If a PDF viewer does not supply PDF mime support, it
should not provide the virtual package.
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: