app-containers/nvidia-container-toolkit-1.7.0: make: *** No rule to make target 'binaries'. Stop.
exonitocris opened this issue · comments
emerge fails on app-container/nvidia-container-toolkit-1.7.0! It seems that portage can't find Makefile for src_compile.
nvidia-container-toolkit-1.7.0.tar.gz file is unpacked info ${PORTAGE_TMPDIR}/portage/app-containers/nvidia-container-toolkit-1.7.0/work/nvidia-container-toolkit-1.7.0/src/github.com/NVIDIA/nvidia-container-toolkit/ so portage can't find it!
Thx for fixing it!
I replaced inherit golang-build golang-vcs-snapshot with inherit go-module, removed EGO_PN="github.com/NVIDIA/${PN}" from the ebuild in local repo and left everything as is. I could emerge the package successfully afterward and it seemed to work.
Because in commit NVIDIA/nvidia-container-toolkit@35c6559#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52, nvidia changed make binary to make binaries, so this ebuild need many change and debug to fix bug.
Can I help you with anything?
Wouldn't it be much easier in regard to maintenance and readability if you keep the tar.gz packaged version instead of listing all go mods inside the ebuild ? In case of nvidia-container-toolkit-1.7.0, the packaged tar.gz had a go.mod file and vendor directory inside and according to go-module.eclass manpage just a inhert go-module inside the ebuild would just do the work...Or am I missing something?
Can I help you with anything?
Wouldn't it be much easier in regard to maintenance and readability if you keep the tar.gz packaged version instead of listing all go mods inside the ebuild ? In case of nvidia-container-toolkit-1.7.0, the packaged tar.gz had a go.mod file and vendor directory inside and according to go-module.eclass manpage just a inhert go-module inside the ebuild would just do the work...Or am I missing something?
The main reason is that many users' portages run in sandbox mode, which means that the network cannot be accessed during the src_unpack/src_compile/src_install stage. At this time, the network download triggered by the default go.mod/go.sum will go wrong, resulting in gentoo It is more difficult to play non-live build packages. When I tried to use inherit golang-build golang-vcs, I found that this only supports live builds, not builds with version numbers. Then I tried inherit golang-build golang-vcs-snapshot, and found that it still failed, and finally had to revert to inherit go-module. After checking most of gentoo's inherit go-module packages, it is found that EGO_SUM is inevitably maintained, so that portage can download the dependent packages in advance before entering the sandbox environment (it is also convenient for mirroring), avoiding the network error. This makes it difficult to maintain packages using Golang, and there is a lack of a mechanism to automatically generate EGO_SUM.