Bug#954078: vulkan-loader: consider using multiple .orig tarball to simplify packaging
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
Reply to: