[pkg-nvidia-devel] Bug#558434: Bug#558434: libvdpau1 should not depend on the libvdpau-driver metapackage

[Andres Mejia]

On Sunday 29 November 2009 00:12:52 Mario Limonciello wrote:
> Andres:
> 
> I think we've got a few disconnects here still.
> 
> > libvdpau without a vdpau driver is not very useful, thus the reason why
> > libvdpau1 depends on libvdpau-driver.
> 
> I'd argue against this.  Binary packages can then link against this package
> without having to pull in the full VDPAU implementation which is a big win.

As I already said, libvdpau without a vdpau driver is not very useful. What 
exactly is the point of installing the libvdpau library at all if it's not 
going to work? libvdpau *Depends* on some implementation of the vdpau driver. 
Currently there's only one (that I know of and that's the NVIDIA 
implementation).

The only other way I see this working is if each software package that uses 
libvdpau have the alternative dependencies for a vdpau driver implementation 
(i.e. what libvdpau-driver has). This of course is redundant work and harder 
to update as coordination has to be done between the maintainers of each 
package that depends on libvdpau.

What I would consider a big win is when an actual free implementation of a 
vdpau driver implementation written and released.

> > Seeing that the nvidia vdpau driver is the only vdpau driver
> > implementation available, that's why you see libvdpau-driver have only
> > one dependency. Once
> > more vdpau driver implementations are available, libvdpau-driver will be
> > updated and users may freely choose what vdpau driver they want to use,
> > or install all of the drivers (libvdpau can handle picking a suitable
> > driver), or
> > simply let apt install the default vdpau driver (the first package in the
> > Depends field out of all the alternatives). Also, once a free vdpau
> > implementation becomes available, libvdpau can enter main.
> 
> Does Debian allow different sections for different binary packages from the
> same source package? 

No.

> Perhaps for now you can then leave libvdpau-driver in
> contrib and the rest in main so other packages in main can start taking
> advantage of this sooner since there is no ETA for an Intel or AMD VDPAU
> solution currently.

They would have to be separated into different source packages and even if that 
were done, libvdpau couldn't enter main as it would still depend on libvdpau-
driver which would be in contrib.

By the way, packages in main can still take advantage of libvdpau so long as 
libvdpau is dlopened. Check how mplayer in Debian implements vdpau support 
(you'll need to check the git repo).

> > Also, nvidia-glx doesn't depend on any of the libvdpau packages so
> > installing
> > nvidia-glx won't install libvdpau.
> >
> > I'm surprised this isn't the case already for Debian.  I saw this in the
> 
> Ubuntu packages for NVIDIA, so I expected it was the same here.  Is there
> any reason *not* to do this?  At least as a Recommends.  The NVIDIA closed
> source VDPAU implementation library makes little to no sense by itself, and
> then users don't have to go through the extra step to install it if they
> want to use it.

You install libraries when you need them or when they'll provide some sort of 
functionality to some other software. libvdpau is not needed to make nvidia-
glx work. libvdpau doesn't enhance nvidia-glx either. It makes little to no 
sense having nvidia-glx depend, recommend, or suggest libvdpau.

Software that make use of libvdpau, such as mplayer, need to take care of 
adding the proper Depends, Recommends, or Suggests entry for libvdpau.

-- 
Regards,
Andres