Bug#554194: ifupdown virtual package name and mass-filing (if accepted)

[Wouter Verhelst-5]

Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: debian-devel@..., ifupdown@...

Hi all,

As you may or may not know, I've been working on an alternative
implementation of ifup and ifdown, which I call 'ipcfg', for a few
months now[1]. The code is now nearly at the point where I'll be using
it on my own laptop, at which point I intend to upload it to
experimental, too.

Since it intends to be an ifupdown replacement, and indeed provides
ifup and ifdown binaries, it will have to conflict with ifupdown. As a
result, I'll have to make sure that it can be installed as an
alternative to it, by way of a virtual package name.

As such, I'd like to propose the addition of a virtual package name,
"network-config-tool", that would be used for any package which provides
"/sbin/ifup" and "/sbin/ifdown" binaries. If accepted, I will also be
mass-filing wishlist bugs on packages that currently depend on ifupdown
only because they need to be able to use ifup and ifdown, or because
they have a versioned dependency on ifupdown to avoid certain bugs, with
a request to provide a "network-config-tool" alternative.

Thoughts, comments?

[1] The announcement and some more detail can be found at
    http://grep.be/blog/en/computer/code/ipcfg/announce

--
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

[martin f krafft]

also sprach Wouter Verhelst <w@...> [2009.11.03.1915 +0100]:
> As such, I'd like to propose the addition of a virtual package
> name, "network-config-tool", that would be used for any package
> which provides "/sbin/ifup" and "/sbin/ifdown" binaries.

You'll need to be a lot more specific on the interface definition.
Do they have to be binaries? Do they have to take the same flags,
e.g. --force and --all?

What about /etc/network/interfaces and /etc/network/if-*.d/*?
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.

--
 .''`.   martin f. krafft <madduck@...>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems

[Wouter Verhelst]

On Tue, Nov 03, 2009 at 08:02:31PM +0100, martin f krafft wrote:
> also sprach Wouter Verhelst <w@...> [2009.11.03.1915 +0100]:
> > As such, I'd like to propose the addition of a virtual package
> > name, "network-config-tool", that would be used for any package
> > which provides "/sbin/ifup" and "/sbin/ifdown" binaries.
>
> You'll need to be a lot more specific on the interface definition.
> Do they have to be binaries? Do they have to take the same flags,
> e.g. --force and --all?

With 'binaries', I meant 'executables'. Whether they're scripts or
compiled programs doesn't actually matter to me. Sorry for the
confusion.

The goal is indeed for ipcfg to become command-line compatible with
ifupdown, though I'm not there yet.

> What about /etc/network/interfaces and /etc/network/if-*.d/*?

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.

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 ;-)

(occasionally, that's the only reason why it's not been uploaded yet)

> 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.

However, it should also be sensible to change the Depends: line in
isc-dhcp-client from

Depends: (...), ifupdown (>= 0.6.8+nmu3), (...)

to

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.

Of course there are some packages that just don't make sense without
ifupdown, and there it's fine to not add the "network-config-tool"
alternative. One example of this is guessnet; ipcfg has a much more
flexible way of doing what guessnet does (in fact it's a design goal),
and therefore does not have support for ifupdown's "mapping scripts"
that guessnet uses.

--
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

[martin f krafft]

also sprach Wouter Verhelst <wouter@...> [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! ;)

It *is* questionable how mucn /e/n/i is part of the interface
though.

> 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.

> > 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.

> 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.

Cheers,

--
 .''`.   martin f. krafft <madduck@...>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"i love deadlines. i like the whooshing
 sound they make as they fly by."
                                                      -- douglas adams

[Wouter Verhelst-5]

On Wed, Nov 04, 2009 at 10:52:00AM +0100, martin f krafft wrote:

> also sprach Wouter Verhelst <wouter@...> [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

[martin f krafft]

also sprach Wouter Verhelst <w@...> [2009.11.04.1906 +0100]:

> 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.

I don't think we need to cater for people parsing --verbose output.

--
 .''`.   martin f. krafft <madduck@...>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"distrust all those who love you extremely
 upon a very slight acquaintance and without any visible reason."
                                                  -- lord chesterfield