Drafting a Guix blog post on the FHS container

[John Kehayias <john.kehayias@protonmail.com>]

Hi Guixers!

I've started working on a little blog post about our new --emulate-fhs option for Guix containers. In short, this sets up an FHS-like (Filesystem Hierarchy Standard) container which has things like /lib and /bin.

I would like to get some suggestions on good examples to include. More general feedback, questions, and other comments are also welcome! I've included a rough draft of the beginning of the post, leading up to showing some examples.

(I've sent this to the devel and help list as I think input from different types of users will be helpful given the feature being discussed. I'm not currently subscribed to the help list, so please cc the devel list or me directly.)

One question: what is appropriate or recommended for examples concerning things like pre-built binaries? As an example, I had tested the FHS container by running the Siril appimage, which has since been packaged for Guix (nice work!). There are ones that I don't see that happening for anytime soon, like an Electron-based app. Something like VSCodium is very popular, free (as in freedom and I believe the FSDG sense), but just not something you can package fully from source due to JavaScript as I understand it. It runs in the FHS container.

Examples I was thinking of including: using rustup (uses pre-build rust binaries) and building a package that depends on newer (nightly) rust, like eww <https://github.com/elkowar/eww> This builds and nicely is screenshot-able with pretty looking desktop widgets.

What would be useful examples? What is the right line to toe regarding binaries? I don't want to necessarily advocate for that, yet sometimes we may feel we have no other choice or want to be able to test something. I was thinking to keep it to what we do have packaged in Guix yet may want to run in a different way, or something that would fit if the language ecosystem wasn't so at odds with the Guix approach (and reproducibility more generally).

Appreciative of any and all thoughts!

John


Here is a current (rough!) draft. For the ease of plain text email I've exported from the org source to text with some light edits:


______________________________

FHS COMES TO GUIX CONTAINERS

        John Kehayias
______________________________


GNU Guix is different from most other GNU/Linux distributions and
perhaps nowhere is that more obvious than the organization of the
filesystem: Guix does not conform to the [File Hierarchy Standard]
(FHS). In practical terms, this means there is no global `/lib'
containing libraries, `/bin' containing binaries[1], and so on. This is
very much at the core of how Guix works and some of the convenient
features, like per-user installation of programs (different versions,
for instance) and a declarative system configuration where the system is
determined from a configuration file.

However, this also leads to a difference in how many pieces of software
expect their world to look like, relying on finding a library in `/lib'
or an external tool in `/bin'. When these are hard coded and not
overcome with appropriate build options, we patch code to refer to
absolute paths in the store, like
`/gnu/store/hrgqa7m498wfavq4awai3xz86ifkjxdr-grep-3.6/bin/grep', to keep
everything consistently contained within the store.

It all works great and is thanks to the hard work of everyone that has
contributed to Guix. But what if we need a more FHS-like environment for
developing, testing, or running a piece of software?

To that end, we've [recently added] a new option for Guix containers,
`--emulate-fhs' (or `-F'). This will set up an environment in the
container that follows FHS expectations, so that libraries are visible
in `/lib' in the container, as an example. Additionally, for the more
technically-minded, the [`glibc' used in this container] will read from
a global cache in `/etc/ld.so.cache' contrary to the behavior in [Guix
otherwise].

Here is a very simple example:
,----
 guix shell --container --emulate-fhs coreutils -- ls /bin
`----

[
b2sum
base32
base64
basename
basenc
cat
catchsegv
chcon
chgrp
chmod
...

Contrast that with `/bin' on a Guix system:
,----
 ls /bin -la
`----

lrwxrwxrwx  1  root  root   61  Dec  3  16:37  sh  ->  /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/sh

There are several uses that spring to mind for such a container in Guix.
For developers, or those aspiring to hack on a project, this is a
helpful tool when needing to emulate a different (non-Guix) environment.
For example, one could use this to more easily follow build instructions
meant for a general distribution, say when a Guix package is not (yet)
available or easy to write immediately. Another usage is to be able to
use tools that don't really fit into Guix's model, like ones that use
pre-built binaries. There are many reasons why this is not ideal and
Guix strives to replace or supplement such tools, but practically
speaking they can be hard to avoid entirely. The FHS container helps
bridge this gap, providing an isolated and reproducible environment as
needed.

Users not interested in development will also find the FHS container
useful. For example, there may be software that is free and conforms to
the FSDG Guix follows, yet is not feasible to be [packaged] by our
standards. JavaScript and particularly Electron applications are not yet
packaged for Guix due to the [difficulties] of a properly source-based
and bootstrapable approach in this ecosystem.


[File Hierarchy Standard]
<https://refspecs.linuxfoundation.org/fhs.shtml>

[recently added]
<https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c7ba5f38b80433b040d3946b8fc0b1e8621ba30a>

[`glibc' used in this container]
<https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3d1d29e440910a99531b738f8f090de2cd4df9da>

[Guix otherwise]
<https://guix.gnu.org/blog/2021/taming-the-stat-storm-with-a-loader-cache/>

[packaged] <https://hpc.guix.info/blog/2021/09/whats-in-a-package/>

[difficulties]
<https://dustycloud.org/blog/javascript-packaging-dystopia/>



Footnotes
_________

[1] Other than a symlink for `sh' from the `bash' package, for
compatibility reasons.