Cabal: new-freeze does not freeze dependencies of executables

[lspitzner]

And even though some dependency is frozen, it will be rebuilt because an executable it depends on is updated. In the worst case, all your frozen dependencies will be re-built after a cabal update because somethink like "happy" has a new version.

cabal-install-2.0.0.0. The observed behaviour is consistent independent of using freeze file or project file constraints field.

Reproduction: Init empty cabal lib project, add dependency gkt3, try to restrict version of happy (an executable dependency) to something non-latest.

[hvr]

@lspitzner That's a long-standing issue; we've had long conversations about this; most recent comment about this I can recall is https://github.com/haskell/cabal/issues/3502#issuecomment-282597043 by @grayjay

[grayjay]

It looks like new-freeze currently doesn't add any qualifiers to the constraints in the freeze file (CmdFreeze.hs), so it only constrains the top-level dependencies. It should probably at least use the any qualifier on every constraint until we finish implementing #3502.

[hvr]

@grayjay but if you simply add any. to all constraints, doesn't this risk the freeze file being inconsistent with the "unconstrained" install-plan computed (and in the worst case, the freeze file being unsatisfiable)?

[grayjay]

I think that new-freeze already took the union of all of the versions in the install plan when calculating the constraints, to work around the lack of qualified constraints before they were added. So this issue is probably a regression from when we made constraints like happy == 1.19.8 only apply to top-level dependencies. If cabal took the union of happy versions in the install plan and output an any.happy constraint, it would at least be able to prevent a project from picking up a newer version after an update. I'll try to work on a fix.

[23Skidoo]

I think that new-freeze already took the union of all of the versions in the install plan when calculating the constraints

I think I saw new-freeze generate constraints of form foo == x.y.z || == a.b.c, is that a consequence of that behaviour?

[grayjay]

I think I saw new-freeze generate constraints of form foo == x.y.z || == a.b.c, is that a consequence of that behaviour?

Yes

[23Skidoo]

@grayjay Can it lead to situations where we read in a freeze file, but the solver chooses a different install plan than the one that was frozen? Do we have a ticket for fixing that?

[grayjay]

@23Skidoo Yes, it's possible for the solver to choose a different version for a package if anything changes, such as solver flags or Hackage revisions, or the user edits other constraints in the file. #3502 covers using qualified constraints in the freeze file. We probably also need component based solving (#4087) before we can expose a stable format for qualified constraints for build tools.

[23Skidoo]

@grayjay Thanks!