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!
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
