Fix nvidia-like ports, help needed
bapt at FreeBSD.org
Thu Feb 23 07:21:37 UTC 2012
On Thu, Feb 23, 2012 at 01:35:02AM +0000, 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.
Why not but which package will provide the libGL.so file? in all case the users
might need to be able to switch the libGL.so file from the nvidia one to the
mesa one, what would a user have to do for that, in particular a user using only
binary packages where a file can't belong to 2 different packages without
if someone have a better solution than a framework for that I'm open but no the
knob is not a solution for package people.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120223/3654e336/attachment.pgp
More information about the freebsd-ports