Description of problem: When upgrading from 5.2 to 5.3, the Evolution upgrade now installs NetworkManager and all of its dependencies, which is a change from previous behavior. Version-Release number of selected component (if applicable): 5.3 How reproducible: Always Steps to Reproduce: 1.yum upgrade 2. 3. Actual results: Following dependencies installed: Installing for dependencies: NetworkManager i386 1:0.7.0-3.el5 base 1.0 M NetworkManager-glib i386 1:0.7.0-3.el5 base 79 k ppp i386 2.4.4-2.el5 base 382 k Expected results: Update of evolution without unwanted packages Additional info:
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Nothing has changed on the Evolution side; this is likely due to the NetworkManager rebase, and possibly a dupe of bug #351101 for Fedora. Reopening for Dan to have a look at it.
I vote against this dependency -- it really screwed me. I only have NetworkManager because of evolution, but it is not enabled. Early March an update of NetworkManager enabled the service without warning and I didn't notice. I rebooted my machine Sunday. After networking had successfully started NetworkManager loaded and killed eth0 again (even though /etc/sysconfig/network-scripts/ifcfg-eth says "NM_CONTROLLED=no"). I'm 4000 miles from my machine, so I had to get someone to go into my office, work out what had happened, and restore my connectivity. I see two bugs here: the fact that NetworkManager is an unnecessary dependency, and the fact that a package update would set a service "on" that had previously been "off"
Yeah, carrying this dep over was an oversight when we rebased to NM 0.7, and there shouldn't be any hard dep between NM and NM-glib. We've removed that dep in the Fedora NM packages.
Fixed in NetworkManager-0.7.0-7.el5
-> 5.5 We cannot actually remove the NM-glib dep on NetworkManager, because libnm_glib requires libnm-util, which is shipped in the NetworkManager package. We can't move libnm-util to NetworkManager-glib due to multilib issues (see bug #351101). The end-fix is to backport the upstream Evolution patch that uses plain D-Bus to find the NM state instead of using NM-glib.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in the last planned RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX. To request that Red Hat re-consider this request, please re-open the bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days