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. :) > > 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. > > #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? -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant | D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]