Bug#681834: tech-ctte: Use of Recommends instead of Depends for metapackages
Package: tech-ctte
Severity: minor
Dear committe
First of all, I'm not a Debian Developer, but just a long time user, and recent Maintainer. I'm writing this since I found no request on Constitution requiring being a DD for submitting an issue to the Committe.
As suggested by Ian Jackson on [1], the discussion at hand become circular and repetitive, and this is why I'm submitting this to the committe. I'm not requesting a ruling, but just a clarification. Anyway, a ruling can be made about the issue, or even some developers could be overruled.
Whole thing started at [2] in an ITP for a new Window Manager. Thread developed into a more general discussion about packages in the archive that duplicates other packages functionality [3], sometimes focusing in the amount of window managers present in Debian. At a certain moment [4] network-manager entered the discussion as an example of a point where Debian should start removing window managers instead of vetting new ones. A separated thread raised at [5] to discuss the duplicates issue, but network-manager issue continued at [6] and a bit later [7].
Then network-manager centered the discussion at [8] where it was stated that it breaks working software like udev or ifupdown, and it was suggested that the relationship between the gnome package and the network-manager package should not be a Depends chain, but have a Recommends.
FYI actual chain is:
gnome Depends gnome-core
gnome-core Depends network-manager-gnome
network-manager-gnome Depends network-manager
and Adam Borowski suggested a Recommends instead of a Depends, most probably in the gnome-core -> network-manager-gnome step.
Two sides formed. One side critizising network-manager and pressing for a Recommends relationship. Other side defending network-manager and defending a Depends relationship. Main argument of the defender side was that gnome is not a normal package but a metapackage, and thus it should include a set of software using mainly Depends even if there is actually not a real software dependency.
>From this, discussion changed names again [9] and get called "Recommends for metapackages", being a two-fold discussion. On one hand, it was a discussion for and against metapackages using Recommends as a genera topic. On the other hand, at the same time it was a discussion about if network-manager should be or not a Recommends instead of a Depends. Arguments were given both to the general question and to the particular one.
I've tried to be as neutral as possible in the explanation above. My particular point of view on the general is that metapackages are not so special as to avoid the Policy, which states that Recommends should be used for packages that are to be found in all but unusual installations, and metapackages sometimes are used by user with special needs who need to avoid or deinstall certain not required pieces of the platform. My particular point of view about the particular is that since network-manager causes issues to a not negligible fraction of our users, some of which can want to use gnome, the relationship between these two packages should be a Recommends, since the lack of network-manager causes no breakage at all on a gnome system. A complete resume of my arguments (and I hope those of others are included) is on [10]. I can not present a resume on the arguments from the other side since none was provided.
I do not want to get the Depends side undefended, I hope you can involve in the discussion some of their representattives.
I request from the committe a position about the general issue of Recommends on metapackages (but I wish a ruling about network-manager in particular).
Regards
Noel Torres
er Envite
[1] https://lists.debian.org/debian-devel/2012/07/msg00388.html
[2] https://lists.debian.org/debian-devel/2012/06/msg00821.html
[3] https://lists.debian.org/debian-devel/2012/06/msg00838.html
[4] https://lists.debian.org/debian-devel/2012/06/msg00860.html
[5] https://lists.debian.org/debian-devel/2012/06/msg01057.html
[6] https://lists.debian.org/debian-devel/2012/06/msg00884.html
[7] https://lists.debian.org/debian-devel/2012/07/msg00154.html
[8] https://lists.debian.org/debian-devel/2012/07/msg00155.html
[9] https://lists.debian.org/debian-devel/2012/07/msg00211.html
[10] https://lists.debian.org/debian-devel/2012/07/msg00403.html
Reply to: