The NVIDIA packages and squeeze

Tue Sep 21 17:22:55 UTC 2010

On Tue, Sep 21, 2010 at 18:23:40 +0200, Andreas Beckmann wrote:

> On 2010-09-21 15:59, Julien Cristau wrote:
> > It's a bit surprising to have the Xorg driver in a package with a glx
> > name, but I guess that's due to both parts of the driver being in the
> > same package previously..
> 
> Nearly everything was in nvidia-glx previously ... when splitting the
> package I was considering moving the driver, too, but then things would
> have become more complicated. But we still can do this post-squeeze -
> suggestions for a package name welcome. Would
>     xserver-xorg-video-nvidia and
>     xserver-xorg-video-nvidia-legacy-ABCxx
> be OK?
> 
I don't know, it might not be worth it.  Let's discuss this after
squeeze?

> > Can you make the X driver package depend on xorg-video-abi-6.0?  I'm
> > trying to get rid of the model we were using before so the X server
> > doesn't have to conflict against old drivers, and the drivers depend on
> > the server ABI they're built against (or work with, for the closed ones)
> > instead.
> 
> No problem. Should we remove the Provides: xserver-xorg-video-6 at the
> same time?
> 
You can keep it for now.  When we move to video ABI 8 (or up, if we go
to xserver 1.10 directly) then we'll drop those.

> > I'm not sure why you conflict against the old 2.6.32-trunk header
> > packages?
> 
> Because they sort badly (i.e. newer than 2.6.32-5) and we had at least
> one bug report where the module was built for the wrong kernel because
> -trunk- kernel/headers was still installed. We couldn't reproduce this
> or track it down completely. There is no reason to have packages with
> the bad abiname -trunk remaining installed, anyway.
> 
OK.  I guess it does no harm.

> > I don't understand how the libnvidia-compiler thing works, it installs a
> > SONAME-less library in /usr/lib?  What uses it?
> 
> libnvidia-compiler.so is a huge plugin used by NVIDIA's CUDA/OpenCL
> implementation. As it is not neccessary for all CUDA/OpenCL applications
> (only if they are to be compiled on the fly) it is not bundled with
> libcuda1.
> Starting with 256.xx NVIDIA uses a soname matching the current upstream
> version, so this will change with every new upstream. They will dlopen
> libnvidia-compiler.so.NVIDIAVERSION then instead of
> libnvidia-compiler.so as in 195.xx. Unfortunately there is no specific
> search path being used, so this needs to go to /usr/lib. As the only
> user is libcuda.so.1 with an exactly matching upstream version I decided
> to go for a package without a soname to avoid going through NEW
> everytime for no good reason. Versioned dependencies will ensure that no
> mismatching upstream versions are installed. There is no use in having
> different versions of libnvidia-compiler.so.* installed when there is
> only one user (libcuda.so.1) available that will use exactly one of them.
> 
ok.

> > Maybe a stupid question: why do you need to install libGL.so pointing at
> > the nvidia lib at all?
> 
> Hmm, for historical reasons. It has been shipped and messed around with
> forever. I think, as long as we have the NVIDIA OpenGL headers available
> (in /usr/include/nvidia/GL), we should ship a matching libGL.so. (For
> the people that really want to to use NVIDIAs headers and link against
> their library).
> 
I don't know if these people exist, but ok :)
Not worth revisiting for squeeze anyway.

> > The diversion+alternatives stuff makes my head hurt so I'm not sure I
> > can review that.  Can you explain how this stuff works?
> 
> Historically, nvidia-glx (and the legacy and ia32 variants) have
> diverted libGL.so, libGL.so.1 and libglx.so and created random symlinks
> (I think that's the best description of the old maintainer scripts and
> init script operations). Removing and purging often failed or did not
> undo things correctly.
> 
> Now we have the lib*-nvidia-alternatives packages that handle
> diversions, and setup alternatives via triggers
[...]

Thanks, that's starting to make sense.

> > libgl1-nvidia-dev.postinst doesn't install an alternative, but
> > debian/libgl1-nvidia-dev.prerm removes it anyway, is that intentional?
> 
> Yes. We currently don't want to provide libGL.so from NVIDIA as an
> alternative to the one from MESA. People should link with MESA at
> compile time and run with NVIDIA.
> 
> > Was the '42' priority chosen at random (or, well semi-random, it's 42
> > after all)?
> 
> I was considering using the NVIDIA major version, but currently we don't
> support concurrent installation of current and legacy packages, so I
> chose '42' higher than MESA ('5') and lower than NVIDIA (71, 96, 173,
> 195, 256)
> 
> > debian/libgl1-nvidia-glx.prerm removes the alternative from
> > libgl1-nvidia-dev? (same with the ia32 versions)
> 
> That was superfluous, thanks. For the ia32 variant there is no separate
> -dev package, so both libGL.so and libGL.so.1 have to be handled (even
> if libGL.so is not registered as an alternative currently).
> 
> > I don't understand debian/libgl1-nvidia-glx.symbols.common.in,
> > libGL.so.1 ABI is set in stone by http://www.opengl.org/registry/ABI/ so
> > there shouldn't be any need for symbols for it.
> 
> There is no symbols file for libGL.so.1 being installed in the package,
> only shlibs files pointing to MESA are being used.
> The remaining symbols are for NVIDIA's "internal" libraries.
> 
I'll have to look at this again, then, because I haven't found how you
avoid installing that symbols file with libGL.so.1 stuff.

> > I'm not sure diversion+alternative for
> > /usr/lib/xorg/modules/extensions/libglx.so is the best plan as opposed
> > to installing in a directory which the module loader will check first
> 
> Is there a possibility to "override" libglx.so from Xorg without
> diverting it away?
> 
the dlloader has a list of directories to look at:
/* Standard set of module subdirectories to search, in order of preference */
static const char *stdSubdirs[] = {
    "",
    "input/",
    "drivers/",
    "multimedia/",
    "extensions/",
    "internal/",
    NULL
};

Probably not something to change for squeeze either anyway.

> > (there's no such choice for libGL.so.1 since the ABI spec says it's in
> > /usr/lib).  Although I guess that makes it possible to switch
> > implementations while keeping the package installed.
> 
> The possibility to switch was something users were asking for. This may
> work now, but has not been tested in detail.
> 
> There are currently three providers (that I know) for libGL.so.1 and
> libglx.so: NVIDIA (non-free), FGLRX (non-free), MESA/Xorg (free). (If
> you count the NVIDIA legacy drivers separately, there are more
> providers). If these packages agree on some way to handle their
> co-existence via alternatives/diversions/triggers/conflicts/... in a
> common way, maintaining the non-free variants will become easier in the
> future. But that's a task for squeeze+1. The things I implemented now
> for nvidia-graphics-drivers(-legacy-*) are an example how this could be
> done - and a great improvement over the previous mess.
> 
ok.

> > Do the nvidia packages do anything to prevent nouveau.ko from being
> > loaded?
> 
> nvidia-kernel-common (all binary module packages and the dkms packages
> depend on this package) installs a blacklist entry in /etc/modprobe.d/
> 
That kind of sucks because it means that package has to be purged before
nouveau can work again.  Oh well.

Cheers,
Julien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20100921/642f1512/attachment.pgp>