Unfortunately, git submodules break in all sorts of ways:
- Various github workflows (dependabot, github pages) try to do a shallow
clone of git submodules which does not work at all when the git repository
is hosted on pagure (https://pagure.io/pagure/issue/5453,
https://github.com/dependabot/dependabot-core/issues/9391).
- If the git forge hosting the git repository uses SHA256, then it breaks our
usage of it as a submodule as SHA256 repositories cannot be used as submodules
in SHA1 repositories (src.opensuse.org moved to SHA256 which broke our usage of
opensuse's systemd spec as a submodule).
- git submodules completely break usage of git worktrees.
- ...
Let's avoid all these issues by just doing our own home grown implementation of
git submodules. We lose the automatic dependabot updates this way but since dependabot
fails to run more often that not with submodules we don't really lose anything.
By always cloning the latest branch commit, we can't bisect properly
using mkosi as when bisecting wildly different packaging sources will
be used compared to when the commit was merged. By using submodules, we
track individual commits which means when bisecting the same packaging
sources will be used.
We use git submodules as dependabot has support for automatically making
PRs to update git submodules. This commit also includes the necessary
dependabot configuration to enable this.
We make ubuntu/debian use the same submodule instead of adding the debian
packaging sources twice by introducing a new $PKG_SUBDIR environment variable
and using it instead of $DISTRIBUTION.
It's like CIFuzz but unlike CIFuzz it's compatible with forks and
it should make it possible to run the fuzzers to make sure that
patches backported to them are backported correctly without introducing
new bugs and regressions.
Apparently version updates aren't always disabled on old forks,
which leads to new PRs opened there. To somewhat mitigate the
issue let's limit the number of PRs Dependabot can create.
It was reported in https://github.com/yuwata/systemd/pull/2#issuecomment-967737195
