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?

  • Lojcs@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    9 months ago

    Either you create an fhs environment by listing the set of derivations to be symlinked into a chroot environment which mimics an FHS.

    Why isn’t this done on the actual system and by default? That would make it fhs compliant, no?

    • hallettj@beehaw.org
      link
      fedilink
      English
      arrow-up
      7
      ·
      9 months ago

      If you put an FHS on the actual system you wouldn’t be able to install multiple versions of the same package, updates wouldn’t be atomic - you wouldn’t get the big selling points of Nix.

    • palebluethought@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      9 months ago

      If your system uses 3 different Pythons as dependencies of different packages, which one gets to be /usr/bin/python?

      • Lojcs@lemm.ee
        link
        fedilink
        arrow-up
        2
        ·
        9 months ago

        The most recent one by default unless another is manually chosen. The nix packages can keep using their specific versions directly

        • palebluethought@lemmy.world
          link
          fedilink
          English
          arrow-up
          8
          ·
          edit-2
          9 months ago

          Now you’ll have a zillion users trying to install software in ways that violate all the assumptions that NixOS operates on, but which are still tightly coupled to your NixOS config. Now updates to your system, or even seemingly unrelated config changes (through some transitive dependency chain) can easily break that software.

          So now we’ve basically removed half the advantages that motivate Nix/OS in the first place, and when stuff breaks it will look like it’s Nix’s fault, even if it isn’t.

          On the other hand, nixpkgs is already the most comprehensive repository of system software out there, and for 99% of packages Nixifying it is pretty trivial. Hell, my NixOS config does that for 3 different GitHub repos right inline in my config.nix

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

          Choosing the most recent one might be impossible if you have multiple installations of the same package with same version but different features enabled during the configure step.

          • Lojcs@lemm.ee
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            9 months ago

            Conflict resolution is not an impossible task. You just need to have a sensible algorithm. I get that they don’t want to do it lest people abuse it instead of using nix but there isn’t a technical challenge that can’t be overcome.

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

              Conflict resolution was not my point. Rather the question which the “most recent” between two almost identical installations…

              • Lojcs@lemm.ee
                link
                fedilink
                arrow-up
                1
                arrow-down
                1
                ·
                9 months ago

                That’s what I meant. How the default is chosen is irrelevant and is not my point. (You can pick the earliest installed among the latest version for example) The point is, it can be done and isn’t a technical challenge.

                • MadMaurice@discuss.tchncs.de
                  link
                  fedilink
                  arrow-up
                  1
                  arrow-down
                  1
                  ·
                  edit-2
                  9 months ago

                  It’s not that it’s hard to do. It’s that it goes directly against the idea of NixOS since it breaks the separation. With NixOS I can start a shell in a different iteration of my system without switching over the whole system. If I had all my software installed into standard places, that shell might find things it’s not supposed to find.

                  Bottom line is: Most things work on NixOS out of the box. The PATH variable is adjusted accordingly to what a program is supposed to find, which in my opinion is perfectly reasonable and enough for software to find other software. The dynamic library paths are hardcoded as absolute paths, so software can find it’s libraries. There’s a special dynamic loader for binaries that don’t adhere to this. And if you really need an FHS compliant environment NixOS gives you the tools to create one in a sandbox.

                  You can either have the perks of NixOS or use an FHS compliant distro. That’s your choice.

                  • Lojcs@lemm.ee
                    link
                    fedilink
                    arrow-up
                    1
                    arrow-down
                    1
                    ·
                    9 months ago

                    It’s not that it’s hard to do. It’s that it goes directly against the idea of NixOS since it breaks the separation.

                    That’s what I said:

                    I get that they don’t want to do it lest people abuse it instead of using nix but there isn’t a technical challenge that can’t be overcome.