#!/usr/bin/make -f
# The install layout lives in the Makefile at the top of the source tree and
# nowhere else. Nothing here lists a file: `make install WITH_GUI=0` puts down
# the base package's 25 files and `make install-gui` the GUI package's 3, and
# crates/porthole-cli/tests/install_layout.rs stages those same two calls on
# every `cargo test` and compares what they produce against a written-out list
# of paths. What lands in the .deb is that, plus dpkg's own post-processing:
# the eleven man pages gzipped by dh_compress, and usr/share/doc/ and
# usr/share/lintian/overrides/ added.
#
# That is also why there are no debian/*.install files. Splitting the two
# packages out of a single debian/tmp would mean writing the file list a
# second time here, and the Makefile already draws the same line: WITH_GUI=0
# drops exactly the GUI binary, its desktop entry and its AppStream metainfo,
# which is exactly what the porthole-gui package holds.

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

# Cargo must not write into the build user's ~/.cargo. Removed by
# override_dh_auto_clean below.
export CARGO_HOME = $(CURDIR)/debian/cargo-home

# cargo's release profile carries debug = false, which leaves the binaries
# with a symbol table and no DWARF -- and dh_strip then builds -dbgsym
# packages holding a .debug file with no debug information in it. debug = 1
# (line tables) makes those packages worth the space they take; dh_strip
# moves it all out of the shipped binaries either way.
export CARGO_PROFILE_RELEASE_DEBUG = 1

# Native builds only. porthole-gui links GTK4 through gtk4-sys, and nothing
# here sets up a cross toolchain or a cross pkg-config; a cross build would
# need both.
WITH_GUI := 1
ifneq (,$(filter pkg.porthole.nogui,$(DEB_BUILD_PROFILES)))
WITH_GUI := 0
endif

%:
	dh $@

# A Makefile at the top of the tree makes dh pick its makefile build system,
# whose dh_auto_configure would run ./configure if one existed. There is none.
override_dh_auto_configure:

# The Makefile's own targets rather than the `cargo build --release --locked`
# they expand to: the same one place the install layout lives, so a change to
# how this tree is built happens once. `build` is the workspace's
# default-members -- the CLI, the helper and the agent -- and, through
# crates/porthole-cli/build.rs, the eleven man pages and the three completion
# files that `make install` then installs. porthole-gui is not a
# default-member, so `build-gui` is separate.
override_dh_auto_build:
	$(MAKE) build
ifeq ($(WITH_GUI),1)
	$(MAKE) build-gui
endif

# No test run here, and the reason is not that the suite is slow. Both
# reasons written here until 2026-09-10 have stopped being true, so both are
# replaced rather than edited.
#
# It is no longer the system bus. The reason used to be that
# doctor_says_the_helper_is_missing_when_it_is wanted the Helper check to
# report a missing helper and a chroot's missing *bus* made it report
# something else. crates/porthole-cli/tests/cli.rs starts a private
# dbus-run-session for the test binary and hands every porthole process it
# launches DBUS_SYSTEM_BUS_ADDRESS pointing at it. Measured on 2026-09-10
# with that variable pointing at /nonexistent/bus and DBUS_SESSION_BUS_ADDRESS
# unset -- a machine with no reachable bus of either kind -- `cargo test -p
# porthole-cli --test cli doctor`: 4 passed, 0 failed.
#
# It is no longer --release either. PORTHOLE_STATE_FILE,
# PORTHOLE_DEVICES_FILE and the helper's --session are still honoured only
# where cfg!(debug_assertions) holds, deliberately: a release binary runs
# privileged and must not take those paths from its environment. What
# changed is that the tests depending on them now carry
# #[cfg_attr(not(debug_assertions), ignore = ...)], so a release run reports
# them as ignored, by name, with the reason. Twelve in cli.rs, four in
# helper_e2e.rs, and in cli.rs two assert-at-setup guards make forgetting the
# attribute a red test rather than a write into the invoking user's own
# ~/.config/porthole/devices.toml, which is what it had already been twice.
# Measured: `cargo test --release -p porthole-cli --test cli`
# -> 37 passed, 0 failed, 12 ignored.
#
# What does stand in the way is a build-dependency that debian/control does
# not declare. The requirement moved from "a system bus exists" to
# "dbus-run-session is on PATH", which cli.rs asserts rather than skipping,
# and busctl, which helper_e2e.rs waits with.
# packaging/rpm/porthole.spec:84-86 declares both as BuildRequires;
# debian/control declares neither. Declaring them is the first step to adding
# a run here, not the whole of it: nothing has been measured in a build
# chroot since these two reasons stopped applying.
#
# The suite runs on a developer machine and in CI.
override_dh_auto_test:

# PREFIX=/usr, not the Makefile's own default being taken on trust:
# data/com.jacopobriccola.Porthole.service and data/porthole-helper.service
# both name /usr/libexec/porthole-helper literally, and the Makefile stops
# while it is being read -- before installing anything -- when LIBEXECDIR and
# those two files disagree.
#
# ZSHCOMPDIR is the one directory Debian places differently from the
# Makefile's default: vendor-completions is where a package that is not zsh
# itself puts a completion, and the Makefile provides the override for this.
# Both directories are on the default fpath, so this is convention rather
# than function.
ZSHCOMPDIR := /usr/share/zsh/vendor-completions

override_dh_auto_install:
	$(MAKE) install DESTDIR=$(CURDIR)/debian/porthole PREFIX=/usr WITH_GUI=0 \
	  ZSHCOMPDIR=$(ZSHCOMPDIR)
ifeq ($(WITH_GUI),1)
	$(MAKE) install-gui DESTDIR=$(CURDIR)/debian/porthole-gui PREFIX=/usr
endif

override_dh_auto_clean:
	rm -rf $(CURDIR)/debian/cargo-home
	rm -rf target/generated target/install-check

# porthole-helper.service is Type=dbus with no [Install] section, reached
# through /usr/share/dbus-1/system-services/com.jacopobriccola.Porthole.service.
# There is nothing for `systemctl enable` to link and nothing to start at
# install time: the bus starts it when a client first addresses the name. So
# --no-enable --no-start.
#
# --restart-after-upgrade is not the opposite of --no-start, and the two
# together are not a contradiction. dh_installsystemd branches on both
# (debhelper 13.24.2, /usr/bin/dh_installsystemd, read rather than inferred):
# with NO_START and RESTART_AFTER_UPGRADE both set it emits the
# postinst-systemd-restartnostart autoscript with RESTART_ACTION=try-restart,
# which is guarded by `if [ -n "$2" ]` -- dpkg passes the old version there
# only on an upgrade. So a fresh install still starts nothing, and an upgrade
# runs `systemctl --system daemon-reload` and then
# `deb-systemd-invoke try-restart porthole-helper.service` after the new files
# are in place. try-restart and not restart: a machine whose helper was not
# running must not acquire a root daemon as a side effect of a version bump.
#
# Setting it explicitly is what it takes, because --no-start alone leaves it
# off: dh_installsystemd defaults RESTART_AFTER_UPGRADE to 1 only when
# NO_START is empty. What --no-start alone produced instead was a preinst
# holding `deb-systemd-invoke stop porthole-helper.service` -- emitted
# `unless ($dh{R_FLAG} || $dh{RESTART_AFTER_UPGRADE})`, so setting
# --restart-after-upgrade is also what removes it -- and no postinst snippet
# at all. That stop already kept the previous version's root daemon from
# serving the new version's clients, which is the failure that matters:
# porthole's D-Bus wire format has already changed incompatibly once (three
# members added to WireRule moved RuleClosed from ((sqssssttu)s) to
# ((sqssssttusqq)s)), and zbus drops a signal whose signature does not match
# rather than raising anything -- a stale component goes quiet, it does not
# fail.
#
# What the move to try-restart buys is the window after that: stop left the
# helper down until the next client call, and the helper's network-change
# monitor runs inside the helper process, so a subnet change in that window
# went unnoticed. (An opened rule's automatic close does not share the gap:
# it is a transient systemd timer outside the process.) try-restart brings
# the helper back on the new binary at the end of the upgrade instead, and
# leaves the state file behind it -- RuntimeDirectoryPreserve=yes in
# data/porthole-helper.service is what keeps /run/porthole across the
# restart. packaging/rpm/porthole.spec's %systemd_postun_with_restart and
# packaging/aur/porthole.install's post_upgrade are the same decision on the
# other two distributions, each spelled in its own terms -- that RPM macro on
# current systemd-rpm-macros runs no restart itself, it marks the unit
# `needs-restart` for systemd's own rpm trigger to act on at the end of the
# transaction.
#
# --no-start also suppresses the stop-on-remove dh_installsystemd would
# otherwise put in prerm -- it emits that one `unless NO_START`. That stop is
# in debian/porthole.prerm instead; see the comment there.
#
# -pporthole because the unit is only in that package; without it
# dh_installsystemd stops on porthole-gui, which installs no units at all.
override_dh_installsystemd:
	dh_installsystemd -pporthole --no-enable --no-start --restart-after-upgrade \
	  porthole-helper.service

# porthole-agent.service is the other decision, and it is a different one:
# WantedBy=graphical-session.target, Restart=on-failure, enabled globally so a
# graphical login starts it. porthole also installs an XDG autostart entry for
# desktops that do not start session services through systemd; a desktop that
# honours both starts two agents and the second exits on finding the bus name
# taken.
#
# dh_installsystemduser generates enable and disable snippets only -- it has
# no --no-start, because it starts nothing: unpacking runs as root, where
# there is no user session to start a user unit in. The next graphical login
# starts it.
override_dh_installsystemduser:
	dh_installsystemduser -pporthole porthole-agent.service
