[wip] nixos/lsb.nix: init #78798

matthewbauer · 2020-01-30T01:03:51Z

Add an LSB module to run binaries built for other distros. Two
sub-options are available:

enableDesktop: add extra desktop libraries like gtk & qt
support32Bit: support 32-bit binaries

Motivation for this change

Things done

Add an LSB module to run binaries built for other distros. Two sub-options are available: - enableDesktop: add extra desktop libraries like gtk & qt - support32Bit: support 32-bit binaries

nixos-discourse · 2020-01-30T01:04:43Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-make-nixos-so-easy-that-people-can-be-productive-up-front-without-having-to-first-learn-the-nix-language/5625/20

grahamc · 2020-01-30T01:10:14Z

Is every package here required by LSB? I think if there are any packages in this list which aren't defined as required by LSB, this module is doomed to become a "well this one might be useful..." megalist of software without a reasoned criteria for adding (or rejecting) something.

edit gosh, this module gives me a serious case of queasy stomach. I would much rather find a different way to support those users than a module which breaks NixOS's story around upgrades and version dependencies.

nixos/modules/config/lsb.nix

jtojnar · 2020-01-30T01:19:02Z

nixos/modules/config/lsb.nix

+    };
+  in lib.mkIf config.environment.lsb.enable ({
+    environment.sessionVariables.LD_LIBRARY_PATH =
+      "${base-libs64}/lib${lib.optionalString config.environment.lsb.support32Bit ":${base-libs32}/lib"}";


Should not this be a list so that it can be extended?

Yeah it should be a list. I forgot that was allowed in sessionVariables.

infinisil · 2020-01-30T02:48:50Z

It's an interesting module and I can see how it can be useful for special cases. However this goes very much against the purity aspect of Nix. With such a module I can imagine such situations:

Somebody with that option enabled packages a downloaded binary for nixpkgs, but they don't realize it uses these impure paths because it just works, resulting in it not working for everybody else
Package repositories saying that people need to enable this option to have their package work on NixOS
Troubleshooters saying people should enable this option to "fix" it, resulting in less people helping to fix impurities

As a NixOS user, the fact that /lib doesn't even exist is a thing I can say with pride, going against the global packages on almost every other distro. But with this option it kind of feels like giving up because it's not worth the effort to patch stuff. Next thing somebody adds to this module is a symlink /{,usr/}bin -> /run/current-system/sw/bin, and who knows what follows from that. I don't think going in this direction is a good idea.

Instead we should continue to push upstreams to not hardcode their paths, to make things configurable, maybe we can auto-patch things or use things like buildFHSUserEnv or bubblewrap to rewrite paths. That's the direction I'd like to go in.

So yeah I'm against having such a module in NixOS, but I think it would fit nicely into NUR

zimbatm · 2020-01-30T12:15:24Z

So to recap the current objection, what is happening right now is that we have an install base of NixOS users that run programs and discover missing runtime dependencies by using those packages. This only works when the runtime dependencies are sourced from absolute paths, if they are fetched from PATH we rely on an even smaller subset of NixOS users that don't have the runtime dependency installed. The whole discovery process is quite asynchronous and means we get regressions in nixpkgs. It's a strategy that works but it much less compelling than what we have for build dependencies where the sandbox basically guarantees that all dependencies are mapped and is fixed synchronously.

On the other side we have users whose system usability is impaired because they can't just download binaries from the Internet like they would be able to on any other distro. Fixing those issues rarely an easy task, which means that they basically need to be nix experts to use NixOS. Binaries can be shipped in many forms. As a developer I might get them in a JAR file, npm package, python wheel, ... We could solve a lot of that pain with that NixOS module.

I don't see those two things as necessarily mutually exclusive. What we really need is to find a better solution to map missing runtime dependencies so that they get discovered earlier.

edolstra · 2020-01-30T12:57:01Z

Closing this for the reasons @infinisil stated. It's fundamentally incompatible with the NixOS approach. If we bring back /lib etc., then what really is the point of running NixOS rather than a conventional Linux distribution? I realize this module can be very useful as a quick fix for getting 3rd party binaries to work, but it should be provided in NUR or as a flake. If it's in the NixOS base distribution it implies that this is an endorsed mechanism which it really shouldn't be.

Also, the option enableDesktop ("add extra desktop libraries like gtk & qt") is extremely open-ended: there is no way that this module would not quickly acquire dozens of other options to manage the set of impure packages.

matthewbauer · 2020-01-30T15:58:34Z

I'm a little bit surprised by how strong the objection is. It's opt-in and undoing it is only a simple unset LD_LIBRARY_PATH away. The difference between setting LD_LIBRARY_PATH and PATH is no different - they both introduce runtime impurities and allow what works on one machine to not work on another. If you really don't like this, you should also really not like all of the commands that NixOS provides in PATH by default (with no option for removal even!). At least with this module it is pretty standardized what you get and binary distributors can actually predictably get things working. PATH ends up being a mess of random binaries.

I definitely get the objection though, and at least agree that it shouldn't go in NixOS. I think it does makes sense to maintain this out of tree, which is actually pretty easy. enableDesktop probably should be rethought though, and maybe removed altogether. It was the minimum necessary libraries for me to get Electron + Dwarf Fortress working, but ended up being a huge number of packages, some of which really should be distributed with those libraries.

jtojnar · 2020-01-30T16:08:23Z

LD_LIBRARY_PATH is much worse than PATH since it overrules the libraries applications were linked against (through DT_RUNPATH ELF header). And we do criticize setting global PATH for dependencies: wrapper or, better, patch is preferred for that whenever possible.

matthewbauer · 2020-01-30T16:08:49Z

LD_LIBRARY_PATH is much worse than PATH since it overrules the libraries applications were linked against (through DT_RUNPATH ELF header).

Yeah, maybe this isn't such a good idea :) I guess I need a LD_LIBRARY_PATH_AFTER for this to work like I want it to.

danbst · 2020-02-02T10:05:53Z

@edolstra

then what really is the point of running NixOS rather than a conventional Linux distribution?

I disagree. There is point in running NixOS even when lsb.enable option exists. We only have to enforce that PR contributor and PR reviewer both have lsb.enable = false && nix.sandbox = true;.

This option is perfectly fine for end-users as long as contributors have pure systems.

danbst · 2020-02-02T10:16:41Z

@matthewbauer I understand you won't continue work on this PR, but I'll throw in my suggestion.

I think list of packages included under enviornment.lsb.enable should be autogenerated from webpage, so it is clear it is not "arbitrary" or something is missing, or something is added ad-hoc.

Also, I'm waiting for options environment.ubuntu."19.10".enable, environment.debian.enable, environment.gentoo.enable which will masquerade NixOS as another distribution. environment.lsb.enable is first step here :)

And yes, it should be done more like in #69057

nixos-discourse · 2020-02-02T10:20:04Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/add-bin-bash-to-avoid-unnecessary-pain/5673/26

This reverts commit af665d8, see #78798 (comment) for the reasons in a similar PR.

alyssais · 2020-02-02T20:45:19Z

I disagree. There is point in running NixOS even when lsb.enable option exists. We only have to enforce that PR contributor and PR reviewer both have lsb.enable = false && nix.sandbox = true;.

This option is perfectly fine for end-users as long as contributors have pure systems.

If you don’t want a pure system, there are plenty of other distributions that will serve your needs much better than NixOS.

Your suggestion means that in order for somebody to contribute to NixOS, they have to break installations of software that otherwise work for them. That’s going to be great for attracting new contributors! Part of the reason NixOS is so successful is that it’s so easy to go from being an end-user to a contributor.

Plus, if contributors aren’t allowed to use an option, who’s going to maintain it?

danbst · 2020-02-03T08:14:31Z

@alyssais I still like NixOS. On landing page https://nixos.org/nixos/ you don't see "purity" as an advantage. All of the "declarative", "reliable" and "devops-friendly" will still stay even with LSB/FHS stuff.

Disabling LSB by default is understandable, but forbidding it is too opinionated.

alyssais · 2020-02-03T10:24:19Z

On landing page https://nixos.org/nixos/ you don't see "purity" as an advantage.

It literally says “The Purely Functional Linux distribution” and all the benefits listed are consequences of purity. It is not “too opinionated” to break purity when the whole point of the project is to create a pure system.

nixos-discourse · 2020-02-03T23:10:16Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/add-bin-bash-to-avoid-unnecessary-pain/5673/29

7c6f434c · 2020-02-04T07:50:51Z

From my experience, there is an opposition of _NixOS Server_ and _NixOS Workstation_ (to name it after old Windows, and I do have a lot of `if isWorkstation then` in my NUR): * _server_ should be immutable, pure, reproducible, etc, while * _workstation_ should be flexible and allow everything.

It is not that clear-cut. On the one hand, the current discussion is partially fueled by requests of the people who want to manage computation servers where sometimes they need a proprietary binary for HPC tasks and sometimes they need Matlab or whatever. On the other hand, I have done a bisection of laptop configuration to debug a change in Xorg driver behaviour (it wasn't literally NixOS, but Nix-based), and of course impurities that might or might not affect the tests should better be a short list for that. Also, of course, some desktop users would like the tested-on-NixOS checkmark on GitHub mean something compared to non-NixOS Linux. There is also a user-facing NixOS feature that would suffer: the more impurities and system-wide settings there are, the easier it is to find yourself in a situation where you can easily install either X or Y, but installing both is complicated.

It might have sense to use another distro for _workstation_, but there is a strong pro-NixOS argument: nixops (and clones). One could manage eir laptops (and even laptops of granma) using the same server management tools

So, it should be NixOS with some extra modules but very clearly different name? It would be more Nix than Nix-on-Arch, but some of our promises do not apply and you should not say you tested something on NixOS if you only tested it there etc.

The opposition already leaked in `nixpkgs`, for example in form of `users.mutableUsers` setting.

… and I think some people use immutable users on laptops/desktops, and for some servers (long-living multi-user ones) mutable users make sense. The option has the benefit that non-user-management software affected by it would be pretty damning for the said software.

7c6f434c · 2020-02-04T08:22:48Z

@7c6f434c by _server_ and _workstation_ I did not mean exact the use cases of server and workstation, it is just to mark the dichotomy of * systems closely supervised by a human, so the flexibility is more important then enforcing rules vs. * something deployed en mass with containers and EC2 on the extreme end. They could be called using old-fashioned _master_ and _slave_ (and it would be more accurate) :)

Slave is the one closely supervised, right? I guess pet/cattle dichotomy is _almost_ there.

So the exceptions like "long-living multi-user servers" are _workstation_ in this axis.

I specifically gave an example where very much a «pet» system needed the «cattle» features to move forward (bisecting Xorg setup on a laptop)

zimbatm · 2020-02-04T12:44:18Z

This discussion reminds me a bit of Debian and Ubuntu where Debian took a principled approach, did a lot of amazing ground work. Then Ubuntu came along, added a graphical installer, added all the proprietary graphical drivers, picked a default desktop environment, created a great default user experience and became very popular because of it. I don't know if there are necessarily lessons to take from that except that NixBuntu will probably happen at some point. It's our choice if we want to make it part of the main project or have it as a (friendly) fork.

This reverts commit af665d8, see NixOS#78798 (comment) for the reasons in a similar PR.

balsoft · 2020-05-05T19:09:52Z

For anyone interested, I've created https://github.com/balsoft/nixos-fhs-compat which implements this functionality as well as basic FHS support (yes, yes, linking stuff to /bin and /usr/bin etc). It's available as a flake and intended for use in nixos-containers and virtual machines specifically tailored for running stubborn executables and scripts without patchelfing them. I'm going to add a separate module that generates a container that does this and a simple command to run something in that container soon.

matthewbauer · 2020-05-05T20:39:50Z

For anyone interested, I've created https://github.com/balsoft/nixos-fhs-compat which implements this functionality as well as basic FHS support (yes, yes, linking stuff to /bin and /usr/bin etc). It's available as a flake and intended for use in nixos-containers and virtual machines specifically tailored for running stubborn executables and scripts without patchelfing them. I'm going to add a separate module that generates a container that does this and a simple command to run something in that container soon.

Nice! I was meaning to make something like this.

The one piece that is still missing from all of this is a patch to glibc to add support for something like LD_FALLBACK_LIBRARY_PATH that is only used when a library is not in DT_RUNPATH.

nixos-discourse · 2020-12-26T02:02:30Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixos-flakes-and-kiss/10602/6

jkachmar · 2021-03-14T17:29:32Z

I'd just like to register my objection that this is the issue provided to justify the reversion of af665d8 (cf. 26aba55 commit message).

JojOatXGME · 2021-07-17T21:45:27Z

I just made some research to find possible solutions for NixOS/nix-idea#30. I have to say that I am not quite satisfied with the argumentation for reverting config.environment.ld-linux (26aba55). I think there is one question: Do we want to allow executables to work if they are build outside Nix? If the answer is “no”, we should remove bin/sh and /usr/bin/env. Otherwise, we should support the most common interpreters for ELF files.

If I understand the ELF specification correctly, it is currently impossible to build an ELF executable outside the Nix store with dynamic linking that supports NixOS. (ELF does not support any dynamic resolution of the interpreter.) I guess you could even argue that this makes these interpreters even more important than /bin/sh.

Anyway, I agree that having these binaries at global paths is not ideal. I personally think that the concepts of nix-ld or envfs could be a good compromise. Both of them avoid the problem of /bin/sh, that it is always available (EDIT: in a specific version) regardless of the environment.

PS: Why does #69057 not exist anymore? I have found a bunch of references to this issue, which obviously do not work anymore.

samueldr · 2021-07-17T22:19:05Z

PS: Why does #69057 not exist anymore? I have found a bunch of references to this issue, which obviously do not work anymore.

There are some users who got "disappeared" from GitHub. And when that happens project information gets disappeared too, which in turn means we're left with well gaslit holes in our history :(.

infinisil · 2021-07-18T00:53:48Z

we should remove bin/sh and /usr/bin/env

I was going to argue that /usr/bin/env makes sense to stay because many people rely on that for script shebangs. But then I realized that such Nix-external shell scripts are no different than Nix-external binaries, but we allow the former while disallowing the latter.

JojOatXGME · 2021-07-18T01:35:00Z

we should remove bin/sh and /usr/bin/env

I was going to argue that /usr/bin/env makes sense to stay because many people rely on that for script shebangs. But then I realized that such Nix-external shell scripts are no different than Nix-external binaries, but we allow the former while disallowing the latter.

I guess you could argue that binaries are build by a compiler, while shell scripts are written by hand. If you develop a binary on your local machine, you don't have to set the interpreter manually. If you write a shell script, you have to manually specify the path to bash. So it is a bigger annoyance for scripts then for binaries if you develop them locally. 🤔

nixos-discourse · 2021-12-10T00:49:41Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-make-nixos-so-easy-that-people-can-be-productive-up-front-without-having-to-first-learn-the-nix-language/5625/51

matthewbauer requested a review from infinisil as a code owner January 30, 2020 01:03

matthewbauer changed the title ~~[wi[] nixos/lsb.nix: init~~ [wip] nixos/lsb.nix: init Jan 30, 2020

jtojnar reviewed Jan 30, 2020

View reviewed changes

ofborg bot added 6.topic: nixos 8.has: module (update) 10.rebuild-darwin: 0 10.rebuild-linux: 1-10 labels Jan 30, 2020

fixup

23a0ab9

add libs needed for electron

052e19b

edolstra closed this Jan 30, 2020

edolstra added a commit that referenced this pull request Feb 2, 2020

Revert "add config.environment.ld-linux"

26aba55

This reverts commit af665d8, see #78798 (comment) for the reasons in a similar PR.

infinisil added the significant label Apr 19, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[wip] nixos/lsb.nix: init #78798

[wip] nixos/lsb.nix: init #78798

matthewbauer commented Jan 30, 2020

nixos-discourse commented Jan 30, 2020

grahamc commented Jan 30, 2020 •

edited

Loading

jtojnar Jan 30, 2020

matthewbauer Jan 30, 2020

infinisil commented Jan 30, 2020

zimbatm commented Jan 30, 2020

edolstra commented Jan 30, 2020

matthewbauer commented Jan 30, 2020

jtojnar commented Jan 30, 2020

matthewbauer commented Jan 30, 2020 •

edited

Loading

danbst commented Feb 2, 2020

danbst commented Feb 2, 2020

nixos-discourse commented Feb 2, 2020

alyssais commented Feb 2, 2020

danbst commented Feb 3, 2020

alyssais commented Feb 3, 2020

nixos-discourse commented Feb 3, 2020

7c6f434c commented Feb 4, 2020 via email

7c6f434c commented Feb 4, 2020 via email

zimbatm commented Feb 4, 2020

balsoft commented May 5, 2020

matthewbauer commented May 5, 2020

nixos-discourse commented Dec 26, 2020

jkachmar commented Mar 14, 2021

JojOatXGME commented Jul 17, 2021 •

edited

Loading

samueldr commented Jul 17, 2021 •

edited

Loading

infinisil commented Jul 18, 2021

JojOatXGME commented Jul 18, 2021

nixos-discourse commented Dec 10, 2021

[wip] nixos/lsb.nix: init #78798

[wip] nixos/lsb.nix: init #78798

Conversation

matthewbauer commented Jan 30, 2020

Motivation for this change

Things done

nixos-discourse commented Jan 30, 2020

grahamc commented Jan 30, 2020 • edited Loading

jtojnar Jan 30, 2020

Choose a reason for hiding this comment

matthewbauer Jan 30, 2020

Choose a reason for hiding this comment

infinisil commented Jan 30, 2020

zimbatm commented Jan 30, 2020

edolstra commented Jan 30, 2020

matthewbauer commented Jan 30, 2020

jtojnar commented Jan 30, 2020

matthewbauer commented Jan 30, 2020 • edited Loading

danbst commented Feb 2, 2020

danbst commented Feb 2, 2020

nixos-discourse commented Feb 2, 2020

alyssais commented Feb 2, 2020

danbst commented Feb 3, 2020

alyssais commented Feb 3, 2020

nixos-discourse commented Feb 3, 2020

7c6f434c commented Feb 4, 2020 via email

7c6f434c commented Feb 4, 2020 via email

zimbatm commented Feb 4, 2020

balsoft commented May 5, 2020

matthewbauer commented May 5, 2020

nixos-discourse commented Dec 26, 2020

jkachmar commented Mar 14, 2021

JojOatXGME commented Jul 17, 2021 • edited Loading

samueldr commented Jul 17, 2021 • edited Loading

infinisil commented Jul 18, 2021

JojOatXGME commented Jul 18, 2021

nixos-discourse commented Dec 10, 2021

grahamc commented Jan 30, 2020 •

edited

Loading

matthewbauer commented Jan 30, 2020 •

edited

Loading

JojOatXGME commented Jul 17, 2021 •

edited

Loading

samueldr commented Jul 17, 2021 •

edited

Loading