overriding things to "upstream" nix is fragile if upstream nix ever updates majors

jade commented

2024-09-21 00:05:42 +00:00

Owner

Currently we override things like nixos-option (in particular, as a questionable pile of c++ that links to nix) by redirecting them to the stable version of cppnix. This is actually very liable to break spectacularly in updates, since they may not actually have their nix input set to whatever the stable version of nix is. I have /no/ idea how to correctly overlay these to not touch them.

I don't think we can trivially just do nixos-option = prev.nixos-option, right? even though that will correctly evaluate to the previous nixos-option and might actually work properly within the overlay itself (?), I believe it would be a no-op, though the recursion structure that leads to this intuition eludes me at the moment.

Currently we override things like nixos-option (in particular, as a questionable pile of c++ that links to nix) by redirecting them to the stable version of cppnix. This is actually very liable to break spectacularly in updates, since they may not actually have their nix input set to whatever the stable version of nix is. I have /no/ idea how to correctly overlay these to not touch them. I don't think we can trivially just do `nixos-option = prev.nixos-option`, right? even though that will correctly evaluate to the previous nixos-option and might actually work properly within the overlay itself (?), I believe it would be a no-op, though the recursion structure that leads to this intuition eludes me at the moment.