January 2008 - cabal-devel

[Hackage] #202: add a flag/config to make cabal use sudo/su/.. when installing with --global
by Hackage 19 Mar '08

19 Mar '08

#202: add a flag/config to make cabal use sudo/su/.. when installing with --global ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: global install sudo Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ cabal install --global usually fails because of missing privileges. sudo cabal install --global is quite messy since every intermediate file is then owned by root, so other tasks that wouldn't need privileges at all, now requires them to handle those files. I propose to add the possibility to configure a command to use when running the equivalent of "runhaskell Setup install" on the package. So that the user can set it in ~/.cabal/config and it will always be used when install --global is run. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/202> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #221: a generic way for cabal-install to specify external dependencies
by Hackage 18 Mar '08

18 Mar '08

#221: a generic way for cabal-install to specify external dependencies ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- Cabal-install needs a way to specify external dependencies, so that re- install can be made as automatic as possible. The fact that Cabal records the 3rd digit version in the path indicates a diligent user has to re- install all the packages on every new 3rd-digit dot release. Exanples are HDBC-ODBC and regex-pcre. This issue was raised in http://www.mail-archive.com/haskell-cafe@haskell.org/msg37001.html It was discussed before and Tim had one suggestion: http://www.mail-archive.com/haskell-cafe@haskell.org/msg33790.html I suggest to have a config-replacement file (or a section in .cabal/config) as such: package: SDL include-dirs: c:\libs\SDL\include When cabal-install attempts to install SDL in this case, it will replace the line "include-dirs" in <package>.cabal with what is suggested in the config-replacement file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/221> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #204: should setting user-prefix in ~/.cabal/config work?
by Hackage 12 Mar '08

12 Mar '08

#204: should setting user-prefix in ~/.cabal/config work? ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ Setting user-prefix in .cabal/config leads to the following error: {{{ wolverian@puni:~$ cabal info xmonad Warning: Error parsing config file /home/wolverian/.cabal/config: On line 5: Parse of field 'prefix' failed: Warning: Using default configuration. }}} I don't think the file format is documented anywhere, but a bit of poking in the source and a Google led me to believe that this should work. My config file looks like this: {{{ wolverian@puni:~$ cat .cabal/config compiler: GHC repos: hackage.haskell.org:http://hackage.haskell.org/packages/archive cachedir: "/home/wolverian/.cabal/packages" user-install: true user-prefix: "/home/wolverian" hackage-username: "" hackage-password: "" }}} This is with up-to-date (as of today) Cabal and cabal-install from Darcs: {{{ wolverian@puni:~$ cabal --version cabal-install version 0.4.1 using version 1.3.2 of the Cabal library }}} And my GHC is a local (in ~) GHC 6.8.2: {{{ wolverian@puni:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 }}} -- wolverian[[BR]] ilmari.vacklin(a)cs.helsinki.fi -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/204> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #205: Remove BSD4 from Cabal.Distribution.License.License
by Hackage 12 Mar '08

12 Mar '08

#205: Remove BSD4 from Cabal.Distribution.License.License ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- I doubt any Haskell software actually uses the BSD4 license, and it is likely to confuse users as it looks like a newer version of BSD3. Currently we have {{{ data License = ... | BSD3 | BSD4 }}} so I propose moving to one of {{{ data License = ... | BSD3 data License = ... | BSD data License = ... | BSD3 | OldBSD data License = ... | BSD | OldBSD data License = ... | NewBSD | OldBSD }}} (http://www.opensource.org/licenses/alphabetical lists it as "New BSD license") All but the first will require changing a number of packages. We could leave the old BSD3 name as deprecated for a while, though. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/205> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #193: add a --with-package-conf= flag to configure
by Hackage 01 Mar '08

01 Mar '08

#193: add a --with-package-conf= flag to configure ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Linux | ---------------------+------------------------------------------------------ From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317803 {{{ Consider adding a --with-package-conf= flag to the configure command, or the register command. }}} There is partial support for this internally in Cabal, though only for GHC of course. We have to decide if and how we want to present this feature given that it is currently GHC-only. Could it be done in a way that allows other implementations to provide a similar feature in future without us having to change the Cabal user interface? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/193> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #172: cabal-install segfaults
by Hackage 23 Feb '08

23 Feb '08

#172: cabal-install segfaults ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | ----------------------------+----------------------------------------------- Using the newest library version on hackage, "cabal update" segfaults after downloading the package list from hackage. "cabal install" produces the error "cabal: Data.ByteString.Lazy.index: index too large: 0" steps to reproduce the problem (at least for me): install the newest versions of Cabal (1.2.2.0), HTTP (3001.0.0), and zlib (0.4.0.1) from hackage, compile and install cabal-install (0.4.0) from hackage, create a directory called dist (to circumvent another problem with cabal-install), run cabal update, or cabal install -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/172> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #211: Add qa/check command
by Hackage 22 Feb '08

22 Feb '08

#211: Add qa/check command ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ The current set of QA checks (see #191) will be run automatically before sdist however it would still be useful for developers to be able to run them specifically. It'd also allow adding more expensive checks that would be inappropriate to run for sdist. Initially just running the existing QA checks would be enough. We can add more expensive ones later. As such, marking this ticket as easy. What should the command be called? "qa" "check" ? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/211> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #222: Hackage should be able to track which version of package is compatible with which version of GHC
by Hackage 21 Feb '08

21 Feb '08

#222: Hackage should be able to track which version of package is compatible with which version of GHC --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | --------------------------------+------------------------------------------- This is related to ticket #221 and #199. Cabal-install at this time always fetches the highest version of a package. But the highest version may not be compatible with the version of GHC. The example is the HXT package. http://www.fh-wedel.de/~si/HXmlToolbox/ As of this writing, version 7.4 is for GHC 6.8. But for those who have GHC 6.6, version 7.3 should be fetched. If there is a flag in Hackage to indicate this compatibility matrix, then cabal-install can make correct decision which version to fetch based on the GHC version the user has. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/222> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #220: detect inconsistent package dependencies
by Hackage 19 Feb '08

19 Feb '08

#220: detect inconsistent package dependencies -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- Now that packages are more fine grained and upgradeable we're commonly getting situations where we build a package that uses two other packages that were built against different versions of another common package. The most common example in the wild at the moment is people installing `bytestring-0.9.0.4` in addition to the `bytestring-0.9.0.1` that came with ghc-6.8.2 and then half their packages are built against one version and half against the other and when they try to use packages built against different versions we get a type error about `bytestring-0.9.0.1:Data.ByteString.ByteString` not being the same as `bytestring-0.9.0.4:Data.ByteString.ByteString`. Cabal could and should detect this situation, and `cabal-install` should plan around it in its dependency resolution algorithm. However in both cases we require the dependency information of the existing installed packages. See http://hackage.haskell.org/trac/ghc/ticket/1839 The simplest thing is to get the full `InstalledPackageInfo` for all the packages in the package databases. From that we can find all the dependencies. When we do find this situation it is not guaranteed to cause a compiler error, it's just rather likely. So it's not obvious if Cabal should warn or error. `cabal-install` could try to fix up inconsistencies but in general only by re-installing existing packages against different versions of their dependencies. The longer term solution is to allow installing multiple instances of the same versions of a package built against different versions of its dependencies. This is the functional Nix approach however it would probably also require support from ghc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/220> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

3 5

[Hackage] #210: Enable access to the x- extension fields, as simple [(String, String)] name-value pairs
by Hackage 13 Feb '08

13 Feb '08

#210: Enable access to the x- extension fields, as simple [(String, String)] name-value pairs ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- The .cabal file format allows custom fields beginning with "x-". This should be useful for many as yet unthought of extensions, experiments and integration with other systems. However currently the Cabal library api does not provide access to these fields. This should be added, as the subject says as a simple list of [(String, String)] name-value pairs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/210> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2