Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Mon, Jan 18, 2010 at 01:56:17AM -0800, Steve Langasek wrote:
> On Sat, Jan 16, 2010 at 03:31:28PM +0100, Wouter Verhelst wrote:
> > There was no further discussion on this item since the above date.
>
> FWIW, I for one hadn't commented up to now because I find that
> fundamentally, implementing a compatible commandline interface for
> ifup/ifdown and not implementing support for /etc/network/interfaces is
> precisely backwards, and I was waiting to see if anyone else would speak to
> this point.
>
> AFAICS, there are only two places in the system where other packages
> integrate by calling ifup/ifdown: /etc/init.d/networking, and
> /lib/udev/net.agent. The former ought to be all but obsoleted by the latter
> (N.B.: "should", but isn't), and the latter could just as well be moved to
> the ifupdown package itself and a corresponding agent be provided by any
> conflicting packages.
Indeed. In fact, I had assumed that that initscript was, indeed, part of
the ifupdown package; so much so, in fact, that I hadn't even checked.
Thanks for pointing that out.
> So the commandline ifup/ifdown interface is of little relevance, whereas the
> configuration state contained in /etc/network/interfaces is of vital
> importance to the operation of the system and I would expect anyone trying
> to replace ifupdown to handle this critical configuration migration issue.
It's a fair point, but one I happen not to agree with.
As an example, ifplugd has a default configuration that calls 'ifup'
when it discovers that the MII reports a link. I think this is a valid
case of something using the 'ifup' binary, and not something that needs
to be migrated away (at least not until the daemon functionality of
ipcfg has been implemented, which might take a while). That's a third
example (added to your two above); I'm sure there are more. I think the
use of ifup/ifdown as an interface to manage network interfaces (no pun
intended) is more widespread than you seem to believe.
Second, the main reason I chose not to support the
/etc/network/interfaces at this phase is that I believe it is
fundamentally limited in what it can support: it makes the assumption
that whenver the user calls 'ifup <something>', we already know which
interfaces we're going to be configuring. I specifically do not wish to
support that assumption. Now of course I could extend the interfaces
format to allow this, but I'm afraid that's going to be kludgy at best.
That's why I started off with a different file format.
Of course upgradeability is a major cause for concern, and if ipcfg is
ever going to replace ifupdown then at one point or another I'll have to
deal with this issue. I'm not sure yet how I'll be doing that; it could
be by way of a perl script to convert an interfaces file to an ipcfg
config file, or it could be by way of an alternate parser. It's not
something I want to deal with now, however -- first things first; while
it's in experimental now, I don't think it'll be ready for unstable in
time for squeeze -- I'd even be surprised if it was ready for prime time
in time for squeeze+1.
Third, I do not see any good reason why any configuration file format
should be part of a described interface. If another software package
wishes to do something with network interfaces consistently with ifup's
configuration, then that package should not try to read ifup's config
file -- it should be calling ifup with the necessary parameters to
accomplish what it needs to do. We might need to extend the interface to
allow querying of available configuration to allow this better, but
that's about it. If another package wishes to write ifup's configuration
file, then either it is doing something utterly wrong and against
policy, or it is a user configuration agent that needs to know much
about the inner workings of the particular ifup implementation it is
working for anyway, and has no business depending on a virtual package.
Regards,
--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
Reply to: