5 Dependency from gnome-core to network-manager
9 gnome-core should Recommend, not Depend, on network-manager
10 (overrule maintainer).
14 The dependency from gnome-core to network-manager (via
15 network-manager-gnome) was referred to the Technical Committee.
17 The TC has made the following decision:
23 1. The gnome-core metapackage is intended to reflect the core of the
24 GNOME desktop environment: the basic tools and subsystems that
25 together constitute GNOME. The gnome metapackage is intended to
26 reflect the broader desktop environment, including extra components
29 2. network-manager is the GNOME network control system, and is
30 recommended for most GNOME users. Some Debian GNOME users don't like
31 some of network-manager's behavior and prefer to instead use other
32 tools, either basic ifupdown or other frameworks such as wicd.
34 3. In squeeze, the gnome metapackage lists network-manager in Recommends
35 but not Depends. In wheezy, currently, network-manager has moved from
36 gnome to gnome-core, and from Recommends to Depends. This represents
37 a substantially increased insistance that users of the GNOME
38 metapackages have network-manager installed; specifically, there is no
39 longer any way to install any but the most minimal GNOME metapackage
40 (gnome-session) without installing network-manager, and users who have
41 gnome or gnome-core installed but have removed or never installed
42 network-manager will have network-manager installed during an upgrade
45 4. For most applications and components, the only drawback of this would
46 be some additional disk space usage, since the application, despite
47 being installed, wouldn't need to be used. However, network-manager
48 assumes that, if it is installed, it should attempt to manage the
49 system's network configuration. It attempts to avoid overriding local
50 manual configuration, but it isn't able to detect all cases where the
51 user is using some other component or system to manage networking.
52 The user has to take separate, explicit (and somewhat unusual for the
53 average user) action to disable network-manager after it has been
56 5. The Technical Committee believes that this will cause undesireable
57 behavior for upgrades from squeeze, and (of somewhat lesser
58 importance) will make it more difficult than necessary for GNOME users
59 to swap network management components, something for which there
60 appears to be noticable demand. We therefore believe that
61 network-manager should be moved to Recommends in gnome-core.
63 6. Please note that this is not a general statement about GNOME
64 components. It is very specific to network-manager because all of the
67 (i) The package takes action automatically because it is installed,
68 rather than being a component that can either be run or not at the
71 (ii) The package has historically been recommended rather than listed
72 as a dependency, so existing Debian users are used to that
73 behavior and will expect it to be preserved during upgrades.
75 (ii) There is both demonstrable, intentional widespread replacement of
76 that package by Debian GNOME users and no significant loss of
77 unrelated GNOME desktop functionality by replacing it with a
80 If any of these points did not apply, the situation would be
81 significantly different.
85 7. The Technical Committee overrules the decision of the gnome-core
86 metapackage maintainers. The dependency from gnome-core to
87 network-manager-gnome should be downgraded to Recommends.
89 8. The Technical Committee requests that the Release Managers unblock
90 the update to implement this decision, so that this change may be
94 ===== # processor will insert "Please see http://..." for the TC bug.
95 ===== # mentioning bug urls here will result in a "see also" on the web page
97 http://bugs.debian.org/645656 (against gnome-core) will be used to
98 track the the implementation of this decision.
100 Along with the specific case of gnome-core and network-manager, the TC
101 also considered the policy on use of Recommends more generally,
102 particularly in the context of metapackages; this was also discussed
103 and resulted in a TC decision which can be found at
104 http://bugs.debian.org/681783.