Hi,
I wanted an example piece of software for a tutorial on packaging
upstream software from git for binary .debs, and figured GNU Hello would
be a good choice. I'm afraid the experience of building from a git tag
(i.e. clone the repo, check out the tag of the release you want to
build, build) is quite hostile; I found three key problems:
1) bootstrap installs git hooks that reject commit messages
I appreciate that for patches sent upstream you have coding standards,
but the commit-message hook is confusing for newcomers, and particularly
interacts badly with e.g. emacs' git mode (if you commit a message from
within emacs that the hook doesn't like your emacs spins indefinitely;
and then recovery is hard because the hook will look for the editor
configured in git, so even if you do EDITOR=nano git commit to try and
un-wedge things, it still tries to launch emacsclient if the commit
message wasn't right.
2) gnulib is used as a git submodule
This adds unnecessary complexity to the build process, and requires
special handling in CI too. Further, it's not necessary to use gnulib
thus (e.g. man-db doesn't use it as a submodule), and submodules aren't
really best practice (cf https://diziet.dreamwidth.org/14666.html which
expounds on their limitations at length)
3) tests erroneously fail inside CI
I've made no modifications to gnulib, but my CI (inside gitlab, using
GIT_SUBMODULE_STRATEGY: recursive ) fails because the test code thinks
I've modified something in the submodule - the failing code is:
git submodule --quiet foreach \
'test "$(git rev-parse "$sha1")" \
= "$(git merge-base origin "$sha1")"' \
|| { echo 'maint.mk: found non-public submodule commit' >&2; \
exit 1; };
You can see a full build log here (error at the bottom):
https://gitlab.wikimedia.org/repos/data_persistence/matthewvernon-demo-hello/-/jobs/150946
It's hard to make headway on fixing that because the actual outputs from
git rev-parse and git merge-base aren't emitted, and maint.mk is inside
the submodule (which I can't edit without falling foul of that check for
real).
Likewise, I can get my package to build by skipping the tests, but
that's not really ideal for a tutorial showing how things should be done :)
Sorry to be picky about build systems, but GNU Hello does describe
itself as an example of best development practice, and I think given
that it ought to be more straightforward to build it from a git checkout.
Thanks for your consideration,
Matthew
