As for stateless, in my understanding it’s basically saying to separate configs from packages. This complies to Filesystem Hierarchy Standard.
There’re mainly three locations we should install custom packages, /usr/local, /opt, and ~/.local.
Except explicitly recommended by package developer, in your case you just need to decide whether to use /usr/local or /opt.
Normally if you build a package from source, the default install prefix is /usr/local, which has same/similar subdirectory structure as /usr.
As for /opt, I’ve only see several cases where the package is by default installed there. One is the driver for my printer, and another is a runtime requirement for Rstudio. Things installed there are located in their own sub-directory named after the package name. Say if you want to build something that won’t be touched by package management softwares even when there’s a new version, /opt is a good place. (This is why Rstudio have an external module installed there, it’s never modified so it guarantees Rstudio works).
Correspondingly the configurations should be located in /etc, /etc/opt for /usr/local and /opt.
The rationale is, binaries, libraries, manpages and other stuff under /usr are sharable between system. So theoretically you can clone them into another system and they should work.
On the other hand, (system-wide) configurations are host specific, and not sharable, so you should separate them from the sharable ones.
Well in practice it’s quite the opposite.
The stateless concept conforms to the FHS.
Default configurations ensures basic functionality without any host specific settings, and are located under /usr/share/sub-directory or /use/share/defaults/sub-directory. They are sharable.
Host specific configurations stay in /etc or /etc/opt. And per-user configurations are in home directory. None of them is sharable.
Normally even without stateless, many applications looks for configurations in the following order:
- Command line options will override anything specified in any configurations
- Per-user configurations overrides system-wide configurations
- System-wide configurations
The stateless just added another layer, that if a configuration is required but not found, the application uses the default stateless configuration under /usr/share.
If you build something that’s also included in a bundle, then a configuration in /etc would effective for both your custom built package and the one shipped with swupd. And indeed, that has higher priority comparing to stateless default configurations. But it doesn’t break stateless because the configurations are still separated from executables and etc.
To avoid this, you may specify a different sysconfdir when building the package, for example, /etc/local.
If you build something not included in any bundle, configurations in /etc shall work as normal.
In either case, you custom built packages shall not read stateless configurations unless you explicitly required that when building them.