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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
