Description of problem: `yum remove wpa_supplicant` appears to remove FAR too many packages as dependencies Version-Release number of selected component (if applicable): 1:0.5.7-10.fc8 How reproducible: Every time Steps to Reproduce: 1. yum remove wpa_supplicant Actual results: ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: wpa_supplicant x86_64 1:0.5.7-10.fc8 installed 589 k Removing for dependencies: NetworkManager x86_64 1:0.7.0-0.3.svn2995.fc8 installed 2.2 M NetworkManager i386 1:0.7.0-0.3.svn2995.fc8 installed 2.2 M NetworkManager-glib x86_64 1:0.7.0-0.3.svn2995.fc8 installed 103 k NetworkManager-glib i386 1:0.7.0-0.3.svn2995.fc8 installed 98 k NetworkManager-gnome x86_64 1:0.7.0-0.3.svn2995.fc8 installed 521 k NetworkManager-openvpn i386 0.3.2-7.fc6 installed 198 k NetworkManager-openvpn x86_64 0.3.2-7.fc6 installed 208 k NetworkManager-vpnc x86_64 1:0.7.0-0.3.svn2970.fc8 installed 316 k NetworkManager-vpnc i386 1:0.7.0-0.3.svn2970.fc8 installed 305 k evolution x86_64 2.12.1-3.fc8 installed 37 M evolution i386 2.12.1-3.fc8 installed 36 M evolution-help x86_64 2.12.1-3.fc8 installed 40 M krb5-auth-dialog x86_64 0.7-5.fc8 installed 56 k libpurple x86_64 2.2.1-2.fc8 installed 18 M nautilus-sendto x86_64 0.12-3.fc8 installed 276 k pidgin x86_64 2.2.1-2.fc8 installed 2.2 M Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 17 Package(s) Expected results: Not sure what I expected, but I didn't think evolution or pidgin should be removed. The machine is wired to the network, so I'm just removing all packages that are for wireless devices. Should I not still have the ability to use NetworkManager for wired-only connection? Additional info:
I've just tried removing NetworkManager and got the following: ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: NetworkManager x86_64 1:0.7.0-0.3.svn2995.fc8 installed 2.2 M NetworkManager i386 1:0.7.0-0.3.svn2995.fc8 installed 2.2 M Removing for dependencies: NetworkManager-glib x86_64 1:0.7.0-0.3.svn2995.fc8 installed 103 k NetworkManager-glib i386 1:0.7.0-0.3.svn2995.fc8 installed 98 k NetworkManager-gnome x86_64 1:0.7.0-0.3.svn2995.fc8 installed 521 k NetworkManager-openvpn i386 0.3.2-7.fc6 installed 198 k NetworkManager-openvpn x86_64 0.3.2-7.fc6 installed 208 k NetworkManager-vpnc x86_64 1:0.7.0-0.3.svn2970.fc8 installed 316 k NetworkManager-vpnc i386 1:0.7.0-0.3.svn2970.fc8 installed 305 k evolution x86_64 2.12.1-3.fc8 installed 37 M evolution i386 2.12.1-3.fc8 installed 36 M evolution-help x86_64 2.12.1-3.fc8 installed 40 M krb5-auth-dialog x86_64 0.7-5.fc8 installed 56 k libpurple x86_64 2.2.1-2.fc8 installed 18 M nautilus-sendto x86_64 0.12-3.fc8 installed 276 k pidgin x86_64 2.2.1-2.fc8 installed 2.2 M Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 16 Package(s) So will change the component of this bug to NetworkManager
Version of NetworkManager is: 1:0.7.0-0.3.svn2995.fc8
Think this should be at least a Medium severity since NetworkManager is going to be "released" as soon after F8 as possible?
wpa_supplicant is a hard dep of NM. it can also be used on _wired_ links for 802.1x authentication. Until RPM grows a 'recommends' function or something else like that, it's likely to remain this way, otherwise you would always have to know to also install wpa_supplicant if you want wireless or wired 802.1x support.
Hmm - fair call. But is there then an issue with evolution, pidgin, nautilus-sendto etc being removed as deps of NetworkManager? I should be able to use all these packages without having NetworkManager installed shouldn't I?
Yeah, there may well be a bug here; these apps should require NetworkManager-gnome, but not NetworkManager (ie, NM and -gnome are not mutually dependent). I think that the issue here was that the API between NM and -gnome needs to be in lock-step at the moment so we added a hard dep for NM + NM-gnome, and we can break that dep later once NM has settled down a bit. Thanks for bringing this up again though.
The problem is that on F-7, NetworkManager-glib depends only on libnm_glib.so.0, while on F-8 it also depends on libnm-util.so.0, which is provided by the main NetworkManager package. My suggestion is to move libnm-util to another subpackage if possible. F-7: % rpm -q NetworkManager-glib NetworkManager-glib-0.6.5-7.fc7.x86_64 % rpm -qR NetworkManager-glib | grep nm libnm_glib.so.0()(64bit) F-8: % rpm -q NetworkManager-glib NetworkManager-glib-0.7.0-0.6.6.svn3109.fc8.i386 % rpm -qR NetworkManager-glib | grep nm libnm-util.so.0 libnm_glib.so.0 libnm_glib_vpn.so.0
Ping. Come on, this is a trivial packaging issue. It doesn't require rocket science to fix.
This can only be done when the API between NetworkManager and libnm_glib is stable enough that people won't get screwed when they update NM but it doesn't pull in a new libnm_glib. The requirement reflects D-Bus API requirements at the current time too, not just ABI.
(In reply to comment #9) > This can only be done when the API between NetworkManager and libnm_glib is > stable enough that people won't get screwed when they update NM but it doesn't > pull in a new libnm_glib. The requirement reflects D-Bus API requirements at > the current time too, not just ABI. Then add explicit Requires: NetworkManager-glib = %{version}-%{release} to NetworkManager.spec so that it doesn't happen. You're irritating a lot of people by forcing them to keep wireless-releated packages on systems without a wireless card. Or by forcing them to keep NetworkManager. Or both. Or are you simply too busy with other stuff to fix this trivial issue? If that's the case, then please say so instead of inventing irrelevant reasons for not fixing this. This is still broken in rawhide/f9 beta.
Still broken on F9/i386 release. NetworkManager screws up wired connections with fixed ip, a workaround is to remove it, but them pidgin, system-config-printer (?!) and many others are removed too. NetworkManager doesn't work since f5, please just get rid of it.
NM works fine with static IP connections. If you have static DNS servers though, you'll need to add them directly to the ifcfg file as DNS1=xxx.xxx.xxx.xxx and DNS2=xxx.xxx.xxx.xxx. The fact that system-config-network doesn't do that is a bug that I'm fixing now.
Nevertheless it should be possible to remove it without removing pidgin and others. I've already described a solution, so why can't you implement it?
Created attachment 308169 [details] patch to allow uninstalling NetworkManager And to put my money where my mouth is, here's a patch that does what I want.
Patch has the right idea, but we also need to put the libnm-util headers into a devel subpackage. I think the better solution is to put libnm-util and it's associated headers into NetworkManager-glib and NetworkManager-glib-devel (since you still need glib to use libnm-util), and then make NM depend on NetworkManager-glib instead. Thus NM-glib is the bottom of the stack, not NetworkManager. This is what I'll put into the next testing update.
NetworkManager-0.7.0-0.9.4.svn3675.fc9 has been submitted as an update for Fedora 9
Also built as 0.7.0-0.6.8.svn3675.fc8
NetworkManager-0.7.0-0.9.4.svn3675.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update NetworkManager'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5017
NetworkManager-0.7.0-0.9.4.svn3675.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-1:0.7.0-0.9.4.svn3675.fc9 (i386) is missing on the Fedora 9 stable repository. "yum update" fails with the following error: Resolving Dependencies 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 from installed has depsolving problems --> Missing Dependency: NetworkManager-glib = 1:0.7.0-0.9.3.svn3623.fc9 is needed by package 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 (installed) 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 from installed has depsolving problems --> Missing Dependency: NetworkManager-glib = 1:0.7.0-0.9.3.svn3623.fc9 is needed by package 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 (installed) Error: Missing Dependency: NetworkManager-glib = 1:0.7.0-0.9.3.svn3623.fc9 is needed by package 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 (installed)
Phil; I see http://download.fedora.redhat.com/pub/fedora/linux/updates/9/i386/NetworkManager-0.7.0-0.9.4.svn3675.fc9.i386.rpm ; can you check again to see if it's still missing for you?
So we're going to have to break this again and we won't be able to 'yum remove NetworkManager' without taking out half the desktop. The reason is that due to multilib, which Phil has just encountered, there is no way to remove the NM.i386 package on multilib (x86-64) arches. The i386 package was installed originally because libnm-util was in the core package. When it got moved out to -glib to fix this bug, there was no way to obsolete the core i386 package since we can't do cross-arch obsoletes. Unfortunately, multilib more important than being able to 'yum remove NetworkManager' easily. I'd suggest that instead, you 'chkconfig NetworkManager off' since that should produce the same runtime effect as removing the NM RPM completely. For F10, we can fix this issue from anaconda-assisted upgrades, but not from a 'yum upgrade' directly.
Why do you want to obsolete it? Is there a problem with having both 32bit and 64bit NM package in the repo? Just keep it there. It won't break for people who want it and it won't break for the people who don't. I don't understand why the main 32bit package vanished from the 64bit repos.
It disappeared because it no longer contains libraries, which was the whole point of this bug in the first place. Multilib packages should be parallel installable, but having both a 32-bit and 64-bit NetworkManager package installed obviously isn't since the binaries use the same path. On a 64-bit machine, your binaries should be 64-bit if the 64-bit package is installed.
The previous main NM 32bit and 64bit packages had the binaries in the same place. Of course, rpm would keep only the 64bit binaries if you installed both. I agree that you should only have 64bit binaries, but in this case you will, even if you have the 32bit package installed, too. I think you should just keep the NM.i386 package in the repo (some manual override?) to help with updates. It can be removed manually (or by anaconda on upgrade) afterwards.
*** Bug 466858 has been marked as a duplicate of this bug. ***
This is fixed in rawhide, there is no longer a dependency between NetworkManager and NetworkManager-glib. Again, cannot be fixed for F9 and earlier due to #451519.