On Wed, Nov 04, 2009 at 10:52:00AM +0100, martin f krafft wrote: > also sprach Wouter Verhelst <wouter@debian.org> [2009.11.04.0230 +0100]: > > Since to me the point of this exercise is so that I can usefully > > put ipcfg into the archive, and since ipcfg does not actually > > support /etc/network/interfaces, I'd say that should not be part > > of the interface. > > Hehe, but interface definitions usually describe the status quo from > the users' perspective, not the state of development of a new tool > aiming interface compatibility. > > Gosh, I wish the ISO 9000 specs worked that way! ;) That'd be nice, wouldn't it? ;-) > It *is* questionable how mucn /e/n/i is part of the interface though. Indeed, and that's really my main point. I could also have said that I don't want to be command-line compatible because it's too much work, but it's *not* questionable how much *that* is part of the interface, so yes, that I do intend to be compatbile with. A config file format is something else; and since, first, Debian packages are not supposed to modify eachother's configuration files; and, second, ifupdown makes the relevant values in its configuration file available through environment variables (so that ifupdown plugins don't have to parse the ifupdown config file), I think it's not unreasonable to make the config file format not part of the interface. Since that would make it easier for me (I'm not aiming for ifupdown config file compatibility, at all), I'd prefer it that way. Of course we could define an interface that requires things to be drop-in replacements for ifupdown, but then I can't use it, and I don't think there's much point in defining a virtual package that ifupdown (and ifupdown alone) could put in its "Provides:" header. Instead, what I'm trying to accomplish is to come up with an interface that can be used by packages which want to mangle the state of network interfaces without actually caring much about how, specifically, it's done. Since I don't think it can be said that you don't care about that if you care about a config file format, I think it's fair to exclude that from this interface. > > I do have code to support /etc/network/if-*.d/*, though I consider > > that a temporary hack so that the code would be useful sooner > > rather than later. It also doesn't work yet ;-) > > Okay. I definitely think the hooks are part of the interface that we > need to support in any network configuration tool. I'm not sure I fully agree with that, but since the code is there, and since it's a plugin that can be disabled, I don't actually care all that much about the issue. So yeah, that can be kept in for all I care :-) > > > Especially the hooks are integral to a lot of other packages that > > > depend on ifupdown. I'd say that's part of any Debian > > > "network-config-tool" interface. > > > > Basically, the interface that I'd like to see is "tool that can bring up > > a given interface as configured by the user". E.g., if ifplugd calls > > "ifup eth0", it should not care which implementation of ifup is being > > called to actually bring the interface up. > > Yes. But there are tools that will call it with --verbose, or with > --all. I think we agree anyway. Supporting --all should not be hard. Basically, I just need to map --all to "ifup auto" or "ifdown all" internally. That's a no-brainer. Supporting --verbose might be a different issue, and depending on how it's used, might be a bad idea to support from ipcfg. If the --verbose output is just used to log stuff or give a user more information, then that doesn't matter, and I intend to have a --verbose output option, anyhow. If these commands are parsed and executed somewhere else, it might be possible to make sure the --verbose option does some output that these tools can parse, too, but it's an edge case. If the tools try to parse that information to figure out how to bring an interface down again later or some such, then they're really exploiting the fact that ifupdown exposes much about its internals, and it might be said that the statement that they "don't care about how it's done" is no longer true for these tools. > > Depends: (...), ifupdown (>= 0.6.8+nmu3) | network-config-tool, (...) > > > > because this is a matter of "we need at least this version of ifupdown > > to work properly" rather than "we absolutely need ifupdown"; after all, > > it's ifupdown or ipcfg that calls dhclient, not the other way around. > > That does seem weird and should not be needed, indeed. Actually, I think Andrew should have made that a versioned Conflicts: rather than a versioned Depends:. I vaguely remember him blogging about ISC DHCP4 not working properly with ifupdown and that the latter needed patches. I guess this version is the first one where these patches are included. -- 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
Attachment:
signature.asc
Description: Digital signature