At least the last few versions of nvidia-drivers, including x11-drivers/nvidia-drivers-285.05.09, report broken symlinks when installed by portage-2.1.10.28. These broken symlinks are reported by QA notices during emerge, and revdep-rebuild afterward. Of course revdep-rebuild can't fix it when the broken link is in the affected package itself. When installed by portage-2.1.10.27, all is well. Reproducible: Always Steps to Reproduce: 1. emerge =sys-apps/portage-2.1.10.28 2. emerge =x11-drivers/nvidia-drivers-285.05.09 3. revdep-rebuild Actual Results: # * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 26% ] * broken /usr/bin/nvidia-smi (requires libnvidia-ml.so.1) [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /usr/bin/nvidia-smi -> x11-drivers/nvidia-drivers * Generated new 4_raw.rr and 4_owners.rr * Cleaning list of packages to rebuild * Generated new 4_pkgs.rr * Assigning packages to ebuilds * Generated new 4_ebuilds.rr * Evaluating package order * Generated new 5_order.rr * All prepared. Starting rebuild emerge --complete-graph=y --oneshot --pretend x11-drivers/nvidia-drivers:0 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-285.05.09 * Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild Expected Results: no breakage
Created attachment 290247 [details] build.log build.log from a successful emerge of x11-drivers/nvidia-drivers-285.05.09 on sys-apps/portage-2.1.10.28, with QA notices about broken links
After a bit more rebuilding & testing, I'm having trouble reproducing the exact behavior. But *something* is going on with the way different portage versions handle the same ebuild version.
sys-apps/portage-2.2.0_alpha69 exhibits the same problem here are the QA notices: * QA Notice: Found an absolute symlink in a library directory: * usr/lib64/libnvcuvid.so -> /usr/lib64/libnvcuvid.so.285.05.09 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Found an absolute symlink in a library directory: * usr/lib64/libnvidia-cfg.so -> /usr/lib64/libnvidia-cfg.so.285.05.09 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Found an absolute symlink in a library directory: * usr/lib64/libnvidia-ml.so -> /usr/lib64/libnvidia-ml.so.285.05.09 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Missing soname symlink(s): * * usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.285.05.09 * usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.285.05.09 * usr/lib64/libnvcuvid.so.1 -> libnvcuvid.so.285.05.09 * usr/lib64/libnvidia-ml.so.1 -> libnvidia-ml.so.285.05.09 *
It's probably a bug in the nvidia-drivers ebuild. The related portage changes are from bug 387053: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=d1499e9e3b08fd3e539f1b9a740d243bec67872c
Same problem.
Same error here, tried both 275.09.07 and 285.05.09 drivers using Portage 2.2.0_alpha69_p6
There are definitely issues with this ebuild. I can confirm that on my ~amd64 laptop libnvidia-ml.so.1 is missing, causing nvidia-drivers to keep getting drawn into the rebuild cue when doing a revdep-rebuild. The absolute symlink issue as shown here has been around for quite awhile and is an independent issue not related to the above bug which is new: "* QA Notice: Found an absolute symlink in a library directory: * usr/lib64/libnvcuvid.so -> /usr/lib64/libnvcuvid.so.285.05.09 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Found an absolute symlink in a library directory: * usr/lib64/libnvidia-cfg.so -> /usr/lib64/libnvidia-cfg.so.285.05.09 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Found an absolute symlink in a library directory: * usr/lib64/libnvidia-ml.so -> /usr/lib64/libnvidia-ml.so.285.05.09 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Missing soname symlink(s): * * usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.285.05.09 * usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.285.05.09 * usr/lib64/libnvcuvid.so.1 -> libnvcuvid.so.285.05.09 * usr/lib64/libnvidia-ml.so.1 -> libnvidia-ml.so.285.05.09"
The .1 files don't actually belong. There were newer QA variables added in newer Portages so we'll have to upgrade all the ebuilds to now pass additional QA variables.
(In reply to comment #3) > * QA Notice: Missing soname symlink(s): > * > * usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.285.05.09 > * usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.285.05.09 > * usr/lib64/libnvcuvid.so.1 -> libnvcuvid.so.285.05.09 > * usr/lib64/libnvidia-ml.so.1 -> libnvidia-ml.so.285.05.09 > * Something like this should work with >=sys-apps/portage-2.1.10.28: QA_SONAME_NO_SYMLINK=" usr/lib64/libXvMCNVIDIA\\.so.* usr/lib64/libnvidia-cfg\\.so.* usr/lib64/libnvcuvid\\.so.* usr/lib64/libnvidia-ml\\.so.* "
(In reply to comment #9) > Something like this should work with >=sys-apps/portage-2.1.10.28: > > QA_SONAME_NO_SYMLINK=" > usr/lib64/libXvMCNVIDIA\\.so.* > usr/lib64/libnvidia-cfg\\.so.* > usr/lib64/libnvcuvid\\.so.* > usr/lib64/libnvidia-ml\\.so.* > " Actually, make those usr/lib.*/ so that they work for all ABIs.
(In reply to comment #7) > "* QA Notice: Found an absolute symlink in a library directory: > * usr/lib64/libnvcuvid.so -> /usr/lib64/libnvcuvid.so.285.05.09 If necessary, we can add another QA_* variable for absolute symlinks. If that's what you want please file a separate bug for sys-apps/portage and explain the reason for absolute symlinks there.
Fixed 285.05.09-r1.
Not sure why this is still open, resolved in stable portage a while ago.
