Fix nvidia-like ports, help needed

John Hein jhein at
Wed Feb 22 23:36:13 UTC 2012

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 provided by another
 > package which is broken by design because the package database isn't consistent
 > anymore. however this nvidia-driver needs to replace
 > In that case we definitely need to have a tool allowing us to safely provide
 > 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:
 > 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/
 > ${LOCALBASE}/etc/alternative.d/libgl/
 > ${LOCALBASE}/etc/alternative.d/libgl/current
 > ${LOCALBASE}/etc/alternative.d/libgl/mesa
 > ${LOCALBASE}/etc/alternative.d/libgl/mesa/
 > current behing a symlink to either nvidia or mesa
 > cat
 > NAME="libgl"
 > DESCRIPTION="Default OpenGL library"
 > cat mesa/
 > NAME=mesa
 > DESCRIPTION="libGL provided by the mesa project"
 > cat nvidia/
 > NAME=nvidia
 > DESCRIPTION="libGL provided by the nvidia driver"
 > with that nvidia could have and mesa
 > the script alternative might change the 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

In addition to something like alternatives, another option is to allow
installation of conflicting files (like 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.

More information about the freebsd-ports mailing list