Re: RFC: proposal for indirect deplibs

[Thien-Thi Nguyen]

Ralf Wildenhues <address@hidden> writes:

   [definitions]
   Does that make more sense?

yes thanks, i find "base" and "derived" easier to understand.

   What exactly do you mean with these terms?  (I have a vague idea
   but would rather like to know a precise definition.)

in trying to be more precise, i abandoned the idea of distinguishing
fatal vs. non-fatal or even foo vs. non-foo.  now i think it is better
to think along general terms: "edge attributes".  whether or not a
particular edge attribute has a value is another question.

for example, if we allow values, the pair "closeness / zero" is another
way of saying "direct", and "closeness / non-zero" another way of saying
"indirect".

if we do not allow values, the attribute "direct" means "direct" (wow,
complicated!), and the lack of that attribute means "indirect".

in any case, we can further characterize the relationship between things
by adding (i.e., recognizing and handling) more attributes.  i had in
mind "fatal" as one particular attribute (valid only for indirect edges)
that means roughly "if this base lib is not included the derived object
cannot start".  but that's still rather fuzzy.  what/when does "start"
mean, etc?  please ignore that malformed idea.

regardless of the merit (or lack of merit) of "fatal" as an attribute, i
propose looking at edges from the attributes point of view rather than
the categories point of view.  (does that make sense?)

   Since it is in general impossible to find out which library
   dependencies are directly or indirectly derived by looking at the
   source

yes, the best we can do is provide a way for people to describe the
relationships fully, resorting to heuristics as little as possible.

thi