concerning libva-1.7.2-1 backport

[James Cowgill]

Hi,

On 05/09/16 15:41, Nicholas D Steeves wrote:
> On 6 August 2016 at 05:12, Sebastian Ramacher <sramacher at debian.org> wrote:
>> On 2016-08-05 16:03:39, Nicholas D Steeves wrote:
>>> Hi Sebastian,
>>>
>>> I did a fresh build of libva-1.7.1-1~bpo+1 today, and noticed that it
>>> was building against mesa-10.3.2-1+deb8u1 from Jessie.  I've been
>>> testing it on a Jessie+backported mesa-11.1.3-1~bpo8+1, and the
>>> packages I've been testing have also been built against mesa-10.3.x.
>>> Do you think it's ok to build against mesa 10.3.2, or should we bump
>>> the build deps of libva to pull in mesa from jessie-backports.  I'm in
>>> favour of bumping the deps asap.
>>
>> NACK. The mesa build dependency does not matter at all. The only intersting
>> thing is libdrm vor intel-vaapi-driver.
>>
>>> Additionally, I think it would also
>>> be wise to bump the intel-vaapi-driver build-depend on libdrm-dev to
>>> prevent it from being built against libdrm-2.4.58-2.
>>
>> This was recently bumped to match the upstream requirement. There is not other
>> bumping needed.
>>
>> Cheers
>> --
>> Sebastian Ramacher
> 
> 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

-------------- 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/e4681618/attachment-0001.sig>