On Wed, Jul 31, 2019 at 04:22:35PM +0100, Ian Jackson wrote:
> Submodules are intensely frustrating[1]. One way they are frustrating is
> that it is not clear even what it means for a .dsc to be identical to
> a git tree which has submodule references. Are the submodules
> supposed to be populated ? My inclination is to say the answer is
> "yes", but your own practice here seems to be "no" ?
Well, from the perspective of the upstream author (in this case
dwarves-dfsg), I think what's going on is they want to reuse code, but
young'un's these days don't understand how to maintain API stability
(never mind the ABI compatibility required for shared libraries).
So what they do is to say, "ok, I'm going to use *this* version of
lib/bpf" for vN of libdwarves, and at some point, for vN+x of
libwarves, "I'll do a "git pull" of lib/bpf, discover that functions
have changed arguments for various functions, so I'll have to fix up
my source code to deal with this new version of lib/bpf."
Because API stability is too hard(tm), they can't depend on having a
particular version of libbpf.a installed in a distribution library.
So instead, particular versions of lib/bpf are associated with
particular version of dwarves, and a "git pull" of the top-level
dwarves-dfsg git repository will also update the lib/bpf version of
the submodule to the version tied to that version of the top-level git
repo.
>From the perspective of the source tarball, they distribute the source
files for lib/bpf in dwarves-dfsg's source tar.xz file. And they
static link lib/bpf in the binaries in the distro package, so the fact
that modern open source programs have no idea how to achieve API or
ABI stability, it all works. Mostly.
So yeah, it's frustrating, and it means that we're shipping 576k of
lib/bpf with dwarves-dfsg, and if there is some other source package
that also uses lib/bpf, they will also ship their own version. It
also means that if there is a security bug fix needed for lib/bpf,
each user will have to update to the fixed version of lib/bpf, fix any
API breakage, and then do a new source and binary release.
The problem is, if we want to build upstream kernels with compressed
type information for BPF, we need to use dwarves-dfsg. And the fact
that it has the bad taste to use a completely unstable lib/bpf is what
it is. But if dgit is supposed to be able to support *all* packages,
even packages like lib/bpf and their users, such as dwarves-dfsg, then
it's going to have to figure out how to deal with this.
And git created submodules to be able to support this workflow; so if
dgit is going to be a universal system, it needs to deal with packages
that have decided to use this particular mechanism of code reuse. :-/
> [1] I think they are nearly always the wrong answer. Usually they are
> the worst answer. Even (especially) to the situation they were
> specifically intended to address. They are simply too broken. Of
> course this is of no help to you as a downstream if your upstream has
> drunk the poison kool-aid.
Exactly.
Compare and constrast this with e2fsprogs, where I've maintained ABI
compatibility for over a decade.... Discipline! The young'uns don't
understand Discpline! And they should also get off my d*mned lawn. :-)
- Ted
