November 2009 - cabal-devel

[Hackage] #601: cabal setup doesn't respect --prefix
by Hackage 20 Dec '09

20 Dec '09

#601: cabal setup doesn't respect --prefix ----------------------------+----------------------------------------------- Reporter: zooko | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I'm trying to install Cabal here. The install process (and the running cabal executable itself) isn't allowed to write into {{{/var/lib}}}, nor into any directory outside of {{{/usr/local/stow/Cabal}}}. So I pass {{{--prefix=/usr/local/stow/Cabal}}} and in addition I use unix permissions to make it so that if it attempts to write outside of the specified prefix it will fail. Good thing I did, because it does indeed so attempt: {{{ ./Setup configure --prefix=/usr/local/stow/Cabal ./Setup build ./Setup install Fri Oct 23 21:29:12 MDT 2009 Installing library in /usr/local/stow/Cabal/lib/Cabal-1.6.0.2/ghc-6.10.4 Registering Cabal-1.6.0.2... Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... ghc-pkg: /var/lib/ghc-6.10.4/./package.conf: you don't have permission to modify this file }}} Is there a different option to tell it to use a {{{package.conf}}} file in a specific directory? In any case, the fact that it is attempting to write outside the specified {{{--prefix}}} seems like a bug to me. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/601> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #602: support for jhc adapted to jhc-0.7.2
by Hackage 19 Dec '09

19 Dec '09

#602: support for jhc adapted to jhc-0.7.2 ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- See attached darcs patch. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/602> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #609: ghc-pkg dump encoding
by Hackage 19 Dec '09

19 Dec '09

#609: ghc-pkg dump encoding ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- With ghc-6.12.0.20091120, `FunctorSalad` on IRC found: {{{ when I try to run some Setup.hs (of any package, apparently), it compiles, but ./Setup configure crashes with: Setup: fd:5: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character) *** glibc detected *** ./Setup: double free or corruption (!prev): 0x098953a0 *** }}} As far as I can tell, the problem is that `./Setup` finds `/usr/bin/ghc` which is 6.10.4, and the output of `ghc-pkg dump | hexdump -C` includes: {{{ 00038060 63 6f 70 79 72 69 67 68 74 3a 20 a9 20 32 30 30 |copyright: . 200| }}} i.e. there's a latin-1 copyright symbol 0xA9. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/609> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #171: Add command to automagically create an initial cabal package
by Hackage 19 Dec '09

19 Dec '09

#171: Add command to automagically create an initial cabal package --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | --------------------------+------------------------------------------------- Don Stewart has a nice tool called mkcabal (http://www.cse.unsw.edu.au/~dons/code/mkcabal/) which creates an initial cabal package. It would be nice to have this built into the 'cabal' program itself so that "cabal create" or "cabal init" or similar would interactively create a cabal package. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/171> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #516: Maintain central haddock module index.
by Hackage 19 Dec '09

19 Dec '09

#516: Maintain central haddock module index. ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- The ghc api documentation includes a central index of [http://haskell.org/ghc/docs/latest/html/libraries/ all the modules in the core libraries]. Some people would like the same for all the modules provided by all the packages they have installed. See #206 for some of the previous discussion on this topic. The questions to resolve are where the index should be kept by default and how it should be configured (eg switched off). For example for a per-user install an index could live in `$HOME/.cabal/share/doc/index.html` but the equivalent is not appropriate for other prefixes like `/usr/local`. For global packages shipped by a distro the problem is much worse. We do not really want to have to have distro packages re-generating an html index every time they add and remove a package. Perhaps we should be looking at alternative solutions like using [http://live.gnome.org/devhelp devhelp] which can give easy access to installed documentation without maintaining a central index/catalog. Similar issues apply to a hoogle index. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/516> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #484: generalise version range syntax
by Hackage 19 Dec '09

19 Dec '09

#484: generalise version range syntax ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- The internal version range syntax allows arbitrary unions and intersections. The parser only allows two clauses and no brackets. See: http://haskell.org/pipermail/haskell-cafe/2009-January/054049.html {{{ I'm having some difficulty specifying dependencies in my .cabal file for a package I'm looking to upload to hackage soon. The difficulty is as follows. I basically want to specify parsec (>= 2.1 && < 3.0.0) || (> 3.0.0 && < 4) }}} I suggest we allow any number of clauses and brackets, to match the internal representation. We could also add `/=` or `!=` syntax since that is also easy to represent. It is harder to translate into other representations however we have a new view in terms of version ranges which should make it easier to do translations and to discover when the version range has more detail than can be represented in the target language (and maybe even approximate in such situations). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/484> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #485: preference on base version should only be applied for open constraints
by Hackage 19 Dec '09

19 Dec '09

#485: preference on base version should only be applied for open constraints ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently we apply the preference on the base version. That means that if you have base 3 and 4 available then for dependencies like: {{{ build-depends: base >= 2 }}} or {{{ build-depends: base >= 3 && < 5 }}} Then we end up picking base 3. That makes perfect sense in the first case. In the first case the developer clearly did not think about base 4. However in the second case they clearly have thought about it and yet we end up picking base 3. On balance it is probably better to pick base 4 in the second case even though both are allowed. One suggestion for how to handle soft constraints on the version of base is to say that we only apply the preference if the version is not bounded above. If it is bounded above then we use no preference and end up picking the highest version available. This policy cannot be expressed in the simple preferred versions syntax. It's probably ok to hard code it for base for now. This will require generalising the interface to the constraint solver to supply preferences in a slightly different form. It may need to be as a function from a list of possible versions to the selected version. The function would also be supplied with the package it's for, the dependency and the list of installed versions since it may want to take any of these into account and it is needed to express the above policy. This is related to the splitting of preferences into real preferences and hacks (see #483). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/485> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #385: emgm package incorrectly shown as "program" but is "library and program"
by Hackage 01 Dec '09

01 Dec '09

#385: emgm package incorrectly shown as "program" but is "library and program" --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | --------------------------------+------------------------------------------- The summary says it all. In the HackageDB package overview, it is shown whether packages contain libraries and/or programs, but this does not seem to work correctly in all cases, as emgm demonstrates. kosmikus -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/385> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

Multi-versioning and compatibility classes.
by Jason Dusek 01 Dec '09

01 Dec '09

I have been looking at the Cabal roadmap (tickets marked for bottom) and notice that no one has mentioned multi-versioning or compatibility classes. Maybe these are bad ideas? Multi-versioning seems highly desirable. Essentially, it allows us to have the same qualified names be provided by different packages for different packages. This is desirable in the case of package versions which really are no longer the same, like Parsec 2 and Parsec 3; it also allows for the case where more than one package specifies the same qualified name because it is obvious (like `Text.JSON` or some such). It stands to reason that the "package environment" specified in the `.cabal` file is enough to tell us which package we really need to use. However, there are problems, too. Like what if I have one package that depends on `parsec-2.1.0.1` and another that depends on `parsec-2.1.0.0`? With multi-versioning, they both compile fine but then I try to use a parser from one with a combinator defined in the other: this fails to compile because: parsec-2.1.0.1:Text.ParserCombinators.Parsec.GenParser is not the same as: parsec-2.1.0.0:Text.ParserCombinators.Parsec.GenParser So now we need compatibility classes. The first package might specify a package dependency like: ~parsec-2.1.0.1 where we take the `~` to mean "requires something compatible with". The second package specifies a similar dependency: ~parsec-2.1.0.0 Then the maintainer of Parsec specifies that 2.1.0.1 is compatible with 2.1.0.0 and we can compile the second package, the one that require 2.1.0.0, with 2.1.0.1 since they are compatible and that is all it is asking for. Then we try to use these two packages together and everything works. -- Jason Dusek

1 0

patch applied (cabal): Fix warnings
by Ian Lynagh 30 Nov '09

30 Nov '09

Sun Nov 29 08:46:43 PST 2009 Ian Lynagh <igloo(a)earth.li> * Fix warnings M ./Distribution/Simple/Program/Run.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20091129164643-3fd76-072af017…

1 0