[pkg-nvidia-devel] Bug#558464: Bug#558464: Please don't put libvdpau1 in contrib
josh at joshtriplett.org
Mon Nov 30 00:06:25 UTC 2009
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.
> 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
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
> 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] |
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
> 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
More information about the Pkg-nvidia-devel