Skip to content

Cabal install should upgrade in the correct order. #219

Closed
bos opened this Issue May 24, 2012 · 2 comments

1 participant

@bos
Haskell member
bos commented May 24, 2012

(Imported from Trac #226, reported by guest on 2008-01-31)

Also, cabal upgrade package-name should probably upgrade that packages and dependencies, but not other packages.

Here was my session with darcs cabal-install 2008-01-31:

$ cabal upgrade
Upgrading the following packages:
cgi-3001.1.5.2
hmatrix-0.2.0.0
pcre-light-0.3
regex-base-0.93.1
regex-compat-0.91
regex-posix-0.93.1
TypeCompose-0.3
xhtml-3000.0.2.2
zlib-0.4.0.2
Downloading 'cgi-3001.1.5.2'...
[... cgi upgrades fine ...]
Configuring regex-compat-0.91...
setup: At least the following dependencies are missing:
    regex-base >=0.93, regex-posix >=0.93
Downloading 'TypeCompose-0.3'...
Downloading 'xhtml-3000.0.2.2'...
Downloading 'zlib-0.4.0.2'...
cabal: Error: some packages failed to install:
  zlib-0.4.0.2
  xhtml-3000.0.2.2
  TypeCompose-0.3
  regex-compat-0.91
  regex-posix-0.93.1
  regex-base-0.93.1
  pcre-light-0.3
  hmatrix-0.2.0.0
$ cabal upgrade regex-base
Upgrading the following packages:
hmatrix-0.2.0.0
pcre-light-0.3
regex-base-0.93.1
regex-compat-0.91
regex-posix-0.93.1
TypeCompose-0.3
xhtml-3000.0.2.2
zlib-0.4.0.2
'hmatrix-0.2.0.0' is cached.
[... everything through TypeCompose upgrades fine ...]
'xhtml-3000.0.2.2' is cached.
Configuring xhtml-3000.0.2.2...
'zlib-0.4.0.2' is cached.
Configuring zlib-0.4.0.2...
[... zlib upgrades fine ...]
cabal: Error: some packages failed to install:
  xhtml-3000.0.2.2
$ cabal upgrade
Upgrading the following packages:
xhtml-3000.0.2.2
'xhtml-3000.0.2.2' is cached.
Configuring xhtml-3000.0.2.2...
[... succeeds ...]
@bos
Haskell member
bos commented May 24, 2012

(Imported comment by @dcoutts on 2008-01-31)

See also #198 about the behaviour of upgrade and install.

Note also that the install error recovery is very simple minded. Currently if a package fails we continue to try to build the remaining packages and then report them as failures too. We should keep the package dep graph and remove packages that depended on the failing one rather than trying to build them anyway. So that means maintaining a dep graph while building, not just immediately flattening to a topological order.

@bos
Haskell member
bos commented May 24, 2012

(Imported comment by @dcoutts on 2008-01-31)

I think this should already be fixed. If the planner produces a valid plan (which it often does not) then that plan should now always be in dependency order.

@bos bos closed this May 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.