- cabal-devel - Haskell.org

how to implement uninstall & Logging paths of installed files?
by Isaac Jones 19 Sep '06

19 Sep '06

> On 9/16/06, Isaac Jones <ijones(a)syntaxpolice.org> wrote: >> "Johan Tibell" <johan.tibell(a)gmail.com> writes: >> >> > I'm trying to write a module that logs all files installed by Cabal to >> > a file. I've looked through parts of the source and conclude that some >> > of the information (the one used to generate prefixes) needed to >> > construct absolute file paths for installed files exists in >> > Distribution.Simple.LocalBuildInfo. Where does the actual copying take >> > place and is there a way to list the files being copied or am I better >> > of trying to list all files in the dist/ dir and prepend the prefixes >> > myself? What code decides how files are laid out in dist/? Hi all, FWIW, Johan is still interested in this. I would look especially at the "copy" and "install" commands. Look at Distribution.Simple.Utils, lots of "copy" related functions in there. Look especially at the "prefix" type parameters. The Distribution.Simple.Install.install function also implements the "copy" command; so "install" is more general, the prefix is all that changes, so look especially at this function. Look at the copydest parameter. Someone (else?) was looking into writing an "uninstall" feature, which would log the files installed so that it could remove them later. I think that logging & uninstall could be implemented quite effectively by tweaking the "install" target so that it first copies stuff into a temporary location, then uses a "find" type algorithm to discover all of the files that are meant to be installed. The find algorithm would create this list of files and dump it to a log. It would then use a recursive copy algorithm to copy all of these files into place. (The copy command would do pretty much the same, but skip the copy-in-place step.) The recursive copy function would have to not freak out if the directories already exist, of course. Install should also install this "log" of files somplace (where?), for the sake of uninstall. How's that sound? peace, isaac

2 3

Re: please try this tiny script to test cabal-install
by Isaac Jones 15 Sep '06

15 Sep '06

"Jason Dagit" <dagit(a)codersbase.com> writes: > The script test-cabal-install fails with this messages: > ./setup build > setup: Warning: The field "hs-source-dir" is deprecated, please use > hs-source-dirs. > Preprocessing executables for cabal-install-0.3.0... > Building cabal-install-0.3.0... > Chasing modules from: src/CabalInstall.hs > Could not find module `Distribution.Compat.FilePath': > it is hidden (in package Cabal-1.1.5) > (imported from src//Network/Hackage/CabalInstall/Install.hs) > make: *** [build] Error 1 > > The reason for this error is that cabal does not set the permissions > on freshly installed librarys correctly on my machine. I don't know > why this is the case, but I can provide information about my setup. Thanks for the report! I think that this has already been fixed with the new cabal release. Is that so, Duncan? We had thought to hide FilePath, but it's apparently too popular to keep from the people. peace, isaac

2 1

please try this tiny script to test cabal-install
by Isaac Jones 15 Sep '06

15 Sep '06

Paolo has been hacking on cabal-install, as many of you know. Cabal-install is a tool for installing cabal packages and their dependencies. We put together this little script that _should_ just install cabal-install, along with testing it out to install hnop. I know this works on my Debian box, your results may vary, especially if you don't use sudo, but these commands should be pretty clear for you to try them yourself. Please copy and paste this into a terminal, or make minor tweaks and do the same. Email cabal-devel to let us know if it worked or if it didn't! wget http://hackage.haskell.org/~paolo/darcs/cabal-install/test-cabal-install && chmod 755 test-cabal-install && ./test-cabal-install (Now that you've got that working, you can "cabal-install list" and see the packages on the server.) peace, isaac p.s. of course, if you don't trust hackage or paolo, you should look at the code before you run it as root ;) p.p.s. the script itself, in case you want to copy, mod, and paste is: #!/bin/sh darcs get http://hackage.haskell.org/~paolo/darcs/cabal-install/ && \ cd cabal-install && \ make && \ sudo make install && \ sudo cabal-install update && \ cabal-install install --prefix=/tmp --user hnop && \ ls -l /tmp/bin/hnop

1 0

3rd Cabal-1.1.6 release candiate
by Duncan Coutts 12 Sep '06

12 Sep '06

Hi all, I've put up a tarball for the third 1.16 Cabal release candidate: http://www.haskell.org/cabal/release/cabal-1.1.5.9.3/cabal-1.1.5.9.3.tar.gz This is also included with very recent GHC 6.5 snapshots. Please test this with your packages and report any issues to cabal-devel(a)haskell.org We're particularly interested of course in anything that worked before and is now broken. Duncan

1 0

Build failures in packages built with GHC 6.6
by Duncan Coutts 11 Sep '06

11 Sep '06

Hi folks, Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell packages with the latest GHC 6.6 RC snapshot. Here is his report of what failed, and how: http://www.haskell.org/~gentoo/gentoo-haskell/projects/GHC-6.5-failures.html You'll note that there are some common ones, like Data.FiniteMap going away and the old API in Data.Set disappearing. There seemed to be several programs which used the old lang or text packages. The change in the array bounds api broke some things. Text.Regex moved into a different package. Most of these look fairly trivial. Class instance changes broke a couple packages, which might be a bit more tricky to fix. One Cabal api change broke one package, again easily fixable. We made some Cabal modules that had been private by convention properly private (ei Distribution.Compat.*). This broke lhs2tex. I'm not sure exactly what Cabal scripts should be using for portable file path handling since Setup.hs modules are not supposed to have external dependencies on other packages (otherwise there's a chicken and egg problem with compiling Setup.hs). Advice here would be apreciated, I could let Distribution.Compat.FilePath remain public in this release and seek a better solution for the next release. BTW, you can see the complete set of Gentoo's Haskell packages here: http://www.haskell.org/~gentoo/gentoo-haskell/ (mostly under dev-haskell/) Gentoo users & developers can use this package collection as a portage overlay. Duncan (wearing his Cabal release manager hat and his Gentoo hat)

1 0

Repositories
by Paolo Martini 02 Sep '06

02 Sep '06

Hello, I've published a number of repositories so that people can try cabal- install more easily, I need to know wether it's working for you too, and what are the important things to do to towards the goal of shipping it with ghc-6.6. My Cabal repository: <http://hackage.haskell.org/~paolo/darcs/Cabal/> Patches (applied in the above repository): <http://hackage.haskell.org/~paolo/tmp/cabal-install-tarball- index.patch> <http://hackage.haskell.org/~paolo/tmp/cabal-install- dependencies.patch> Packages repository: <http://hackage.haskell.org/~paolo/darcs/packages/> Some of the notable programs in the packages repository, if you are thinking about testing it out: * hnop (!) * lambdabot (!) * darcs-graph * hmp3 * hask-home * many of the dependencies of Hope (<http://hope.bringert.net/>), but no HaskellDB, any version available? * ...etc, darcs send me packages if you please. Issues & ideas: * some packages miss the brief synopsis * no multiple repositories are allowed (I am thinking about how to solving it, ideas are welcome) * should it work on windows for ghc-6.6? * the dependency resolution code seem to work, but it should be probably "audited" better * you ideas? Peace, Paolo. --

2 1

darcs patch: Added c2hs dependency resolver
by Lennart Kolmodin 01 Sep '06

01 Sep '06

Fri Sep 1 19:19:57 CEST 2006 Lennart Kolmodin <kolmodin(a)dtek.chalmers.se> * Added c2hs dependency resolver

1 0

Configure/build separation
by Neil Mitchell 30 Aug '06

30 Aug '06

Hi, First off, being a windows user, having a configure/build separation seems a bit unusual. However, accepting that separation has been chosen, I was wondering what the design rationale for the following behaviour is: I download alex from darcs, runhaskell Setup configure checks for an absolute pile of things - such as alex, c2hs, cpphs - all things that are absolutely not required. In amongst all this waffle, it also checks for Happy - an absolute essential build dependancy. It doesn't find that, like it doesn't find plenty of other things, and continues straight along. Then when I try to buid, it fails. So the two points are: 1) Shouldn't configure check for what is required, rather than everything that any Haskell program might possibly require. 2) Shouldn't failing a configure check be an error, directing you to go get happy? Thanks Neil PS. I'm really liking this Cabal thing, its a very nice concept.

7 8

Plan for cabal-install
by Paolo Martini 28 Aug '06

28 Aug '06

Hello, during AngloHaskell, me, Duncan, Shae and David had the occasion to think about cabal-install (formerly known as cabal-get). The current situation: There is a server-program called cabal-server-install which checks that a given package is valid and updates the index accordingly. Its code can be found here <http://hackage.haskell.org/darcs/cabal-server- install/>. The current index file is a list of {name, description, dependencies, url} informations for each package. The hierarchy of packages and the corresponding index file can be found here <http:// hackage.haskell.org/darcs/cabal-server-install/pub/unstable/>. The problems: The current hierarchy is full of outdate packages, this is easy solvable after we've made some design decisions about the format of the hierarchy and the index file. The current index file format is a made-up format consisting of a certain number of fields, this is a problem because: * Cabal is going to support more dependencies information, like optional dependencies, which will require a field per-se. * For example GUI package managers need to know more than the little information now available after an update command. * The index file contains URL information for each package, which we don't know at the moment of producing that file on the server. A solution to all these problems is having all the `.cabal' files in a tarball as the index file. This is good for a number of reasons, some of those are: * No code is needed to generate the index. One can simple tar the directory hierarchy skipping the tarballs. Now, it will only pack the `.cabal' files; in future, it easily packs all the other files we will eventually need, like `.sig' files for signatures and whatnot. This is a big advantage. * The tarball format is very simple, it is all ASCII, and an Haskell un-tar implementation is very few lines of code, which will be needed for Windows. * Using the `.cabal' files for all the information means that cabal- get is easily {backward,forward}-compatible with changes in the `.cabal' files format, because it just relies on the Cabal parser. (e.g. optional dependencies in the near(?) future.) * We have all the informations from the beginning, after the first `cabal-install update' command. We are quite happy with this solution, but some other decisions need to be made: Now cabal-install saves the server list file in configuration-dir/ serv.lst; the index file in conf-dir/pkg.lst; and downloads all the tarballs in conf-dir/packages/. I'd like to discuss what should the local hierarchy of files look like with this change in the index file format. One problem is that we need to support multiple repositories, and still map the packages to the right URLs. The proposed solution would look like this: We have a conf-dir/repositories/ directory which contains a subdirectories. Those subdirectories are the string-encoded URLs of each repository. They contain the local mirror of the remote hierarchy produced by simply unpacking the index file; it generates a perfect local mirror missing the tarballs. This looks like a sensible nice thing. `cabal-install' will then fetch the informations it needs by looking order-sensitively at the server-list-file, then recurse through the hierarchy finding all the .cabal files. This looks like a pratical solution which should work well until we get thousands of packages. If we ever reach that point and efficiency becomes an issue we could simply load the tarball in memory and play with it lazily, mapping in- memory-cabal-files to records structures with the informations we need. What do you think? Does it look like a good plan? More questions: I am personally not sure about the OutputGen type which is defined in Cabal/Network/Hackage/CabalInstall/Types.hs. It seem to be evil and should be removed. Anybody has a precise idea about it? I have some initial code that makes cabal-get work on the tarball index, but I am not sure about how to integrate with the OutputGen actions, so it is not working now. I need some explanation about it. I hope the contents of this email are understandable, please ask for whatever I have explained badly or I have assumed for some reason. Peace, Paolo. --

5 5

darcs patch: Be cleverer about guessing hc-pkg name a... (and 1 more)
by Duncan Coutts 25 Aug '06

25 Aug '06

I got annoied with specifying: ./setup configure --with-compiler=ghc-6.5.20060724 --with-hc-pkg=ghc-pkg-6.5.20060724 So the first patch makes it guess better about so that this works: ./setup configure --with-compiler=ghc-6.5.20060724 The second patch is just a trivial simplification. That bit should probably use pipes rather than outputting to a file and then reading the file. I didn't want to just push these changes, so can someone else give them a quick look over and commit. Cheers. Duncan Wed Aug 23 11:54:12 BST 2006 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Be cleverer about guessing hc-pkg name and location. So it now works if you say: ./setup configure --with-compiler=ghc-6.5 ie specifying a path-relative name rather than an absolute path. We then look for hc-pkg in the same dir as where we found the compiler. If the compiler appears to have a version suffix then we additionally and preferentially look for hc-pkg with that same version suffix. (I'm not sure that bit works if you've got a .exe suffix, perhaps a windows person could try it / take a look) Wed Aug 23 11:59:56 BST 2006 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Use slightly simpler way of getting GHC version. ghc has supported --numeric-version for ages.

1 0