nvidia-* and fglrx need to be migrated to per-architecture gl_conf alternative

[Anders Kaseorg]

From the mesa changelog:

mesa (7.10.3-0ubuntu1) oneiric; urgency=low
…
  * Merge multiarch support branch:
    - Declare Breaks: against old versions of xserver-xorg-core and
      libgl1-mesa-glx that will look for DRI modules only in /usr/lib/dri.
    - Fix up the maintainer scripts to transition to per-architecture
      alternatives for ld.so configs.
    - Declare Breaks: against nvidia-current, nvidia-173, and fglrx due to the
      migration of alternatives for the ld.so.conf snippets.
    - Use multiarch dirs for our dri module search path, with a fallback to
      /usr/lib/dri.
    - Use the right path for dh_shlibdeps.

Hence libgl1-mesa-glx 7.10.3-0ubuntu1 Breaks: nvidia-current (<= 270.41.19-0ubuntu1). But since then, a new nvidia-current 275.09.07-0ubuntu1 was released that has not actually been migrated to the new per-architecture alternatives. That makes it impossible now to use mesa’s libGL while nvidia-current is installed.

nvidia-current needs to be migrated, and the Breaks: version needs to be updated in libgl1-mesa-glx.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: nvidia-current 275.09.07-0ubuntu1
ProcVersionSignature: Ubuntu 3.0-0.1-generic 3.0.0-rc2
Uname: Linux 3.0-0-generic x86_64
NonfreeKernelModules: openafs
Architecture: amd64
Date: Thu Jun 16 03:18:22 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20101202)
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: nvidia-graphics-drivers
UpgradeStatus: No upgrade log present (probably fresh install)

[Anders Kaseorg (andersk)]

The libgl1-mesa-glx Breaks: was made unversioned in bug 798007. The nvidia-current fix is still needed.

[Mathieu Comandon (strycore)]

The patches works nicely, thanks Anders !

[Anders Kaseorg (andersk)]

BTW, my patched nvidia-current is available in https://launchpad.net/~anders-kaseorg/+archive/ppa , if anyone else wants it.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nvidia-graphics-drivers - 275.09.07-0ubuntu2

---------------
nvidia-graphics-drivers (275.09.07-0ubuntu2) oneiric; urgency=low

  * debian/rules, debian/nvidia-current.prerm{.in},
    debian/nvidia-current.postinst{.in}:
    - Add initial support for multi-arch (LP: #798049).
    - Remove obsolete instructions.
 -- Alberto Milone <email address hidden> Thu, 23 Jun 2011 16:56:00 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package nvidia-graphics-drivers-173 - 173.14.30-0ubuntu3

---------------
nvidia-graphics-drivers-173 (173.14.30-0ubuntu3) oneiric; urgency=low

  * debian/rules, debian/nvidia-173.prerm{.in},
    debian/nvidia-173.postinst{.in}:
    - Add initial support for multi-arch (LP: #798049).
    - Remove obsolete instructions.
 -- Alberto Milone <email address hidden> Thu, 23 Jun 2011 16:59:30 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package fglrx-installer - 2:8.861-0ubuntu1

---------------
fglrx-installer (2:8.861-0ubuntu1) oneiric; urgency=low

  * New upstream release 8.861 (11-6).
  * Add scripts to support for PXpress (see debian/pxpress) and
    install an additional alternative to switch between libraries.
  * Deep rework of the packaging scripts, so as to make it possible
    to generate more files from templates.
  * Add initial support for multi-arch (LP: #798049).
 -- Alberto Milone <email address hidden> Thu, 23 Jun 2011 18:42:40 +0200

[Anders Kaseorg (andersk)]

> - Add initial support for multi-arch (LP: #798049).

Since regen-from-templates is only called from the ‘clean’ target, this will cause the package to be misbuilt on any architecture that the source package wasn’t built on, if the builder does not call debian/rules clean first. The Ubuntu builders currently do, but it won’t necessarily happen if somebody rebuilds the package on their system.

[Harry (harry33)]

I can confirm the nvidia-current_275-09-07-0ubuntu2 works with mesa_7.10.3-0ubuntu1.
That first mesa 7.10.3 build does not break the 275.09 series nvidia-current.
The breakage was added to the later builds.
So now we need to remove the breakage from the newest mesa_7.10.3.

However, nvidia-current_275.09.07-0ubuntu2 works only if it is installed after the mesa packages.

[Anders Kaseorg (andersk)]

Hmm, it’s still not possible for me to install nvidia-current on x86_64 but configure it to not be used, because although x86_64-linux-gnu_GL.conf can be overridden by the mesa version, there is no mesa version of i386-linux-gnu_GL.conf, and nvidia’s i386-linux-gnu_GL.conf includes the 64-bit libraries too.

BTW, it seems unfriendly for the postinst to delete all non-multiarch gl_conf alternatives including those belonging to other packages. It should only delete the ones belonging to itself.

[Alberto Milone (albertomilone)]

@Anders:
Yes, we have to upload a new mesa and set versioned breaks.

I know that removing all non multiarch gl_conf alternatives may not seems exactly a good idea but I've noticed that installing a multiarch alternative beside a non multiarch one would fail because they point to the same files (despite using different links).

[Alberto Milone (albertomilone)]

*seem

[Launchpad Janitor (janitor)]

This bug was fixed in the package mesa - 7.10.3-0ubuntu4

---------------
mesa (7.10.3-0ubuntu4) oneiric; urgency=low

  * debian/control:
    - Make the Breaks against the proprietary drivers versioned again now that
      the proprietary drivers work well with multi-arch mesa. (LP: #798049)
 -- Alberto Milone <email address hidden> Fri, 24 Jun 2011 12:18:53 +0200

[Alberto Milone (albertomilone)]

Adding a task for Jockey so that its handlers deal with the right alternatives.

[Alberto Milone (albertomilone)]

Adding a task for nvidia-common, which Jockey uses to deal with alternatives.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nvidia-common - 1:0.2.31

---------------
nvidia-common (1:0.2.31) oneiric; urgency=low

  * NvidiaDetector/alternatives.py:
    - Replace __ with _ for private methods.
    - Make Alternatives a new-style class.
    - Add MultiArchUtils class so that Jockey can get the names of
      multi-arch alternatives (LP: #798049).
 -- Alberto Milone <email address hidden> Fri, 24 Jun 2011 18:11:31 +0200

[Anders Kaseorg (andersk)]

In comment 13:
> Yes, we have to upload a new mesa and set versioned breaks.

Assuming that was a reply to comment 12, that wasn’t what I was worried about. Even when a new mesa is uploaded with versioned breaks, it will still have the problem I described:

“Hmm, it’s still not possible for me to install nvidia-current on x86_64 but configure it to not be used, because although x86_64-linux-gnu_GL.conf can be overridden by the mesa version, there is no mesa version of i386-linux-gnu_GL.conf, and nvidia’s i386-linux-gnu_GL.conf includes the 64-bit libraries too.”

> I know that removing all non multiarch gl_conf alternatives may not
> seems exactly a good idea but I've noticed that installing a multiarch
> alternative beside a non multiarch one would fail because they point
> to the same files (despite using different links).

My suggestion was not that you should install the multiarch alternative beside the non-multiarch alternative pointing to the same files. It was “It should only delete the [non-multiarch alternative] belonging to itself.” This is what libgl1-mesa-glx.postinst does, and it’s what I did in my patch:

case "$1" in
    configure)
        # on upgrade from previous versions, clean up our non-arch-qualified
        # alternative
        if dpkg --compare-versions "$2" lt-nl 275.09.07-0ubuntu2; then
            update-alternatives --remove gl_conf /usr/lib/nvidia-current/ld.so.conf
        fi

        # Deal with alternatives

[Alberto Milone (albertomilone)]

On 06/24/2011 11:08 PM, Anders Kaseorg wrote:
> In comment 13:
>> Yes, we have to upload a new mesa and set versioned breaks.
>
> Assuming that was a reply to comment 12, that wasn’t what I was worried
> about. Even when a new mesa is uploaded with versioned breaks, it will
> still have the problem I described:
>
> “Hmm, it’s still not possible for me to install nvidia-current on x86_64
> but configure it to not be used, because although x86_64-linux-
> gnu_GL.conf can be overridden by the mesa version, there is no mesa
> version of i386-linux-gnu_GL.conf, and nvidia’s i386-linux-gnu_GL.conf
> includes the 64-bit libraries too.”

fglrx and nvidia install a fake alternative in addition to the one for
your architecture, which is meant to override the second alternative
provided by multi-arch mesa (e.g. by i386 mesa if you're using adm64).
This means that you should only configure the alternative for your arch
for now as apt, by default, is not multi-arch enabled yet and therefore
you can't install i386 mesa using apt yet (again with the default settings).

>> I know that removing all non multiarch gl_conf alternatives may not
>> seems exactly a good idea but I've noticed that installing a multiarch
>> alternative beside a non multiarch one would fail because they point
>> to the same files (despite using different links).
>
> My suggestion was not that you should install the multiarch alternative
> beside the non-multiarch alternative pointing to the same files. It was
> “It should only delete the [non-multiarch alternative] belonging to
> itself.” This is what libgl1-mesa-glx.postinst does, and it’s what I
> did in my patch:
>

Yes, I didn't misunderstand what you said. I tested this on a system
with fglrx, nvidia-current and nvidia-173 installed at the same time. So
if, for example, you installed nvidia-current you would remove the old
alternative installed by the old nvidia-current but then the new
alternative would conflict with the old alternative provided by
nvidia-173, and so on. Unfortunately I don't have access to my
workstation to show you the exact error but I'm available to do so next
week when I'm back home, if you're interested.

--
Alberto Milone
Sustaining Engineer (system)
Premium Engagements Team
Canonical OEM Services

[Anders Kaseorg (andersk)]

> fglrx and nvidia install a fake alternative in addition to the one for
> your architecture, which is meant to override the second alternative
> provided by multi-arch mesa (e.g. by i386 mesa if you're using adm64).
> This means that you should only configure the alternative for your arch
> for now

I don’t have such a choice. If I have mesa and nvidia-current installed on x86_64, I can configure the x86_64-linux-gnu_gl_conf alternative, but the only alternative available for i386-linux-gnu_gl_conf is /usr/lib/nvidia-current/ld.so.conf. An alternative with only one option is not configurable. So I cannot prevent /usr/lib/nvidia-current and /usr/lib32/nvidia-current from being added to the linker path.

I’d be more okay with this if nvidia-current’s i386-linux-gnu_gl_conf pointed to a file that only has the 32-bit library locations, but right now it has both 32-bit and 64-bit library locations.

> Unfortunately I don't have access to my
> workstation to show you the exact error but I'm available to do so next
> week when I'm back home, if you're interested.

Hmm, I am a little interested. Under normal circumstances it should be totally fine to have several alternatives pointing to the same file:

$ ls -l /etc/alternatives/ | grep flashplugin
lrwxrwxrwx 1 root root 58 2011-06-24 17:15 firefox-flashplugin -> /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
lrwxrwxrwx 1 root root 58 2011-06-15 16:06 iceape-flashplugin -> /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
lrwxrwxrwx 1 root root 58 2011-06-15 16:06 iceweasel-flashplugin -> /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
lrwxrwxrwx 1 root root 58 2011-06-15 16:06 midbrowser-flashplugin -> /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
lrwxrwxrwx 1 root root 58 2011-06-24 17:15 mozilla-flashplugin -> /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
lrwxrwxrwx 1 root root 58 2011-06-15 16:06 xulrunner-addons-flashplugin -> /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
lrwxrwxrwx 1 root root 58 2011-06-15 16:06 xulrunner-flashplugin -> /var/lib/flashplugin-installer/npwrapper.libflashplayer.so

[Alberto Milone (albertomilone)]

On 06/27/2011 03:35 AM, Anders Kaseorg wrote:
> I’d be more okay with this if nvidia-current’s i386-linux-gnu_gl_conf
> pointed to a file that only has the 32-bit library locations, but right
> now it has both 32-bit and 64-bit library locations.
>

My bad, it was supposed to point to an empty file. I'll fix it.

Thanks for reporting

--
Alberto Milone
Sustaining Engineer (system)
Premium Engagements Team
Canonical OEM Services

[Alberto Milone (albertomilone)]

it should be fixed now

[Launchpad Janitor (janitor)]

This bug was fixed in the package nvidia-graphics-drivers-96 - 96.43.20-0ubuntu1

---------------
nvidia-graphics-drivers-96 (96.43.20-0ubuntu1) oneiric; urgency=low

  * New upstream release:
    - Fixed a bug that caused freezes and crashes when resizing
      windows in KDE 4 with desktop effects enabled using X.Org
      X server version 1.10 or later.
    - Added support for X.Org xserver 1.10 (LP: #741930).
  * debian/control.in:
    - Drop transitional packages.
  * debian/dkms.conf.in:
    - Prevent DKMS builds with kernels newer than the ones we ship.
  * debian/dkms/patches:
    - Drop obsolete patches.
  * debian/nvidia-96.postinst.in:
    - Add support for multi-arch (LP: #798049).
    - Remove slave link to nvidia-smi since the binary does not
      exist.
    - Remove any previous gl_conf alternative.
  * debian/nvidia-96.README.Debian.in
    - Update the README with the DKMS OBSOLETE_BY option.
  * debian/rules:
    - Do not hardcode the X ABI any more.
    - Install an empty ld.so.conf for the fake alternative
    - Remove obsolete instructions from debian/rules
    - Prevent the build from failing when no patches are available.
 -- Alberto Milone <email address hidden> Mon, 01 Aug 2011 16:18:40 +0200