cabal upgrade: dependencies conflict
Duncan Coutts
duncan.coutts at worc.ox.ac.uk
Thu Oct 23 18:37:20 EDT 2008
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
More information about the cabal-devel
mailing list