concerning libva-1.7.2-1 backport

[James Cowgill]

Hi,

On 05/09/16 16:39, Nicholas Steeves wrote:
> On 5 September 2016 at 11:03, James Cowgill <jcowgill at debian.org> wrote:
>> On 05/09/16 15:41, Nicholas D Steeves wrote:
>>> Hi Sebastian,
>>>
>>> When backporting libva-1.7.2-1 today, it builds against and depends on
>>> libdrm-2.4.58-2 instead of 2.4.70-1~bpo8+1.  Intel-vaapi-driver
>>> correctly builds and depends on libdrm-2.4.70-1~bpo8+1.  Is it really
>>> ok?  Shouldn't the two build against and require the same libdrm
>>> version? eg, intel-vaapi-driver/debian/control: libdrm-dev (>= 2.4.60)
>>
>> libdrm 2.4.70 gets pulled in when intel-vaapi-driver is built because
>> intel-vaapi-driver depends on intel-gpu-tools from backports, which in
>> turn depends on a newer libdrm.
>>
>> I think I said this to you before: this is not a problem because the
>> versions of libdrm at runtime will always be the same everywhere and
>> intel-vaapi-driver does not seem to do anything different (as far as I'm
>> aware) if built against a more recent version of libdrm.
>>
>> James
>>
> 
> Hi James,
> 
> I understand how the intel-vaapi-driver dependencies work, and which packages end up installed at runtime.  My concern is specifically:
> 
> A.
> 1. build libva (built with old_libdrm)
> 2. build intel-vaapi-driver (built with new_libdrm and with (libva built with old_libdrm))
> 3. install intel-vaapi-driver (install new_libdrm and (libva built with old_libdrm))
> 
> vs
> 
> B.
> 1. build libva (built with with newdrm)
> 2. build intel-vaapi-driver (built with new_libdrm and with (libva built with new_libdrm))
> 3. install intel-vaapi-driver (install new_libdrm and (libva built with new_libdrm))
> 
> Are (A) and (B) really equivalent?  I understand that the installed package versions are the same, but
A2 != B2 makes me think that they're not equivalent.  That's what I'm
wondering :-)

From your breakdown, A and B are equivalent iff:
 libva built with old_libdrm
  and
 libva built with new_libdrm
are equivalent.

I believe this is true on the basis that libav doesn't do anything
special if built against a newer libdrm. The final libav binaries should
pretty much be identical.

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160905/f99c896a/attachment.sig>