Created attachment 882423 [details] build log tin
Guess could check if I can (easily) stop it from using it instead, this does not install documentation so it's just a waste.
(In reply to Ionen Wolkens from comment #1) > Guess could check if I can (easily) stop it from using it instead, this does > not install documentation so it's just a waste. ...nope, tried a few things but it's quite insistent. Not worth making a convoluted workaround so I'll just add the dep.
(In reply to Ionen Wolkens from comment #2) > (In reply to Ionen Wolkens from comment #1) > > Guess could check if I can (easily) stop it from using it instead, this does > > not install documentation so it's just a waste. > ...nope, tried a few things but it's quite insistent. Not worth making a > convoluted workaround so I'll just add the dep. Oh wait, looked at the binutils ebuild and guess it's not so bad to do the same.
I think you can also MAKEINFO=true yeah
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=90dae1b4ae07d6bb6fc650743269f5b55a8995c3 commit 90dae1b4ae07d6bb6fc650743269f5b55a8995c3 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-01-16 16:51:07 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-01-16 17:52:05 +0000 dev-util/mingw64-toolchain: prevent makeinfo usage This does not install .info pages (that is left to binutils+gcc real packages), so little reason to depend on texinfo(makeinfo) and generate them for nothing. Could possibly come back as an issue if use gcc snapshots (that lack pre-gen info pages), and unsure if this same workaround will work for gcc (currently only binutils is trying to use it). MAKEINFO=: on ./configure is not necessary (and is insufficient to stop usage given it is not respected in Makefiles), but it prevents a command not found QA notice. That aside, generally hard for texinfo to be missing unless depclean build deps, so BDEPEND would not have been too wasteful. Closes: https://bugs.gentoo.org/922230 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-util/mingw64-toolchain/mingw64-toolchain-11.0.0_p2.ebuild | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
Hehe, you're right, I was running a @world update in an emerge --root I had just created. That said, I think issues like this are gonna become more relevant as time goes on and binrepos get more use. Do we have any good way to test ebuilds with only DEPEND and BDEPEND installed?
(In reply to Esteve Varela Colominas from comment #7) > Do we have any good way to test ebuilds with only DEPEND and BDEPEND installed? Not really, not that you can't just `emerge -c --with-bdeps=n` to get rid of them on a whim (and then restore binpkg build deps as-needed). Shame unmerging/merging a wall of bdeps is pretty slow even with binpkgs though. Minimal'ish checks would be something like stage3 -> emerge --onlydeps yourpackage -> emerge -c --with-bdeps=n -> emerge yourpackage Not that I bother going that far in my current workflow, but will fix when someone reports anything.
Yeah... You kinda need an extra clean beforehand too, as you might end up building some things from source in the second round. I wish there was just a way to --depclean-except-bdeps <package>. Oh well.
