From owner-freebsd-x11@FreeBSD.ORG Wed Feb 22 23:51:23 2012 Return-Path: Delivered-To: x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B4011065672; Wed, 22 Feb 2012 23:51:23 +0000 (UTC) (envelope-from jhein@symmetricom.com) Received: from duck.timing.com (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD9E8FC22; Wed, 22 Feb 2012 23:51:22 +0000 (UTC) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by duck.timing.com (8.14.5/8.14.4) with ESMTP id q1MNaCor077576; Wed, 22 Feb 2012 16:36:12 -0700 (MST) (envelope-from jhein@symmetricom.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.5/8.14.5) with ESMTP id q1MNa8d1001506; Wed, 22 Feb 2012 16:36:08 -0700 (MST) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.5/8.14.5/Submit) id q1MNa8uA001504; Wed, 22 Feb 2012 16:36:08 -0700 (MST) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20293.31720.350021.74506@gromit.timing.com> Date: Wed, 22 Feb 2012 16:36:08 -0700 From: John Hein To: Baptiste Daroussin In-Reply-To: <20120222222544.GA88092@azathoth.lan> References: <20120222222544.GA88092@azathoth.lan> X-Mailer: VM 8.2.0b-8.2.x-reddyuday.r1325 under 23.3.1 (i386-portbld-freebsd7.3) Cc: ports@FreeBSD.org, danfe@FreeBSD.org, x11@FreeBSD.org Subject: Re: Fix nvidia-like ports, help needed X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 23:51:23 -0000 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.