Date: Thu, 23 Feb 2012 03:55:24 +0100 From: Mel Flynn <rflynn@acsalaska.net> To: Alexey Dokuchaev <danfe@freebsd.org> Cc: ports@freebsd.org, Baptiste Daroussin <bapt@freebsd.org>, x11@freebsd.org, John Hein <jhein@symmetricom.com> Subject: Re: Fix nvidia-like ports, help needed Message-ID: <4F45AA9C.5080303@acsalaska.net> In-Reply-To: <20120223013502.GA78308@FreeBSD.org> References: <20120222222544.GA88092@azathoth.lan> <20293.31720.350021.74506@gromit.timing.com> <20120223013502.GA78308@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/23/2012 02:35, Alexey Dokuchaev wrote: > On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: >> 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. > > I tend to agree. While I currently do not see clearly the best solution to > the problem, when I see "etc/alternative.d" I want to unsee it ASAP. > > For nvidia driver, it might be easier to simply provide a knob in > xorg-server and libGL and perhaps register a dependency on nvidia-driver; > no need to invent some cumbersome framework. Years ago, I suggested to have nvidia-driver conflict with Mesa libGL and select nvidia through WITH_NVIDIA_GL knob. At the time the consensus was that end users shouldn't be left with a non-working system if they uninstall the driver. So maybe the solution it to have a "restore" mechanism in place (/usr/local/lib/pkg/restore?) that puts replaced files back. This is essentially what nvidia-driver is doing, not just with libGL. The challenge will to update the pkg that it replaced files for and to know that it should not install the files that are replaced in case of an upgrade of that package. This will also make things easier for users, because the current situation is that after an upgrade of Mesa, users will need to forcibly reinstall nvidia-driver to overwrite the libGL. -- Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F45AA9C.5080303>