Steve Langasek wrote: > From what I can tell, the only difference between the two implementations is > compatibility with disabling installation of Recommends by default. > > I don't think this is a good rationale for adding yet another package > relationship field. The Recommends field is *already* defined in Policy to > have the behavior you're looking for (installed by default but not a hard > requirement), and I don't see any reason that metapackages should need the > added complexity of a different field.
Without this metapackage thing, the only option we have is to have so many many metapackages, so we can choose one of them. This is not very nice, because that means that maintainers have to have the will to do it (which wont ever be the case for all of them). Which is why a real system to manage this would be nice. Another point would be that a meta-package could add a new meta-dependency in a new release. > Try to change your POV from the uber-user, who knows how to install "base" > packages and let others be pulled in, to the low-level users, which want > "gnome" installed, but don't want "rhythmbox" nor "banshee" installed. This > is what they do (writing the CLI version, but they're likely to use > something like Synaptic): > > # aptitude install gnome > # aptitude remove rhythmbox > > OOPS! Since aptitude does "autoremove" by default, the users suddenly get > asked to remove all their desktop environments. How many requests of this > type have you seen on IRC, mailing lists, Usenet? I've seen *TOO MANY*, and > that's why I drafted this DEP in the first place. EXACTLY! This is not only because of requests, this has annoyed everyone for a long long time. > Then I suggest you just help converting the gnome metapackage to a > task, since this'll work with no intrusive changes in our tools. Well, the issue is not ONLY with gnome, there are many many more. For example the X system installing all drivers, then you want to remove few of them that you don't care and identify as not for you, but keep all the rest of "just in case". I see few other examples in packages that I maintain myself where removing 1 or 2 package could be nice, still keeping new packages that would come with the metapackage in case of an upgrade, and giving freedom to users to do what they want. Andreas Metzler wrote: > The current proposal is not backwards compatible since it fundamentally > changes the meaning of Depends. Depends is transitive. If A depends on > B, and B depends on C. A can rely on functionality proveided by C. > Your proposal breaks that, since it allows removal of C (assuming B is > a meta package), keeping it installed in a broken state. > > I am not convinced that the gain (easily install KDE without kmail, or > something like that) is worth this price. It changes a clear relation > to something that most of the times works as expected, except for some > special cases. I do agree that the proposed implementation is bad, and that Depends should not change meaning. I do like more the Meta-Depends: instead of Depends: if we want to keep the original idea. How about having a differentiation about the idea and the implementation in this discussion? :P Also, I think having a Metapackage: yes field IS a good idea anyway, even if there's absolutely NOTHING ELSE implemented with it but search functionalities, which would be very convenient (unless there's also Meta-Depends, but we could imagine a package that would like the functionality of Meta-Depends and still not being a Meta-Package and installing useful files...). Does the majority agree with me on that point here? Just my 2 cents, as I wont be the one implementing anything... :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
