Cabal install should upgrade in the correct order. #219

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

Comments

Projects
None yet
1 participant
@bos
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@bos

bos May 24, 2012

Contributor

(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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@bos

bos May 24, 2012

Contributor

(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.

Contributor

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