Bug 195080 - x11/nvidia-driver / graphics/libGL affected by install order
Summary: x11/nvidia-driver / graphics/libGL affected by install order
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Alexey Dokuchaev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-16 20:08 UTC by Kevin Bowling
Modified: 2016-07-31 08:51 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Bowling freebsd_committer freebsd_triage 2014-11-16 20:08:11 UTC
nvidia-driver and libGL use hardlinking to install their respective libGL.so files into lib/.  However, the last installed package wins, for instance after upgrading graphics/libGL it will unwanted overwrite x11/nvidia-driver's libGL.so.
Comment 1 Bugzilla Automation freebsd_committer freebsd_triage 2014-11-16 20:08:11 UTC
Maintainers CC'd
Comment 2 Koop Mast freebsd_committer freebsd_triage 2014-11-19 12:01:22 UTC
both libGL and nvidia-driver have post-install and deinstall scripts that make the hardlinks and remove them.

I build it so that if libGL is reinstalled after nvidia-driver it check if nvidia driver libGL is present and links that instead of its own.
Comment 3 Alexey Dokuchaev freebsd_committer freebsd_triage 2014-11-19 12:37:16 UTC
Right, and I think this simple logic can be improved.  Currently nvidia-driver conflicts not just with xorg and libGL, but also libEGL and libGLESv2.

I'm playing with the idea to stop assuming of any particular order in which these ports/packages are installed, and create symlinks (hardlinks only complicate things here) upon install/deinstall in the following way:

In post-install:
        ...
        /bin/ln -sf .nvidia/libGL.so.1 ${PREFIX}/lib
        /bin/ln -sf .nvidia/libGL.so ${PREFIX}/lib
        /bin/ln -sf .nvidia/libEGL.so.1 ${PREFIX}/lib
        /bin/ln -sf .nvidia/libEGL.so ${PREFIX}/lib
        /bin/ln -sf .nvidia/libGLESv2.so.2 ${PREFIX}/lib
        /bin/ln -sf .nvidia/libGLESv2.so ${PREFIX}/lib
        /bin/ln -sf .nvidia/libglx.so ${PREFIX}/lib/xorg/modules/extensions

In post-deinstall:

# Conditionally put links to files (i.e., if they were previously installed)
# $1 common path (prior to hidden directory)
# $2 remainder (e.g., .foo/libbar.so)
maybe_link_back()
{
        [ -f "$1/$2" ] && /bin/ln -sf "$2" "$1"
}
        ...
        maybe_link_back ${PREFIX}/lib .libGL/libGL.so.1
        maybe_link_back ${PREFIX}/lib .libGL/libGL.so
        maybe_link_back ${PREFIX}/lib .libEGL/libEGL.so.1
        maybe_link_back ${PREFIX}/lib .libEGL/libEGL.so
        maybe_link_back ${PREFIX}/lib .libGLESv2/libGLESv2.so.2
        maybe_link_back ${PREFIX}/lib .libGLESv2/libGLESv2.so
        maybe_link_back ${PREFIX}/lib/xorg/modules/extensions .xorg/libglx.so

Similar changes will have to be added to "conflicting" ports (libraries and X server).
Comment 4 Koop Mast freebsd_committer freebsd_triage 2014-11-19 13:43:36 UTC
The reason I picked hardlinks is else it going to look into the .libGL dirs and will select the wrong libGL.so. Or something like that, I can't remember clearly.
Comment 5 Koop Mast freebsd_committer freebsd_triage 2014-11-27 15:50:13 UTC
I should also mentioned that the pkg-install script of libGL checks if the lib/.nvidia/libGL.so.1 is present and will put those symlinks in, instead of its own. Unless I make a error with the check, I don't see why this shouldn't work.
Comment 6 Kevin Bowling freebsd_committer freebsd_triage 2016-07-31 08:51:50 UTC
Not sure this is still relevant, I haven't had an issue with it in 2 years.