Re: [Haskell-cafe] Issue building with ghc-9.8.2 and packages unix, directory, filepath and os-string
The problem is that `--allow-newer` tells cabal to ignore dependencies' upper bounds completely. If those bounds turn out to be necessary in some cases, the solver will produce a bad build plan.
Looking at the compile error of the unix package, it looks like it gets the wrong combination of filepath and os-string packages, resulting in the missing symbols. This depends on the os-string flag, either the unix package gets the older filepath package containing these symbols or the newer one without them and additionally the os-string package now containing the symbols. This handling with the os-string flag feels wrong to me and therefore cabal can‘t resolve the right dependencies. The unix 2.8.5.0 package has an upper bound for filepath of <1.5, the one with the symbols, but unix 2.8.5.1 has the lower bound filepath >1.4.100, therefore supporting the filepath packages with and without the symbols. It seems if unix 2.8.5.1 would only support the filepath package without the symbols, by having the lower bound filepath >=1.5, then cabal could work out the right dependencies. Is there a reason why the unix 2.8.5.1 does it that way?
On Sat, 1 Jun 2024, Daniel Trstenjak wrote:
Looking at the compile error of the unix package, it looks like it gets the wrong combination of filepath and os-string packages, resulting in the missing symbols. This depends on the os-string flag, either the unix package gets the older filepath package containing these symbols or the newer one without them and additionally the os-string package now containing the symbols.
This handling with the os-string flag feels wrong to me and therefore cabal can‘t resolve the right dependencies.
It would work, but --allow-newer ignores upper version bounds and thus can choose old filepath with new os-string.
Right, the point here is that `allow-newer` _breaks the solver_ and in particular breaks packages that require it to obey upper bounds (like `unix`) to produce a valid build plan. Using it blindly is therefore a very bad idea. On Sat, Jun 1, 2024 at 11:11 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Sat, 1 Jun 2024, Daniel Trstenjak wrote:
Looking at the compile error of the unix package, it looks like it gets the wrong combination of filepath and os-string packages, resulting in the missing symbols. This depends on the os-string flag, either the unix package gets the older filepath package containing these symbols or the newer one without them and additionally the os-string package now containing the symbols.
This handling with the os-string flag feels wrong to me and therefore cabal can‘t resolve the right dependencies.
It would work, but --allow-newer ignores upper version bounds and thus can choose old filepath with new os-string.
-- brandon s allbery kf8nh allbery.b@gmail.com
participants (3)
-
Brandon Allbery -
Daniel Trstenjak -
Henning Thielemann