[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Drafting a Guix blog post on the FHS container
Re: Drafting a Guix blog post on the FHS container
Mon, 5 Dec 2022 07:51:38 +0100
> 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.
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 :)
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ąż
On Mon, 05 Dec 2022 02:32:40 +0000
John Kehayias <firstname.lastname@example.org> 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
> 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
> 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!
> 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, 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
> Here is a very simple example:
> guix shell --container --emulate-fhs coreutils -- ls /bin
> Contrast that with `/bin' on a Guix system:
> ls /bin -la
> lrwxrwxrwx 1 root root 61 Dec 3 16:37 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
> 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
> packaged for Guix due to the [difficulties] of a properly source-based
> and bootstrapable approach in this ecosystem.
> [File Hierarchy Standard]
> [recently added]
> [`glibc' used in this container]
> [Guix otherwise]
> [packaged] <https://hpc.guix.info/blog/2021/09/whats-in-a-package/>
>  Other than a symlink for `sh' from the `bash' package, for
> compatibility reasons.
Description: OpenPGP digital signature