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