Created attachment 466094 [details] dev-qt/linguist-tools-5.7.1 build log dev-qt/{qtprintsupport,linguist-tools}-5.7.1 apparently require the dev-libs/double-conversion library (cf. the attached build logs). On the computer where this issue occured, dev-qt/qtcore and a few other QT packages have been installed as binary packages from another computer where dev-libs/double-conversion is installed; thus it's entirely possible that this some type of automagic dependency determined at qtcore build time.
Created attachment 466096 [details] dev-qt/qtprintsupport-5.7.1 build log
You are correct, it's an automagic dependency in dev-qt/qtcore.
As per bug #581054 comment #0 I suppose we will add this as a mandatory dependency.
(In reply to Michael Palimaka (kensington) from comment #3) > As per bug #581054 comment #0 I suppose we will add this as a mandatory > dependency. Thanks, I hadn't noticed that bug. When will you add this dependency, though? The ebuild is broken _right now_. Bug #581054 is closed, and dev-libs/double-conversion has aquired all neccessary keywords, other than ~arm64. Can we re-open the aforementioned bug for the ~arm64 keyword request, or should that go into a new bug?
Another thought: ~arm64 is a dev profile, and qtcore's dependency tree is already broken in several dev profiles (~arm64 and ~x86-fbsd, due to the libressl dep), so I suppose you can add the libdouble-conversion dependency right away.
Thanks, this was fixed in the overlay by Davide and I've pushed it to the main tree. https://gitweb.gentoo.org/proj/qt.git/commit/?id=3351afb360c87bb9d0596bff371536b710886375 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=efdcc72fba7a1140422277426d2cca29c24f5e23 (In reply to Luis Ressel from comment #5) > Another thought: ~arm64 is a dev profile, and qtcore's dependency tree is > already broken in several dev profiles (~arm64 and ~x86-fbsd, due to the > libressl dep), so I suppose you can add the libdouble-conversion dependency > right away. The main point of dev/exp profiles is that we don't really have to worry about them and there's often a lot of depgraph breakage because of this (if someone was actively taking care of it, it'd probably be a stable profile). That said, if you're affected by depgraph breakage on a dev profile you're more than welcome to hassle that team to get it fixed.