Hi everyone! Upstream gamescope[1] have several embedded copies which current packaging changes for system libraries (except reshade patch[2]). But after looking at upstream git commits I believe upstream fully intends to use these dependencies in an embedded way. I am gonna list them with upstream intentions: 1. wlroots, libliftoff, vkroots They added check[3] to discourage use of system libraries for these dependencies. And the commit message states: > Packagers have been overriding our `force_fallback_for` definition, and > replacing our > submodules with their system libraries. > Gamescope regularly takes untagged work, and sometimes has its own > forks/branches of > projects with fixes and features that we need. > We also don't religiously follow wlroots versioning, which does not have a > stable ABI, > which is problematic when people want to mix and match. > Seriously, you should not change this! It is there for a reason, and I am > also tired > of debugging random issues reported across a myriad of distros with differing > random > patches because of this.
Also: wlroots - they are using the 0.18 version with backported optimization from 0.19. And if they don't intend to upgrade in near future gamescope could block wlroots transition in debian. vkroots - maintainer of vkroots does not guarantee any compatibility between versions[4]. For now it's fine but if in the future packageA needs vkroots commit from 2024 and packageB needs the latest commit this will definitely be problematic. 2. reshade I didn't find any upstream comments, but they are using a fork with small changes and don't update it regularly. So if we were to package it, it shouldn't be named reshade, so it doesn't interfere with possible reshade package from the original upstream. And this forked reshade would be only used by gamescope 3. stb They locked stb version in 2023[5] and recently forced it to always use embedded version[6] (which we patched to use dependency instead) 4. glm It was first introduced in 2023[7] and updated to 1.0.1 recently[8]. We don't have 1.0.1 in Debian yet, but gamescope builds and works fine (in my testing) for now. Also it was forced to be embedded just like stb[6] Debian policy[9] states: > Debian packages should not make use of these convenience copies unless the > included package is explicitly intended to be used in this way. I believe that upstream makes it very clear that it's their intention. And embedding these dependencies would be beneficial for users (more stable package) and relationship with upstream (less bug reports to upstream because of forced usage of system libraries). What do you think about it? And if you think it's a good idea I would appreciate some directions on what is the best way to embed git submodules and meson subprojects in the source package. Cheers Ilya [1]: https://github.com/ValveSoftware/gamescope [2]: https://salsa.debian.org/games-team/gamescope/-/blob/debian/3.16.14-1/debian/patches/0006_use_system_wlroots-0.18-headers.patch [3]: https://github.com/ValveSoftware/gamescope/commit/7741cd587fa2274989f3307a3c6f23ab08e98460 [4]: https://github.com/misyltoad/vkroots/issues/4#issuecomment-1453841820 [5]: https://github.com/ValveSoftware/gamescope/commit/bc503b32060e7fa0ad11b7fd70fac2614241af9b [6]: https://github.com/ValveSoftware/gamescope/commit/baae74c4b13676fa76a8b200f21ac78f55079734 [7]: https://github.com/ValveSoftware/gamescope/commit/5ce316fa5723a8a1419217cb1340e4a3a41c0394 [8]: https://github.com/ValveSoftware/gamescope/commit/0fed8f3d69203c5bea20c73eb526574260f4ebd7 [9]: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
