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.kehay...@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. > >
pgpXVsPsyuhTy.pgp
Description: OpenPGP digital signature
