December 2007 - cabal-devel

[Hackage] #198: cabal install foo should upgrade foo if there's a newer version
by Hackage 12 Aug '08

12 Aug '08

#198: cabal install foo should upgrade foo if there's a newer version ---------------------------------+------------------------------------------ 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 | ---------------------------------+------------------------------------------ if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/198> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[Hackage] #175: cabal-install needs a new package dependency resolution algorithm
by Hackage 12 Aug '08

12 Aug '08

#175: cabal-install needs a new package dependency resolution algorithm ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ----------------------------+----------------------------------------------- The current package dependency algorithm is pretty simple. It's main failing is that it cannot backtrack if it finds the solution is impossible. What we would like is a new dependency resolution algorithm that can backtrack. We would also like to be able to configure policy issues separately, perhaps as a parameter. It may also be handy to let users or the system add extra version constraints. The input is the set of available packages and the output is a list of packages to install, and the assignment of configuration flags to use for each one. As for the policy input, this might take the form of a function that picks between possible dependencies in a slot, this could then allow us to make choices like preferring installed packages over the latest available package version, or vica versa. See also symptoms of the existing system: * bug #168 -- lack of configurable policy * bug #174 -- lack of backtracking -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/175> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #187: Paths_pkgname module is hard to use in a library
by Hackage 12 Jun '08

12 Jun '08

#187: Paths_pkgname module is hard to use in a library ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.1 Platform: Linux | ------------------------------+--------------------------------------------- Most users of the auto-generated {{{Paths_pkgname}}} module are programs. With GHC at least they can get away with not specifying the {{{Paths_pkgname}}} in the {{{Other-Modules}}} field. Get away with in the sense that it does not lead to linker errors because {{{ghc --make}}} does dependency chasing and links in all the necessary .o files. However for a library you must specify every module in {{{Exposed- Modules}}} or {{{Other-Modules}}} or one does get linker errors when you try to use the packages. That's because the missing module's .o files will not have been included in the library .a archive. See bug #128. So for a library one must specify {{{Other-Modules: Paths_pkgname}}} but then of course Cabal cannot find that module since it is not in the normal source directories but in {{{dist/build/autogen}}}. So people have to hack around it by adding {{{dist/build/autogen}}} to the {{{Hs-Source-Dirs}}} field. Obviously that's rather unsatisfactory. Probably the right solution is for Cabal to automatically add that directory to the end of the source dir search path. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/187> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #196: ability to specify custom args to haddock
by Hackage 26 May '08

26 May '08

#196: ability to specify custom args to haddock ---------------------+------------------------------------------------------ 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=293523 {{{ The ability to specify custom args to haddock, which is necessary to do things such as build docs that encompass parts of other packages }}} We can pass extra options to any program via the generic configure --$PROG-options= mechanism however for haddock this is not very useful since we also have to call haddock for another purpose and passing extra options there causes problems. Since the debian bug was filed there are several more feature of the haddock command, perhaps they solve the problem. If not, perhaps the problem could be explained further. What problem are we trying to solve here that would require passing extra options to haddock, and what extra options would one use? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/196> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #174: cabal-install tries to upgrade the base package
by Hackage 21 May '08

21 May '08

#174: cabal-install tries to upgrade the base package ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | ----------------------------+----------------------------------------------- When using ghc-6.6.x, with some packages, cabal-install tries to upgrade the base package to satisfy dependnecies. This is obviously impossible. The dependency resolution mechanism needs to be taught this fact. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/174> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #166: sdist puts Happy-generated .hs files in the wrong place
by Hackage 25 Mar '08

25 Mar '08

#166: sdist puts Happy-generated .hs files in the wrong place ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | ---------------------+------------------------------------------------------ I want to use sdist to generate source distributions of Happy that don't depend on Happy, and hence come with the Happy-generated .hs files for the parsers. When I try this, the source files are included, but in the root of the tree, whereas Cabal seems to look for them in `dist/build`. I can move them by hand and re-generate the tarball, and that works. I'm fairly sure this worked with older versions of Cabal. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/166> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[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] #193: add a --with-package-conf= flag to configure
by Hackage 29 Feb '08

29 Feb '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 22 Feb '08

22 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] #183: Provide "library-rank" in hackage
by Hackage 12 Feb '08

12 Feb '08

#183: Provide "library-rank" in hackage --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | --------------------------+------------------------------------------------- Google page rank is assigned to each page depening on (transitive) popularity. Something similar could be used to rank libraries, giving an indication of how central each library is in the haskell community. Google page rank is described in http://en.wikipedia.org/wiki/PageRank -ketil -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/183> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2