Why does my system config depend on (now broken) package

Hey all, when i try to upgrade my system to 19.03(:partying_face:) the switch fails due to a random python library fails do build.
I know nix why-depends exists, but it require a derivation path. My naive idea was:
nix why-depends python2.pkgs.pycdio config.system.topLevel which obviously didn’t work out.

Is there a way to get the dependency graph anyway?

2 Likes

For the simple answer, there’s only one package that depends on pycdio, and it’s called whipper. Nothing depends on whipper, so it’s a safe bet that this is your guy.
For the dep graph, you can maybe try building by allowing broken packages, cancel it, and then check the top level drv with why-depends.

Yeah this is kind of difficult. If you can’t build python2.pkgs.pycdio, there’s no way to find why it depends on your system. We really need something that’s like “why-build-depends” for analyzing .drv files instead of output paths. This would be useful for lots of things when auditing systems.

5 Likes

At long last i found the package in question, which was morituri which actually is only an alias for whipper.
Of course own configuration could also in theory make use of pycdio

This of course was a quite easy example but a more straight-forward method would be great.

I agree. There exists a hacky workaround for analyzing build time dependencies without having to build stuff. See #1918 for the workaround and #59124 for an example application.

2 Likes