Re: Drafting a Guix blog post on the FHS container

[Wojtek Kosior via <help-guix@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 7720 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]