Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
Christoph Anton Mitterer <firstname.lastname@example.org> writes:
> On Sun, 2012-08-19 at 19:41 +0200, Marco d'Itri wrote:
>> NM, as a design goal, is not supposed to be able to manage every
>> possible configuration.
> Well but then it shouldn't be kind of a default package.
No it shouldn't. And it isn't either. gnome-core is not default.
> And yes, I
> know, strictly speaking it's neither required nor essential.
> But as I mentioned before, more and more uses it... and one usually
> get's it already with gnome-core.
Except for GNOME, what other unrelated packages depends on NM?
The GNOME dependencies are deliberately broken to bring in as much cruft
as possible, but GNOME is neither required nor default so what's the
problem? Why do you install gnome-core if you don't want the resulting
> And to be honest, I don't think that it's impossible that NM would
> integrate well with ifupdown (and the others).
I believe it already does. Any problems with this integration should be
reported as bugs.
Neither NM nor ifupdown is currently capable of dealing with every
possible networking setup (NM fails on complex static configurations,
ifupdown fails on dynamic stateful configurations). And I expect this
is how it will be for the foreseeable future. At least that's how I
understand the current scopes of those packages.
Debian need *both*, and any efforts in this area should be put into
making them interoperate.
Never mind wireless lan where you've got a well defined kernel API. Try
to configure a modern 3G/LTE modem using ifupdown, and you will see the
usefulness of a framework like NM and it's companion ModemManager. Yes,
there are of course bugs and missing features. But let's fix them then.
NM upstream is very active and easy to co-operate with.
And before someone asks: There won't be any "standard wireless
extensions" for wan connections. That sort of thing is just not
considered appropriate for the kernel anymore. Drivers export the device
native control channel(s), and leave the rest of the job for userspace
libraries. This means that you will need something like ModemManager,
oFono or similar to provide a common device independent application