[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: