On Feb 10, 2007, at 9:15 , Donald Bruce Stewart wrote:

haskell:

...

said:

...

Then another problem,after I unregistered cgi-2006.9.6,the fastcgi-2006.10.9could't work well with cgi-1.0 .

You might need fastcgi-1.0:

http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi

...

Actually,I was trying my best to install hope: http://www.cs.chalmers.se/~bringert/darcs/hope and lasted for three days, it's really too hard.

hope really is rather hard to install. You're best 'hope' is to get packages from hackage that match version numbers you're after:

http://hackage.haskell.org/packages/archive/pkg-list.html

And then anything else from darcs. hope is really the pathological case for dependencies at the moment. Perhaps shapr or Bjorn can comment on the issues involed?

We hope to be able to solve the hope (and other complex package) problems with cabal-install, which will pull all dependencies off hackage, build them, and build your package, automatically. It's almost there.

A few days ago I put some work into the hope.cabal file, so that you should now be able to use that to build it. Just get the versions of all packages listed in the current darcs version of hope.cabal. I think all of them except the haskelldb ones are available from Hackage. If haskelldb 0.10 was released and uploaded to Hackage, I think you could even install Hope itself from Hackage. I've also recently changed the version number scheme on most of the packages I maintain (which includes most of the packages required by Hope) from a date-based one to a major.minor scheme. This has the unfortunate side-effect of making newer versions have smaller version numbers than older ones, but it felt silly to start with a major version number of 2008. That might have been a bad decision. /Björn

On Feb 11, 2007, at 0:12 , Robin Green wrote:

On Sat, 10 Feb 2007 23:37:04 +0100 Bjorn Bringert wrote:

...

I've also recently changed the version number scheme on most of the packages I maintain (which includes most of the packages required by Hope) from a date-based one to a major.minor scheme. This has the unfortunate side-effect of making newer versions have smaller version numbers than older ones, but it felt silly to start with a major version number of 2008. That might have been a bad decision.

The rPath Linux package management tool, conary, has a nice solution to the problem that software version numbers have inconsistent lexical ordering conventions between projects and sometimes within the same project. It does not compare version numbers at all, and (as far as I can tell) asks the package repository for the most recent package, unless you specify a particular version. Perhaps Cabal could do something similar?

Of course, this way you can't express "I want version >= 1.2" which is kind of a bummer.

Yeah, that would make specifying dependencies a bit of a drag. I think I'll just rerelease all the packages as version 3000.0.0 or something. Who cares if the version numbers look silly? /Björn