Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Feb 2012 16:36:08 -0700
From:      John Hein <jhein@symmetricom.com>
To:        Baptiste Daroussin <bapt@FreeBSD.org>
Cc:        ports@FreeBSD.org, danfe@FreeBSD.org, x11@FreeBSD.org
Subject:   Re: Fix nvidia-like ports, help needed
Message-ID:  <20293.31720.350021.74506@gromit.timing.com>
In-Reply-To: <20120222222544.GA88092@azathoth.lan>
References:  <20120222222544.GA88092@azathoth.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
Baptiste Daroussin wrote at 23:25 +0100 on Feb 22, 2012:
 > Hi all,
 > 
 > this mail is also sent to ports@ has the problem we have with nvidia-driver
 > might also occur elsewhere and we need a general fix for that.
 > 
 > First what is the failure: nvidia driver overwrite libGL.so provided by another
 > package which is broken by design because the package database isn't consistent
 > anymore. however this nvidia-driver needs to replace libGL.so.
 > 
 > In that case we definitely need to have a tool allowing us to safely provide
 > libGL.so and switch between the mesa one and the nvidia one.
 > 
 > currently this kind of bugs silently occurs with pkg_install, but pkgng is more
 > strict about that and refuses it.
 > 
 > We then need a tool like gentoo's eselect, redhat alternative and I don't
 > remember the name for debian.
 > 
 > We need it the FreeBSD way, not sure we need something as complex as what the
 > linux distribution does, maybe yes.
 > 
 > I wrote a quick and dirty script named alternative:
 > http://people.freebsd.org/~bapt/alternative.txt
 > 
 > That get informations about the alternatives in ${LOCALBASE}/etc/alternative.d
 > 
 > ${LOCALBASE}/etc/alternative.d/libgl
 > ${LOCALBASE}/etc/alternative.d/libgl/nvidia
 > ${LOCALBASE}/etc/alternative.d/libgl/nvidia/nvidia.cf
 > ${LOCALBASE}/etc/alternative.d/libgl/libgl.cf
 > ${LOCALBASE}/etc/alternative.d/libgl/current
 > ${LOCALBASE}/etc/alternative.d/libgl/mesa
 > ${LOCALBASE}/etc/alternative.d/libgl/mesa/mesa.cf
 > 
 > current behing a symlink to either nvidia or mesa
 > 
 > cat libgl.cf:
 > NAME="libgl"
 > DESCRIPTION="Default OpenGL library"
 > 
 > cat mesa/mesa.cf
 > NAME=mesa
 > DESCRIPTION="libGL provided by the mesa project"
 > 
 > cat nvidia/nvidia.cf
 > NAME=nvidia
 > DESCRIPTION="libGL provided by the nvidia driver"
 > 
 > with that nvidia could have libgl-nvidia.so and mesa libgl-mesa.so
 > 
 > the script alternative might change the libgl.so symlink to point on nvidia or
 > mesa depending on the user choices.
 > 
 > this script is just an idea definitly not an implementation.
 > 
 > nvidia case is just an example but the script should try to be more general.
 > (handle binaries scripts etc.)
 > 
 > I don't have time to work on this currently hope someone will takle this task.

One of the issues with 'alternatives' implementations is that they are
not selectable per-user (including non superuser).

In this particular case (libGL), also what about the native X server
vs. virtual X servers that support using the mesa lib (per-application
selection)?

In addition to something like alternatives, another option is to allow
installation of conflicting files (like libGL.so in this case) to
separate directories and specify which to use using a path (like
LD_LIBRARY_PATH or rpath at compile time).  That can help with the
aforementioned per-user and per-application variation.

Personally, I prefer the "path" method over something like alternative
sym links (e.g., debian/redhat alternatives).  There can still be a
front-end tool to get at the "alternates" configuration information,
but I like the ability to set a path rather than a sym link.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20293.31720.350021.74506>