I've been thinking about this over lunch, and I do feel like the gnome metapackage is substantively different than the gnome-core metapackage. I'm not sure if it's sufficiently different to warrant a different decision, but it does seem different enough to warrant a separate discussion.
The historic point of the gnome metapackage is not to just install the base machinery of GNOME in the same way that gnome-core is. It's rather to give the user a complete desktop environment built around GNOME. There have historically been all sorts of applications in there that people may or may not use. It's a fairly "heavy-weight" metapackage; it pulls in everything from office suites to a mail client. We still have the upgrade problem with network-manager from squeeze gnome to wheezy gnome, but I would expect, if I had the full gnome metapackage installed, for quite a lot to potentially change across versions: new applications added or dropped, new implementations of particular common tasks to be blessed upstream, etc. So I'm not sure if that's as strong of a reason to stick with Recommends in that metapackage. To be clear, if I were the GNOME maintainers, I would use Recommends. But I'm not, and I'd rather that they make the call as much as possible. Putting aside the communication breakdowns and the heated arguments and so forth, if just the gnome metapackage issue in its current form had come to us cold, I'm trying to work through what decision I'd make. I'm wondering if we should just document the change to the gnome metapackage in the release notes. I think there's really something to be said for treating this as a compromise position. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
