[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#656719: R: Re: [RFC] [PATCH v3 2/3] debian/control: libg3dvl-mesa: Depend on libxvmc1



>Am Montag, den 25.06.2012, 08:55 +0200 schrieb Michel Dänzer:
>> On Son, 2012-06-24 at 18:02 +0200, Paul Menzel wrote: 
>> > 
>> > This should be needed for the libxvmc1 interfaces to work. The VDPAU
>> > libraries should work without `libxvmc1`.
>> [...] 
>> > diff --git a/debian/control b/debian/control
>> > index a9fcdd3..064cd29 100644
>> > --- a/debian/control
>> > +++ b/debian/control
>> > @@ -809,6 +809,7 @@ Package: libg3dvl-mesa
>> >  Section: libs
>> >  Architecture: linux-any
>> >  Depends:
>> > + libxvmc1,
>> >   ${shlibs:Depends},
>> >   ${misc:Depends},
>> >  Description: xvmc and vdpau Gallium3D video acceleration drivers
>> 
>> Doesn't ${shlibs:Depends} contain libxvmc1 and libvdpau1?
>
>        $ LANG=C aptitude show libg3dvl-mesa
>        Package: libg3dvl-mesa                   
>        New: yes
>        State: installed
>        Automatically installed: no
>        Version: 8.0.3-2
>        Priority: optional
>        Section: libs
>        Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
>        Architecture: i386
>        Uncompressed Size: 69.5 M
>        Depends: libc6 (>= 2.3.6-6~), libdrm-nouveau1a (>= 2.4.23), libdrm2 
(>= 2.4.3), libffi5 (>= 3.0.4), libgcc1 (>= 1:4.1.1), libstdc++6 (>=
>                 4.6), libvdpau1 (>= 0.2), libx11-6 (>= 2:1.4.99.1), 
libxext6, libxfixes3, libxv1
>        Description: xvmc and vdpau Gallium3D video acceleration drivers
>         
>        Homepage: http://mesa3d.sourceforge.net/
>
>So without that change I only see `libxv1` and not `libxvmc1`. Am I
>missing something?
>
>> Which is BTW just one reason why I think separate packages for the VDPAU
>> and XvMC functionality would make more sense.
>
>Alright. I will respin this series. I welcome drafts for more elaborate
>descriptions too. ;-)
>
>Fabio, it would be great to hear your comments too.

Separating the packages may have sense, especially since the media players 
could automatically choose an API that may not properly work on a specific 
driver: with separate packages one can install only the API he wants. I however 
put all in a single package since all APIs are still experimental anyway and to 
reduce the number of packages.

Anyway I am on vacation now, I have no time to deep work on this.



Reply to: