Re: vkd3d

[Jens Reyer <jre.winesim@gmail.com>]

Hi Mike

thanks.

On 02.02.19 03:35, Michael Gilbert wrote:
> On Fri, Feb 1, 2019 at 11:19 AM Jens Reyer wrote:
>> My idea for a backports-versioned recommends of libvulkan1 would not
>> work anyway, because in a test that led to libvulkan1:amd64 being
>> uninstalled, instead of updating it on amd64 and installing it on i386.
>> This behavior by apt makes sense in hindsight.
> [...]
>> $ dpkg -l '*vulkan*' | grep '^ii'
>> ii  libvulkan1:amd64         1.0.39.0+dfsg1-1
>> ii  libvulkan1:i386          1.0.39.0+dfsg1-1
> 
> I'm not sure I follow.  The vkd3d updates in git still require
> libvulkan-dev (>= 1.1.70) to build, so how do you retain compatibility
> with 1.0.39?

vkd3d has no runtime dependency on libvulkan1 or any other vulkan
related packages.  So with the currently existing package relationships
you can build vkd3d with newer vulkan and then install it next to wine
with older vulkan.[1]

I assume vkd3d really works that way, and incorporates everything it
needs during build time.

Do you think it depends on (a compatible) vulkan being installed in
order to work correctly?  Wouldn't it pick up some vulkan symbols and
thus automatically have a dependency on libvulkan1 then?

In case i make vulkan-enabled wine packages I'd need to check how the
backports buildd work, but if they reuse existing environments, then I
might set a maximum libvulkan-dev version builddep in wine to ensure it
is not built in an environment with newer vulkan packages from a
previous vkd3d build.


>> No changes for the wine backport except removing the export
>> DEB_RULES_REQUIRES_ROOT from d/rules.
> 
> You could update this to be set only if ~bpo9 is not in the version
> string to eliminate this difference too.

Good idea, will do.

Greets
jre