Date: Thu, 23 Feb 2012 08:21:33 +0100 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: ports@FreeBSD.org, x11@FreeBSD.org Subject: Re: Fix nvidia-like ports, help needed Message-ID: <20120223072132.GB88092@azathoth.lan> 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
--0eh6TmSyL6TZE2Uz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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). > >=20 > > 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)? > >=20 > > 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. > >=20 > > 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. >=20 > 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. >=20 > 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 u= sers 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. regards, Bapt --0eh6TmSyL6TZE2Uz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9F6PwACgkQ8kTtMUmk6Ewd/QCfXxbHBhX91uwFVWvIab/bZ0nP +qcAn3gzdWdRYeAmVR+N32WBALERK7fJ =gYLG -----END PGP SIGNATURE----- --0eh6TmSyL6TZE2Uz--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120223072132.GB88092>