Guix: creating a package from a binary
21 points by aloys
21 points by aloys
Note that when the binary depends on dynamic libraries there are more things that one has to do. Nonguix provides the binary build system which provides ways to update the rpath of the binary. For example:
https://git.sr.ht/~puercopop/glue/tree/default/item/src/glue/packages/atuin.scm
I agree with the author that using upstream binaries, as well as using Flatpak, are a good way to use software that isn't packaged yet. There is a channel for binary packages. bin-guix https://github.com/ieugen/bin-guix
Thank you, I wasn't aware of this channel. Though I am glad I did not find it, I would have lost a learning opportunity.
I must add that I am quite new to Guix and might not approach it from the most idiomatic way.
Good point about dynamic libraries, I got away with the copy-build-system because caddy happened to be self contained. Thank you for pointing it out.
That's quite interesting. My perception from taking to NixOS-using colleagues is that using binaries on NixOS is quite problematic. It's surprising that Guix seems superior in this regard, perhaps my priors are wrong?
In my experience guix has more understandable build systems. They are written in scheme. In contrast with nixpkgs which are are mostly interpolated bash snippets glued together. And a lot of build systems in nixpkgs inherit from stdenv when they really shouldn't. In that regard Guix is better than nix imho. Another one is that error messages in Guix tend to be useful to point where the error occurred.
That said that is only one of the several dimensions in which one can compare both projects. The nix ecosystem has other advantages (and disadvantages).
Oh, I see advantages to Guix; what I don't understand is what's the reason behind Guix making using executable binaries easy to use, while they seem to be a problem in NixOS.
I'm not really familiar with guix, but I would guess the challenges are the same; that you usually have to use rpath (or LD_LIBRARY_PATH) to update paths to dynamic libraries, before you can use existing binaries.
When skimming the post here, the process is the same as in nix, for binaries without dependencies on other dynamic libraries.
I don't think it is hard on NixOS. They have have the functions to modify the rpath. You just have to pass the libraries as inputs.
Note the binary system is in nonguix, not guix. The copy system mentioned in the post is intended for things like assets
I think how "problematic" it is on nixos, depends on what you want from it.
I think having nix-ld and envfs enabled is a good default for systems where you'd like to run arbitrary binaries. Sadly not an upstream default, but see:
https://fzakaria.com/2025/02/26/nix-pragmatism-nix-ld-and-envfs
That's the brute, but generic approach.
If I'd like to start packaging a binary, I often use https://github.com/Lassulus/nix-autobahn to get a quick idea of the needed dependencies. Sometimes it suffices, sometimes its at least a starting point for more proper packaging.
Ah, I guess my NixOS-using colleagues might have not known those bits at the time we discussed these things. I believe in general they used some Steam runtime thing to run non-NixOS binaries. Thanks!
It's using basically the same elements as nix. All the library patching is done by patchelf to make it run with the expected dependencies, or usually autoPatchelfHook https://ryantm.github.io/nixpkgs/hooks/autopatchelf/ to make things simpler. They're not much different in practice.
Binary packages in nix are pretty simple, even in more advanced cases (multi arch, plugin support, multiple audio backends: https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/re/reaper/package.nix)
Impressive how s-expressions can be used as a data asset declaration and provide for this kind of elegant descriptions of packages, a notoriously difficult thing, with a wide array of competing DSLs... and yet here we have a compelling take from a tech from the 1950s