Skip site navigation (1)Skip section navigation (2)
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>