[pkg-nvidia-devel] Moving diversions between packages
Andreas Beckmann
debian at abeckmann.de
Thu Aug 12 21:56:30 UTC 2010
On 2010-07-29 02:02, Steve Langasek wrote:
> Hi Russ,
>
> On Thu, Jul 22, 2010 at 06:47:34AM -0700, Russ Allbery wrote:
>
>> We're attempting to solve this problem by splitting out just the libGL
>> library into a separate package (libgl1-nvidia) that can be independently
>> installed. However, that means the diversions of libGL have to move from
>> nvidia-glx to this new package. And that's where we ran into problems.
>
> Somewhat orthogonal to your original question, but the Ubuntu nvidia
> packages have recently switched to using alternatives instead of diversions
> for managing the libgl bits for various reasons. It would be great if
> Debian and Ubuntu could get synced up on this... and maybe moving to
> alternatives solves the problem with moving diversions, since alternatives
> don't have the unpack ordering problem that diversions do. Cc:ing the
> Ubuntu nvidia package maintainer to make him aware of this discussion.
The Ubuntu way (everything in one package,
there-is-only-one-kernel-version) does not work for the current Debian
approach, but using alternatives is a good idea.
I now implemented the following:
libgl1-nvidia-glx ships its libGL.so.* in /usr/lib/nvidia/ instead of
usr/lib/. In the postinst (hopefully this fixes the corner case upgrade
problems, I couldn't reproduce them) the libGL.so.* from libgl1-mesa-glx
in /usr/lib is diverted to /usr/lib/nvidia/diversions. Diverting late is
now possible since we don't have file conflicts with shipped files. The
preinst wrong-upgrade-order check has been removed.
Afterwards I setup some alternatives to provide libGL.so.1 (there are
two possibilities: /usr/lib/nvidia/libGL.so.1 with priority 42 (we could
use the major version but since we don't allow more than one version to
be installed at the same time this does not really matter) and
/usr/lib/nvidia/diversions/libGL.so.1 with priority 5). This would
actually allow the user to have nvidia-glx installed and still use the
mesa libGL.so.1 by manually reconfiguring the alternatives. Since
libgl1-mesa-glx is not required to be installed, this second alternative
is controlled by a trigger. Similarily the trigger that updates
/usr/lib/libGL.so now handles this as an alternative, too. I do not
consider /usr/lib/nvidia/libGL.so from libgl1-nvidia-dev as a valid
alternative to provide libGL.so since we want to discourage linking with
libGL.so* from NVIDIA when compiling.
Similar things are done for libgl1-nvidia-glx-ia32 (but without triggers
because we depend on ia32-libs with carries mesa's libGL.so*).
If this approach works, we might consider a joint effort with the
maintainers of libgl1-mesa* and fglrx to simplify the libgl1 diverting
mess by switching to alternatives in all providers of libGL.so*.
Open question: does the shlibs system work properly and generate the
correct dependencies when libraries are provided via alternatives?
I successfully tested upgrading nvidia-graphics-drivers from lenny and
sid to 195.36.31 (with late diversions and alternatives) using my
modified piuparts. The package needs more lintian cleanup and the
divert/alternatives modifications still need to be ported to the legacy
packages (but first I'd like to see that this is working with 195.36.31
in sid).
I did some initial tests on 256.xx in my private svn repository, but due
to changed archive layout provided by nvidia this involves more changes
to the packaging that won't be compatible with the legacy packages.
Therefore even if it is not latest upstream, let's try to get 195.36.31
out (needs to go trough NEW) so the package layout changes can be tested.
I'll be at a conference in Chicago next week, so I won't have much time
to test or work on n-g-d things.
Andreas
PS: One last minute thought: eventually the diversion+trigger stuff
could be moved to a separate package "libgl1-alternatives", that all
libgl1-nvidia(-legacy*)-glx would depend upon. So the "mess" would be in
one place only. I had thought about this before but without considering
alternatives at that time it did not work out.
More information about the Pkg-nvidia-devel
mailing list