On Wed, Aug 19, 2009 at 11:26:24AM +0200, Raphael Hertzog wrote:
> > How do you imagine a technical implementation of a 'Enhances' field?
> > Something
> > like 'apt::install-enhances'?
I do not *want* this personally - I just wanted to know if any tool
makes use of this field in some way.
> The Enhances field like the Suggests field is just about informing the
> user of packages that are related and that he might want to look at.
With the differenscet that you have the (really weakly documented
#473089) option to actually use a tool on the Suggests field and nobody
knows how to use Enhances, which means the feld seems to be a structured
way to put some kind of text like "This package might be nice to have as
an enhancement of package foo" into the long desription.
> So
> in user interfaces where you present suggested package of package A you
> should also include packages which have Enhances: A.
This was exactly my assumption: Have an equivalent to Suggets which
is under control of the maintainer of package "B".
> IIRC that's the only goal that we ever wanted to reach with that field.
OK.
> Auto-installing suggested packages is not really a good idea as you have
> witnessed.
Well, there *might* be users who might consider this as a feature
(probably a subset of those users who use "-o 'Apt::Install-Suggests=1'"
- is this the reason why it is so weakly documented to keep the set as
small as possible?).
> But I don't know of any tool that implements this (even if it doesn't look
> like complicated).
Well, the background of my question was that I actually am considering
using it in the Blends framework because it comes really cheap when
using UDD. I just wanted to make sure that I will not missuse a feature
which I do not completely understand.
Short background: We are listing in the tasks file for med-bio all
packages which are relevant for biology and it turned out that there
are some packages amongst them which are not really intended to be used
on their own but just provide some extre functionality. The idea came
up to specify this by:
Recommends: <main_package>
Enhanced-By: foo, bar
I had the idea that this information would be redundant if foo and bar
would have Enhances fields properly set in their control files. The
real use I had in mind for this field was that on the Blends bugs pages
also those packages should show up which are related to our workfield
even if not explicitely listed in the tasks file. The goal of a Blends
packaging team should be to care for all packages related to the use
in a specific workfield.
Once I started thinking about this idea it came to my mind that we
consequently should also list those packages with "Depends / Recommends
/ Suggests" relations. But if all these would be included we would
probably loose the focus on our main target of tasks specific packages.
That's why I'm currently in favour to *only* regard those Enhances
relation having the fact in mind that the "Enhances" field is more a
contextual information in contrast to a technical information (to Depend
from a certain library or something like this).
The discussion here seems to prove this point that the "established"
dependencies "Depends / Recommends / Suggests" are rather used in a
technical context (and thus are featuring technical implementations)
while the "Enhances" field is more in the context of a use case - which
is exactly what we are targeting for in the Blends effort.
Besides watching those Enhancing packages in our bugs view we might
consider adding a specific lower priority status on the tasks pages
but I have not yet made up my mind about this.
Please correct me if my considerations are wrong or if my intention
might overstress the intended use of this field.
Kind regards
Andreas.
--
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
