February 2011 - cabal-devel

[Hackage] #725: Distinguish speculative and required build-depends upper bound
by Hackage 03 Mar '12

03 Mar '12

#725: Distinguish speculative and required build-depends upper bound ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ When a package adds a build-dependency on another package, it's good form to follow the Package Versioning Policy and add a speculative upper bound that is x.(y+1), if the current version is x.y. This is great, but in many cases the next version will /not/ break compatibility with your package. In that case, once you have tested that the dependency is fine, you can bump the upper bound. As the list of dependencies for any respectable Cabal package can be quite long, it may be useful to have some sort of 'cabal whatsnew' command which checks the upper bounds of your build dependencies and notifies you when there are newer versions than your upper bounds availble. Furthermore, there should be a mechanism for telling Cabal that the upper bound is required, and that the package will break if you try to bump it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/725> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #768: Cabal cannot find GHC when using relative path in -w flag
by Hackage 03 Mar '12

03 Mar '12

#768: Cabal cannot find GHC when using relative path in -w flag ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Trying to build the network package while standing at the root of a GHC build tree fails to find GHC: {{{ $ cabal install -w inplace/bin/ghc-stage2 network -v2 inplace/bin/ghc-stage2 --numeric-version looking for package tool: ghc-pkg near compiler in inplace/bin found package tool in inplace/bin/ghc-pkg inplace/bin/ghc-pkg --version inplace/bin/ghc-stage2 --supported-languages Reading installed packages... inplace/bin/ghc-pkg dump --global inplace/bin/ghc-pkg dump --user inplace/bin/ghc-stage2 --print-libdir Reading available packages... Resolving dependencies... selecting network-2.3 (hackage) and discarding network-2.0, 2.1.0.0, 2.2.0.0, 2.2.0.1, 2.2.1, 2.2.1.1, 2.2.1.2, 2.2.1.3, 2.2.1.4, 2.2.1.5, 2.2.1.6, 2.2.1.7, 2.2.1.8, 2.2.1.9, 2.2.1.10, 2.2.3 and 2.2.3.1 selecting base-4.3.0.0 (installed) selecting ffi-1.0 (installed) selecting ghc-prim-0.2.0.0 (installed) selecting integer-gmp-0.2.0.2 (installed) selecting rts-1.0 (installed) selecting parsec-2.1.0.1 (hackage) and discarding parsec-2.0, 2.1.0.0, 3.0.0, 3.0.1 and 3.1.0 selecting unix-2.4.1.0 (installed) and discarding unix-2.0, 2.2.0.0, 2.3.0.0, 2.3.1.0, 2.3.2.0, 2.4.0.0, 2.4.0.1 and 2.4.0.2 selecting bytestring-0.9.1.8 (installed) and discarding bytestring-0.9, 0.9.0.1, 0.9.0.2, 0.9.0.3, 0.9.0.4, 0.9.1.0, 0.9.1.1, 0.9.1.2, 0.9.1.3, 0.9.1.4, 0.9.1.5, 0.9.1.6 and 0.9.1.7 In order, the following would be installed: parsec-2.1.0.1 (new package) network-2.3 (new package) parsec-2.1.0.1 has already been downloaded. Extracting /home/tibell/.cabal/packages/hackage.haskell.org/parsec/2.1.0.1/parsec-2.1.0.1.tar.gz to /tmp/parsec-2.1.0.117969... Configuring parsec-2.1.0.1... cabal: Cannot find the program 'ghc' at 'inplace/bin/ghc-stage2' or on the path cabal: Error: some packages failed to install: network-2.3 depends on parsec-2.1.0.1 which failed to install. parsec-2.1.0.1 failed during the configure step. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/768> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #781: cabal list should have --with-compiler, --user, --global and --package-db flags
by Hackage 03 Mar '12

03 Mar '12

#781: cabal list should have --with-compiler, --user, --global and --package-db flags ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ `cabal list` is lacking a way to control which compiler and package databases are queried. See also ticket #457 about enhanced filtering for `cabal list` -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/781> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #804: support remote .cabal files in cabal info
by Hackage 03 Mar '12

03 Mar '12

#804: support remote .cabal files in cabal info ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently, `cabal info` supports local .cabal files and remote tarballs, but not remote .cabal files. The [http://hackage.haskell.org/package/lscabal lscabal] program supports remote .cabal file target like: {{{ $ lscabal http://code.haskell.org/xmonad/xmonad.cabal XMonad XMonad.Main }}} Is this useful? Presumably it would also need a more general query language to pull out the fields that the user is interested in. Note that `lscabal` only lists exposed modules and only unconditional ones (e.g. not ones that are platform dependent). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/804> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #667: Improve tools to manage ad-hoc package releases
by Hackage 05 Jan '12

05 Jan '12

#667: Improve tools to manage ad-hoc package releases ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Hackage is suited for major software releases by package maintainers. It is not suited to distributing betas, daily snapshots or random forks, or patches of existing releases. For example a user may have some patch or bugfix for a package that they need. It takes time for maintainers to review and integrate these. Sometimes maintainers have little time, or they disagree with a patch approach or quality. It is right that maintainers have control over what is released on hackage. However there is a need for decentralised, ad-hoc and short term releases. We do not want to encourage the pollution of the package namespace with lots of short-term forks. One solution is to let users post package forks on their own webspace. We would want to extend cabal so that people can run: {{{ cabal install http://code.haskell.org/~user/foo/foo-fork-to-fix- blah-1.0.1.tar.gz }}} This makes it very decentralised. We may want to add some feature to hackage package pages to link to third-party forks. In addition to hosting and installing single packages it would be useful to be able to publish package collections. Of course this is exactly what a hackage archive is. We should provide easy tools to make and manage hackage archives that can be hosted on dumb http file servers. Going one step further, the hackage index format should be extended to make it more RESTful by including links to tarballs rather than just assuming that tarballs are found relative to the index file using some fixed layout. This would allow people to publish indexes that span multiple servers. This gets close to the concept of a package "search path" promoted by the searchpath project (http://searchpath.org/) Additonally, an index should allow us to point to source control repos rather than just to release tarballs. This kind of index would be useful for nighly builds. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/667> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #724: Add getDataDirectory function to Paths_pkgname
by Hackage 05 Jan '12

05 Jan '12

#724: Add getDataDirectory function to Paths_pkgname ----------------------------+----------------------------------------------- Reporter: tommd | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Some libraries and programs have a large number of files. Instead of having explicit knowledge of each file (and instead of using a mutation on the result of getDataFilename) there should be a "getDataDirectory" or a "getDataDirectoryContents": getDataDirectoryContents = getDataDirectory >>= getDirectoryContents -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/724> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #739: cabal install regression with GHC HEAD - ghc-paths
by Hackage 05 Jan '12

05 Jan '12

#739: cabal install regression with GHC HEAD - ghc-paths ----------------------------+----------------------------------------------- Reporter: AntoineLatter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- with the Cabal library installed with GHC 6.13.20100911 I can no longer install the package ghc-paths-0.1.0.6 In 'ghci Setup.hs' I get the error: Setup.hs:41:25: Ambiguous occurrence `None' It could refer to either `Distribution.Simple.Setup.None', imported from Distribution.Simple.Setup at Setup.hs:2:1-32 or `Pkg.None', imported from Distribution.Simple.PackageIndex at Setup.hs:7:1-46 It looks like the 'None' constructor didn't exist in Distribution.Simple.Setup in Cabal 1.8.x. While we can't guarantee that an added constructor doesn't conflict with data declarations used in every Setup.hs, it seems in poor form to export the same constructor in two types in the same library. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/739> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #671: better error message for broken build tools
by Hackage 05 Jan '12

05 Jan '12

#671: better error message for broken build tools ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Consider: {{{ Configuring haskell-src-exts-1.9.0... setup: happy version >=1.17 is required but the version of /usr/local/bin/happy could not be determined. }}} The actual problem is: {{{ /usr/local/bin/happy: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory }}} We could produce a better error message in this situation. If we get a non-0 exit code when we check the `--version` then we can probably safely report that the program is probably broken. Of course if we get some result text back and we cannot extract and parse the version number then that's different. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/671> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #663: Setup.hs doesn't look into ~/.cabal/bin for build tools.
by Hackage 05 Jan '12

05 Jan '12

#663: Setup.hs doesn't look into ~/.cabal/bin for build tools. ----------------------------------+----------------------------------------- Reporter: Axel Simon | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Cabal currently only checks the current PATH for buildtools. If the user installs and new pre-processor with the default --user installation, these tools wind up in ~/.cabal/bin. However, cabal doesn't find these unless ~/.cabal/bin has been added to the PATH. This is irritating since it is then not possible to make a library depend on a cabal package that contains it's build tools: Even if cabal-install installs the build tools first, building the library still fails since the tools cannot be found. The solution is very simple: Add ~/.cabal/bin to the search path when looking for build tools! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/663> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #701: Help packages to avoid linker symbol clashes
by Hackage 05 Jan '12

05 Jan '12

#701: Help packages to avoid linker symbol clashes ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently it is all too easy to end up with silently clashing linker symbols. The prime example is C code linked into a Haskell package. Multiple versions of the same package will define the same linker symbols. The system linker is happy to just pick the first occurrence of a symbol (though the ghci linker is stricter). This can cause havoc if the behaviour of the C code changes from one version of the package to another (see for example the problem with mmap and darcs, ticket #700). There are a number of things we could do to improve the situation. * We could make it easier to make versioned C symbols in the C code used in a Haskell package by providing cpp macros. * We could explicitly check for unversioned C symbols in Haskell libs * We could try linking Haskell libs in such a way that the C symbols are not visible and thus cannot clash, but it would also mean they are not exported for other libs to use. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/701> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2