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

[Josh Triplett]

On Sun, Nov 29, 2009 at 03:28:13PM -0500, Andres Mejia wrote:
> 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 see.  mplayer completely reinvents libvdpau's functionality, by
manually using dlopen itself, and shipping a copy of the vdpau headers.
And libvdpau itself then dlopens the backend library.

> > 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.

That sounds like a bug in mplayer; it ought to treat
VDP_STATUS_NO_IMPLEMENTATION as a failure to initialize the vo, and go
to the next one in the list.

> vdpau-info 
> also doesn't work properly until a vdpau driver is installed.

"doesn't work properly" in what sense?  It ought to just print an error
and exit; does it crash instead, or print invalid data?

> > 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.

Right, adding a Depends or Recommends on a driver package would
currently mean moving to contrib.

> 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.

Adding to this, you could also make the nvidia driver packages (and any
other drivers which have a corresponding VDPAU driver) Recommend their
VDPAU driver.  That would help the user get the right one installed for
their system.

> 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.

This seems equivalent to your current approach of shipping a
libvdpau-driver package which Depends on the available VDPAU drivers,
though it does seem more convenient in the future case where more VDPAU
drivers exist to not have to maintain a list of them in libvdpau-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

That seems really ugly.  I think it would make a lot more sense to not
have that list in every package using VDPAU.

(Also, no need to limit the nvidia driver by architecture; if it doesn't
exist on a given architecture, the alternatives will allow selection of
another choice.)

> 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.

True, but I'd expect that anyway from most such software.

- Josh Triplett