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