On Wed, Jul 24, 2002 at 01:09:22PM -0500, Branden Robinson wrote: > On Wed, Jul 24, 2002 at 11:07:02AM -0700, Matt Kraai wrote: > > [Please excuse my terseness. I'm learning the Dvorak keyboard > > and this makes me economize my words even more than usual.] > > So come back to the QWERTY dark side. Quicker, easier. :)
No kidding. > > > If we handle dhcp-client as we do other virtual packages, the specific > > > knowledge is expressed where it is needed (i.e., "my package can use > > > udhcpc and nothing else" ), and not everywhere *except* where it's > > > needed. > > > > This compatibility does not currently exist. udhcpc, for > > instance, will by default not exit unsuccessfully if it fails to > > obtain a lease. Other clients use a different option to control > > this, or do it by default. Similarly for choosing which > > interface to configure. > > It's my contention that for the purposes of a virtual package, this > simply doesn't matter. postfix, sendmail, and exim exhibit different > behaviors as well; that doesn't make them non-mail-transfer-agents. > > Perhaps you're thinking of alternatives, where command-line > compatibility -- at least to some defined extent -- is required. But they do provide (at least some) command-line compatibility, /usr/lib/sendmail. > > > #113620 has little to do with this. ifupdown declares no dependency on > > > any DHCP client. That it did not properly support udhcpc has nothing to > > > do with package dependencies and thus nothing to do with virtual > > > packages. > > > > I was citing it as an example of how widely the interfaces > > differ, not of how the dependencies should be handled. > > So you have no objection to a dhcp-client virtual package, then? Suppose `Provides: dhcp-client' is added to udhcpc. Does it also need to provide a script, /sbin/dhcp-client, which invokes udhcpc with the correct options, and conflict with the other DHCP clients? Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
