[Haskell-cafe] Re: Hackage on Linux

[David Leimbach]

On Thu, Aug 26, 2010 at 5:02 AM, Don Stewart <dons at galois.com> wrote:

> marlowsd:
> > If you look at the original Cabal design document[1], you'll see that
> > one of the goals of Cabal was to be the glue that lets you convert an
> > arbitrary Haskell library into a native package for a variety of systems
> > - including MSIs on Windows.  Indeed, I must admit when we were
> > designing Cabal I thought that native packages would be the most common
> > way that people would install Cabal packages, specifically because many
> > systems already have a good package manager, and trying to bypass the
> > system package manager would be a fundamental mistake.  It turned out
> > that cabal-install would be a lot more useful than I imagined, but the
> > two systems are complementary: native packages are for installing
> > globally, and cabal-install is for installing packages in your home
> > directory.
> >
>
> We also didn't know that Hackage would get so big, so quickly. So
> there's three levels of packages now:
>
>    1. absolutely vital: HP (now on every system)
>    2. native packaging of useful Haskell apps and libs (many on Debian,
> Arch, Gentoo, few elsewhere)
>    3. cabal-install: everything else, works everywhere.
>
> And it looks like many distros are learning towards just providing 1.
> natively. Those with more automation (Debian, Arch) do 2. as well,
> though it is less useful than we thought now that cabal-install is
> relatively stable.
>
> A new trend are tools like 'bauerbill' on Arch, which has a --hackage
> flag, that converts hackage to native packages on the fly. That's like
> teaching apt to grok hackage.
>
> It's interesting how its all sorting out.
>
> -- Don
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>


Library packages are only interesting to me when it comes to application
deployment.  Things are greatly simplified when you DO NOT have shared
libraries to contend with because the only person tracking dependencies is
the developer.

Go, for example, has no shared libraries, and the runtime fits in every
binary.  It does not even depend on libc.  Go binaries call the system call
interface of the kernel, and the net result is that I get to test my go
code, deploy it, and not worry about the state of deployed go environments
quite so much as I do in the presence of shared libraries.

As such I think cabal-install is excellent in that it installs in the
developer's home directory, because that's all I need in other environments
as well.

It's quite practical.  People are obsessed with shared library support but I
can not for the life of me figure out why.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100826/a11c6b92/attachment.html