Statelessness: Settle on a uapi / freedesktop "hermetic /usr" compatible statelessness story

[ermo]

Historical context

For context, Ikey has been in the statelessness game at least since the days when he worked on Clear Linux at intel's OSTC.

This definition of statelessness, via Ikey, made its way into Solus, where the de facto standard was to have per-package stateless configuration saved to /usr/share/defaults/<packagename>.

Current state of statelessness

Per the uapi-group configuration files specification and the freedesktop file-hierarchy specification, we may want to consider building a "hermetic /usr" story which is as compatible as we can make it with Ikey's preferred Clear Linux-derived statelessness approach.

Goals and non-goals

The longer term goal is to avoid getting into a situation where our definition of statelessness clashes with the upstream "hermetic /usr" approach, to the point where upstreams refuse to accept patches related to our definition of statelessness, thus forcing us to maintain an unbounded number of downstream patches that have no upstream relevance.

Instead, we may want to make it so that we have a well understood and agreed upon way to integrate upstream "hermetic /usr" compatible packages in our recipes, to the point where we can reliably get statelessness patches accepted upstream, whilst seamlessly benefiting from them in our package recipe maintenance story as a downstream distribution.

Upstream and distro collaboration options

Taking the above one step further, one option that was informally discussed with the nice FHS people on matrix (people from openSUSE and Fedora were present at the time), is to attempt to patch build systems to provide a distconfdir variable next to the existing sysconfdir variable.

In openSUSE, the distconfdir variable apparently already refers to their hermetic-/usr config directory, /usr/etc, hence re-using this variable name would be the path of least resistance for openSUSE.

The idea here is the following:

• Build systems use the prefix variable and distro packagers then ensure that this reflects in the source code of distributed tarballs (no hardcoding of /usr for instance) -- this is upstreamable already.
• Build systems gain the distconfdir variable next to the existing sysconfdir variables via a patchset that can be adopted by distros and then proposed for upstreaming once consensus is reached.

The outcome of this is that distros using the build system patches can now patch packages to support the hermetic-/usr approach of first checking the distconfdir config file in question, and then letting any config files present in sysconfdir override these settings in a way that makes sense for code base in question.

And by making the patches use the distconfdir variable, the hermetic-/usr patches can now be adopted verbatim by other distros, where the only thing that is change is the config-time setting of the distconfdir path used by the distro.

This would ideally lead to the longer term outcome where:

• All build systems eventually accept the distconfdir patches into their default distribution tarballs
• All software vendors accept patches that enable them to take advantage of the hermetic-/usr distconfdir + sysconfdir approach
• All distributions contribute towards the same hermetic-/usr goal, whilst being able to use each others' patches until they become properly upstreamed

Concrete AerynOS implementation suggestion

Currently, we use the old Clear Linux %(vendordir) = /usr/share/defaults definition macro. Up until a certain point, this was previously %(vendordir) = /usr/share/defaults/etc.

To align more closely with the proposal above, we could ditch the %vendordir macro completely and consolidate by using the %(distconfdir) = /usr/config/ macro definition.

Context: AerynOS/recipes#597 and #419