On Mon, Aug 24, 2009 at 01:16:58AM +0200, Steffen Moeller wrote on
debian-med list[1] but the discussion should be here on debian-devel
(Reply-To is set):
> > Once we are at the topic of web tools: I'm really waiting for an answer
> > from you why you think that mgltools fit in your categories Friends /
> > Enhances-By / ... for autodocktools
> No, I don't think that mgltools are enhanced by autodocktools.
Wasn't it the other way around: mgltools-* are enhancing autodocktools?
At least I understand your Enhanced-By on autodocktools exactly like this.
> I was only looking for some
> indication that says "I am interested in the mgltools packages because I am
> interested in
> autodocktools, but please don't list all the mgltools packages as interesting
> packages in
> their own right, unless you find a bug in them."
And this is exactly what I plan to do when implementing the Enhances
feature. We are just lacking revised Enhanced fields in the Debian
control files. But the process of using this feature might bring the
field more in the focus. Perhaps I will put links to the enhancing
packages as a footnote of the Enhanced package to give us some visible
control what actually is observed. If you don't agree please continue
the discussion on debian-devel where it belongs to.
> > but you refuse to add the Enhances
> > field to the control file of mgltools-*.
>
> I would not say "refuse", it only depends on what you intend to bribe me
> with. :o) I think
> it is wrong. Our misunderstanding may result from differences between the
> semantics of
> "enhances" and may sole motivation that I summarised above.
Yep. That's obvious. ;-)
> Autodocktools depends on the mgltools packages (directly and indirectly).
Yes, sure. Have a look at Debian Policy 7.2.:
`Enhances'
This field is similar to Suggests but works in the opposite
direction. It is used to declare that a package can enhance the
functionality of another package.
So if a package A Suggests package B (or even has a stronger dependency
which IMHO is a direct consequence from the statement above) the
B Enhances A
is definitely a valid setting and covered perfectly by the policy.
I hoped that my long explanation [2] would have clarified the issue.
1. We can not observe *all* dependencies of our packages (like
in the case of autodocktools python and python-central).
2. So let's specify those we *want* to observe and strengthen
the network of dependencies inside the Debian packages by
using a feature documented in Debian Policy.
> The only
> exceptions are mgltools-PMV and mgltools-Vision, which may stand on their
> own, the latter
> is not even used by autodocktools.
Would you mind expressing this as perhaps Suggests in the tasks files?
> Vision is a workflow tool. You can automate what you'd
> manually do with autodocktools. Here, we clearly have a case for the
> "Enhances", Vision
> does enhance autodocktools.
I agree that these packages do enhance autodocktools - but if you say
that the other do not you IMHO are missinterpreting the meaning of
Enhances. The discussion on debian-devel which leaded to the
conclusion[2] shows that my interpretation is not wrong but there is no
real technical use. I'd suggest to take over the interpretation by
providing a technical implementation.
> To me A enhances B, i.e. A improves on B iff A is optional to
> B and when A has a functionality that is not already in B.
And how do you backup this requirement to be optional from the
definition given in Debian Policy? Would you mind bringing it into the
discussion on debian-devel? IMHO the thing is like this: If a man has
only one leg he Depends on his crutches. In turn crutches Enhance the
life of the men. (And the analgoy that Depending on crutches is a
technical requirement while the Enhancement of life is a quality measure
was perfectly intended.)
> However, in the case for the
> mgltools, with the exception of -vision, for all A in mgltools-* : A part-of
> autodocktools. And with A being part of autodocktools, the functionality of A
> is already
> part of the functionality of autodocktools, hence nothing of A can enhance
> autodocktools.
If a package X does not work fully without package Y it is a direct
consequence that package Y enhances X. This is valid from a technical
and from a real life perspective. The fact that Depends is a stronger
relation does not exclude that Enhances is valid as well. Even a
Suggests or Recommends are valid dependency relations if Depends is
technically correct - they are just redundant because the strongest
relation is just specified. Guess why whe do sometimes observe
discussion whether a package should Depend or Recommens an other
package or why Recommends or Suggests are sometimes borderline cases.
> One may argue that autodocktools enhances PMV. I would not fight against
> that. But we have
> that dependency already.
There is no harm done - this is exactly the case which is covered by
the explanation in policy (opposite direction). IMHO we should weave
a stronger net between the packages we have in our tasks file. If
we consider those packages who have dependencies with each other we
might gain some new clues about them. So let's be outright with
specifying dependenices.
> With vision enhancing autodock, we want to stress the importance of vision
> for us. This
> would be fine with me (in the case of vision). But all the other packages to
> which you
> desire to add "enhances" don't enhance autodocktools, they are just part of
> it. And I want
> to hide them, not stress their importance.
As I told you above: This is my plan when interpreting the Enhances
field. Mentioning only those packages which are explicitely Depends /
Recommends / Suggests in the tasks files and observe those packages
which are enhancing one of them as well in the bugs pages. As I said I
might also start with links to packages.qa.debian.org at the relevant
place as kind of a footnote or something like this just to keep us
developers informed what is observed in addition. Not less and not more
will be the technical implementation of the Enhances field in the Blends
context. And in the general Debian context it fits the documented
meaning in Debian Policy.
> I think that (as a start at least) we should leave the debian/control fields
> for the
> reasons that Debian wanted them initially. Or not use them at all until we
> know what we want.
I'm just lacking a proof for the statement that Debian had a different
meaning in mind. I checked on debian-devel. Did you followed the
thread?
> To learn what we want, and to help communication between ours, I suggest to
> edit the
> blends' tasks file with the information that we want to interpret. Should we
> then find,
> that we use a term in the exact same way that Debian has already thought
> about using some
> (not necessarily syntactially identical) term or combination of terms, then,
> well, sure,
> let us use the Debian one(s) and transfer the information into debian/control
> or
> elsewhere. I don't think we are there, yet.
Please verify whether we are really not there and try to clarify it
on debian-devel. (Well, I'll copy that part of
Kind regards
Andreas.
[1] http://lists.debian.org/debian-med/2009/08/msg00111.html
[2] http://lists.debian.org/debian-devel/2009/08/msg00678.html
--
http://fam-tille.de
Klarmachen zum Ändern!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
