On Fri, 03 Sep 2021 at 02:46:20 +0200, Jonas Smedegaard wrote: > I suspect that it helps if separating reasons for _encouraging_ > embedding (tiny upstream projects and deeply integrated sets of > upstreams, I guess) from reasons for _discouraging_ embdding (all other > cases, I guess).
If the embedded project is specifically not maintained as API- or ABI-stable, then I think that's also a common and valid reason to embed it, perhaps even more so than the ones you mentioned here. This can mean library APIs, but also command-line options, output behaviour or some other machine interface that the embedding project might require. (Or perhaps you intended "deeply integrated" to cover this, but I think it's worth being explicit about the API stability factor.) I'm mainly thinking here of "copylibs" like gnulib, libiberty, libglnx, stb. If an upstream tells us their code will break API/ABI without notice, then I think we should believe them - which means the only long-term-maintainable way to depend on it is for the projects that need it to vendor a known-compatible copy, and be responsible for updating that copy and the code that calls it at the same time if a serious bug is found. This is not new - gnulib and libiberty have been like this for decades, and vendoring those is not really the same thing as vendoring the likes of zlib or libjpeg. I know we do have a libstb package that builds a shared library, but the existence of a stb build system (let alone a shared library build system) is a Debian-specific patch, which does not fill me with confidence that it has the necessary API- and ABI-stability to be correct as a shared library. Outside the scope of libraries, a few packages in GNOME are currently using gi-docgen (a gtk-doc-like API documentation generator) as a vendored project, because it is intended to have a stable interface in future but has not got there yet. There's a gi-docgen package in NEW, but it will stay in experimental and will not be used in build-dependencies until it has stabilized enough to be valid to use that way. Of course, if an upstream decides that their project *is* ready to be a sufficiently-stable separate project, then we should usually prefer to package it separately (for example, bubblewrap and xdg-dbus-proxy are vendored into flatpak, and the vendored copies were used in Debian early in its lifetime, but both are now stable enough and independent enough that we have moved to system copies). smcv