On Sun, 28 Jul 2002, Branden Robinson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
