I’ve read a lot, but didn’t get a simple answer for 3 topics I’m interested about:
Are there any 3rd party repos for NixOS? It seems some people overlay one package, but I cannot find entire packagesets such as the one in Nixpkgs. Are channels used for that? Would I be able to have my own repo with several packages? Can I have more than 1 repo in my Nix system, and set which package install each program from?
Would it be possible, for propietary software compiled directly for NixOS, to have a binary-only (as opposed to source, or binary+patched) repository? Everything I see is either source+cache or binary+patched, but nothing like binary especifically for NixOS.
Let’s say I want to add some extra, propietary codecs unavailable to NixOS. How would I be able to change a dependency so that each package dependent on it automatically picked it? Could I switch a dependency for a certain repo from one of another, different repo?
Yes to all of the above! You can even use packages from multiple versions of the same repo.
Full repos are uncommon though, the only one I’m aware of is the NUR. It’s also the only other set of channels providing packages I’m aware of, as the infrastructure to provide those takes some effort to set up.
Small additional ones exist primarily as flakes.
I assume you mean “I don’t want to show my sources, but I do want to publish my binary with nix”? I’ve never seen this done, but I do believe it is possible in theory; your source is just a fixed-output derivation, a consumer does not need to have access to the source to be able to download the output of the build, just to the hash of your source.
That said, there would be some kinks to iron out. You’d likely still want to depend on nixpkgs to enable easy consumption on NixOS, and then you suddenly have issues keeping up with version bumps in your transitive dependencies that cause full rebuilds every week or so. If you pin an old nixpkgs that’s less problematic, but your users may not be happy being forced to have a second copy of libc.
Yes, you would use an overlay for exactly this use case, substituting the original package attribute for your new one. As long as your package provides the same interface, the only way to notice the change would be that a bunch of packages that depend on that codec need to be rebuilt.
Note that if you wanted to provide a binary cache for the result of the rebuilds caused by this substitution, you might violate a lot of GPL licenses, as I believe the redistribution of that GPL software with your codec linked in would be a modification. IANAL, this is not legal advice, and software licensing is confusing, consult with someone who knows exactly what they’re talking about before you try something like this.
Note that if you wanted to provide a binary cache for the result of the rebuilds caused by this substitution, you might violate a lot of GPL licenses, as I believe the redistribution of that GPL software with your codec linked in would be a modification. IANAL, this is not legal advice, and software licensing is confusing, consult with someone who knows exactly what they’re talking about before you try something like this.
Actually, what I meant is: in Fedora, we have the VAAPI drivers with only free codecs (the official ones), and the ones with proprietary stuff (freeworld ones). My question was if there was a way to switch the ffmpeg-free with an ffmpeg-unfree dependency. Would this require a recompilation of everything?
I assume you mean “I don’t want to show my sources, but I do want to publish my binary with nix”? I’ve never seen this done, but I do believe it is possible in theory; your source is just a fixed-output derivation, a consumer does not need to have access to the source to be able to download the output of the build, just to the hash of your source.
That said, there would be some kinks to iron out. You’d likely still want to depend on nixpkgs to enable easy consumption on NixOS, and then you suddenly have issues keeping up with version bumps in your transitive dependencies that cause full rebuilds every week or so. If you pin an old nixpkgs that’s less problematic, but your users may not be happy being forced to have a second copy of libc.
Understood. I guess you can also statistically build everything, but at that point that would apply to every single package.
An extra question, has autopatchelf any performance overhead over the binaries?
Yes - the way nix packages work is that the full package output is stored in a directory like /nix/store/<hash>-ffmpeg-free-<version>/. Instead of “installing” the package like on a traditional distro, the package is kept there in deployment too - and dependants are linked directly against this directory, instead of something in /usr/lib.
(Actually it’s a bit more complex than that and involves LD* variables and rpath and stuff as well, but I forget the details - give the nix pills a read if you want a better explanation).
Since a hash (which is over the build inputs, including sources, build script and build dependencies) is part of this path, when you substitute this package all dependants will need to be updated to link against the new package path.
This has two effects - for one, a change in a package with many dependencies causes a cascade of rebuilds, which is a bit of a PITA. However, this does ensure that you know exactly what inputs your package depends on, and no unexpected dependency mismatches can happen. Also, you can have things like effortlessly using multiple glibcs in a running system (at a disk space cost).
Nixpkgs (IMO somewhat miraculously) manages to hold up against this rebuild pressure, so it’s clearly feasible. Hydra is a pretty cool piece of software, too.
It shouldn’t - autopatchelf effectively just replaces the paths to dynamic libraries with the correct ones for the inputs.