Hi, Jonas Smedegaard wrote:
> No, I do not find it right for Debian to mandate meta-packages to only > recommend when some users need only a subset of the offerings of said > meta-package: There will _always_ be some users needing only a subset of > things, rendering all dependencies "wrong" by that logic! Now hold on a second. I don't think Eugene would advocate any such sweeping principle as the one described above. One thing he did say is that he is against is a magic "metapackages" section transforming Depends into something weaker. I imagine you'd agree with him about that. So where is the point of disagreement here? There is a danger in overgeneralizing too early. As far as I can tell, the actual problem at hand is: - The gnome-core metapackage is very useful to some people. It helps people install a standard GNOME installation, keep it installed, and remove it later if they wish, using a single package. - Some of the same people do not want to have network-manager installed. They also do not want to have network-manager fake-installed using equivs because they want to notice if they try to install something that actually requires network-manager. Given the above problem description, using a Recommends in the metapackage would seem like a pretty reasonable solution. Unfortunately there is another complication that throws a spanner in the works: - Some higher-level package managers do not honor Recommends correctly (I do not know the details of this and would love to see a link to the relevant bug), and therefore the Debian GNOME maintainers are very wary of using Recommends in their metapackages See? Two reasonable perspectives. Nothing left to argue about. I'd encourage anyone wanting to move forward to take all three items listed above into account. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120710214627.GA20337@burratino
