On Sat, Jan 13, 2018 at 07:15:13PM +0100, Pierre Labastie wrote:
> 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.
>
Only brief comments, so snipping most of it. And I'm not subscribed
to alfs-discuss, so although I'm replying to all I'm not sure if it
will get hrough.
> 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.
>
For the explanation, I have read this veeeery slowly, because my
inclination is to read arrows as some form, of "leads to" or
"enables", so I assume a -> b has something to do with building a
before b, and similarly I assume a <- b implies that a is built
after b. But I think I've gotthe gist of what you are showing.
[...]
>
> 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 understand the problem
> 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".
>
I think I'm going to have trouble remembering this (as an editor - I
assign dependencies _manually_ in my scripts so that I can cover
what _I_ want to do). No objection to putting it in, but it feels
very strange.
> 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
I'm afraid you lost me completely there. If it works for jhalfs, do
it - but please watch out for accidental future breakage.
ĸen
--
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
- Unseen Academicals
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
