Bdale Garbee writes ("Bug#681834: network-manager, gnome, Recommends vs Depends"): > I believe our goal should be to require that there not be a hard Depends > relationship. I would be equally satisfied if the dependency were just > dropped, or if it were possible to craft a suitable "or" list of > alternatives that network-manager could be the first choice of the > maintainer among. I have not followed the discussion closely enough or > independently studied this situation in sufficient detail to know if > this is possible, however.
Thinking about this some more, I think it would be better to mandate a specific solution. There have been many suggestions of alternative approaches which are (i) more complicated and (ii) whose effects we are not entirely sure and (iii) which would require specifying in detail, but which somehow avoid sidestep the key disputes. The key disputes seem to be: - Some people claim that metapackages should not use Recommends. I disagree. - GNOME upstream have declared Network Manager to be an integral part of GNOME and the Debian maintainer is insisting on following their lead in gnome-core. The maintainer is essentially asserting that the very purpose of the gnome-core metapackage is to reflect precisely what upstream have decreed, and that we should not deviate. I disagree; I think (a) we should feel free to deviate from upstream if doing so is better for our users and (b) anyway setting one of the dependencies to Recommends is not a significant deviation. My best argument in favour of specifying the specific solution is that we know exactly what the effects will be. If we want instead to write a resolution specify the effects, we will have to consider carefully exactly which effects we want to mandate. For example, creating another metapackage might have transitional implications; both for users upgrading from squeeze and for other packages which depend on gnome-core. Also if we want this to be in wheezy we want not to be messing about with complicated solutions. There is a risk, for example, that the maintainer might choose an approach unsuitable for release in wheezy. We can hardly tell the maintainer `you must do this but you must do it in the way you think is best for wheezy' - that would amount to asking them to undermine their own judgement. For the same reason I would like a decision quickly. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org