
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. 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. 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) 6. A script to upload packages to "unstable" (Paolo is working on it). 7. Someone to spearhead all of this! peace, isaac p.s. here are the packages we have currently in the database: parsedate-2006.6.4 Haskell library for parsing dates and times cgi-2006.8.5 A Haskell library for writing CGI programs HDBC-odbc-1.0.1.0 lambdabot-4.0 bzlib-0.2 Compression and decompression in the bzip2 format HDBC-sqlite3-1.0.1.0 hask-home-2006.3.23 Generate homepages for cabal packages XmlRpc-2006.6.26 hnop-0.1 Haskell No Operation fps-0.7 HDBC-postgresql-1.0.1.0 rss-2006.7.12 A library for generating RSS 2.0 feeds. HTTP-2006.7.7 Crypto-3.0.3 DES, Blowfish, AES, SHA1, MD5, RSA, X.509 Identity and Attribute Certificates, General ASN.1 Support, Base64, PKCS8, PKCS1v15, Hexdump, Support for Word128, Word192 and Word256 and Beyond, PKCS5 Padding, Various Encryption Modes e.g. Cipher Block Chaining all in one package.plugins-1.0 fastcgi-2006.8.5 A Haskell library for writing FastCGI programs zlib-0.2 Compression and decompression in the gzip and zlib formats HDBC-1.0.1 xhtml-2006.7.5 A Haskell XHTML combinator library darcs-graph-0.1 gd-2006.7.12 A Haskell binding to a subset of the GD graphics library hmp3-1.1 Djinn-2005.12.14 A haskell proof generator iconv-0.2 Perform character set conversion exif-2006.7.11 A Haskell binding to a subset of libexif HaXml-1.13.1 Utilities for manipulating XML documents

On 10/4/06, Isaac Jones
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

I'd like to trim the followup to cabal-devel@ or libraries@ so we
don't cross-post to all lists.
Lemmih
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.
Cool! (snip)
What about the packages that have external dependencies? They won't necessarily be buildable on the server.
That's true. For such packages, we could install their dependencies by hand. Or we could exclude them as being too outside the system. I think an automagic solution for this problem is beyond the scope of cabal/hackage. (snip)
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?
The web interface is important for both the "unstable" and "stable" collections. People need to be able to look at what's available on the server. People need to know where to go for the authoritative release of packages. Simon Peyton Jones also happens to think that a web interface that shows all of the packages is very important. Maybe he can go into some detail about why. Would anyone else like to take up hacking on the web interface? Lemmih's version is here: http://hackage.homedns.org
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.
Like what? peace, isaac
participants (2)
-
Isaac Jones
-
Lemmih