my point was that the Nix package manager has useful enough features and functonality that it was ported to OpenBSD to use for managing OpenBSD software and packages.
My point was that support for BSDs in Nixpkgs (which is the de-facto “standard library”) is still in its infancy. Nix without Nixpkgs is like C without a libc.
That’s what porting does, it’s making a program fully functional on a different operating system or different hardware architecture. Compatibility serves a different purpose from porting.
Terminology on this is a bit loosely defined. What I meant was that the packages in Nixpkgs largely haven’t been “ported” to BSDs yet.
Many of the packages might already be “ported” and would work if other packages lower down in the tree worked. In Nixpkgs we don’t really differentiate between fixing packages so that the package works as upstream intends or making something work that was never intended to work.
There is zero interest in Nix pkgs, that’s all Linux stuff. Every and all Linux packages is incompatable with BSD, and there is no way to make Linux packages ever compatable with BSD.
To port Nix package manager to BSD they change the source code to run on BSD libraries, look for BSD compiled programs, and how run on BSD dependancies, interacting with a BSD kernel.
Installing Nixpkgs on BSD is the same as talking about making Mac OS programs run on Linux, that’s physically impossible.
OpenBSD is not trying to run the whole Nix distribution, they only tool the Nix package manager and changed the source code of the Nix package manager but removing all referances to Nix and Linux, changed the code to run on BSD libraries and changed the Nix package manager source code to look for BSD format files.
Nix package manager on OpenBSD has no knowledge and no understanding of Linux or NixOS files.
I may not have been precise enough here with the wording.
To clarify: Nixpkgs is a source distribution. You can see all of it here: https://github.com/NixOS/nixpkgs
From Nixpkgs, Hydra builds binary artifacts which then get distributed through the binary cache (cache.nixos.org). Users usually use binaries substituted by the cache but these binary artifacts are a direct result of the source, a small set of parameters (mainly platform), some time and some energy, so we usually rarely talk about them. They’re not interesting to us; we could reproduce them at any time by just building again.
What I’m talking about all happens at the “source” level, not the binary level. You obviously can’t take a Linux binary to a BSD and expect it to run but you can take a package definition initially made for Linux, try to build it on a BSD and run the result of that.
From experience with Darwin, this works in the majority of cases and usually only requires very few adjustments to the build recipe. With Nix, we have a full expression language at our hands, so we are able to to things like optionally adding some dependencies depending on the platform. We usually do not maintain separate build recipes for separate platforms; they usually use the same build definitions with different parameters.
OpenBSD is not trying to run the whole Nix distribution, they only tool the Nix package manager
What do you mean by this? OpenBSD “forking” Nix (a la Guix) would be news to me. Do you have some links for me?
Nix package manager on OpenBSD has no knowledge and no understanding of Linux or NixOS files.
The Nix package manager has no knowledge or understanding of “Linux or NixOS files” on any platform, including Linux/NixOS.
Its purpose is to know how to evaluate and realise Nix expressions.
I can evaluate a Nix expression for OpenBSD on my macOS machine. Nix doesn’t care.
(Obviously I can’t build it but I could theoretically cross-compile it, if support for that was to be wired up in Nixpkgs.)
I think you’re misunderstanding a bit how Nix and Nixpkgs work with different platforms.
My point was that support for BSDs in Nixpkgs (which is the de-facto “standard library”) is still in its infancy. Nix without Nixpkgs is like C without a libc.
Terminology on this is a bit loosely defined. What I meant was that the packages in Nixpkgs largely haven’t been “ported” to BSDs yet.
Many of the packages might already be “ported” and would work if other packages lower down in the tree worked. In Nixpkgs we don’t really differentiate between fixing packages so that the package works as upstream intends or making something work that was never intended to work.
There is zero interest in Nix pkgs, that’s all Linux stuff. Every and all Linux packages is incompatable with BSD, and there is no way to make Linux packages ever compatable with BSD.
To port Nix package manager to BSD they change the source code to run on BSD libraries, look for BSD compiled programs, and how run on BSD dependancies, interacting with a BSD kernel.
Installing Nixpkgs on BSD is the same as talking about making Mac OS programs run on Linux, that’s physically impossible.
OpenBSD is not trying to run the whole Nix distribution, they only tool the Nix package manager and changed the source code of the Nix package manager but removing all referances to Nix and Linux, changed the code to run on BSD libraries and changed the Nix package manager source code to look for BSD format files.
Nix package manager on OpenBSD has no knowledge and no understanding of Linux or NixOS files.
I may not have been precise enough here with the wording.
To clarify: Nixpkgs is a source distribution. You can see all of it here: https://github.com/NixOS/nixpkgs
From Nixpkgs, Hydra builds binary artifacts which then get distributed through the binary cache (cache.nixos.org). Users usually use binaries substituted by the cache but these binary artifacts are a direct result of the source, a small set of parameters (mainly platform), some time and some energy, so we usually rarely talk about them. They’re not interesting to us; we could reproduce them at any time by just building again.
What I’m talking about all happens at the “source” level, not the binary level. You obviously can’t take a Linux binary to a BSD and expect it to run but you can take a package definition initially made for Linux, try to build it on a BSD and run the result of that.
From experience with Darwin, this works in the majority of cases and usually only requires very few adjustments to the build recipe. With Nix, we have a full expression language at our hands, so we are able to to things like optionally adding some dependencies depending on the platform. We usually do not maintain separate build recipes for separate platforms; they usually use the same build definitions with different parameters.
What do you mean by this? OpenBSD “forking” Nix (a la Guix) would be news to me. Do you have some links for me?
The Nix package manager has no knowledge or understanding of “Linux or NixOS files” on any platform, including Linux/NixOS.
Its purpose is to know how to evaluate and realise Nix expressions.
I can evaluate a Nix expression for OpenBSD on my macOS machine. Nix doesn’t care.
(Obviously I can’t build it but I could theoretically cross-compile it, if support for that was to be wired up in Nixpkgs.)
I think you’re misunderstanding a bit how Nix and Nixpkgs work with different platforms.
In the OpenBSD ports and packages tree for user installation here