Re: Testing netapplet
Update: netapplet is now in sid.
Matthew Garrett wrote:
> (snip: netapplet is broken with interesting Debian network setups)
>
> Yes, it is.
That is a problem. Configuration tools should not break when they
encounter configurations that they do not understand.
An example of a reasonably well written configuration tool is
Libranet's adminmenu. When you click on "Edit network configuration"
it immediately displays a warning:
This program modifies the system network configuration
files. If you edit these files manually this program may
behave unexpectedly.
This program cannot work with logical interface names that are
different from physical interface names and cannot work with
physical interface names other than the default ones ('eth0', etc.)
Thus when it starts it sees no interfaces configured. However,
and this is the important part: my non-standard configuration does
not cause the program to display garbage and when I play around
with the program it always reports errors and refuses to overwrite
my existing configuration. Good.
It would be _nice_ if configuration tools supported the advanced
features of ifupdown, but so long as they don't they should,
as adminmenu, refrain from doing damage.
> It also entirely fails to deal with anything that uses the
> crack-addled mapping format. The debian networking infrastructure
> currently fails to provide information that sensibly maps into
> anything to do with reality. The interaction between it and stuff
> like guessnet is a prime example of this - without parsing the
> guessnet configuration, you have no idea how to relate the
> interfaces provided to anything sane.
All I can infer from this paragraph is that you don't like ifupdown,
possibly because you do not understand how it works.
In mapping, ifupdown calls an external program that makes the decision
about which interface definition to choose for a given physical
interface to be brought up. A front end for ifup/ifdown (which is
what I gather netapplet is supposed to be) either uses mapping
(if it does "ifup IFACE") or overrides mapping (if it does
"ifup IFACE=LIFACE"); it does not need to know how the external
program does the mapping. All the information needed by the front
end is available. E.g., to find out how a physical interface is
currently configured the program can look in /etc/network/ifstate.
> There's no clearly defined way of expressing who enacts policy
> over /etc/network/interfaces at present.
I don't know what you mean by this. What kind of policy would
you like to see?
> Until that's fixed, expecting other applications to deal with
> it is utterly insane.
Hopefully we can address the "undefined policy enactment way" problem
you complain about.
Of course, even if we do address it, no one can "expect" you to do
anything. There are no bosses in Debian. You are free to maintain
your dismissive attitude. And thanks to the wonderful institution of
package ownership you are in a position to ensure that netapplet never
supports ifupdown fully. That's fun for you but it is also the reason
why there is a role for redistributors: they distribute subsets of the
archive consisting of packages that do work well together.
--
Thomas Hood
Reply to: