This occurs on a uclibc system where util-linux pulls in the following dependency: uclibc? ( ${AUTOTOOLS_DEPEND} ) Reading autotools.eclass, this should pull in || ( >=sys-devel/automake-1.11.1:1.11 >=sys-devel/automake-1.12:1.12 ) >=sys-devel/autoconf-2.68 sys-devel/libtool When I do emerge -evp util-linux, I get the expected result, where autoconf, automake and libtools are emerged before util-linux. But when I do emerge -evp @world or @system, I do not! This hits hard during a catalyst stage3 build where util-linux breaks because of the order. I'll attach the results below.
Created attachment 327210 [details] Result of `emerge -evp util-linux`
Created attachment 327212 [details] Result of `emerge -evp @system`
Created attachment 327214 [details] Result of `emerge -evp @world`
(In reply to comment #0) > When I do emerge -evp util-linux, I get the expected result, where autoconf, > automake and libtools are emerged before util-linux. But when I do emerge > -evp @world or @system, I do not! There are probably some circular dependencies in there. Please attach a debug log created as follows: emerge -evp @system &> debug.log > This hits hard during a catalyst stage3 build where util-linux breaks > because of the order. The dependencies should all be installed though, so why is it failing? Typically, these kinds of issue are best solved by using a USE dependency to ensure that the dependencies are properly satisfied. For stage builds, it may be something like foo/bar[build=], since stage1 packages built with USE=build sometimes have special properties.
(In reply to comment #4) > (In reply to comment #0) > > When I do emerge -evp util-linux, I get the expected result, where autoconf, > > automake and libtools are emerged before util-linux. But when I do emerge > > -evp @world or @system, I do not! > > There are probably some circular dependencies in there. Please attach a > debug log created as follows: > > emerge -evp @system &> debug.log The output is identical to the attachment in comment #2. I'll upload it next anyhow. > > > This hits hard during a catalyst stage3 build where util-linux breaks > > because of the order. > > The dependencies should all be installed though, so why is it failing? > Typically, these kinds of issue are best solved by using a USE dependency to > ensure that the dependencies are properly satisfied. For stage builds, it > may be something like foo/bar[build=], since stage1 packages built with > USE=build sometimes have special properties. I hit it first in catalyst stage3, but it is not a catalyst issue. I'm seeing it in a virtual machine where I get 1) sys-devel/autoconf and sys-devel/automake being pulled *before* util-linux when I do emerge -e util-linux 2) But these are pulled in *after* if I do emerge -e @system. This makes no sense. The dependency is there ... uclibc? ( ${AUTOTOOLS_DEPEND} ). If you add an ewarn to src_prepare() where you print out ${AUTOTOOLS_DEPEND} you get that util-linux should DEPEND on sys-devel/autoconf and sys-devel/automake. So why is point 2 happening? Thinking that maybe I was misreading the class etc, I even replaced ${AUTOTOOLS_DEPEND} explicitly with sys-devel/autoconf sys-devel/automake with the same result. Somehow -e @system is not calculating that autoconf and automake need to be built before util-linux is.
Created attachment 327260 [details] emerge -evp @system &> debug.log
I'm sorry, I meant to say to use --debug for debug.log, like this: emerge -evp @system --debug &> debug.log
(In reply to comment #5) > I hit it first in catalyst stage3, but it is not a catalyst issue. I'm > seeing it in a virtual machine where I get > > 1) sys-devel/autoconf and sys-devel/automake being pulled *before* > util-linux when I do emerge -e util-linux > > 2) But these are pulled in *after* if I do emerge -e @system. > > This makes no sense. > > The dependency is there ... uclibc? ( ${AUTOTOOLS_DEPEND} ). If you add an > ewarn to src_prepare() where you print out ${AUTOTOOLS_DEPEND} you get that > util-linux should DEPEND on sys-devel/autoconf and sys-devel/automake. So > why is point 2 happening? Like I said, it's probably due to circular dependencies. The should be visible in the --debug log. > Thinking that maybe I was misreading the class etc, I even replaced > ${AUTOTOOLS_DEPEND} explicitly with sys-devel/autoconf sys-devel/automake > with the same result. Somehow -e @system is not calculating that autoconf > and automake need to be built before util-linux is. The thing is, the dependencies are satisfied. Therefore, it should succeed regardless of the order. The fact that it doesn't succeed suggests that the dependencies are not fully specified. For example, something like the foo/bar[build=] approach that I mentioned might help.
Created attachment 327270 [details] emerge --debug -evp @system &> debug.log
(In reply to comment #8) > (In reply to comment #5) > Like I said, it's probably due to circular dependencies. The should be > visible in the --debug log. Ah okay. I wasn't sure what you meant because usually circular deps are pretty obvious. > > > Thinking that maybe I was misreading the class etc, I even replaced > > ${AUTOTOOLS_DEPEND} explicitly with sys-devel/autoconf sys-devel/automake > > with the same result. Somehow -e @system is not calculating that autoconf > > and automake need to be built before util-linux is. > > The thing is, the dependencies are satisfied. Therefore, it should succeed > regardless of the order. The fact that it doesn't succeed suggests that the > dependencies are not fully specified. For example, something like the > foo/bar[build=] approach that I mentioned might help. Okay I see what you're saying. Let me play with this and see what I can do.
It looks like at least this cycle could be responsible for triggering the sub-optimal merge order: sys-devel/autoconf-2.68 -> dev-lang/perl-5.12.4-r1 -> sys-libs/db-4.8.30 -> sys-devel/autoconf-2.68 A cycle like this tends to delay the merge order of the involved packages. Since autoconf is already installed, util-linux appears to have satisfied dependencies, and it's merged before. I don't think that there's anything we can do on the portage side. What we really need to do is find out why the autoconf dependency which appears to be satisfied leads to a build failure, and possibly fix it by using an approach like the foo/bar[build=] example that I've mentioned.
(In reply to comment #11) > I don't think that there's anything we can do on the portage side. What we > really need to do is find out why the autoconf dependency which appears to > be satisfied leads to a build failure, and possibly fix it by using an > approach like the foo/bar[build=] example that I've mentioned. Okay I see what's going on here and you're right. portage really can't unravel this issue, or similar. In this particular case, the circular dependency can be avoided by removing USE=berkdb. Or one can resort as you said to the cat/foo[build=] technique. emerge --debug is useful to see the logic behind portage.
