Github autogenerated tar releases cannot be disabled upstream and do not include submodules. The upstream recommendation[1] is to always use git with submodules in order to have a complete build. Without submodules features such as mixer FTL support are missing. In the future if browser source is desired it is also a submodule. 1: https://github.com/obsproject/obs-studio/wiki/Install-Instructions#linux-build-directions
Upstream recommendations are one thing. GitHub submodules however most of the time imply bundled dependencies, and we despise bundled dependencies and only use them if not at all otherwise possible.
Packagers are of course free to de-vendor whatever they want. Though im not sure if the mixer SDK even supports this. Nor will obs-browser. But its important that packagers do not mistake the github tar ball as the intended release.
Yes, if available, and unfortunately that is less and less the case with GitHub based upstreams, the proper release tarball should be used.
(In reply to kkartaltepe from comment #0) > The upstream recommendation[1] is to always use git with > submodules in order to have a complete build. Well, that is not an option for distribution packaging. It is unfortunate that upstream is too lazy to create proper release tarballs themselves. One way *could* be to workaround that by adding submodule tarballs separately to SRC_URI for those that are relevant.
I've definitely kept them submodules in mind, to have them handled as needed, but so far I've not seen any related to Linux use. That said, I had not bumped into FTL before (in the OBS Studio sense), and no one had requested support for it to be added. As mentioned, for actual release packaging, using git tags isn't really feasible, unless we were to do snapshots only, but I don't see the point in that since the sources are available as plain downloads as well (even if incomplete in a sense). I will look into packaging FTL soon (and the browser source, once it's ready), probably via the GitHub releases of its repository unless there is a very good reason to not do that.
> unless there is a very good reason to not do that. If i remember correctly it was submoduled because the sdk was happy to break source compatibility more or less every version. But it hasnt been touched for two years since Microsoft acquired them. So this might not be too much of a worry on packagers.