On Fri, 09 Nov 2012, Ian Jackson wrote: > This for me is the critical point. Can _anyone_ provide a coherent > and fact-based explanation for why this is a good idea ?
NM is apparently required for various parts of gnome to figure out whether it is online or offline. It's also necessary for the network configuration components to work properly inside of gnome. There may be additional technical problems that not having NM causes gnome, but they haven't been adequately communicated. [However, Michael Biebl is planning on communicating them in an e-mail to us shortly.] > The biggest technical downside is that this approach doesn't solve > the upgrade problem without a good deal of complicated machinery to > try to determine whether the system should pretend that n-m isn't > installed (or annoying prompts, or something). This machinery should be in place even without the upgrade process just to avoid breakage when multiple elements of the NM, wicd, and conntrack set are installed. > Secondly, there is a process/approval problem here for the > post-wheezy case. I think this resolution text effectively neuters > itself after wheezy since AIUI the n-m maintainers naturally think > that all the concerns are _already_ satisfactorily addressed. This is only the case if we are convinced the NM maintainer(s) are acting in bad faith. While that's certainly a possibility, we shouldn't assume it. Perhaps specifically spelling out what the technical requirements are would be sufficient to mitigate the potential for the appearance of bad faith. Such as: 1. NM must not break an existing working networking configuration. 2. In the event that a networking configuration manger which is unable to cooperate with NM is previously installed, NM should default to disabling itself. [With possibilities for debconf prompting at low priority to change it, I suspect.] > Alternatively, if it's intended that after wheezy the maintainers > will do whatever they feel appropriate then the resolution should > explicitly limit the scope of the overruling to wheezy and have a > new advisory paragraph for the post-wheezy case. (I mention this for > completeness; I wouldn't agree with that approach.) I don't agree with this approach either, because the technical concerns are the entire reason why we're here. Don Armstrong -- This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
