Control: reassign -1 ifupdown 0.8.35
Hello,
On Fri, Sep 27, 2019 at 11:21:51AM +0300, sergio wrote:
> On 27/09/2019 11:15, Luca Boccassi wrote:
>
> > why the reassignment from bridge-utils to iproute2
>
> bridge-utils already provides if-{pre|post}-up.d/bridge and iproute2
> does not.
I'm going to reassign this back to where it originally came from,
ifupdown.
My opinions is that bridge-utils is deprecated and should eventually
get removed. (The sooner the better.)
As previously suggested bridge-utils /could/ ports its ifupdown hooks
over to use iproute2, but as I'm personally not a fan of micro-packaging
keeping the bridge-utils package around simply for the ifupdown hooks
does not sound like a good plan to me. (The current hooks
implementations also seems to have limitations that one might want to
adress in a newly designed solution.)
The iproute2 package also can't ship the same ifupdown hook files as
bridge-utils does as that would be a conflict. And even if the conflict
was specified via the Conflicts: control keyword that still wouldn't
work as files under /etc are dpkg conffiles. The files could ofcourse
have a different name under iproute2 but then you would also need to
handle the case when both iproute2 and bridge-utils provides the same
hooks (with different names) and avoid both of their functionality
colliding mid-air. I simply don't find this compelling to pursue.
I'm also going to state that iproute2 is a package with (only) low level
networking utilities. It is not the right place to implement higher
level (ifupdown) functionality. The iproute2 package does not ship any
kind of policy on how the tools should be used (eg. init scripts, etc.),
it simply provides a mechanism which other higher level packages can
use to implement their policy.
The ifupdown implementation already heavily relies on iproute2 and
changing that would be a big undertaking and isn't going to change any
time soon as far as I can predict. If someone wants bridge support in
ifupdown, then I'd suggest the correct place to implement that would be
in the ifupdown package itself. The functionality is already at
ifupdowns fingertips as the already existing dependency on iproute2
also gives the bridge command. Spreading ifupdown implementation over a
wide range of packages is in my opinion a mistake. I also think the
hooks are an often overused way of working around missing functionality
in ifupdown that is better adressed by implementing it properly in
ifupdown if so desired.
I personally think that networking tools that wants to be something to
count with needs to be able to speak netlink (and listen to events). I
don't see ifupdown as part of a future vision. It's mainly filling the
need of being a widly documented way of setting up basic networking. As
time passes I hope documentation for more modern solutions will be more
pervasive and the need for keeping compatibility with
/etc/network/interfaces hopefully diminish. The iproute2 suite can be
used for simpler "one off" tasks (which higher level networking policy
tools should see via netlink events). With all this in mind, I think
this is yet another reason why iproute2 should not get involved in
ifupdown business (or in any other way widen its scope). Specially since
getting people interested in helping out with iproute2 package
maintenance has unfortunately proven harder than desired despite its
very wide usage. In my opinion someone who wants to rely on advanced
functionility like bridging should probably be looking for an
alternative to ifupdown. I personally wouldn't mind this bug report
simply being tagged wontfix (and closed) in a self-deprecating kind of
way if ifupdown maintainers thinks bridging is not something they
want to support.
Apart from the reasons already stated above, I think the original
description fits well with this being an ifupdown feature request
(rather than any other alternative view of how to interpret this as has
been done during the following reassignings).
Regards,
Andreas Henriksson
