January 2010 - cabal-devel

[Hackage] #623: when a package is already installed, print the version as well
by Hackage 25 Jan '10

25 Jan '10

#623: when a package is already installed, print the version as well ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ At the moment, when a package is already installed, '''cabal-install''' prints a message like the following: {{{ > cabal install 'HaXml>1.3' Resolving dependencies... No packages to be installed. All the requested packages are already installed. If you want to reinstall anyway then use the --reinstall flag. }}} It would be helpful to print the version(s) of the requested package(s) as well. One case where this would be useful is to help the user realise that a preferred-version entry is in effect - in the case above, the version of !HaXml selected would be 1.13.3, while the latest version on hackage is 1.20. The output could look like this: {{{ > cabal install 'HaXml>1.3' Resolving dependencies... No packages to be installed. All the requested packages are already installed, in particular: HaXml-1.13.3 If you want to reinstall anyway then use the --reinstall flag. }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/623> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #624: "cabal haddock" should not break my build
by Hackage 25 Jan '10

25 Jan '10

#624: "cabal haddock" should not break my build ----------------------------+----------------------------------------------- Reporter: AntoineLatter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- See GHC bug 3799: http://hackage.haskell.org/trac/ghc/ticket/3799 With the package "syb-with-class" executing "cabal haddock" regenerates the .hi files and most of the .o files. It doesn't, however regenerate HSsyb-with-class.6.1.0.o. Since syb-with-class exports top-level declarations generated by template haskell, they have a different name every time we compile. So my (regenerated) .hi files exports names not in my .o file. If this happens during a "cabal install" we package up haddock's .hi files with the previously built HSsyb-with-class.6.1.0.o. I'm not sure if this is a Cabal bug or a haddock bug (or a GHC bug?). Either way I thought I'd post it here so people are aware of it. The work around is to turn off the auto-haddock option. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/624> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #234: track installed files to allow uninstall
by Hackage 24 Jan '10

24 Jan '10

#234: track installed files to allow uninstall -----------------------------+---------------------------------------------- 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: | -----------------------------+---------------------------------------------- `cabal-install` needs to be able to track all the files it installs so that it'll be possible to uninstall packages. The copy/install code should be extended to be able to generate a list of files and hashes of files that will be installed. `cabal-install` could use that to write out a manifest file and use that later to allow uninstalling. One solution might be to restructure the install code to gather the source files that it would install rather than just doing it. Once that list of files is known we can copy them all in one go, and do other things like check for clashing target files and generate manifests etc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/234> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

darcs patch: Fix #624 by making haddock put its compilation results...
by Andrea Vezzosi 22 Jan '10

22 Jan '10

Fri Jan 22 16:25:11 CET 2010 Andrea Vezzosi <sanzhiyan(a)gmail.com> * Fix #624 by making haddock put its compilation results in the temp directory. So the .hi files from the build phase don't get overwritten.

1 0

[Hackage] #625: Bad .cabal/config = "Command.optionToFieldDescr: feature not implemented"
by Hackage 19 Jan '10

19 Jan '10

#625: Bad .cabal/config = "Command.optionToFieldDescr: feature not implemented" ---------------------------------+------------------------------------------ Reporter: tommd | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ With Cabal 1.6 or 1.8.0.2 (either way) if I have a "bad" .cabal/config file, such as one with: optimization: True Then I get the error in the title. Need better error messages for broken configuration files! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/625> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

darcs patch: Fix mismatch between arch and os variables in D.S.Inst...
by Andrea Vezzosi 19 Jan '10

19 Jan '10

Tue Jan 19 04:16:42 CET 2010 Andrea Vezzosi <sanzhiyan(a)gmail.com> * Fix mismatch between arch and os variables in D.S.InstallDirs interpolation

1 0

Meaning of version tags in cabal files
by C Rodrigues 18 Jan '10

18 Jan '10

I noticed that cabal will parse, but ignore, version tags. For example, the two lines appear to be equivalent in how a package gets built: Version: 1.1Version: 1.1-alternate Arguably this is not the right thing to do, as it changes the semantics of versions. For example, I can install version 1.1 of a package without replacing version 1.0, but if I try to install version 1.0-alternate, I will actually replace version 1.0. I'm not against discarding version tags, but I'd like to know if there's a rationale for _silently_ discarding them. -heatsink _________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. http://clk.atdmt.com/GBL/go/196390706/direct/01/

3 2

build-dep command
by Ian Lynagh 17 Jan '10

17 Jan '10

Hi all, This patch adds a build-dep command to cabal-install, so cabal-install build-dep mypackage installs all the dependencies of mypackage, but not mypackage itself. There are at least a couple of problems with this patch: * I don't know what happens if you say cabal-install build-dep foo bar and bar is one of the transitive dependencies of foo. * Removing the packages from the install plan should probably do so directly, rather than converting the plan to a list and back again. But I'm sending it now so it doesn't just sit on my HD for eternity. Thanks Ian

1 0

[Hackage] #462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds.
by Hackage 16 Jan '10

16 Jan '10

#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | --------------------------------+------------------------------------------- Given these packages: C depends on B, B depends on A. A failed to build, B and C were uploaded later and failed also. Later, A was fixed, bumped version, re-uploaded. B did not need fixing, so remained untouched. C was also fixed, bumped version, re-uploaded. Finally, A rebuilt OK, B was not scheduled for rebuilding, C failed because B was still failed. It is requested that once a package that failed to build is updated and builds, all packages immediately dependent upon it are scheduled for rebuild. Then the same logic applies to those that rebuilt OK (their dependencies are scheduled for rebuild). Thanks. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/462> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #598: Bogus build failures on HackageDB
by Hackage 16 Jan '10

16 Jan '10

#598: Bogus build failures on HackageDB --------------------------------+------------------------------------------- Reporter: mboes | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- HackageDB reports build failures for packages due to inconsistent dependencies. For instance, the dedukti package currently has a build failure because it depends on both bytestring and text. The latest version of bytestring is 0.9.1.5, but text is built using bytestring-0.9.1.4. This causes a build failure because the functions in text expect as arguments something of type ByteString from bytestring-0.9.1.4, not something of type ByteString from package bytestring-0,9.1.5. If the text package were built using the latest available version of bytestring, as would happen after a "cabal install text" on a fresh system, the problem would go away. Always building packages with the latest versions of their dependencies available isn't a solution, because dedukti could, for instance, depend on some specific version of bytestring yet text might happen to be built with another version on the Hackage server. Could there be a way to at least detect when build failures are due to inconsistent versions in dependencies, which is a problem specific to the Hackage server installation and not the package itself? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/598> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9