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

[Andreas Tille-5]

On Tue, Aug 18, 2009 at 03:46:50PM +0200, Steffen Moeller wrote:
> > Enhanced-By: autogrid
> >
> >> +Depends: autodocktools
> >> +Friends: mgltools-dejavu, mgltools-pmv, mgltools-utpackages, mgltools-vision, mgltools-volume
> > Enhanced-By: mgltools-dejavu, mgltools-pmv, mgltools-utpackages, mgltools-vision, mgltools-volume
> >
> > What do you think?
> >  
> I'll go for it ... good to hear you like it (I was not sure).

As you might have noticed I tried to investigate a bit [1] about the
role of the Enhances field because thinking twice about it the suggested
Enhanced-By field sounds somewhat redundant.  IMHO we could do better if
we consistently maintain the Enhances field where needed and there is no
real need to put this information into a different place.  So I tried to
find out what Enhancement relations we currently have in the Debian Med
tasks.  Here is a raw logfile output after grep-ing 'enhanc':

The following packages are enhancing loki: ['loki-doc']
The following packages are enhancing blast2: ['mcl']
The following packages are enhancing seaview: ['muscle']
The following packages are enhancing t-coffee: ['dialign-tx', 'clustalw', 'mafft', 'kalign', 'poa']
The following packages are enhancing emboss: ['clustalw', 'primer3']
The following packages are enhancing clustalw: ['clustalw-mpi']
The following packages are enhancing gamgi: ['gamgi-doc', 'gamgi-data']
The following packages are enhancing rasmol: ['rasmol-doc']
The following packages are enhancing ncbi-tools-bin: ['mcl']
Unknown key 'Enhanced-By': autogrid in task bio
Unknown key 'Enhanced-By': mgltools-dejavu, mgltools-pmv, mgltools-utpackages, mgltools-vision, mgltools-volume, mgltools-bhtree, mgltools-geomutils, mgltools-opengltk, mgltools-pyglf, mgltools-sff, pdb2pqr in task bio
The following packages are enhancing mustang: ['mustang-testdata']
The following packages are enhancing bioperl: ['exonerate', 'mcl']
The following packages are enhancing bioperl-run: ['clustalw']
The following packages are enhancing mcl: ['zoem']
The following packages are enhancing r-base: ['texmacs']
The following packages are enhancing gnumed-client: ['gnumed-doc']


IMHO it might make perfectly sense to add

  Enhances: autodock

in debian/control of autogrid as well as

  Enhances: autodocktools

to the control information of all the mgltools-* packages.
IMHO this is more consistent and makes sense in general and not only
in the Blends scope while serving the same purpose.

What do you think?

Kind regards

         Andreas.

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

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


--
To UNSUBSCRIBE, email to debian-blends-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steffen Moeller-3]

Hello,

Andreas Tille wrote:

> On Tue, Aug 18, 2009 at 03:46:50PM +0200, Steffen Moeller wrote:
>>> Enhanced-By: autogrid
>>>
>>>> +Depends: autodocktools
>>>> +Friends: mgltools-dejavu, mgltools-pmv, mgltools-utpackages, mgltools-vision, mgltools-volume
>>> Enhanced-By: mgltools-dejavu, mgltools-pmv, mgltools-utpackages, mgltools-vision, mgltools-volume
>>>
>>> What do you think?
>>>  
>> I'll go for it ... good to hear you like it (I was not sure).
>
> As you might have noticed I tried to investigate a bit [1] about the
> role of the Enhances field because thinking twice about it the suggested
> Enhanced-By field sounds somewhat redundant.  IMHO we could do better if
> we consistently maintain the Enhances field where needed and there is no
> real need to put this information into a different place.  So I tried to
> find out what Enhancement relations we currently have in the Debian Med
> tasks.  Here is a raw logfile output after grep-ing 'enhanc':

...

> What do you think?

I must admit that I was completely unaware of the reverse-suggests. I never used it, but
you are right. It should be used more.

For our purpose, which is to hide packages from being displayed as individual tasks since
they have more the character of a helpers' application, the "enhances" is not appropriate.
E.g. we want to show clustalw even though we show emboss.

While writing, how about (for our tasks specs):

Recommends: autodock
Hides: autogrid

Cheers,

Steffen



--
To UNSUBSCRIBE, email to debian-blends-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

On Thu, Aug 20, 2009 at 01:54:14PM +0200, Steffen Moeller wrote:
> I must admit that I was completely unaware of the reverse-suggests. I never used it, but
> you are right. It should be used more.

Definitely.  I'd suggest doing it immediately in SVN if you are aware of cases
where it is missing.
>
> For our purpose, which is to hide packages from being displayed as individual tasks since
> they have more the character of a helpers' application, the "enhances" is not appropriate.
> E.g. we want to show clustalw even though we show emboss.

Sure.  Every package which is listed in the tasks file will be
explicitely mentioned.  So clustalw as well as emboss are listed when
using the current tasks file. But *if* you would intend to hide clustalw
you could remove it from the tasks dependencies.  It would show up only
where we show Enhances (in whatever form this might be implemented and I
did not made up my mind about an implementation yet).

So it is with your mgltools.  They are not mentioned in the tasks file -
so they do not show up. But *if* they would have the Enhances tag properly
set they could brought into our attention by using some technical means
(which have to be implemented somehow - but as I have shown this is comes
quite cheap with UDD; I have their names, so they are under control).
 
> While writing, how about (for our tasks specs):
>
> Recommends: autodock
> Hides: autogrid

Well, we just have "Ignore" (see [1]) which is probably what you want.
But "Ignore" is just what it says: it is ignored.  And you also want to
specify an inter-package relation.  Ignore does not build a bridge
between autogrid and autodock - but the Enhances field in the control
file perfectly does.  So adding extra packages using Ignore is a nice
kind of documentation inside the tasks files.  But Enhances is stronger
and enables further processing while Ignore is more kind of a
documentation.
 
Kind regards

     Andreas.

[1] http://blends.alioth.debian.org/blends/ap-DevelDescription.en.html

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


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Thu, Aug 20, 2009 at 10:12:10AM +0200, Andreas Tille a écrit :
> The following packages are enhancing bioperl: ['exonerate', 'mcl']

Hi all,

they probably should better enhance bioperl-run, which contains a wrapper to
run them. If nobody objects, I will correct them.

Have a nice day,

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

On Thu, Aug 20, 2009 at 10:12:06PM +0900, Charles Plessy wrote:
> they probably should better enhance bioperl-run, which contains a wrapper to
> run them. If nobody objects, I will correct them.

You are the expert!  I'm happy that we detected the next feature
to enhance the quality of our packaging.

Kind regards

        Andreas.

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


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steffen Moeller-3]

Hello,

Andreas Tille wrote:

> On Thu, Aug 20, 2009 at 01:54:14PM +0200, Steffen Moeller wrote:
>> I must admit that I was completely unaware of the reverse-suggests. I never used it, but
>> you are right. It should be used more.
>
> Definitely.  I'd suggest doing it immediately in SVN if you are aware of cases
> where it is missing.
>> For our purpose, which is to hide packages from being displayed as individual tasks since
>> they have more the character of a helpers' application, the "enhances" is not appropriate.
>> E.g. we want to show clustalw even though we show emboss.
>
> Sure.  Every package which is listed in the tasks file will be
> explicitely mentioned.  So clustalw as well as emboss are listed when
> using the current tasks file. But *if* you would intend to hide clustalw
> you could remove it from the tasks dependencies.

ok. so we have autogrid removed. but we see bugs, still, since autodock recommends
autogrid, right? And the Enhances is kind of redundant in this respect?!?

> It would show up only
> where we show Enhances (in whatever form this might be implemented and I
> did not made up my mind about an implementation yet).

> So it is with your mgltools.  They are not mentioned in the tasks file -
(you removed them, this means)
> so they do not show up. But *if* they would have the Enhances tag properly
> set they could brought into our attention by using some technical means
> (which have to be implemented somehow - but as I have shown this is comes
> quite cheap with UDD; I have their names, so they are under control).

I agree that autodocktools enhances autogrid and also autodock. 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.

>> While writing, how about (for our tasks specs):
>>
>> Recommends: autodock
>> Hides: autogrid
>
> Well, we just have "Ignore" (see [1]) which is probably what you want.
> But "Ignore" is just what it says: it is ignored.  And you also want to
> specify an inter-package relation.  Ignore does not build a bridge
> between autogrid and autodock - but the Enhances field in the control
> file perfectly does.  So adding extra packages using Ignore is a nice
> kind of documentation inside the tasks files.  But Enhances is stronger
> and enables further processing while Ignore is more kind of a
> documentation.

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 :)

How about something like

Recommends: autodocktools
Bugs-only: mgltools-*

Better than "Bugs-only" is probably something like "Bugs" or "Monitor".

Many greetings

Steffen


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

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-blends-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

Hi,

I'd like to give an update on the "Enhances" issue.  For the moment our
development instance of the webtools (debian-med.debian.net and
blends.debian.net) are running some new code which displays the packages
which are enhancing a package at the bottom of the long description (if
there is any such package).  Watch out for strings

   "The package is enhanced by the following packages:"

to see what I mean - there are not that many currently.  This is to have
a first overview, which packages are concerned in this topic.  As I told
you my plan is to include those enhancing packages into our bug
sentinel.  The reasoning for using this control field is given below and
in a discussion on debian-devel.

Steffen, you had problems with this but did not responded to my last
mail even if I explicitely asked you to.  So I assume you are either
overworked or convinced.  I would like to continue with this topic and
need a decision.  So I will *assume* you agree if I turn your

  Enhanced-By

fields in the tasks files into

  Enhances

fields in the package in question in our SVN to let it propagate with
the next upload.  Please tell me if you think this is not a good idea
and you are not happy with this change.

Kind regards

     Andreas.

PS: BTW, the development servers at debian.net have another new feature:
    For group maintained packages you can now see the name of the last
    uploader as well.


On Thu, Aug 20, 2009 at 06:37:58PM +0200, Andreas Tille wrote:

> 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-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>
>

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-blends-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steffen Moeller-3]

Hi Andreas,

Andreas Tille wrote:

> I'd like to give an update on the "Enhances" issue.  For the moment our
> development instance of the webtools (debian-med.debian.net and
> blends.debian.net) are running some new code which displays the packages
> which are enhancing a package at the bottom of the long description (if
> there is any such package).  Watch out for strings
>
>    "The package is enhanced by the following packages:"
>
> to see what I mean - there are not that many currently.  This is to have
> a first overview, which packages are concerned in this topic.  As I told
> you my plan is to include those enhancing packages into our bug
> sentinel.  The reasoning for using this control field is given below and
> in a discussion on debian-devel.
>
> Steffen, you had problems with this but did not responded to my last
> mail even if I explicitely asked you to.  So I assume you are either
> overworked or convinced.  I would like to continue with this topic and
> need a decision.  So I will *assume* you agree if I turn your
>
>   Enhanced-By
>
> fields in the tasks files into
>
>   Enhances
>
> fields in the package in question in our SVN to let it propagate with
> the next upload.  Please tell me if you think this is not a good idea
> and you are not happy with this change.

I feel mentally absobed, indeed. I don't agree, but let us see what happens.
How one names attributes we can still talk about at some later time.

Have many thanks for your efforts, I am curious to see what happens

Steffen




--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...