Date: Thu, 23 Feb 2012 09:34:21 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: ports@FreeBSD.org, Alexey Dokuchaev <danfe@FreeBSD.org>, x11@FreeBSD.org, John Hein <jhein@symmetricom.com> Subject: Re: Fix nvidia-like ports, help needed Message-ID: <20120223093421.Horde.oN2FMZjmRSRPRfoNKQ4BA-g@webmail.leidinger.net> In-Reply-To: <20120223072132.GB88092@azathoth.lan> References: <20120222222544.GA88092@azathoth.lan> <20293.31720.350021.74506@gromit.timing.com> <20120223013502.GA78308@FreeBSD.org> <20120223072132.GB88092@azathoth.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Baptiste Daroussin <bapt@FreeBSD.org> (from Thu, 23 Feb 2012 08:21:33 +0100): > 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 > conflicting? > > 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. Do you havea list of packages which overzrite something, respectively do you have a list of files which are overwriten? If we just talk about the nvidia lib, installing the mesa and nvidia ones into subdirectories and asking to add (or adding automatically/optionally) ldconfig_paths="$ldconfig_paths /usr/local/lib/<port>-gl/" to rc.conf could be an option. Bye, Alexander. -- What we cannot speak about we must pass over in silence. -- Wittgenstein http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120223093421.Horde.oN2FMZjmRSRPRfoNKQ4BA-g>