Subject: Re: RFC: new variable SUGGESTS
To: None <firstname.lastname@example.org>
From: Jan Schaumann <email@example.com>
Date: 07/21/2002 23:53:54
Hubert Feyrer <firstname.lastname@example.org> 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
> 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
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.
Life," said Marvin, "don't talk to me about life."