Skip site navigation (1)Skip section navigation (2)
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, John Hein <jhein@symmetricom.com>
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>