[wip] nixos/lsb.nix: init #78798
[wip] nixos/lsb.nix: init #78798
Conversation
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
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
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. |
| }; | ||
| in lib.mkIf config.environment.lsb.enable ({ | ||
| environment.sessionVariables.LD_LIBRARY_PATH = | ||
| "${base-libs64}/lib${lib.optionalString config.environment.lsb.support32Bit ":${base-libs32}/lib"}"; |
There was a problem hiding this comment.
Should not this be a list so that it can be extended?
There was a problem hiding this comment.
Yeah it should be a list. I forgot that was allowed in sessionVariables.
|
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:
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 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 So yeah I'm against having such a module in NixOS, but I think it would fit nicely into NUR |
|
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. |
|
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 |
|
I'm a little bit surprised by how strong the objection is. It's opt-in and undoing it is only a simple 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. |
|
|
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. |
I disagree. There is point in running NixOS even when This option is perfectly fine for end-users as long as contributors have pure systems. |
|
@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 Also, I'm waiting for options And yes, it should be done more like in #69057 |
|
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.
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? |
|
@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. |
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. |
|
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 |
|
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 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)
|
|
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.
|
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 |
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 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
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 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 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 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 :(. |
I was going to argue that |
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 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
infinisil
added
the
significant
Add an LSB module to run binaries built for other distros. Two
sub-options are available:
Motivation for this change
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)