Re: Potato now stable
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
Reply to: