Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de> wrote:

> Look at how gimp treats 'aalib'. It's found
> (without further configure switches) on configure time, and the gimp
> binary is linked against the lib. Now install the lib, and have a problem.

s/install/un\1/ I assume?
Anyway, I see the problem.  However, I do think that, even though it's
related, it's beyond the scope of the SUGGESTS variable as I proposed
it.

> Well, you didn't get the whole picture yet. :)
> 
> There are several kinds of these "soft dependencies:
>  * additional programs which can be executed by the user if present
>    (there's your amanda-plot example)
>  * additional libs (which probably need reconfigure/rebuild/relink)
>    (see gimp & aalib)
>  * additional programs, whic may need additional code to get them run
>    (see compmail & sylpheed)

Given these examples, I would argue that SUGGESTS is only suitable for
solving problems similar to the first one.

It seems to me that anything that actually requires a
reconfigure/rebuild/relink does indeed need to be registered as a
dependency.  The third case (without actually having looked at the
packages you mention) is similar:  if additional code is required to get
the package to run, it is a de facto dependency, no?

As I said, I understand the problem you point out, but I do not believe
that SUGGESTS would be suitable for solving these kinds of problems.
They go deeper and are much more complex.  In fact, I think it would not
be a good idea to combine the solution to these problems with what
SUGGESTS provides.  After all, these problems occur as well when
installing a package B as a dependency of package A or separately
alltogether:  if package C lateron detects package B and builds against
it even though it's not been marked as depending on B, we have the same
situation.

Were we to find a solution to the "implied/unknown/accidental
dependencies" problems, it would affect all installed packages
regardless of whether or not they were installed separately one by one,
as a result of a dependency or because they have been suggested.

Thus, I would argue not to complicate SUGGESTS, but rather look for a
separate approach to those problems.  (Kinda UNIX-like: "Do one thing,
but do it right." ;-)

SUGGESTS was not ment to be (and obviously it is not) a solution to all
"soft dependencies" problems.

Just MHO.

-Jan

-- 
Life," said Marvin, "don't talk to me about life."