On Wed, 25 Mar 2020 at 08:41:45 +0100, Florian Weimer wrote:
> De-vendoring sources might still be an advantage because applications
> can be fixed with a bin-NMU, but it's a lot of work. The resulting
> divergence from upstream can result in additional bugs. On the other
> hand, there are projects which bundle sources only for developer
> convenience, but expect production binaries to use different library
> sources for the dependencies.
I think it's important to distinguish between those two sets of
expectations, yes. Indeed, the same is true in C/C++. We de-vendor
dependencies that are a stable library or CLI tool in their own right
("convenience copies"), but we don't de-vendor dependencies that are
designed to be vendored or that are tightly coupled to the parent package:
- flatpak's vendored bubblewrap and xdg-dbus-proxy: convenience copy,
use system copy instead
- flatpak's vendored libglnx: unstable "copylib" designed to be vendored,
keep
- ioquake3's vendored libjpeg: convenience copy, use system copy instead
(and indeed it's been excluded from the .orig tarball to make d/copyright
less onerous to maintain, since unrelated files had to be excluded for
DFSG reasons anyway)
- mutter's fork of code that used to be cogl/clutter: unstable and tightly
coupled, keep
The meson build system somewhat formalizes this with its concept of
subprojects, which can either be embedded in the upstream git repository
(by direct copying or git subtree), referenced by URL in the upstream
git repository but copied into in dist tarballs (git submodule),
or an external reference by URL (.wrap file), and can either be used
unconditionally, used only as a fallback if there is no suitable system
copy, or have a configure-time choice.
smcv
