new-build stores are dbs in the ghc-pkg sense, but treating them as such breaks cabal

[lspitzner]

e.g.

1. the user ghc-pkg unregisters a dependency of a build-tool
2. the user deletes the corresponding package
3. cabal new-build will choke with some internal error when creating a build-plan involving that build-tool because it expects the dependencies of build-tools to be installed but they are not.

Also note that after 1+2, ghc-pkg check turns up clean, while from cabal perspective, the store is in an inconsistent state. Well, that depends on the "consistency" definition, but alternatively, the store still is consistent, only the build-plan construction makes false assumptions which would make it a bug there instead.

Possible solutions:

1. Properly communicate to users that the store is not a proper package-db. Ideally make it incompatible with ghc-pkg
2. Fix the build-plan to be more robust against this, e.g. by not expecting dependencies of executables to be installed.

[lspitzner]

Also, is there even a sufficient upside to maintaining the ghc-pkg database for stores in the first place? Would just having the package folders each with a "cabal-hash.txt" not be sufficient, without the "package.db" directory?

[hvr]

@lspitzner the main reason we need to maintain a ghc-pkg DB is for GHC's sake, as that's the designated interface to register packages for GHC. Also note that strictly speaking, the only thing that's under the authority of the pkg-db tool is the package.db/ folder. How the rest of the files are structured is not mandated by the hc-pkg-specification.

So the problem here, as you state, is merely that our nix-store assumes more invariants than are encoded in the package.db/-registry. Most importantly, the assumption is that every tool accessing the nix-style store keeps enforcing those invariants.

[gbaz]

I think we should add a sanity-check to ensure the invariants aren't violated -- not sure if that belongs in cabal or hackage-security but it seems like a good defensive idea in general.

[hvr]

@gbaz this has nothing to do with hackage-security, as hackage-security doesn't concern itself with the pkg-db store, but only with the package repo index & tarball cache... :-)

[gbaz]

Fair 'nuff. In any case a sanity check would be good, not least because it would force us to pin down exactly what the invariants are :-)