I know that a lot of what Nix does is working around its break from FHS, but I can imagine there are still things that seep through. Are there any unsolvable problems due to this?

I saw on this post that it is possible to use FHS on Nix. Does this solve all potential issues then?

    • MadMaurice@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      11 months ago

      Nix installs derivations into separate folders. A derivation can be a package, but can also be other things like configuration files, scripts or sources for packages. Nix doesn’t distinguish between these derivations by a name but rather by a hash created from their build instructions.

      For example two instances of the same package with a different version are two different derivations and thus nix can have both package versions installed without them interfering with each other. But this goes beyond just a package version. It is e.g. possible to have the same package with the same version but different patches applied, or relying on different versions of dependencies. Since their build instructions differ both can be installed simultaneously.

      This approach grants a variety of advantages. For example upgrading your NixOS system just installs new derivations of packages and configuration files that have changed, while keeping previous derivations until they’re garbage collected at a later time. This allows you to switch freely between both iterations of your system, for example if an update causes issues you can just revert back to before an update easily. Another advantage is that an unprivileged user can install packages they need without interfering with the rest of the system, for example an older python version or a newer one, or some software they want but the system does not provide.

      The price of having this kind of isolation between packages is that nixos cannot install binaries and libraries into common locations. Effectively /usr/bin only contains the env binary. If you’re familiar with shell scripting you might have run into lines such as #!/usr/bin/env bash. This env util will essentially search bash in your PATH variable and start it. Lines like #!/bin/bash however will not work, because there’s no bash installed in that location.

      Another case where a missing fhs is a problem is when using pre-compiled binaries. In contrast to binaries built through nix, which have their required libraries hardcoded as absolute paths, pre-compiled binaries you download usually only contain the name of the library they need, which works in a conventional fhs environment, because these libraries tend to be found in /libor /usr/lib. On NixOS neither of those are present. There two solutions to this. Either you create an fhs environment by listing the set of derivations to be symlinked into a chroot environment which mimics an FHS. Or you can install https://github.com/Mic92/nix-ld which automatically finds the required libraries the nix way if you start such a binary. There’s also steam-run which installs an fhs with most of the dependencies necessary to start Linux games from Steam.

  • chaorace@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 months ago

    You may be interested in reading this post about the process of packaging Steam.

    tl;dr: It’s mostly an annoyance reserved for packagers to deal with. Dynamically linked executables can be patched in a fairly universal fashion to work without FHS, so that’s the go-to approach. If the executable is statically linked, the package may have to ship a source patch instead. If the executable is statically linked & close-source, the packagers are forced to resort to simulating an FHS environment via chroot.

    • matcha_addict@lemy.lolOP
      link
      fedilink
      arrow-up
      0
      ·
      11 months ago

      So that means packaging software for nix is a pain, compared to, say, gentoo or arch’s AUR, but only for a small subset of packages.

      I’ll keep this in mind as I’m exploring if I should switch from Gentoo.

      • hackeryarn@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        11 months ago

        I would say it’s actually easier in many cases. Nix has really fantastic packaging tooling. You do have to learn a bit of the nix language, however (not become an expert).

        The issue comes when trying to build from source. In most other distros, ou just follow the readme. In nix, you have to package it.

        • matcha_addict@lemy.lolOP
          link
          fedilink
          arrow-up
          1
          ·
          11 months ago

          If I am packaging software for gentoo, all I have to do is translate the build instructions from the project’s documentation to gentoo’s package recipe. In nix, it seems that it is not that simple and you’ll have to do some exploration. Am I wrong?