October 2011 - cabal-devel

[Hackage] #694: mention --constraint flag in error essage when dep planning fails
by Hackage 16 Apr '12

16 Apr '12

#694: mention --constraint flag in error essage when dep planning fails ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Dependency planning problems can often be solved by running with --dry-run -v, seeing what the planner is selecting and forcing it to make different choices using the --constraint flag. When dependency planning fails with particular kinds of constraint problem, it may be useful to users to mention this. We should check if this advice applies to all cases where the dep planner fails, or if its only appropriate for certain classes of failure. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/694> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #789: build-depends on packages that provide no library
by Hackage 10 Apr '12

10 Apr '12

#789: build-depends on packages that provide no library ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ It is possible to list build-depends on packages that have just an executable and no library. Currently the behaviour of cabal-install does not consider this and it will allow such packages to be pulled in as dependencies. It leads to problems however because the non-lib package never gets registered with ghc-pkg and so it leads to re-install loops. The solution is for cabal-install to not consider exe-only packages to be valid for satisfying a build-depends requirement. It should produce a suitable error message. Note that it must take into account the posibility that a newer or older version of a package may switch from exe only to exe+lib or just lib, or indeed vica versa. We should mark exe-only versions of the package as excluded with a reason. Then if the dep is not satisfiable then we can explain why all the excluded ones were excluded (ie due to not exposing a lib). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/789> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #753: cabal executable chooses different versions of libraries than cabal library
by Hackage 09 Apr '12

09 Apr '12

#753: cabal executable chooses different versions of libraries than cabal library ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Hi, cabal-install version 0.8.2 using version 1.8.0.2 of the Cabal library This bug was originally reported by a Debian user. the `cabal' executable, when run on the attached sample library, chooses base 3.0.3.2: $ cabal -v configure [...] Configuring foobar-0.0... Dependency base ==3.0.3.2: using base-3.0.3.2 [...] whereas, the library (via Setup.hs) correctly gets base 4.2.0.0, probably due to ghc's hiding of the earlier version $ runhaskell Setup.hs -v configure Configuring foobar-0.0... Dependency base -any: using base-4.2.0.0 [...] cabal-install should probably perform the same hiding that ghc does. Cheers, Iain -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/753> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #762: cabal-install failed to resolve dependencies
by Hackage 07 Apr '12

07 Apr '12

#762: cabal-install failed to resolve dependencies ---------------------------------+------------------------------------------ Reporter: james_m_chapman | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I tried to update my installation of the development version of Agda. I did a darcs pull from the repo (darcs get --lazy http://code.haskell.org/Agda) and then tried to build it: $ darcs pull $ cabal update $ cabal clean $ cabal install I get the following error: "Resolving dependencies... cabal: cannot configure haskeline-0.6.2.2. It requires mtl ==1.1.* For the dependency on mtl ==1.1.* there are these packages: mtl-1.1.0.0, mtl-1.1.0.1, mtl-1.1.0.2 and mtl-1.1.1.0. However none of them are available. mtl-1.1.0.0 was excluded because Agda-2.2.9 requires mtl ==2.0.* mtl-1.1.0.1 was excluded because Agda-2.2.9 requires mtl ==2.0.* mtl-1.1.0.2 was excluded because Agda-2.2.9 requires mtl ==2.0.* mtl-1.1.1.0 was excluded because Agda-2.2.9 requires mtl ==2.0.*" Agda's .cabal file is here http://code.haskell.org/Agda/Agda.cabal and contains the build-depends line haskeline >= 0.3 && < 0.7 The solution is to upgrade haskeline to the latest version by running: $ cabal install haskeline Should cabal-install have been able to work this out itself? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/762> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #782: When building a plan, use installed package dependencies in preference to those from Hackage
by Hackage 07 Apr '12

07 Apr '12

#782: When building a plan, use installed package dependencies in preference to those from Hackage ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I was installing a package, let us call it foo. This package depended on a package foo', which in turn depended on bar, which in turn depended on baz < 0.3, but baz 0.3 was the default that came with the newer version of GHC I had just installed. Thus, I cabal-unpacked bar and bumped the baz dependency to < 0.4, **without changing the baz version number** since this was just a private change. This built and installed just fine with the new baz. I then went back to cabal install foo. I expected that cabal-install would just install foo' and then foo in that order. Instead, it tried to install baz 0.2, then bar, then foo', then foo. This seems stupid because I already had a perfectly acceptable bar installed. Why didn't Cabal just reuse that? It seems as if it is resolving dependencies by looking at the dependency information for bar **from the Hackage database** rather than the dependencies **from the installed bar**. The workaround is to go back to the unpacked bar and bump the version number, then reinstall it. Now when you install foo the installed baz is used as expected. It would be cool if this worked as expected without bumping the version number, because having to bump the version number even if not making a Hackage release is tiresome. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/782> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #884: Changed dependencies in locally installed packages ignord
by Hackage 07 Apr '12

07 Apr '12

#884: Changed dependencies in locally installed packages ignord ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Hello, in Debian, I have patched yesod-json-0.2.1 to depend on aeson instead of aeson-native, because we want only one aeson and blaze-textual package in Debian. Still, if I use cabal install to install a package that depends on yesod- json, it wants to re-build yesod-json against the -native variants. It seems that cabal install does not take the actual dependencies of installed packages into account and uses the Hackage provided information for them as well. What it should do instead is: If a dependency of some packages that is to be installed can be fulfilled by a locally installed package, and none of its dependencies (as known by ghc-pkg) have to be rebuild, then this package should be used. Only if the package in question has to be rebuild, the dependencies according to hackage should be taken into account. The work around in Debian is to bump the version number, adding a vendor level (0.2.1.0.1), but it would be nice if this could be avoided. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/884> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[Hackage] #731: Custom Build-type with --package-db and --global encounters runtime error
by Hackage 28 Mar '12

28 Mar '12

#731: Custom Build-type with --package-db and --global encounters runtime error ---------------------------------+------------------------------------------ Reporter: cygnus | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.2 Platform: Linux | ---------------------------------+------------------------------------------ To reproduce: * Run `cabal init`, change `Build-type` to `Custom` (`Setup.hs` already provided by `cabal init`) * Run `ghc-pkg init db` * Run `cabal configure --package-db=./db --global` * Output: {{{ Resolving dependencies... cabal: internal error: unexpected package db stack }}} In `cabal-install-0.8.2`, this appears to be caused by the code on lines 112-114 of `Distribution.Client.Configure`: {{{ usePackageDB = if UserPackageDB `elem` packageDBs then packageDBs else packageDBs ++ [UserPackageDB] }}} in combination with the code on lines 297-306 of `Distribution.Client.SetupWrapper`: {{{ ghcPackageDbOptions :: PackageDBStack -> [String] ghcPackageDbOptions dbstack = case dbstack of (GlobalPackageDB:UserPackageDB:dbs) -> concatMap specific dbs (GlobalPackageDB:dbs) -> "-no-user-package-conf" : concatMap specific dbs _ -> ierror where specific (SpecificPackageDB db) = [ "-package-conf", db ] specific _ = ierror ierror = error "internal error: unexpected package db stack" }}} Essentially, the order of the package databases in the stack is not as expected since the list already contains a `SpecificPackageDB` when the `UserPackageDB` is appended. (Note: this applies to GHC 6.12.3 and Cabal 1.8.0.6 on my system, but I could not select those versions in the ticket properties.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/731> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #807: inplace is shadowed by package
by Hackage 15 Mar '12

15 Mar '12

#807: inplace is shadowed by package ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: test Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a library, persistent, that builds. When I try to build the test suite, I get: {{{ Preprocessing library persistent-0.4.0.1... Preprocessing test suites for persistent-0.4.0.1... Building persistent-0.4.0.1... Registering persistent-0.4.0.1... <command line>: cannot satisfy -package-id persistent-0.4.0.1-inplace: persistent-0.4.0.1-inplace is shadowed by package persistent-0.4.0.1-f5ffa1e952f5d8b58608c8d1f9f69825 (use -v for more information) }}} The test-suite build-depends has: {{{ persistent >= 0.4.0.1, persistent-mongoDB, persistent-postgresql, persistent-sqlite, }}} persistent-mongoDB (and postgresql and sqlite) depends on persistent to build. I have tried this twice now from a fairly clean install- immediately after upgrading to a new version of ghc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/807> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #896: cabal install cabal-install fails if gcc not in /Developer/usr/bin/gcc
by Hackage 11 Mar '12

11 Mar '12

#896: cabal install cabal-install fails if gcc not in /Developer/usr/bin/gcc ---------------------------------+------------------------------------------ Reporter: jeremyw.sherman | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ---------------------------------+------------------------------------------ Under Mac OS X, `cabal` assumes `gcc` is at `/Developer/usr/bin/gcc`. This fails when Xcode is installed to another directory. Xcode has supported installing to an arbitrary folder since at least Xcode 3.x. This is particularly common among iOS developers, as they frequently require multiple parallel Xcode installs. Since Xcode installs gcc to both `$DEVELOPER/usr/bin/gcc` and `/usr/bin/gcc`, this could be fixed by using `/usr/bin/gcc` directly or the result of a search in `$PATH` for `gcc`. The user workaround for now is to symlink `/Xcode_4_2` (or whatever the user's latest Xcode install directory is) to `/Developer`. (Apple is moving from `gcc` to `clang`, anyway. Apple's `gcc` has been frozen at an ancient version for some time now.) Sample session exhibiting this bug: {{{ $ cabal install cabal-install Resolving dependencies... Configuring cabal-install-0.10.2... ghc: could not execute: /Developer/usr/bin/gcc cabal: Error: some packages failed to install: cabal-install-0.10.2 failed during the configure step. The exception was: ExitFailure 1 $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library $ which gcc /usr/bin/gcc $ which clang /usr/bin/clang $ ls -l `which gcc` lrwxr-xr-x 1 root wheel 12 13 Okt 15:37 /usr/bin/gcc@ -> llvm-gcc-4.2 $ ls -l `which clang` -rwxrwxr-x 1 root admin 41251344 27 Aug 03:53 /usr/bin/clang* $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.3 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/896> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #842: cabal appears to complain about relative paths
by Hackage 10 Mar '12

10 Mar '12

#842: cabal appears to complain about relative paths ---------------------------------+------------------------------------------ Reporter: jeffz | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ With `cabal configure --extra-lib-dirs=foo` $ cabal build Preprocessing library HENet-0.0.1... Building HENet-0.0.1... Registering HENet-0.0.1... cabal.exe: HENet-0.0.1: library-dirs: .libs is a relative path (use --force to override) Originally reported on irc: <dcoutts> jeffz: the right solution here would be for cabal to make the paths absolute before passing them on to ghc-pkg -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/842> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2