February 2012 - cabal-devel

[Hackage] #905: Test-suite extra-libraries conditional
by Hackage 16 Apr '12

16 Apr '12

#905: Test-suite extra-libraries conditional ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: test-suite Difficulty: unknown | Ghcversion: Platform: Mac OS | ---------------------------------+------------------------------------------ 1) If a library specified in an "extra-libraries" line in a test-suite is not present, cabal will not build the package even when tests are disabled. 2) Conditionals are not allowed in a test-suite section. The first issue should ideally be fixed, but at least resolving the second would allow me to fix my current issue (I need a framework on mac, and an extra-libraries elsewhere). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/905> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #856: cabal list UTF-8 problem
by Hackage 16 Apr '12

16 Apr '12

#856: cabal list UTF-8 problem ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Windows | ---------------------------------+------------------------------------------ C:\>cabal list dedukti * dedukti Synopsis: A type-checker for the cabal.EXE: <stdout>: invalid argument http://hackage.haskell.org/packages/archive/dedukti/1.1.4/dedukti.cabal "A type-checker for the λΠ-modulo calculus." -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/856> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #695: cabal install world always reinstalls programs
by Hackage 16 Apr '12

16 Apr '12

#695: cabal install world always reinstalls programs ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ cabal-install does not currently track the installed state of programs. It does now list them in the world file however. This leads to it always wanting to reinstall programs. Probably we do want to keep the programs in the world file, since we hopefully will track programs better in future. The temporary hack would be to filter out packages that have no lib when retrieving packages from the world file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/695> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[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] #909: cabal-install-ghc72 tarball has Mac-specific files.
by Hackage 12 Apr '12

12 Apr '12

#909: cabal-install-ghc72 tarball has Mac-specific files. ---------------------------------+------------------------------------------ Reporter: pdxleif | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ In the tarball of http://hackage.haskell.org/package/cabal-install- ghc72-0.10.4, there are Mac-specific metadata files: ._bootstrap.sh ._cabal-install-ghc72.cabal ._Main.hs These cause problems on my Linux system, ./Setup configure complains of multiple cabal files, and refuses to run until I delete the ._* files. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/909> 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