Re: Bug#154142: dhcp-client conflicts
[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 debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: