new NetworkManager dependencies?

[Tom Horsley]

I have found that the only way I can ever get networking to
function correctly on my systems is to

yum erase NetworkManager

with NM installed it insinuates tentacles into everything,
doing stuff like grabbing control of USB network devices
when I plug them in (devices I don't want it fooling with).

Now, yum has just reinstalled NetworkManager because new
dependencies dragged it in. When I remove it, all this
new junk goes with it:

Removed:
  NetworkManager.x86_64 1:0.9.4.0-9.git20120521.fc17

Dependency Removed:
  NetworkManager-gnome.x86_64 1:0.9.4.0-9.git20120521.fc17                      
  control-center.x86_64 1:3.4.2-4.fc17                                          
  gnome-bluetooth.x86_64 1:3.4.2-1.fc17                                         
  gnome-shell.x86_64 0:3.4.1-6.fc17                                             
  orca.x86_64 0:3.4.2-1.fc17

Most of those things didn't depend on NM previously,
why do they depend on it now? Why should I need to
have NM installed just to get to the audio volume
control (for example).

[Tim]

Allegedly, on or about 03 November 2012, Tom Horsley sent:
> Now, yum has just reinstalled NetworkManager because new
> dependencies dragged it in. When I remove it, all this
> new junk goes with it:
>
> Removed:
>   NetworkManager.x86_64
> 1:0.9.4.0-9.git20120521.fc17
>
> Dependency Removed:
>   NetworkManager-gnome.x86_64
> 1:0.9.4.0-9.git20120521.fc17                      
>   control-center.x86_64
> 1:3.4.2-4.fc17                                          
>   gnome-bluetooth.x86_64
> 1:3.4.2-1.fc17                                         
>   gnome-shell.x86_64
> 0:3.4.1-6.fc17                                             
>   orca.x86_64
> 0:3.4.2-1.fc17
>
> Most of those things didn't depend on NM previously,
> why do they depend on it now?

Do they, though?  If you re-install them, individually, do they dredge
in NetworkManager at the same time?

[Ed Greshko]

On 11/03/2012 08:54 PM, Tom Horsley wrote:
> I have found that the only way I can ever get networking to
> function correctly on my systems is to
>
> yum erase NetworkManager
>
> with NM installed it insinuates tentacles into everything,
> doing stuff like grabbing control of USB network devices
> when I plug them in (devices I don't want it fooling with).

Are you saying that even if you

systemctl disable NetworkManager.service

it gives you problems?

I've not had problems with NetworkManger ...  But on one test system I disabled it and enabled "network" using chkconfig.  Everything works fine and no NetworkManager bits are running.

[Tom Horsley]

On Sun, 04 Nov 2012 02:00:39 +1030
Tim wrote:
> Do they, though?  If you re-install them, individually, do they dredge
> in NetworkManager at the same time?

Yep. The dependency is real (as far as yum is concerned).

[Kevin Fenzi]

On Sat, 3 Nov 2012 08:54:26 -0400
Tom Horsley  wrote:
> I have found that the only way I can ever get networking to
> function correctly on my systems is to
>
> yum erase NetworkManager
>
> with NM installed it insinuates tentacles into everything,
> doing stuff like grabbing control of USB network devices
> when I plug them in (devices I don't want it fooling with).
>
> Now, yum has just reinstalled NetworkManager because new
> dependencies dragged it in. When I remove it, all this
> new junk goes with it:

...snip...

https://bugzilla.redhat.com/show_bug.cgi?id=862835

This was a control-center bug where they added the dep.

You might note in that bug that the dep is undesireable and see if they
can fix whatever issue a better way.

kevin

[Tom Horsley]

On Sat, 03 Nov 2012 23:38:33 +0800
Ed Greshko wrote:
> Are you saying that even if you
>
> systemctl disable NetworkManager.service
>
> it gives you problems?

Yep. It springs into life when I do something like plug in
a device that will become wlan0.

I think I've fixed it though: I now have this added to my
"big hammer" yum update hooks:

rpm -q --list NetworkManager 2>/dev/null | xargs rm -rf

NetworkManager is free to pretend to be installed, I just
remove all the files :-).

[Ed Greshko]

On 11/04/2012 12:29 AM, Tom Horsley wrote:
> On Sat, 03 Nov 2012 23:38:33 +0800
> Ed Greshko wrote:
> > Are you saying that even if you
> >
> > systemctl disable NetworkManager.service
> >
> > it gives you problems?
>
> Yep. It springs into life when I do something like plug in
> a device that will become wlan0.
>
> I think I've fixed it though: I now have this added to my
> "big hammer" yum update hooks:
>
> rpm -q --list NetworkManager 2>/dev/null | xargs rm -rf
>
> NetworkManager is free to pretend to be installed, I just
> remove all the files :-).

Interesting...  Do you happen to know what part of NM springs to life?  Seem like disabling it would prevent that.  I think I can test that sometime soon.

Did you file a bugzilla against it?  Don't want to duplicate the effort.

[Tom Horsley]

On Sun, 04 Nov 2012 04:38:14 +0800
Ed Greshko wrote:
> Interesting...  Do you happen to know what part of NM springs to life?  Seem like disabling it would prevent that.  I think I can test that sometime soon.

I don't know, nor to I have a clue how to find out, I just know that
previous attempts to disable it never worked. Some udev nonsense
probably would result in it firing back up again when I plugged in
a wi-fi dongle. I removed it and all my problems were gone, so there
was no need for the huge research project to discover how to make
it stop bothering me :-).
> Did you file a bugzilla against it?  Don't want to duplicate the effort.

I added a comment to the one mentioned earlier in this thread:

https://bugzilla.redhat.com/show_bug.cgi?id=862835

[Rahul Sundaram]

On Sat, Nov 3, 2012 at 9:08 PM, Ed Greshko
> Are you saying that even if you
>
> systemctl disable NetworkManager.service
>
> it gives you problems?

Disabling doesn't prevent some other service from activating it again when
it checks for network connectivity.  If you really want it to be permanent,
mask it instead

systemctl mask NetworkManager.service

Rahul

[Ed Greshko]

On 11/04/2012 01:33 PM, Rahul Sundaram wrote:\
> On Sat, Nov 3, 2012 at 9:08 PM, Ed Greshko
> Are you saying that even if you
>
> systemctl disable NetworkManager.service
>
> it gives you problems?
>
>
> Disabling doesn't prevent some other service from activating it again when it checks for network connectivity.  If you really want it to be permanent, mask it instead
> systemctl mask NetworkManager.service

Good point....  I'd forgotten about that.

FWIW, with only disable I've not run into any problems in my very limited testing and environment today.  I probably won't be doing too much more testing since I've yet to have any problems with NM.

[Gordon Messmer]

On 11/03/2012 09:29 AM, Tom Horsley wrote:
> I think I've fixed it though: I now have this added to my
> "big hammer" yum update hooks:

Isn't this more or less how Eric Raymond broke his system before he 
publicly stormed away from using Fedora?  He forcefully removed a 
package that others depended on, and then the system quit working.

Could we all just agree to not offer that kind of thing as advice? 
Removing dependencies is an awful habit that's going to cause things to 
break.  It's less work to simply disable NetworkManager, and less likely 
to cause a dependent package to fail.

[Tom Horsley]

On Mon, 05 Nov 2012 09:56:42 -0800
Gordon Messmer wrote:
> It's less work to simply disable NetworkManager, and less likely 
> to cause a dependent package to fail.

Not when "disable" is apparently only a mild suggestion that
has no actual effect :-). Apparently the word which actually
means "disable" is "mask".

Also if there are any real dependencies on NM, they are gonna
fail anyway, because NM isn't running anything on my system
and anyone expecting it to be able to do things to the
network is already broken.

[Bruno Wolff III]

On Mon, Nov 05, 2012 at 13:15:53 -0500,
   Tom Horsley  wrote:
> On Mon, 05 Nov 2012 09:56:42 -0800
> Gordon Messmer wrote:
> > It's less work to simply disable NetworkManager, and less likely
> > to cause a dependent package to fail.
>
> Not when "disable" is apparently only a mild suggestion that
> has no actual effect :-). Apparently the word which actually
> means "disable" is "mask".

I run with NM disabled on systems where I am not using wireless and it seems 
to work fine.

[Joe Zeff]

On 11/05/2012 10:21 AM, Bruno Wolff III wrote:
> I run with NM disabled on systems where I am not using wireless and it
> seems to work fine.

So do I.  I have to because if I have NM active on this box it re-writes 
resolv.conf at boot, leaving out my DNS.  It's either disable NM or 
re-enter the DNS numbers at every boot, which is absurd.  Oddly enough, 
it works Just Fine on my laptop.

[Gordon Messmer]

On 11/05/2012 10:15 AM, Tom Horsley wrote:
> Also if there are any real dependencies on NM, they are gonna
> fail anyway, because NM isn't running anything on my system
> and anyone expecting it to be able to do things to the
> network is already broken.

I don't think you understand how the dynamic linker works, or why rpm 
tracks dependencies.  If you turn off the NetworkManager service, 
applications will not be able to monitor or change the network state. 
If you remove the shared object files that NetworkManager provides, then 
anything which was compiled to use those shared objects will no longer 
start.  In the case of control-center, that probably means that the 
"network" panel will either not load, or will cause control-center to 
crash when its load is attempted.  I'm mostly sure gnome-shell won't 
start if you remove those files, nor Empathy.

[Tom Horsley]

On Mon, 05 Nov 2012 10:47:28 -0800
Gordon Messmer wrote:
> I don't think you understand how the dynamic linker works, or why rpm 
> tracks dependencies.

This dependency wasn't added by rpmbuild noticing that a library
was used, this dependency was force fed to the package to make
it depend on NM despite the fact that there is no hard wired
dependency. I was able to uninstall NM until these artificial
dependencies were introduced.

[Gordon Messmer]

On 11/05/2012 11:27 AM, Tom Horsley wrote:
> This dependency wasn't added by rpmbuild noticing that a library
> was used, this dependency was force fed to the package to make
> it depend on NM despite the fact that there is no hard wired
> dependency. I was able to uninstall NM until these artificial
> dependencies were introduced.

Which dependency is "this?"

for x in control-center gnome-bluetooth gnome-shell orca ; do (rpm -ql 
$x | xargs ldd | grep libnm) 2>/dev/null ; done

Of those, orca and gnome-bluetooth depend on a working control-center. 
There is no feature of rpm that allows a package to allow a dependency 
to be partially broken.  Control center's dependency isn't artificial, 
so I'm not sure what you're referring to.  It is definitely linked to 
NetworkManager's libraries, and the dependency will be added by rpmbuild.

[Tom Horsley]

On Mon, 05 Nov 2012 11:51:33 -0800
Gordon Messmer wrote:
> Which dependency is "this?"

https://bugzilla.redhat.com/show_bug.cgi?id=862835

The one described in that bugzilla. Before this "fix" I had
no dependency problems uninstalling NM.

[Reindl Harald]

Am 05.11.2012 21:29, schrieb Tom Horsley:
> On Mon, 05 Nov 2012 11:51:33 -0800
> Gordon Messmer wrote:
> > Which dependency is "this?"
>
> https://bugzilla.redhat.com/show_bug.cgi?id=862835
>
> The one described in that bugzilla. Before this "fix" I had
> no dependency problems uninstalling NM

hopefully this will not affect kde-stations in the future!
my machines do not have any piece of NetworkManager installed
nor do they need it because it is the wrong tool for machines
acting as router/firewall/vpn-gateway/wlan-ap based on
network.service and a large "iptables.sh"

[root@srv-rhsoft:~]$ rpm -qa | grep -i network | grep manager

[root@srv-rhsoft:~]$ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168..x.x  netmask 255.255.255.0  broadcast 192.168.2.255
        ether 3c:d9:2b:65:95:9f  txqueuelen 0  (Ethernet)
        RX packets 11018  bytes 2807179 (2.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11052  bytes 5635635 (5.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        ether 3c:d9:2b:65:95:9f  txqueuelen 1000  (Ethernet)
        RX packets 11451  bytes 2864617 (2.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8473  bytes 3552794 (3.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xfe700000-fe720000

eth1: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
        inet 84.113.x.x  netmask 255.255.255.0  broadcast 255.255.255.255
        ether 00:50:8d:b5:cc:de  txqueuelen 1000  (Ethernet)
        RX packets 2659703  bytes 1312008583 (1.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1186092  bytes 378981781 (361.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xfe6c0000-fe6e0000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Lokale Schleife)
        RX packets 167153  bytes 12486731 (11.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 167153  bytes 12486731 (11.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

mon.wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        unspec FC-75-16-5E-CF-E5-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 1053  bytes 100342 (97.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1444
        inet x.x.0.241  netmask 255.255.255.0  broadcast 10.0.0.255
        ether 0e:75:f2:4f:7b:f3  txqueuelen 100  (Ethernet)
        RX packets 254520  bytes 43866240 (41.8 MiB)
        RX errors 0  dropped 26487  overruns 0  frame 0
        TX packets 77413  bytes 10883456 (10.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vmnet8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168..x.x  netmask 255.255.255.0  broadcast 192.168.196.255
        ether 00:50:56:c0:00:08  txqueuelen 1000  (Ethernet)
        RX packets 16993  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16943  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether fc:75:16:5e:cf:e5  txqueuelen 1000  (Ethernet)
        RX packets 2764  bytes 335468 (327.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3077  bytes 2273107 (2.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0