Date: Thu, 23 Feb 2012 11:28:48 +0000 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Alexander Leidinger <alexander@leidinger.net> Cc: ports@freebsd.org, Alexey Dokuchaev <danfe@freebsd.org>, x11@freebsd.org Subject: Re: Fix nvidia-like ports, help needed Message-ID: <d0ee88b5486535475f0c1c4bf5ecea55@etoilebsd.net> In-Reply-To: <20120223093421.Horde.oN2FMZjmRSRPRfoNKQ4BA-g@webmail.leidinger.net> References: <20120222222544.GA88092@azathoth.lan> <20293.31720.350021.74506@gromit.timing.com> <20120223013502.GA78308@FreeBSD.org> <20120223072132.GB88092@azathoth.lan> <20120223093421.Horde.oN2FMZjmRSRPRfoNKQ4BA-g@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23.02.2012 08:34, Alexander Leidinger wrote: > 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. Currently, no I don't have a list of packages that overwrite things, anyway way I do really like this kind of solution, I don't know yet how this can be automated, it really looks the right way. regards, Bapt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d0ee88b5486535475f0c1c4bf5ecea55>