[pkg-nvidia-devel] Bug#558464: Bug#558464: Please don't put libvdpau1 in contrib

[Andres Mejia]

severity 558464 wishlist
thanks

On Sunday 29 November 2009 01:25:09 Josh Triplett wrote:
> Package: libvdpau1
> Severity: normal
> 
> libvdpau exists as a portable way to use VDPAU without depending on any
> particular vendor's implementation.  In particular, libvdpau also
> supports *optional* use of VDPAU: a program can link to libvdpau, try to
> use VDPAU, and find out via the VDP_STATUS_NO_IMPLEMENTATION error that
> no VDPAU support exists.
> 
> This seems very similar to requesting an X extension from the X server
> and finding that it doesn't exist; the client library for that extension
> shouldn't inherently go in contrib just because the server-side
> extension support doesn't exist in main yet.
> 
> As it stands, putting libvdpau1 in contrib makes it impossible for a
> package in main to compile with optional VDPAU support.

It is not impossible. Check how mplayer implements vdpau support. You'll have 
to check the git repo as 1.0~rc3+svn20090426-1 is still in the NEW queue.

> I realize that at first glance libvdpau doesn't look particularly useful
> without a backend implementation.  However, libvdpau *exists* to serve
> precisely two functions: ship the VDPAU headers for applications to
> build against, and provide functionality to dlopen a VDPAU backend
> implementation.  If applications provided the dlopen functionality
> themselves, and dlopened the backend library at runtime themselves, that
> wouldn't make those applications move to contrib, as long as they worked
> if they didn't find the backend library.  libvdpau just wraps this
> functionality in a small library, and ships it together with header
> files.
> 
> Now, if any application built against libvdpau fails to run if it gets
> VDP_STATUS_NO_IMPLEMENTATION, that might prove a reasonable basis to put
> that application in contrib until some free VDPAU backend exists.
> However, any application which has optional VDPAU support and works even
> if no backend library exists could remain in main.

mplayer is one of those packages. It won't crash, it will just not display any 
video and doesn't properly fallback to some other video output. vdpau-info 
also doesn't work properly until a vdpau driver is installed.

> Thus, please move libvdpau1, libvdpau-dev, and libvdpau-doc into main,
> and change libvdpau1 to Suggests libvdpau-driver.  Any package which
> absolutely needs a libvdpau backend driver and fails without one could
> add a Depends on libvdpau-driver (and move to contrib).

I have thought about this, how libvdpau can be placed in main and about how to 
install a vdpau driver package.

I considered the approach where a package would depend on libvdpau1 (or build 
depend on libvdpau-dev) and then take care of installing a vdpau driver 
package. One way is to use Depends. Currently however, that means a package 
would have to go into contrib or non-free since the only implementation 
available is the NVIDIA one. It's the same in Recommends as most people have 
default configurations where packages in a Recommends field are automatically 
installed.

There is Suggests, and we could make it the user's job to install libvdpau-
driver or install some vdpau driver package directly. This may work as a 
better solution.

This better solution is to have each vdpau driver package have a Provides 
field. The Provides entry would have vdpau-driver as a package it provides. 
This package wouldn't exist as some package you can install, but it will list 
all the vdpau driver packages that a user can choose to install. Then each 
corresponding package that uses vdpau (to include libvdpau1) can then have a 
Suggests entry of whatever vdpau-driver packages that may exist and 
alternatively vdpau-driver.

So each package making use of vdpau would have a Suggests field which looks 
something like:

Suggests: ati-vdpau-driver |
 intel-vdpau-driver |
 . . .
 nvidia-vdpau-driver [amd64 i386] |
 vdpau-driver

Each vdpau driver package would have a Provides field that would look like:

Provides: vdpau-driver

I can't see any problems with this kind of setup so this may be doable. I'll 
look into this. However, this means that each software that does make use of 
vdpau would have to work properly and have some way to recover in case a vdpau 
driver is not available.

-- 
Regards,
Andres