On 10/4/06, Isaac Jones wrote:

Hello good Haskell Hackers.

We're pretty well along the way to getting cabal-install and friends working nicely. We've got almost 30 packages in the database.

I added a few more. We have 32 now.

Let's imagine something that would be awesome. A set of Haskell packages which are all known to work together with a particular version of cabal (the one that GHC comes with), and a particular version of GHC.

GHC version 6.6 will be released soon, and I think we should try to make this happen.

Currently, we have a set of 27 "unstable" packages. They may or may not work with each-other and such:

http://hackage.haskell.org/packages/

I just created an empty directory "testing". I propose that we start testing packages, starting with the cabal release candidate that'll go into GHC 6.6, and make sure they work nicely together. Once they're known to work, we can migrate them from the "unstable" directory to the "testing" directory.

Once we have a sufficient collection of packages, and once ghc 6.6 is released, we can make a snapshot of this directory, call it "stable-6.6" or something. Then if you have ghc 6.6 and cabal-install, you should be able to "cabal-install p" for any package, and it'll definitely work.

What about the packages that have external dependencies? They won't necessarily be buildable on the server.

So what will we need for this to happen?

1. An installed version of ghc 6.6 on the hackage/darcs server. Maybe in a chroot or something. Maybe from the nightly build tree or the previous snapshot?

2. Some initial set of packages (maybe just cabal-install) to start off.

3. Some script that goes through and builds all of the "unstable" packages in dependency order. I think cabal-install can do this already. In fact, it would be ideal if we used cabal-install for this.

4. The script should also run ./setup haddock and ./setup test. If the packages seem to work w/ 6.6 and the other packages in "testing", it should get migrated from "unstable" to "testing".

5. A web interface (lemmih is working on it)

HackageDB is as good as it's gonna get for now. Btw, why is this step necessary?

6. A script to upload packages to "unstable" (Paolo is working on it).

7. Someone to spearhead all of this!

I have time. However, I also see a lot of problems. -- Cheers, Lemmih

In article <83y7rwhkp8.fsf@bishop.syntaxpolice.org>, Isaac Jones wrote:

We're pretty well along the way to getting cabal-install and friends working nicely. We've got almost 30 packages in the database.

I'm a bit confused about the status of various libraries. As I understand it, there are four levels of "officalness": 1. "core packages" in the GHC repository 2. "extra packages" in the GHC repository 3. packages in Hackage 4. any other packages that people may have It would be useful to know - * What determines whether a package ought to be in 2. versus 3.? Or should the "extra" packages migrate to Hackage? * What kind of state do they need to be in at the time of a GHC release? Thanks -- Ashley Yakeley, Seattle WA

Isaac Jones wrote:

here are the packages we have currently in the database:

HaXml-1.13.1 Utilities for manipulating XML documents

Can I just point out that HaXml-1.13.1 does not work with ghc-6.6, and HaXml-1.13.2 was released a couple of weeks ago to fix this issue. Also, a question. A couple of people have reported to me that the .cabal file for HaXml-1.13.2 gives them the error ghc-pkg: The field main-is is defined on both line 62 and 68 There are indeed multiple executable stanzas, each with a "Main-is:" clause. Is this not supported? Or perhaps it is supported now, but was not supported in some previous versions of cabal / ghc-pkg. If so, which versions? Regards, Malcolm