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

Bug#688772: gnome Depends network-manager-gnome



On Friday, October 12, 2012 14:38:07, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > On Fri, 12 Oct 2012, Ian Jackson wrote:
> > > Why do you think the gnome metapackage depending on, rather than
> > > recommending, wicd, is a good idea?
> > 
> > The primary case of NM breaking things is when it's installed with
> > wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.
> 
> There are no other competitors to wicd and n-m then ?

'apt-cache search "network manager"' also comes up with nova-network which is 
a network manager for OpenStack, which I think is Cloud related, but I'm not 
familiar with it.  Here's the relevant portion of the description:

   This package equips a system to function as a network node. This
   service is responsible for managing floating and fixed IP addresses,
   DHCP, bridging, and VLANs, and in some cases acts as a gateway.
   Different networking strategies can be accessed by setting the
   network_manager flag to FlatManager, FlatDHCPManager, or VlanManager
   (the default).

> > > For example, consider the position of someone who has deliberately
> > > removed n-m in squeeze, and is using ifupdown or running ifconfig by
> > > hand or whatever, and upgrades to wheezy. This still gives them n-m
> > > back. That's not respecting their previous choice to remove it.
> > 
> > Right, but if they get NM back, and nothing breaks because of it,[0]
> > it's just the same as any other package being installed by a meta
> > package. They've wasted some disk space, and they've got another
> > program running, but everything continues to work.
> 
> And you're saying nothing will break because in the case where they
> have wicd, n-m won't be installed because of the alternative.  And in
> the case where they don't have wicd "there are no such bugs that
> aren't rc".
> 
> Are we sure that all these rc bugs are going to be fixed and not
> downgraded at the last moment ?  Are we sure that we will find them
> all, for that matter, before the release ?
> 
> Given the very strong insistence by n-m's proponents that these bugs
> aren't even real, in many cases, it seems more likely that n-m will be
> released in wheezy with infelicities which will be argued by the gnome
> maintainers to be not bugs, or not rc, or someone else's fault.
> 
> For example, if I want to use ifupdown then I probably don't want n-m
> to bring up even interfaces which exist but which I haven't mentioned
> in /etc/network/interfaces - but managing those interfaces is
> precisely the point of n-m.  So I'm cast back into "install n-m but
> disable it", which is clearly inferior.
> 
> The result is surely going to be more friction between users who find
> n-m doesn't work for them, and developers who insist on forcing n-m on
> them.

I keep thinking about this in the context of laptops, and forgetting the 
context of "traditional desktop boxes" and servers.  In the context of either, 
it's common to want to install Gnome without any wireless manager installed 
and use ifupdown "just like with any other server" -- and specifically not 
install n-m due to previous bad experiences people have had with it, or to 
have trouble figuring out how to configure n-m for a static IP if they aren't 
able to remove it.  [It can do it, but is apparently not intuitive.]

There are a couple of people at my local LUG that run Gnome on their server 
(usually on Ubuntu).  I've overheard a few discussions about the difficulties 
of removing n-m in this context, and the advice given to the server owner 
generally ranges between "remove n-m -- it's worth it" to "you might as well 
configure n-m for a static IP, because the system will fight you on removing 
it too much".

I thought running Gnome3 on a server was a crazy idea until I asked about it; 
the basic premise is that the server then has a similar interface as the 
traditional Desktop, and allows for running GUI administration programs.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us


Reply to: