Comment 19 for bug 798049

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