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

Re: Enhances field (Was: r1771 - projects/med/trunk/debian-med/tasks)



On Thu, Aug 20, 2009 at 06:05:50PM +0200, Steffen Moeller wrote:
> ok. so we have autogrid removed.

Not really removed because it was not really in the tasks file before
(at least not for the last couple of weeks).  I think you removed it
yourself some time ago).  The fact that you added it as

  Enhanced-By: autogrid

is just a comment which is completely ignored by all tools (at least for
the moment until we actually do something about this field - and *if* we
might do this at all).

> but we see bugs, still, since autodock recommends
> autogrid, right?

Now, wrong. *Currently* I do *not* regard *any* indirect dependency
relation inside the bugs view.  Only the explicite dependencies that are
specified in the tasks file (Depends/Recommends/Suggests) are regarded
for the bugs view.  IMHO this makes perfectly sense because just pulling
in all implicite dependencies of these packages might make this a really
long list of packages which are not relevant for our topic at all. (Want
to see libc problems in our bugs view?)

So if we do not have a reasonable means which of the implicite dependencies
might make sense I would be hesitant to do so.  If you try to follow my
arguing in the relevant thread in devel (specifically [1]) you might
come to the conclusion that exactly Enhances might give us a hint which
concerns the *topic* of our Blend rather than pulling technical packages
in.

> And the Enhances is kind of redundant in this respect?!?

Not at all - that was the main point of my reasoning.
 
> I agree that autodocktools enhances autogrid and also autodock.

Well, I have no idea about all these packages nor their relations to
each other.  The main points are:

  1. Is it ensured that any user will *really* find what he is
     looking for and will the tasks pages informative about all
     issues a user might be interested?

  2. Are we sure to stay informed about problems in all these packages ?

> The remainder of the
> mgltools though I would not want to tag as enhancers. The are just "Molecular Graphics
> Lab's TOOLS", in my view.

Well, if they have any use for users in the field of Biology than we
should make sure that they will be spotted.  I have no idea about these
as well - but I see no point in hiding them from the view of our users
who really might look for *just* "Molecular Graphics Lab's TOOLS".

I really fail to see the logic why you tried to add these packages as
Friends / Enhanced-By to get them spotted (which is not effective because
which user actually *reads* the tasks file and on the other hand refuse
to use the Enhances field which *is* at least shown in the package
information.  That sounds completely strange to me.
 
> Hm. The Enhances should remain in the control files and we can use that info just the way
> you are suggesting it: something that enhances a package that is on our tasks list, that
> should be scrutinised for bugs, too. But for mgltools this does not work, also since a
> series of mgltools* libraries the autodocktools package only indirectly depends on. And if
> we'd perform a closure, then we'd soon also involve libc6, probably :)

That's what I try to avoid by not taking Depends / Recommends / Suggests
into account and prefer Enhances as a marker for us.
 
> How about something like
> 
> Recommends: autodocktools
> Bugs-only: mgltools-*

IMHO you try to invent Blend specific solutions for problems which are
just solved in Debian in general.  I can not follow your reasoning why
Enhances is not a good option.
 
> Better than "Bugs-only" is probably something like "Bugs" or "Monitor".

I'd consider this only in the case that somebody convinces me that
Enhances is not useful to solve the problem.

Kind regards

     Andreas.
 

[1] http://lists.debian.org/debian-devel/2009/08/msg00678.html 

-- 
http://fam-tille.de
Klarmachen zum Ändern!


Reply to: