[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#688772: gnome Depends network-manager-gnome



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


Reply to: