Bug 144818
Summary: | NetworkManager scriplets need to be cleaned up | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Matthias Saou <matthias> | ||||
Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | Keywords: | EasyFix | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-01-13 19:47:36 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Matthias Saou
2005-01-11 19:05:11 UTC
I'd be happy to apply the patch. The thing to keep in mind is that: 1) If the user _hasn't_ ever used NetworkManager, we don't want it to be started by default or added with chkconfig. At this time, users must explicitly enable NM, so just installing the RPM should _not_ run NM on startup or add it with chkconfig unless its already there 2) We should not restart NM if its not already running (condrestart) 3) If the user has NM set to run on startup and its currently running, we should restart NM The current specfile doesn't do these very well, I'll admit :) I get those points, but for 1), the proper way of making sure NetworkManager doesn't get added to run on startup for people who didn't enable it explicitely is simply by changing this line : # chkconfig: 345 98 02 to : # chkconfig: - 98 02 in "initscript/RedHat/NetworkManager" of the sources, as this represents the runlevels in which to run the service by default. Making the change upstream, adding a patch to the srpm or adding a one-liner regexp substitution in %prep or %build are all solutions. Aha, the "-" I was not aware of. Thanks. Created attachment 109633 [details]
Spec file patch
Changes :
- Keep consistent between spaces and tabs
- Added URL so that people know where to look for more info
- Remove big blocks of comments that caused trouble in the scriplets (sorry! a
good syntax highlighting will do as well...)
- Added missing BuildRequirements
- Updated %description based on current README
- Remove unneeded explicit dependencies
- Use %find_lang macro for translations and file colouring
- Clean up scriplets
- Add directory default attributes
- Re-organize %files order to increase readability
- Add slashes to the %files lines for directories
- Set the gnome sub-package dbus file as %config like the main one
Feel free to take or throw away any parts separately.
One quick comment... The NetworkManager-gnome package does indeed require GConf2, since NetworkManagerInfo uses it and links to gconf libraries. Absolutely. But this is a typical case of redundant dependency information, as the library requires/provides that rpm computes will already carry that information : $ rpm -q --requires NetworkManager-gnome | grep gconf libgconf-2.so.4 $ rpm -q --whatprovides libgconf-2.so.4 GConf2-2.8.1-1 Having "GConf2" as an explicit dependency can seem harmless at first (and mostly is, actually ;-)), but say that the GConf2 package dissapears because it's been swallowed by a compat-* one or replaced by a new binary compatible one (think fam vs. gamin)... relying only on automatic deps makes things easier since as long as the same libraries are provided somewhere, things won't break. This was untrue in the "old days" when apt for rpm, yum or even up2date didn't exist, since an explicit missing dep on "GConf2" lead more easily to the package required to satisfy the dependency than "libgconf-2.so.4". Anyway, just take a look at the output, it should make you feel more comfortable ;-) : rpm -q --requires NetworkManager-gnome I see these changes have been merged in the FC3 update that just got released, thanks! The dbus_version and hald_version macros are nice and practical too ;-) |