Re: Bug#99835: seemingly useless and ill-conceived "meta" packages
Anton Zinoviev wrote:
> I know about that task packages are going to be obsoleted by Task: field
> and that's why I made meta-magicfilter and meta-apsfilter. The
> maintainer of recode doesn't have to know that recode is used by some
> filters of magicfilter. Why he has to know that his package is relevant
> to task `Printing'? And why he has to know that some future version of
> magicfilter don't use recode any more? That's why in my opinion the
> task `Printing' should install meta-magicfilter but not directly
> magicfilter and supporting filters.
The Task: fields are populated by an overrides mechanism, which comes
out of some files in debian cvs that more or less anyone can modify.
> No. I didn't know what do you think about these metapackages. On the
> other side I had submitted an ITP for task-printing and I decided that
> it is better for task-printing to depend on meta-magicfilter than
> directly on magicfilter and other filters. And I didn't know that you
> had made task `Print Server'.
My main beef with the meta-* packages is that they seem to create a bad
predicent that is likely to prove very confusing to users. I'm all for
meta packages, but only if they do not have meta- in their name. This
generally means they have to have a slightly broader scope. For example,
we'll probably have a x-window-system-core meta package eventually (more
or less like the task-x-window-system-core). This is useful because it
will let the maintainer of X easily determine what goes into the X task,
plus it will be useful for users to install the metapackage by hand. By
contrast, your meta- packages don't seem to ease maintainance of the
printing task really, since you could just maintain it in cvs, and they
seem more likely to confuse users.
--
see shy jo
Reply to: