Jason Gunthorpe wrote: > Tasks are bettered handled through some kind of non-package means. I've > long said we need to determine some kind of meta-package scheme (a > 'package' whose only purpose is to logically group other packages).
How is introducing some basterdized form of package (perhaps it's just an entry in the Packages file or something), going to allow us to address problems like aj was talking about, where one of the things it depends on is removed from debian, and it needs to be updated? The problem, as I see it, is that task packages declare a strong dependency where often none really exists. After all, if it were a real dependancy, we'd not be having this discussion, since aj/james/whoever's course of action then would have been a lot more clear: remove both packages, or fix one. Thus, it still seems to me that allowing that to be weakened to a reccommends would be the ideal solution. > Clearly the desired effect of all meta-packages is to provide the user > with a single node to manipulate and view a group of packages. They should > have special properties in any UI, you should be able to view and > manipulate their grouped packages. Idillicly the grouping would have > priorities of packages (ie -python doesn't need to install every freaking > package, but some are definately critical) and the ability to track and > optionally install new packages added to the group, remove the whole > group, etc. I don't disagree that all this would be nice, but it seems like icing on a cake that's just hiding the nasty holes. > Logically, the way to represent this is to have package declare their > membership in a grouping. You know, we had this discussion already. Please see the list archives of this winter. We decided this was not the correct way to do it, because metapackages should be maintained by one person. Allowing anyone to add a reverse-dependency and get a package into a metapackage will result in metapackages that are ill-thought-out collections of stuff, without the guiding thought behind them that a real package, with a real maintainer, has. In other words, they would look something like the sections on our ftp site do now, but probably even less organized. Is that game in games/, or x/, or inexplicably, in networking/? :-P Compare with task-games. I have put a *lot* of thought into what goes into that package. If it did not have one single maintainer, with a coherent vision, it would be a random set of games, probably eventually growing to include a large portion of the games in debian. Which would defeat its purpose. -- see shy jo
