Bug#954078: vulkan-loader: consider using multiple .orig tarball to simplify packaging
On 16.3.2020 14.41, Simon McVittie wrote:
> 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.
Hmm, well it seems that using multiple tarballs involves more steps than
the current one, if the tags can get out-of-sync as they are now.. so
right now I'd rather keep the current method.
> 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?
sdk-* tags are needed in order to get the full stack to build, v.. tags
don't guarantee that they all fit together. So in that sense, having
only the loader and maybe tools (and not validationlayers) in
experimental, tracking v.. tags is fine by me. But I'd rather have you
then handle those all the way ;)
--
t
Reply to: