ive been dabbling in nix the past two months now, trying to make a decent config, and wanted to start getting used to nix and help maintain/add new packages, but now that I did a very small version bump and tried to update after it was merged i realized how little I actually know what is going on under the hood.
How exactly do packages move from master → unstable → stable (I mean the last one is just a release cutoff line I suppose) but generally are there people that use nixos/master instead of nixos/unstable?
Also since we probably wont be hosting our own instance of hydra for a while now, how do I force packages to be built on my machine, since the cache might/will not have updates that we have on our fork.
I feel like the more I scratch the surface the more I realize I know jack shit right now and I want to learn.
Cheers Holli
(heading to bed now so probably wont respond quickly)
How exactly do packages move from master → unstable → stable (I mean the last one is just a release cutoff line I suppose) but generally are there people that use nixos/master instead of nixos/unstable?
We only have a master workflow at the moment and we have not had much of a discussion around other branches. But this is a very good point and something that we should work on.
Also since we probably wont be hosting our own instance of hydra for a while now.
Currently we are only a soft fork, this means that we still pull down upstream changes so for the large part we can still utilise their prebuilt binaries.
how do I force packages to be built on my machine, since the cache might/will not have updates that we have on our fork.
The simple answer is you don’t. For a more in-depth explanation on how nix packages works read the below.
So nix packages are built into /nix/store/. Each package has a path like so y4h73bmrc9ii5bxg6i7ck6hsf5gqv8ck-foo-1.0.drv the package name being foo and the hash being the section at the start (y4h73bmrc9ii5bxg6i7ck6hsf5gqv8ck). In this case the package is at version 1.0 we know this from the last section of the derivation name.
So what changes if we wish to update a package to say version 2.0. Well since there has been changes in the source of the project the outcome of the build will differ. This also mean so the will the hash.
So what does that mean for caching. Since the file path is different nix/aux will no longer see the package as the same and won’t be able to use that package from the cache. That means that the new package will be built from source.
Ah perfect! I was remembering something like that but couldnt quite find this, and jsut remember somebody talking about some emacs they always build themself for more performance and thought maybe there was a flag to always build from source (which doesnt sound that smart for most packages).
Ok so that is something that will come with time, if there are things there that are just manual work and can be delegated, please let me know. I would love to get a better insight in all of the infrastructure around nix
