[Please excuse my terseness. I'm learning the Dvorak keyboard and this makes me economize my words even more than usual.]
On Wed, Jul 24, 2002 at 12:36:59PM -0500, Branden Robinson wrote: > On Wed, Jul 24, 2002 at 10:20:06AM -0700, Matt Kraai wrote: > > On Wed, Jul 24, 2002 at 12:53:50PM -0400, Simon Law wrote: > > > What do you guys think? It seems to me that it should be a > > > pretty reasonable thing to push into the next upload. > > > > The clients are not interchangable, as they have different > > interfaces (see #113620). etherconf should depend on an > > alternative of the clients it supports. > > Your reasoning is backwards. x-terminal-emulators and > mail-tranfer-agents aren't interchangeable either, and have different > command line interfaces or configuration file formats. A lot of the > time, though, that simply doesn't matter. > > The correct solution IMO is to have the virtual package and define a > baseline set of functionality if necessary. Packages with more specific > requirements of a DCHP client can depend only on the clients they > support. Packages that require little of, and are truly agnostic about, > the DHCP client should not have to enumerate every DHCP client in the > distribution in their dependency information. Otherwise everyone who > depends on a DHCP client has to rev their package when a new DCHP client > is added to the distro. > > 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. > #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. Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
