January 2008 - 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] #213: allow wildcards in data-files or extra-source-files?
by Hackage 29 Jul '08

29 Jul '08

#213: allow wildcards in data-files or extra-source-files? ----------------------------+----------------------------------------------- Reporter: duncan | 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: | ----------------------------+----------------------------------------------- Some packages end up with very very long fields for data-files or extra- source-files. Is this a problem? Should we allow some kind of globing to make it a bit less verbose? {{{ extra-source-files: cbits/*.h c-sources: cbits/*.c }}} On the other hand, there is a danger with globing that you pick up too many files. Perhaps we can counter that by making the globing rather restrictive, like no subdirectory recursion, and only allowing *'s in the final directory component, so no {{{data/*/*}}} patterns. Is there a sweet spot that allows conciseness without including too much accidentally? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/213> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[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 27 May '08

27 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] #226: Cabal install should upgrade in the correct order.
by Hackage 21 May '08

21 May '08

#226: Cabal install should upgrade in the correct order. ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Also, `cabal upgrade package-name` should probably upgrade that packages and dependencies, but not other packages. Here was my session with darcs cabal-install 2008-01-31: {{{ $ cabal upgrade Upgrading the following packages: cgi-3001.1.5.2 hmatrix-0.2.0.0 pcre-light-0.3 regex-base-0.93.1 regex-compat-0.91 regex-posix-0.93.1 TypeCompose-0.3 xhtml-3000.0.2.2 zlib-0.4.0.2 Downloading 'cgi-3001.1.5.2'... [... cgi upgrades fine ...] Configuring regex-compat-0.91... setup: At least the following dependencies are missing: regex-base >=0.93, regex-posix >=0.93 Downloading 'TypeCompose-0.3'... Downloading 'xhtml-3000.0.2.2'... Downloading 'zlib-0.4.0.2'... cabal: Error: some packages failed to install: zlib-0.4.0.2 xhtml-3000.0.2.2 TypeCompose-0.3 regex-compat-0.91 regex-posix-0.93.1 regex-base-0.93.1 pcre-light-0.3 hmatrix-0.2.0.0 $ cabal upgrade regex-base Upgrading the following packages: hmatrix-0.2.0.0 pcre-light-0.3 regex-base-0.93.1 regex-compat-0.91 regex-posix-0.93.1 TypeCompose-0.3 xhtml-3000.0.2.2 zlib-0.4.0.2 'hmatrix-0.2.0.0' is cached. [... everything through TypeCompose upgrades fine ...] 'xhtml-3000.0.2.2' is cached. Configuring xhtml-3000.0.2.2... 'zlib-0.4.0.2' is cached. Configuring zlib-0.4.0.2... [... zlib upgrades fine ...] cabal: Error: some packages failed to install: xhtml-3000.0.2.2 $ cabal upgrade Upgrading the following packages: xhtml-3000.0.2.2 'xhtml-3000.0.2.2' is cached. Configuring xhtml-3000.0.2.2... [... succeeds ...] }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/226> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #214: Package security
by Hackage 21 May '08

21 May '08

#214: Package security ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: misc | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- It'd be nice to avoid getting hacked by a trojaned package. This task is to: * survey the issue * consider the threats * see what solutions other systems use * consider the cost/benefit trade-offs in various security solutions * propose something -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/214> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

3 17

[Hackage] #224: allow specifying package version constraints to configure
by Hackage 20 Apr '08

20 Apr '08

#224: allow specifying package version constraints to configure ----------------------------+----------------------------------------------- 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: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Currently, configure considers the version constraints from the `build- depends` of the `.cabal` file. Of the available packages that satisfy those constraints it picks the highest version. This is not always what we want. The user might want to pick a specific version of a dependency (eg for testing or to avoid a known dud). cabal-install certainly wants to specify package versions exactly because it does its own dependency resolution and it may well end up not picking the latest version of an available dependency, eg to ensure consistent versions of a dependent package (see #220). So the dependencies would be specified just as in `build-depends`, for example: {{{ cabal configure --constraint="bytestring == 0.9.0.1" }}} (suggestions for a better flag name welcome) However it must only be for dependencies that the package actually depends on. It should be an error to specify constraints on packages that could never be used by the package we are configuring. The fact that package dependencies can be conditional complicates this slightly. To be precise, we could say that if the package name is not mentioned in the flattened package description then it is an error. If the package named in the constraint happens merely not be use in the selected configuration then it is not an error and the constraint is discarded. So an external package manager (like cabal-install) can control exactly how a package will be configured by setting all the use flags and precisely constraining all the dependencies. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/224> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[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