With the way we manage "first" deps, it may happen that no node
unreference the pass2 node. In that case, we add it to root.
Add some documentation for what we do for those deps, too.
Better document the $seen global variable used in path_to,
also at places where "path_to" is called.
Document p and b flags in the loop over "after" deps.
Document lr variable in the loop over "first" deps.
deps only for requested packages), it may happen that a requested packages
is seen at depth > 2 before it is seen at depth=2. In this case, optional
deps are not processed the first time, and then the package is not processed
at depth 2 because it has already been seen. Add a case statement against
that.
- Even if only required or recommended deps only are requested and built,
account for optional deps to build the pacakge order
- build "runtime" deps after the pacakge dependening on them, but before
any other package
- using the "first" role in the book, implement pass1 pacakges when there
are circular dependencies
- Documentation has still to be written
- There must be bugs, thank you for testing...
- the problem is when a .dep file contains pack-A pack-B pack-A. If pack-A
and pack-B have some dep in common, say pack-C, that dep is erased from
pack-B, with the idea that it will be built as a dep of pack-A. But when
the program encounters the second pack-A, it removes the first one, so that
pack-C is built before the second pack-A, but after pack-B. Sorting was
a good workaround, but removing the last line instead of the first is
much better.
- Otherwise, add Xfce and Lxde to the list of packages whose preceding
sibling is a required dep.
When the .dep file is scanned during the tree building, it outputs dependencies
in the file order, while when the tree is scanned later, dependencies are
output in alphabetical order. This may eventually lead to a wrong order
at the end. To be sure that both output are the same, just sort
the .dep file before scanning it.
