x11/nvidia-driver incompatible with portmaster?

[b. f.]

On 7/5/11, Kostik Belousov <kostikbel at gmail.com> wrote:
> On Tue, Jul 05, 2011 at 05:58:53AM +0000, b. f. wrote:
>> On 7/3/11, Kostik Belousov <kostikbel at gmail.com> wrote:
>> > On Sun, Jul 03, 2011 at 12:45:50PM +0000, b. f. wrote:
>> >> On 7/3/11, Kostik Belousov <kostikbel at gmail.com> wrote:
>> >> > On Sun, Jul 03, 2011 at 03:54:15AM +0000, b. f. wrote:
>> >> >> On 7/3/11, Stephen Montgomery-Smith <stephen at missouri.edu> wrote:
>> >> >> > On 07/02/2011 09:02 PM, Stephen Montgomery-Smith wrote:
>> >> >> >> On 07/02/2011 08:39 PM, b. f. wrote:
>> >> ...
>> >> >
>> >> > That said, there is absolutely no need in any static linker tricks,
>> >> > esp. a heavy one like filters or linker scripts. A symlink named
>> ...
>> >>
>> >> > libGL.so would be enough for the static linker, pointing to any
>> >> > of two libraries. And symlink libGL.so.1 would be also enough
>> >> > for dynamic linker.
>> >> >
>> >> > The real issue with xorg-server, mesa and nvidia driver is only
>> >> > the overwrite of extensions/libglx.so and lib/libGL.so.1. If
>> >> > this can be somewhat solved by the packaging system, that would
>> >> > be great. On my hybrid laptop I have to manually manage the
>> >> > said symlinks (actually, with the rc script that verifies
>> >> > the list of pci devices and arranges the symlinks).
>> >>
>> >> So basically, you would prefer that we:
>> >>
>> >> patch xorg-server so that it installs, e.g.,
>> >> ${PREFIX}/lib/xorg/modules/extensions/libglx-xorg.so.1 instead of
>> >> ${PREFIX}/lib/xorg/modules/extensions/libglx.so.1, and points the
>> >> symlink ${PREFIX}/lib/xorg/modules/extensions/libglx-xorg.so at the
>> >> former;
>> >>
>> >> patch libGL so that it installs, e.g., ${PREFIX}/lib/libGL-mesa.so.1
>> >> instead of ${PREFIX}/lib/libGL.so.1, and points the symlink
>> >> ${PREFIX}/lib/libGL.so at the former;
>> >>
>> >> and patch nvidia-driver so that it installs, e.g.,
>> >> ${PREFIX}/lib/xorg/modules/extensions/libglx-nvidia.so.1 instead of
>> >> ${PREFIX}/lib/xorg/modules/extensions/libglx.so.1, and
>> >> ${PREFIX}/lib/libGL-nvidia.so.1 instead of ${PREFIX}/lib/libGL.so.1;
>> >> and during installation it overwrites the
>> >> ${PREFIX}/lib/xorg/modules/extensions/libglx-xorg.so and
>> >> ${PREFIX}/lib/libGL.so symlinks, redirecting them to the corresponding
>> >> nvidia libraries; while during deinstallation it changes them to point
>> >> to the mesa/xorg libraries?
>> > Yes.
>> >
>> >>
>> >> And corresponding redirection to handle the libtool archive file?
>> > I do not think this is needed. First, I believe .la files are only
>> > installed by the Xorg ports. Second, as I described, libGL.so from
>> > Xorg and from NVidia should be replacable for the static linking
>> > purposes. Third, libglx.la is not used at all.
>> ...
>> > On Sun, Jul 03, 2011 at 01:33:09PM +0000, b. f. wrote:
>> >> On second thought the renaming of these libraries is not very
>> >> convenient, since they are built by nvidia, and not necessary if their
>> >> mesa/xorg counterparts already have different names.
>> >
>> > As I said, it is useful for me on the hybrid laptop, where a switch
>> > selects the GPU attached to the panel. The startup script then would
>> > only need to create proper symlink, instead of delicate renaming
>> > of the libraries.
>>
>> Please consider the attached patch.  Small unrelated clean-ups to
>> x11-servers/xorg-server and bsd.mesalib.mk are included with the
>> changes that remove the collisions, and add the necessary symlinks.
>> The renaming in the xorg-server post-install target is a bit ugly, but
>> much easier than dissecting the libtool build and installation of the
>> glx convenience library.  I used sed rather than patches for some of
>> the changes in libGL and nvidia-driver because of the multiple
>> distfiles involved.
>>
>
> I think that the policy in xorg and mesa ports should be to install
> symlinks if they are not present, instead of checking for the
> presence of nvidia driver.

Can do -- although it raises the small possibility that the link could
be damaged or left dangling and forgotten, and interfere with
subsequent reinstallation.  That's not a problem for someone like you,
but other users may not be able to fix such a problem as easily.)  But
on removal, what then?  Always remove the symlink? Always leave it in
place? Or try to determine whether it points to a library owned by the
port being removed, and remove it if it does?  I don't think the
second would be a good idea for many users.

>
> Also, the installation of libglx.so and post-factum renaming looks rude
> and could probably cause complications since original libglx.so symlink
> is removed, am I right ?
>

Yes, as I wrote, I wasn't altogether happy with that, but it was
expedient.  If there is a symlink there, it will be overwritten, and
then replaced by a link to either the xorg library or the
nvidia-driver library, depending upon whether the nvidia-driver is
present.  Of course, that's not so different from any other port
installation, which will overwrite existing files and links.  But I
guess you're using some alternative symlinks that you want to
preserve?  I could take the low road, and move the link out of the way
temporarily, restoring it after renaming the xorg library, or I could
take the high road and add further patches to override  the current
libtool install.  Which road is it to be?

b.