On Fri, 2008-05-02 at 09:55 -0700, David Roundy wrote:
On Sun, Apr 20, 2008 at 09:22:56PM +0100, Duncan Coutts wrote:
In the initial discussions on a common architecture for building applications and libraries one of the goals was to reduce or eliminate untracked dependencies. The aim being that you could reliably deploy a package from one machine to another.
We settled on a fairly traditional model, where one specifies the names and versions of packages of Haskell code.
Do you actually have any precedent for such a system?
I would count all the distro packaging systems as precedent. There are a few others but those are the most significant.
I've never heard of one, but then I've been sort of sheltered, due to living in the linux world where there is a distinction between packagers and upstream authors. I consider this a useful distinction.
I agree it is a useful distinction. I was a packager for gentoo for three years. The jobs have roughly the same goal -- to deliver great software to users -- but there is certainly a different focus.
But that's probably because I'm lazy, or perhaps because I care about my users--and thus like to give them options and reduce the dependencies of my software.
We are actually very lucky to have people doing the packaging job for us. It takes time and because of that only the most important bits of software get packaged. If we could significantly reduce the amount of time that packing people have to spend on each package then we could increase the number of packages that could benefit. So that's what Cabal's model of specifying dependencies is for, to provide enough information to enable package management. Without that information provided up front the packaging people have to spend much more time manually discovering the dependencies by reading through README and configure.ac files. With Cabal packages we have the possibility of generating distro packages automatically. Several distros have tools to do this automatic translation. This is something that is essentially impossible with autoconf. When we started using our translation tool in Gentoo we were able to increase the number of packages we provided by an order of magnitude. Of course we do not expect every little Haskell package to appear in every distro but the information provided by packages makes it possible to provide package management (in the form of cabal-install) even for the packages that do not meet the popularity or QA standards for the distros.
I know there is a long history of the autoconf-style approach being successful. Can you point to any success stories of the approach chosen for cabal?
Again I'd point to all the package management systems. If you want examples of build systems that provide enough information for package management then admittedly there are fewer. Ian already pointed out Python eggs and Ruby Gems. I think CPAN also has some method for tracking dependencies though I don't know if or how CPAN modules specify dependencies. Duncan