On 01/11/2015 18:51, Bruce Dubbs wrote:
Pierre Labastie wrote:
Hi,
I do not know who monitors this list,
I do that.
Now, the BLFS part offers much more room for improvement:
I don't use jhalfs for BLFS, but there are a couple of tools I'd like to see
for it. I'd like a tool to print out the dependency tree for a package. For
instance,
dependencies package-name [required | all]
would look at the dependencies of for example, parted, and give a tree of
packages needed. The normal output would be required+recommended, but the
optional argument 'required' would give just required dependencies while 'all'
would give required+recommended+optional. It would look something like:
$ dependencies parted
parted-3.2
LVM2-2.02.133
$ dependencies parted all
parted-3.2
LVM2-2.02.133
[...]
X Window System
I wouldn't expand 'X Window System'. I didn't finish the above, but you get
the idea. This is far from a trivial program. The circular dependencies need
to be handled in some way and there probably would need to be some changes to
the book to flag dependency issues.
Actually there are two ways of treating the circular dependencies, and I'd
like some advice. First, let's see how we figure out a circular dependency:
- the tool works by recursively building the dependency tree, say (-> means
"depends on", and please use fixed width fonts for viewing):
->C1
/
->B1-->C2
/
A-->B2-->C3
\
->B3-->C4
\
->C5
- at a given point in the building process, we detect that one of the paths
from root to node has the form:
root-->...-->P-->D1-->D2-->...D(n-1)-->Dn-->D1, that is, D1 is a dependency of
Dn, but D1 has already been seen in the path from root to node.
So we have to "break" the circle. First, we have to choose a link where to
break.
Presently, the tool asks whether the user wants to build Dn before D1 (answer
no) or D1 before Dn (answer yes). In the first case, it is easy, just break
between Dn and D1 (the last dep above), and forget about the second D1. In the
second case, the tools puts Dn as a dependency of P, and starts over from P,
that is, it builds:
...->P->Dn->D1->D2...->D(n-1)->Dn and the tool asks again. If the user answers
yes (build Dn before D(n-1)), then the tool generates:
...->P->D(n-1)->Dn->D1->D2... etc, until the user answers no (hopefully before
coming back to the original situation). That can be a very slow process,
because other circles may be met in the process, and so on.
I suggest to change this behavior, and that the tool choose itself where to
break. The idea is to break at the first minimal priority
(optional < recommended < required) that is found when reversing the path from
D1 to D1. Let's say the minimal priority in the circle is optional. If Dn->D1
is optional, then we break at Dn and forget about the second D1. If not, then
we try D(n-1)->Dn, D(n-2)->D(n-1), etc, until we find an optional dependency,
say D(i-1)-->Di.
Then, we have two choices:
(a) Break at D(i-1), and forget about the remaining part of the circle
(Di->...->Dn)
(b) Break at D(i-1), but keep the whole circle starting at Di, that is, build
the following path:
P->Di->...->Dn->D1->...D(i-1)
Choice (b) takes better consideration of the dependencies, since although they
are built after D1, the dependencies Di to Dn are built, while choice (a) does
not even build them.
Right now, I have a beta version with (b). I do not think it'd be harder to do
(a). What do you think?
(sorry if I have not made this clear, it is hard to explain...)
