kych

rules (7123B)

---

 #!/usr/bin/make -f
 
 # The Cargo crate lives in a subdirectory, not at the top of the source tree.
 # It has one path dependency, taler-config/, which cargo builds along with it.
 CRATE = kych_oauth2_gateway
 VENDORED = taler-config
 
 # Man pages are generated from the reStructuredText that also feeds the website
 # build in the taler-docs repository, so that there is a single source for
 # them.  documentation/sphinx-man/conf.py is a minimal Sphinx configuration
 # holding just the man_pages entries; the sources themselves use only core
 # directives, so python3-sphinx alone is enough.
 MANSRC = documentation/taler-docs/manpages
 MANCONF = documentation/sphinx-man
 MANOUT = debian/man
 
 # The SWIYU Generic Verifier: a separate upstream, maintained by the Swiss
 # Confederation and pinned to a release tag in this submodule.  The checkout
 # has to be there before the build -- "git submodule update --init" -- which
 # the build step checks for rather than producing a confusing Maven error.
 VERIFIER = swiyu-verifier/upstream
 
 # Where the jar lands, under a name that does not carry the version, so that
 # debian/swiyu-verifier.install and the systemd unit do not have to change
 # with every upstream release.
 VERIFIER_JAR = debian/jar/swiyu-verifier.jar
 
 # The jar is built for Java 25 since the verifier's 5.0.0 release, so the JDK
 # is named explicitly: a host that also has an older default JDK would
 # otherwise fail the build with a release-version error.
 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 JAVA_HOME ?= /usr/lib/jvm/java-25-openjdk-$(DEB_HOST_ARCH)
 
 # Keep Maven's repository inside the build tree, for the same reason as
 # CARGO_HOME below: the build fetches from Maven Central and must not write to
 # $HOME under Rules-Requires-Root: no.
 #
 # "clean" removes it, as it must for a package build, which means every build
 # re-downloads some 300 MB from Maven Central.  For repeated builds while
 # developing, point it at a cache outside the tree -- it is then not removed
 # either:
 #     MAVEN_REPO=$HOME/.m2/repository dpkg-buildpackage -b -uc -us
 MAVEN_REPO ?= $(CURDIR)/debian/m2
 
 # -Dpgpverify.skip=true: upstream binds the pgpverify plugin to the "validate"
 # phase, which checks the PGP signature of every dependency against
 # pgp/keys.list by querying public keyservers.  That is a worthwhile check in
 # upstream's CI, where its key cache is warm, but in a package build it makes
 # the build depend on keys.openpgp.org being reachable and is upstream's own
 # documented escape hatch (see the comment in their pom.xml).
 #
 # -DskipTests: the verifier's own test suite needs Testcontainers, hence a
 # container runtime, which a package build does not have.
 MAVEN_FLAGS = -B -DskipTests -Dpgpverify.skip=true -Dmaven.repo.local=$(MAVEN_REPO)
 
 # Keep cargo's registry and cache inside the build tree.  cargo fetches crates
 # from the network at build time (this is not an archive-policy-clean offline
 # build), and without this it would write to $HOME, which is not ours to touch
 # under Rules-Requires-Root: no.
 export CARGO_HOME = $(CURDIR)/debian/cargo
 
 # --with installsysusers: dh_installsysusers (which turns debian/kych.sysusers
 # into the /usr/lib/sysusers.d entry that creates the "kych" system user) only
 # joins the sequence automatically from debhelper compat 14 onwards.  Without
 # this the package would install but the service could not start.
 %:
 	dh $@ --no-parallel --with installsysusers
 
 # Nothing to configure: debian/kych.install names explicit paths and the build
 # only needs a cargo from $PATH (see Build-Depends).  The step is still
 # overridden so that dh does not try to auto-detect a build system in the
 # top-level directory, which holds no build files of its own.
 override_dh_auto_configure:
 
 override_dh_auto_build:
 	cargo build --release --manifest-path $(CRATE)/Cargo.toml
 	sphinx-build -b man -q -c $(MANCONF) $(MANSRC) $(MANOUT)
 # The submodule is not part of a plain "git clone" and is not in a source
 # tarball either, so say so clearly instead of letting Maven complain about a
 # missing pom.
 	@test -f $(VERIFIER)/pom.xml || { \
 	  echo "$(VERIFIER) is empty: run 'git submodule update --init'" >&2; \
 	  exit 1; \
 	}
 	@test -x $(JAVA_HOME)/bin/javac || { \
 	  echo "No JDK at $(JAVA_HOME); install openjdk-25-jdk-headless" >&2; \
 	  exit 1; \
 	}
 	cd $(VERIFIER) && JAVA_HOME=$(JAVA_HOME) mvn $(MAVEN_FLAGS) package
 	mkdir -p $(dir $(VERIFIER_JAR))
 # Exactly one jar, and not the ".jar.original" that the Spring Boot plugin
 # leaves next to it: a glob that matched both would install the wrong one.
 	cp $(VERIFIER)/verifier-application/target/swiyu-verifier-application-*.jar \
 	  $(VERIFIER_JAR)
 
 # The unit tests would run without a database, but the two integration suites
 # in $(CRATE)/tests/ need a live PostgreSQL reachable through $DATABASE_URL and
 # silently skip themselves when it is absent -- running them here would report
 # a pass without having tested anything.  Test against a database instead:
 #   DATABASE_URL=postgres:///kych_test cargo test --manifest-path $(CRATE)/Cargo.toml
 override_dh_auto_test:
 
 override_dh_auto_install:
 
 override_dh_auto_clean:
 	rm -rf $(CARGO_HOME) $(CRATE)/target $(VENDORED)/target $(MANOUT)
 	rm -rf $(dir $(VERIFIER_JAR))
 # Only the in-tree Maven repository; one the developer pointed elsewhere with
 # MAVEN_REPO is a cache of theirs and not ours to delete.
 	test "$(MAVEN_REPO)" != "$(CURDIR)/debian/m2" || rm -rf $(MAVEN_REPO)
 # Only if the submodule is actually checked out; "clean" has to work on a
 # tree where it is not.
 	@test ! -f $(VERIFIER)/pom.xml || \
 	  rm -rf $(VERIFIER)/verifier-application/target $(VERIFIER)/verifier-service/target
 
 # Both kych units ship disabled, and so does swiyu-verifier.service.  The
 # gateway cannot run before the administrator has created the database and
 # edited kych.conf (see README.Debian), and
 # kych.socket is only correct once SERVE is switched to "systemd" -- with the
 # shipped SERVE = unix the daemon binds UNIXPATH itself and an enabled socket
 # unit would fight it for the same path.  The verifier is in the same
 # position: without a DID and a signing key of its own it has nothing to
 # verify with.
 #
 # Being disabled is also what keeps a first install from starting anything,
 # which is why the flags are only --no-enable: debhelper's default
 # --restart-after-upgrade then generates a postinst that calls
 # "deb-systemd-invoke start" on a first install and "... restart" on an
 # upgrade.  deb-systemd-invoke skips a disabled unit on "start", so nothing
 # comes up on a first install, but on "restart" it does act on a disabled unit
 # that is running -- which is what makes an upgrade pick up the new binary,
 # even for a service an administrator started without enabling it.  The
 # service is not stopped during the unpack either, so the restart is the only
 # interruption.
 #
 # Do NOT add --no-stop-on-upgrade here: despite the name it also turns off the
 # restart (see its description in dh_installsystemd(1)), leaving the old
 # binary running after an upgrade.
 override_dh_installsystemd:
 	dh_installsystemd --no-enable --restart-after-upgrade