Re: Drafting a Guix blog post on the FHS container

[Wojtek Kosior]

Hello,


> 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.

Hi,

One recent real-life example of `--emulate-fhs` being useful is with
Python's virtualenv. I mentioned it in one help-guix thread which
you can see here[1] :)

Wojtek

[1] https://lists.gnu.org/archive/html/help-guix/2022-11/msg00305.html

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #11: saint Jacek Odrowąż
Poznaj świętych krakowskich!  #11: święty Jacek Odrowąż
https://pl.wikipedia.org/wiki/Jacek_Odrowąż
-- (sig_end)


On Mon, 05 Dec 2022 02:32:40 +0000
John Kehayias <john.kehayias@protonmail.com> wrote:

> 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.
> 
>

pgpFSjB2lOCUT.pgp
Description: OpenPGP digital signature