Fix nvidia-like ports, help needed

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Fix nvidia-like ports, help needed

Baptiste Daroussin-2
Hi all,

this mail is also sent to ports@ has the problem we have with nvidia-driver
might also occur elsewhere and we need a general fix for that.

First what is the failure: nvidia driver overwrite libGL.so provided by another
package which is broken by design because the package database isn't consistent
anymore. however this nvidia-driver needs to replace libGL.so.

In that case we definitely need to have a tool allowing us to safely provide
libGL.so and switch between the mesa one and the nvidia one.

currently this kind of bugs silently occurs with pkg_install, but pkgng is more
strict about that and refuses it.

We then need a tool like gentoo's eselect, redhat alternative and I don't
remember the name for debian.

We need it the FreeBSD way, not sure we need something as complex as what the
linux distribution does, maybe yes.

I wrote a quick and dirty script named alternative:
http://people.freebsd.org/~bapt/alternative.txt

That get informations about the alternatives in ${LOCALBASE}/etc/alternative.d

${LOCALBASE}/etc/alternative.d/libgl
${LOCALBASE}/etc/alternative.d/libgl/nvidia
${LOCALBASE}/etc/alternative.d/libgl/nvidia/nvidia.cf
${LOCALBASE}/etc/alternative.d/libgl/libgl.cf
${LOCALBASE}/etc/alternative.d/libgl/current
${LOCALBASE}/etc/alternative.d/libgl/mesa
${LOCALBASE}/etc/alternative.d/libgl/mesa/mesa.cf

current behing a symlink to either nvidia or mesa

cat libgl.cf:
NAME="libgl"
DESCRIPTION="Default OpenGL library"

cat mesa/mesa.cf
NAME=mesa
DESCRIPTION="libGL provided by the mesa project"

cat nvidia/nvidia.cf
NAME=nvidia
DESCRIPTION="libGL provided by the nvidia driver"

with that nvidia could have libgl-nvidia.so and mesa libgl-mesa.so

the script alternative might change the libgl.so symlink to point on nvidia or
mesa depending on the user choices.

this script is just an idea definitly not an implementation.

nvidia case is just an example but the script should try to be more general.
(handle binaries scripts etc.)

I don't have time to work on this currently hope someone will takle this task.

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

John Hein-2
Baptiste Daroussin wrote at 23:25 +0100 on Feb 22, 2012:
 > Hi all,
 >
 > this mail is also sent to ports@ has the problem we have with nvidia-driver
 > might also occur elsewhere and we need a general fix for that.
 >
 > First what is the failure: nvidia driver overwrite libGL.so provided by another
 > package which is broken by design because the package database isn't consistent
 > anymore. however this nvidia-driver needs to replace libGL.so.
 >
 > In that case we definitely need to have a tool allowing us to safely provide
 > libGL.so and switch between the mesa one and the nvidia one.
 >
 > currently this kind of bugs silently occurs with pkg_install, but pkgng is more
 > strict about that and refuses it.
 >
 > We then need a tool like gentoo's eselect, redhat alternative and I don't
 > remember the name for debian.
 >
 > We need it the FreeBSD way, not sure we need something as complex as what the
 > linux distribution does, maybe yes.
 >
 > I wrote a quick and dirty script named alternative:
 > http://people.freebsd.org/~bapt/alternative.txt
 >
 > That get informations about the alternatives in ${LOCALBASE}/etc/alternative.d
 >
 > ${LOCALBASE}/etc/alternative.d/libgl
 > ${LOCALBASE}/etc/alternative.d/libgl/nvidia
 > ${LOCALBASE}/etc/alternative.d/libgl/nvidia/nvidia.cf
 > ${LOCALBASE}/etc/alternative.d/libgl/libgl.cf
 > ${LOCALBASE}/etc/alternative.d/libgl/current
 > ${LOCALBASE}/etc/alternative.d/libgl/mesa
 > ${LOCALBASE}/etc/alternative.d/libgl/mesa/mesa.cf
 >
 > current behing a symlink to either nvidia or mesa
 >
 > cat libgl.cf:
 > NAME="libgl"
 > DESCRIPTION="Default OpenGL library"
 >
 > cat mesa/mesa.cf
 > NAME=mesa
 > DESCRIPTION="libGL provided by the mesa project"
 >
 > cat nvidia/nvidia.cf
 > NAME=nvidia
 > DESCRIPTION="libGL provided by the nvidia driver"
 >
 > with that nvidia could have libgl-nvidia.so and mesa libgl-mesa.so
 >
 > the script alternative might change the libgl.so symlink to point on nvidia or
 > mesa depending on the user choices.
 >
 > this script is just an idea definitly not an implementation.
 >
 > nvidia case is just an example but the script should try to be more general.
 > (handle binaries scripts etc.)
 >
 > I don't have time to work on this currently hope someone will takle this task.

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.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Alexey Dokuchaev-4
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.

./danfe
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Mel Flynn-10
On 2/23/2012 02:35, 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.

Years ago, I suggested to have nvidia-driver conflict with Mesa libGL
and select nvidia through WITH_NVIDIA_GL knob. At the time the consensus
was that end users shouldn't be left with a non-working system if they
uninstall the driver.

So maybe the solution it to have a "restore" mechanism in place
(/usr/local/lib/pkg/restore?) that puts replaced files back. This is
essentially what nvidia-driver is doing, not just with libGL. The
challenge will to update the pkg that it replaced files for and to know
that it should not install the files that are replaced in case of an
upgrade of that package.

This will also make things easier for users, because the current
situation is that after an upgrade of Mesa, users will need to forcibly
reinstall nvidia-driver to overwrite the libGL.
--
Mel
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Baptiste Daroussin-2
In reply to this post by Alexey Dokuchaev-4
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.

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Alexander Leidinger
Quoting Baptiste Daroussin <[hidden email]> (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

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Alberto Villa-3
In reply to this post by Baptiste Daroussin-2
On Thursday 23 February 2012 08:21:33 Baptiste Daroussin wrote:
> 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?

Something like splitting libGL.so and making a mesa-libgl-whatever port?
Then mark CONFLICTS, and replacing that with nvidia-driver will be easy.
Won't it?
--
Alberto Villa, FreeBSD committer <[hidden email]>
http://people.FreeBSD.org/~avilla

Dear Lord:
        I just want *_o_n_e* one-armed manager so I never have to hear
"On
the other hand", again.

signature.asc (323 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Baptiste Daroussin-2
In reply to this post by Alexander Leidinger
On 23.02.2012 08:34, Alexander Leidinger wrote:

> Quoting Baptiste Daroussin <[hidden email]> (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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

John Hein-2
Baptiste Daroussin wrote at 11:28 +0000 on Feb 23, 2012:
 > On 23.02.2012 08:34, Alexander Leidinger wrote:
 > > 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.
 >
 > 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.

If the nvidia libGL can be dynamically linked with, say, a vnc server, and
have it be a drop in replacement for the mesa libGL, then ldconfig_paths
would be fine.  If not, then those apps which need the mesa libGL would
need to link with -rpath perhaps to point at the "right" libGL (or
pass appropriate path info to those apps that might use dlopen(3)).
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Baptiste Daroussin-2
On Thu, Feb 23, 2012 at 12:56:22PM -0700, John Hein wrote:

> Baptiste Daroussin wrote at 11:28 +0000 on Feb 23, 2012:
>  > On 23.02.2012 08:34, Alexander Leidinger wrote:
>  > > 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.
>  >
>  > 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.
>
> If the nvidia libGL can be dynamically linked with, say, a vnc server, and
> have it be a drop in replacement for the mesa libGL, then ldconfig_paths
> would be fine.  If not, then those apps which need the mesa libGL would
> need to link with -rpath perhaps to point at the "right" libGL (or
> pass appropriate path info to those apps that might use dlopen(3)).
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "[hidden email]"
Another solution could be to add an entry (and drop it in deinstallation to
libmap.conf) when installing the nvidia driver, in that case installing it ad
libGL-nvidia.so.1 and adding:

libGL.so.1 libGL-nvidia.so.1

or something like that.

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Ade Lovett
On 2/23/2012 13:14, Baptiste Daroussin wrote:
> Another solution could be to add an entry (and drop it in deinstallation to
> libmap.conf) when installing the nvidia driver, in that case installing it ad
> libGL-nvidia.so.1 and adding:
>
> libGL.so.1 libGL-nvidia.so.1
>
> or something like that.

Going that route is likely to be messy given the current monolithic
/etc/libmap{,32}.conf

You'd most likely want ${LOCALBASE}/etc/libmap.conf.d/* (in a similar
manner to etc/periodic, etc/rc.d and so on).  Whether the code that
currently handles libmap.conf is itself extended to use this directory
structure is open for discussion.  An alternate method could perhaps be
a 'genlibmap' command which takes /etc/libmap.conf and this directory
structure to create a /var/run/libmap.conf which is actually used by rtld.

Having potentially multiple ports dinking _directly_ with
/etc/libmap.conf will result in considerable foot shooting.

-aDe
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Baptiste Daroussin-2
On Thu, Feb 23, 2012 at 04:18:25PM -0800, Ade Lovett wrote:

> On 2/23/2012 13:14, Baptiste Daroussin wrote:
> > Another solution could be to add an entry (and drop it in deinstallation to
> > libmap.conf) when installing the nvidia driver, in that case installing it ad
> > libGL-nvidia.so.1 and adding:
> >
> > libGL.so.1 libGL-nvidia.so.1
> >
> > or something like that.
>
> Going that route is likely to be messy given the current monolithic
> /etc/libmap{,32}.conf
>
> You'd most likely want ${LOCALBASE}/etc/libmap.conf.d/* (in a similar
> manner to etc/periodic, etc/rc.d and so on).  Whether the code that
> currently handles libmap.conf is itself extended to use this directory
> structure is open for discussion.  An alternate method could perhaps be
> a 'genlibmap' command which takes /etc/libmap.conf and this directory
> structure to create a /var/run/libmap.conf which is actually used by rtld.
>
> Having potentially multiple ports dinking _directly_ with
> /etc/libmap.conf will result in considerable foot shooting.
>
> -aDe
I agree with that, currently we can have LIBMAP env variable to append antoher
libmap.conf file to the /etc/libmap.conf,

So we have two option, convert the LIBMAP variable to a PATH-like variable,
(don't like this very much) or add an "includedir" keyword to libmap.conf then
the code will go thought the includedir and parse all the .conf files available
in that directory.

the second seems pretty easy, I'll write a PoC for it as soon as I can

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Baptiste Daroussin-2
In reply to this post by Ade Lovett
On Thu, Feb 23, 2012 at 04:18:25PM -0800, Ade Lovett wrote:

> On 2/23/2012 13:14, Baptiste Daroussin wrote:
> > Another solution could be to add an entry (and drop it in deinstallation to
> > libmap.conf) when installing the nvidia driver, in that case installing it ad
> > libGL-nvidia.so.1 and adding:
> >
> > libGL.so.1 libGL-nvidia.so.1
> >
> > or something like that.
>
> Going that route is likely to be messy given the current monolithic
> /etc/libmap{,32}.conf
>
> You'd most likely want ${LOCALBASE}/etc/libmap.conf.d/* (in a similar
> manner to etc/periodic, etc/rc.d and so on).  Whether the code that
> currently handles libmap.conf is itself extended to use this directory
> structure is open for discussion.  An alternate method could perhaps be
> a 'genlibmap' command which takes /etc/libmap.conf and this directory
> structure to create a /var/run/libmap.conf which is actually used by rtld.
>
> Having potentially multiple ports dinking _directly_ with
> /etc/libmap.conf will result in considerable foot shooting.
>
> -aDe
Here is a patch to add support for includedir keyword to libmap.conf so that we
can add:
includedir /usr/local/etc/libmap.d
into libmap.conf and then nvidia driver could add a
${LOCALBASE}/etc/libmap.d/nvidia
containing:
libGL.so.1 libGL-nvidia.so.1

http://people.freebsd.org/~bapt/libmap-support-includedir.diff

Any remarks?

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

dougb
On 2/28/2012 1:15 PM, Baptiste Daroussin wrote:
> Here is a patch to add support for includedir keyword to libmap.conf so that we

I think this is overly complicated, and not generally useful. It also
delays the utility of the solution until this gets into the base.

What I would do instead is to incorporate an nvidia option into the xorg
meta-port, and separate the GL libs into a separate port. If the nvidia
option is checked the GL libs come from an nvidia slave port. If not,
they come from an xorg-server slave port.

Or, we just keep doing what we're doing now, since it works. I'm still
not sure what problem we're trying to solve. :)


Doug

--

        It's always a long day; 86400 doesn't fit into a short.

        Breadth of IT experience, and depth of knowledge in the DNS.
        Yours for the right price.  :)  http://SupersetSolutions.com/

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Freddie Cash-8
The problem is when tools like portmaster notice x11/nvidia-driver
(not installed) has a newer version number than x11/nvidia-driver-173
(installed), and the mesa/dri/drm ports have updates available, and
then builds/installs them in the wrong order such that the
x11/nvidia-driver port is installed first, the x11/nvidia-driver-173
port is removed, and then the x11/meda/dri/drm ports are installed,
leaving you with a broken mess.

You get an nvidia.ko that doesn't support the video card installed in
the machine, an nvidia X11 driver that links against the wrong
libGL.so, and thus a broken X11 setup that can lead to a lot of
frustration, gnashing of teeth, and tearing of sackcloth to get sorted
out.  :(

There are three issues here (at least for me, although it's really
only the last one that's the topic of this thread):
  - the fact that portmaster sees "nvidia-driver" instead of
"nvidia-driver-173" as the port name and installs the wrong port
  - the fact that portmaster installs "nvidia-driver" before the
x11/mesa/dri/drm ports
  - the fact that both the nvidia-driver* and x11/mesa/dri/drm ports
install libGL.so, and the wrong one is installed "last"

The combination of those three means that any upgrade of nvidia/x11
ports requires a lot of manual hand-holding to make sure things are
installed in the right order, and that the correct ports are installed
(thank god of -i).

That last option is the one that causes all the issues.  Two ports
install the same file, but they aren't listed as CONFLICTS of each
other, so it's up to the end-user to "make it work".

Ideally, the best solution would be to fix those ports such that they
don't install the same file, and that they are listed as CONFLICTS of
each other.  A nice solution would be, as you suggested, separating
out the libGL bits into slave ports and only installing one of them
(and getting the versioning right so that updates only occur in the
right port).

The other issues are slightly annoying, although not really sure how
to fix them permanently, and they're outside the scope of this thread.

(This issue is making me regret installing an nVidia video card into
my home desktop.  Life was so much simpler with Ati and Intel.)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Jerry
On Tue, 28 Feb 2012 13:36:26 -0800
Freddie Cash articulated:

> (This issue is making me regret installing an nVidia video card into
> my home desktop.  Life was so much simpler with Ati and Intel.)

Except that neither of them seem to work as well; at least not the ATI
cards that I have tried.

By the way, "portmanager" does not have the problems you were
attributing to "postmaster". Whether that is by design or just dumb luck
I cannot attest to. That is why I still use it although most other
users have abandoned it.


--
Jerry ♔

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__________________________________________________________________
Reality always seems harsher in the early morning.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Baptiste Daroussin-2
In reply to this post by dougb
On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote:

> On 2/28/2012 1:15 PM, Baptiste Daroussin wrote:
> > Here is a patch to add support for includedir keyword to libmap.conf so that we
>
> I think this is overly complicated, and not generally useful. It also
> delays the utility of the solution until this gets into the base.
>
> What I would do instead is to incorporate an nvidia option into the xorg
> meta-port, and separate the GL libs into a separate port. If the nvidia
> option is checked the GL libs come from an nvidia slave port. If not,
> they come from an xorg-server slave port.
>
> Or, we just keep doing what we're doing now, since it works. I'm still
> not sure what problem we're trying to solve. :)
>
>
> Doug
the problem we are trying to solve is to avoid having the nvidia drivers
overwritting libGL.so.1 which break the package database consistency.

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

RW-15
In reply to this post by Freddie Cash-8
On Tue, 28 Feb 2012 13:36:26 -0800
Freddie Cash wrote:

> The problem is when tools like portmaster notice x11/nvidia-driver
> (not installed) has a newer version number than x11/nvidia-driver-173
> (installed), and the mesa/dri/drm ports have updates available, and
> then builds/installs them in the wrong order such that the
> x11/nvidia-driver port is installed first, the x11/nvidia-driver-173
> port is removed, and then the x11/meda/dri/drm ports are installed,
> leaving you with a broken mess.

This sounds like it's a portmaster bug to me - it didn't happen with
portupgrade or portmanager when I used nvidia-driver-173.

The consequences of merely building the ports out of order are pretty
minor in my experience. You lose OpenGL 3d hardware acceleration for
wobbly windows, games etc, and it's easily fixed by forcing an
nvidia-driver rebuild. The key reasons for choosing nVidia, vdpau video
acceleration and general performance aren't affected.

If you want to stay with portmaster, I'd suggest you configure it to
ignore nvidia-driver-173, and handle it manually.

 

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

dougb
In reply to this post by Baptiste Daroussin-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/28/2012 14:36, Baptiste Daroussin wrote:

> On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote:
>> On 2/28/2012 1:15 PM, Baptiste Daroussin wrote:
>>> Here is a patch to add support for includedir keyword to
>>> libmap.conf so that we
>>
>> I think this is overly complicated, and not generally useful. It
>> also delays the utility of the solution until this gets into the
>> base.
>>
>> What I would do instead is to incorporate an nvidia option into
>> the xorg meta-port, and separate the GL libs into a separate
>> port. If the nvidia option is checked the GL libs come from an
>> nvidia slave port. If not, they come from an xorg-server slave
>> port.
>>
>> Or, we just keep doing what we're doing now, since it works. I'm
>> still not sure what problem we're trying to solve. :)
>>
>>
>> Doug
>
> the problem we are trying to solve is to avoid having the nvidia
> drivers overwritting libGL.so.1 which break the package database
> consistency.

In that case the solution I outlined above would work, and it's hard
for me to see why it wouldn't be the best solution.


Doug

- --

    This .signature sanitized for your protection
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJPUJQUAAoJEFzGhvEaGryEoIYIANJ0DHtcxIRCCY85rKB/2ENQ
p8iSPhkuA99eGsbBukzhBpyivNskm10/W5XnhLy+VzuyX6UmxRfa1w+hxp7tej75
zZHrSnByb3j3iYG9MgiE/Doeo1Iwg8qknhr+W6JhVVTZQH0jM4Y3uPd4xxlLc8lT
GDhtbPWPeQMggzJdjiajQSUJBLZMMoFzXGiaetr0yyz4HwEv8IjcUSTdkZ/ixHB5
5GoVODLr5RuGCErYWLTzR2DytZ9MroJwH+iRcWNuY5w7aAG6SF5Wqytsq3RgYqga
bWUBVCtozaAah+clGR8dkyL0IC+RZxSRdoR3JqlXtfAbhZBnHuo9VYOlhLtPMIA=
=+RmT
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Fix nvidia-like ports, help needed

Konstantin Belousov
On Fri, Mar 02, 2012 at 01:34:12AM -0800, Doug Barton wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/28/2012 14:36, Baptiste Daroussin wrote:
> > On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote:
> >> On 2/28/2012 1:15 PM, Baptiste Daroussin wrote:
> >>> Here is a patch to add support for includedir keyword to
> >>> libmap.conf so that we
> >>
> >> I think this is overly complicated, and not generally useful. It
> >> also delays the utility of the solution until this gets into the
> >> base.
> >>
> >> What I would do instead is to incorporate an nvidia option into
> >> the xorg meta-port, and separate the GL libs into a separate
> >> port. If the nvidia option is checked the GL libs come from an
> >> nvidia slave port. If not, they come from an xorg-server slave
> >> port.
> >>
> >> Or, we just keep doing what we're doing now, since it works. I'm
> >> still not sure what problem we're trying to solve. :)
> >>
> >>
> >> Doug
> >
> > the problem we are trying to solve is to avoid having the nvidia
> > drivers overwritting libGL.so.1 which break the package database
> > consistency.
>
> In that case the solution I outlined above would work, and it's hard
> for me to see why it wouldn't be the best solution.
There are hybrid machines which have both Intel and NVidia GPUs.
Depending on a switch position, you may activate one of the GPU.
Usually, on-CPU GPU gives power efficiency, while discrete one provdes
a performance.

For such machines, it is _very_ useful to have both libGL.so.1 installed
and somehow switched around. It would be best to have Mesa and NVidia
libGL.so.1 installed under other names, like libGL-mesa.so.1. and
ligGL-nvidia.so.1, and provide a symlink for libGL.so.1

BTW, besides libGL.so.1, another conflicting file is
/usr/local/lib/xorg/modules/extensions/libglx.so.

attachment0 (203 bytes) Download Attachment
12