Having taken an initial look at this...

• The docs shouldn't be referencing install.sh as that's now wrapped by universal.sh
• universal.sh would still create a new unit file, but it would also fill in the required variables (but might well overwrite any custom config)
• Since universal.sh does this by calling install.sh which copies the template in place we might be better off having a check for the existing unit file and skipping if it's there
  • and maybe an option to force a new unit file to get a clean state

@XavierChanth I'm starting to feel like the interaction between universal.sh and install.sh is getting unwieldy (and that it was never really intended for upgrading)

Looking down the road to things like EU Cyber Resilience Act (CRA) we're going to need an automated update mechanism, so we should start thinking now what we'd like that to look like.

Okay, going forward we should probably use the EnvironmentFile directive in systemd as a config file.

This will make it easier on us to just wipe the systemd file if we ever need to make changes. With a standard format for an environment file, we can append new variables to it without having to wipe any existing config.

Finding How to set environment variable in systemd service?, and after some discussion in arch call I tried:

• EnvironmentFile - this felt very much like a mechanism to deal with the old world of SysV init scripts residing in /etc/sysconfig
• override.conf - this felt much more like the systemd native way of doing things, especially as it makes use of systemctl edit

Some progress in PR101, but scope has widened so continuing into PR102