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. 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
I understand the concept and what you are trying to do, but I'm afraid the notation is a bit unclear to me. I'll have to study it a bit.
To answer DJ about attributes like role, generally you can have more than one value, for instance role="a b c" for three different roles. At least it works that way in html/css. I'd have to test it for xsl stylesheets.
I'll also note that for users, a very hard question is "Do I need this optional dependency?" You have to know what it does and if something else needs it. I generally do not script multiple packages. I like to review the optional dependencies and build some, but not all as I build up my system.
-- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
