nix-du fails to build #275
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#275
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the bug
nix-du
is broken when the Lix overlay is active and CppNix is substituted with Lix.Steps To Reproduce
pkgs.nix-du
Expected behavior
build success
nix --version
outputnix (Lix, like Nix) 2.90.0-lixpre20240506-106b959
Additional context
This is due to this Nix change that isn't in Lix. Also
nix-du
possibly shouldn't be relying on that in the first place(?) so it's not clear to me who is responsible to fix.AFAICT this just needs another override added into https://git.lix.systems/lix-project/nixos-module/src/branch/main/overlay.nix
I can't test it locally right now, but I'll circle back tomorrow if this is still unresolved.
hmmm. another fix for this would be to do that part of the splitting. the reason this change isn't in lix isn't that we don't want it, but because it was far too big to review.
and, also, the fact that someone is assuming that we are nix 2.20, which we aren't. shakes fist at version detection.
Unless the goal is to maintain header compat with Nix, there's not much point in spending the effort to try to fix if that's the only benefit.
I assume that Lix isn't trying to maintain header compat with Nix but I haven't found any docs laying out the plan for compatibility with Nix, so I don't really know.
Better to focus on things like #279 to make the break more clear, and spend effort on whatever it is that Lix is trying to work on.
I would expect that not to work since it seems the header reorg was done in upstream 2.19. I also think it would make more sense to conditionally patch du and avoid pulling in upstream if possible. Those seem to be transitory measures anyway though.
Neutral on that. Speaking of, how do you detect Lix? Assume that 2.90+ are Lix?
Agreed. This is not a boiling hot issue for me, I reported it for completeness.
we actually do want the splitting to happen, see #43, but we just haven't done it for effort reasons. it's not like, super hard to actually do it or even slightly a high risk change. we just haven't done it. if you want to help feel free; the thing that we need is having the splitting done file by file so review is tractable.
The overlay change does work, btw. nix-du detects the Nix version and handles the headers.
Eventually we can get other things to detect and use Lix, assuming that we provide equivalent header functions, but right now I think we should get out of the way to let people use Lix where it already works. We can push changes upstream once it's decided that the Lix headers are stable enough.
In my personal capacity, I would support the overlay solution for now.
Now when I try to build nix-du with the nixpkgs pinned in lix, I get another error and I'm confused.