cabal upgrade: dependencies conflict

L.S., Cabal-install refused to upgrade because of a dependencies conflict: >cabal upgrade Warning: Error parsing config file C:\Documents and Settings\Henk-Jan\Application Data\cabal\config: On line 1: GHC Warning: Using default configuration. Resolving dependencies... cabal: dependencies conflict: Win32-2.1.1.1 requires bytestring ==0.9.0.1.1 however bytestring-0.9.0.1.1 was excluded because bytestring-0.9.1.3 was selected instead bytestring-0.9.0.1.1 was excluded because of the top level dependency bytestring >0.9.1.2 After the command: >cabal upgrade bytestring the "cabal upgrade" command had no "dependencies conflict" problem any more. This looks like a bug to me. -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ --

On Fri, 2008-10-24 at 00:22 +0200, Henk-Jan van Tuyl wrote:
L.S.,
Cabal-install refused to upgrade because of a dependencies conflict:
>cabal upgrade Warning: Error parsing config file C:\Documents and Settings\Henk-Jan\Application Data\cabal\config: On line 1: GHC Warning: Using default configuration. Resolving dependencies... cabal: dependencies conflict: Win32-2.1.1.1 requires bytestring ==0.9.0.1.1 however bytestring-0.9.0.1.1 was excluded because bytestring-0.9.1.3 was selected instead bytestring-0.9.0.1.1 was excluded because of the top level dependency bytestring >0.9.1.2
After the command: >cabal upgrade bytestring the "cabal upgrade" command had no "dependencies conflict" problem any more.
This looks like a bug to me.
It is not directly a bug as such. The thing is, asking for $ cabal upgrade bytestring is not a simple subset of $ cabal upgrade The latter requires a consistent solution for all the upgradable packages while the former only requires a consistent solution for a smaller set of packages. We do not require all installed packages to be consistent all the time, just the thing that is requested. The upgrade command is an interesting one. It's not clear when you look at it in detail what it really means. There are several possible interpretations. Currently we take it to mean the following: * find all the installed packages for which there is a later version available * find a consistent solution where each package version is >= it's current version Note that we do not require a strictly later version for all the packages. Another interpretation would be to find a globally consistent solution for all packages. However that may well not be possible where the above is possible. The above allows for a partially inconsistent set of installed packages, it just requires consistency in the set that will be upgraded. It's pretty subtle stuff! We could do better with a more sophisticated solver. We could also do better if we could install multiple instances of the same package version, built in different ways. Duncan
participants (2)
-
Duncan Coutts
-
Henk-Jan van Tuyl