Use released submodules instead random git snapshots about fossilize

[kakra]

I think the reason behind this is unbundling the dependencies into separate packages how distributions should do it. That way, common dependencies could be shared and won't run into issues with conflicting files between packages.

[HansKristian-Work]

The submodules in question to not necessarily have release versions.

[Joshua-Ashton]

Why is this a problem for Debian anyway? You can just clone with --recursive and it should just work.

[Joshua-Ashton]

Fossilize shouldn't depend on or touch the system headers at all so this is a non-issue.

[daissi]

I think the reason behind this is unbundling the dependencies into separate packages how distributions should do it. That way, common dependencies could be shared and won't run into issues with conflicting files between packages.

Yes, exactly! I am just adding the link to the Debian's explanation https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code

Fossilize shouldn't depend on or touch the system headers at all so this is a non-issue.

I am not sure to understand why Fossilize shouldn't depend on the system headers. Could you explain?

[Joshua-Ashton]

Debian does not typically offer the latest packages:

• In the instance of the Vulkan headers (the libvulkan-dev package), the latest available in stable is 1.1.97 which is absolutely ancient and in unstable is 1.2.162 which is also ancient.

• For the SPIR-V headers, the latest is 1.5.4 in unstable which is from November 2020.

• I'd imagine we also don't want to depend solely on tagged releases of the SPIR-V headers, etc either as Fossilize is a bit of a moving target.

It would make Fossilize essentially worthless if it was limited to these ancient versions that Debian has decided to ship as apps/game will be using much newer Vulkan versions than what Fossilize is exposing.

That also goes for any Vulkan layers or tools you guys are shipping as packages.

[sjoerdsimons]

What debian does or doesn't ship at the moment isn't that relevant ; Especially as we're in freeze going toward the next release
some things are frozen at release that were available around the start of this year. Overall making sure the base dependencies are available is Debians problem.

The key of the question here is whether fossilize would be happy to focus on released versions of its dependency (potentially system installed) or if it's aiming to follow those too closely for that, which you quite nicely answered thanks!

Generally if fossilize is a quickly-moving target at the moment it's likely not worth including it in distrubutions yet

[Joshua-Ashton]

It does matter, it illustrates the point of why it would be completely useless to have a Fossilize package with dependencies frozen at random versions picked by package maintainers like this going forward.

Fossilize will always be a moving target -- the entire point of it is (essentially) pipeline/shader caching for games, games that will be a moving Vulkan target much newer than whatever Debian is going to offer at any given time in their vulkan-dev packages.

It's not just a matter of keeping libvulkan-dev up to date in sync with your shipped mesa either -- there are plenty of Debian users using custom PPAs or [1] building mesa from git or NVIDIA proprietary users where artificially limiting what Vulkan version Fossilize can target would essentially make it worthless for them.

I guess I also don't fully understand the purpose of an end-user fossilize package in Debian either...
Steam ships its own version of the layer/tools as it also handles distribution and replaying caches etc. Debian doesn't do any of that.
I guess you could record and replay locally but that's not that useful in-of itself for users aside from debugging -- and anyone debugging is going to be building their own Mesa/drivers anyway[1].