<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 1, 2024 at 11:11 AM Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Sat, 1 Jun 2024, Daniel Trstenjak wrote:<br>
<br>
> Looking at the compile error of the unix package, it looks like it gets <br>
> the wrong combination of filepath and os-string packages, resulting in <br>
> the missing symbols. This depends on the os-string flag, either the unix <br>
> package gets the older filepath package containing these symbols or the <br>
> newer one without them and additionally the os-string package now <br>
> containing the symbols.<br>
><br>
> This handling with the os-string flag feels wrong to me and therefore <br>
> cabal can‘t resolve the right dependencies.<br>
<br>
It would work, but --allow-newer ignores upper version bounds and thus can <br>
choose old filepath with new os-string.</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>