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

[Andreas Tille <andreas@an3as.eu>]

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

-- 
http://fam-tille.de