Statelessness: Settle on a uapi / freedesktop "hermetic /usr" compatible statelessness story #420
Labels
Milestone
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
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.
Concrete implementation suggestion
One option we have is to keep our current
%(vendordir)macro (resolves to/usr/share/defaults) and then also add a%(factorydir)macro, that resolves to e.g./usr/share/factory/etc(TBD!), for the case where it makes more sense to use a shared,(...)/etc/foo.d/configuration drop-in layout?Another option is to consolidate completely and use
%(vendordir) = /usr/share/defaults/etc/, which would essentially displace the need for a separate%factorydirmacro. Up until a certain point, I think this was actually our previous boulder default.@ikeycode thoughts?
Context: AerynOS/recipes#597 and #419
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
distconfdirvariable next to the existingsysconfdirvariable.In openSUSE, the
distconfdirvariable 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:
prefixvariable and distro packagers then ensure that this reflects in the source code of distributed tarballs (no hardcoding of/usrfor instance) -- this is upstreamable already.distconfdirnext to the existingsysconfdirvariables 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
distconfdirconfig file in question, and then letting any config files present insysconfdiroverride these settings in a way that makes sense for code base in question.And by making the patches use the
distconfdirvariable, 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 thedistconfdirpath used by the distro.This would ideally lead to the longer term outcome where:
distconfdirpatches into their default distribution tarballsdistconfdir+sysconfdirapproachThe text was updated successfully, but these errors were encountered: