Source: vulkan-loader Version: 1.2.131.2-1 Severity: wishlist I notice that vulkan-loader contains a vendored copy of vulkan-headers, in order to keep the library and headers in sync, with the "upstream" tarball actually being composed by repacking the combination of vulkan-loader and vulkan-headers.
Since it's a 3.0 (quilt) package already, and the vendored vulkan-headers is in the top-level directory, this seems like a perfect fit for multiple .orig tarballs: - download https://github.com/KhronosGroup/Vulkan-Loader/archive/sdk-1.2.131.2.tar.gz and rename it to vulkan-loader_1.2.131.2.orig.tar.gz - download https://github.com/KhronosGroup/Vulkan-Headers/archive/sdk-1.2.131.1.tar.gz and rename it to vulkan-loader_1.2.131.2.orig-vulkan-headers.tar.gz (note the version number mismatch - sorry, I think this is unavoidable with current tools, if your upstream doesn't always keep the version numbers in sync) - put both in ../ or wherever else you keep your upstream tarballs, or commit them to pristine-tar with gbp import-orig if you use that - import them both into your upstream-unstable git branch, perhaps with gbp import-orig --upstream-vcs-tag=... --component=vulkan-headers to keep it as a descendant of the upstream git history This would avoid needing to repack the upstream tarball, which seems likely to be problematic if more than one developer imports it independently. The yquake2 source package in contrib is an example of this technique. I use DEP-14 branch names rather than the xorg-team's conventions, but I think the difference is mostly just labelling? In particular, "component=ctf" in debian/gbp.conf and debian/watch (in your case it would be "component=vulkan-headers") activates the support for multiple .orig tarballs in gbp and uscan. I'm involved in the maintenance of a derivative (the Steam Runtime) that has an interest in having the latest Vulkan library, and it's looking like I might need to package the latest release (a development version "v...", rather than the stable "sdk-..." versions that you package). Would you be interested in receiving a merge request with that version, targeting experimental? Thanks, smcv
