Hi,
This message is about circular dependencies in BLFS, and the way to resolve
them automatically for jhalfs, so it belongs to both alfs-discuss and blfs-dev.
Let us first introduce some notation (BTW, please read this message with a
monospaced font):
a -> b: means "a directly depends on b". Note that we may use a -d> b, where
d is 1, 2, or 3 to denote respectively required, recommended, or optional
dependency. For example freetype2 -2> harfbuzz
a <- b: means "a is a direct dependency of b". We may need the notation
a <d- b, for example harfbuzz <2- freetype2.
I think there is only one circular dependency at the recommended level:
freetype2 <2-2> harfbuzz
but there are a lot of cycles of various lengths at the optional level:
a -> x1 -> * -> b -3> c
/|\ |
| \|/
yn <- * <- * <- y2 <- y1
For example harfbuzz <3-3> graphite2
Note that in the xml, we have the information on the dependency and its
requirement level, but no help in deciding which package(s) should be built
twice, in order to satisfy all dependencies, except in natural language (which
xslt is not supposed to interpret). For example, we know that the right order
is freetype2-pass1 <- harfbuzz <- freetype2-pass2 only from reading sentences,
not from parsing tags or attributes in the xml... So ATM, there *cannot* be
any algorithm able to decide whether it should be
freetype2-pass1 <- harfbuzz <- freetype2-pass2
or
harfbuzz-pass1 <- freetype2 <- harfbuzz-pass2
I propose to introduce an additional role attribute in the dependencies:
role="first". For example if, in the above big cycle, we have <xref
role="first" linkend="y1-id"/> in the dependencies of c, it would mean: "break
the cycle as follows:
y1-pass2 -> y2 -> * -> * -> yn -> a -> x1 -> * -> b -3> c -> y1-pass1
and remove y2 from the dependencies of y1-pass1"
We would have in the harfbuzz dependencies:
<xref role="first" linkend="freetype2"/>, which means "break the cycle as:
freetype2-pass1 <- harfbuzz <- freetype2-pass2
and remove harfbuzz from the dependencies of freetype2-pass1".
But this is not the end of the story, because we may enter the cycle at any
point. Let's say that we enter at package a, that is something like this:
requested package -> * -> parent -> a -> x1 -> * -> b -3> c
/|\ |
| \|/
yn <- * <- * <- y2 <- y1
If we apply the above resolution, we would end with:
requested package -> * -> parent -> a -> x1 -> * -> b -3> c -> y1-pass1
and now, nothing depends on y1-pass2 -> y2 -> * -> * -> yn
so that those packages might not be built... This may happen for example with
the harfbuzz <-> freetype2 cycle if we enter the cycle at harfbuzz...
So the solution would be to make y1-pass2 a dependency of parents:
requested package -> * -> parent -> a -> x1 -> * -> b -3> c -> y1-pass1
_\|
y1-pass2 -> y2 -> * -> * -> yn
Don't know whether it is clear, but I will apply this if you agree to add this
new role to the book
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
