<br><br><div class="gmail_quote">On Thu, Aug 26, 2010 at 5:02 AM, Don Stewart <span dir="ltr">&lt;<a href="mailto:dons@galois.com">dons@galois.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
marlowsd:<br>
<div class="im">&gt; If you look at the original Cabal design document[1], you&#39;ll see that<br>
&gt; one of the goals of Cabal was to be the glue that lets you convert an<br>
&gt; arbitrary Haskell library into a native package for a variety of systems<br>
&gt; - including MSIs on Windows.  Indeed, I must admit when we were<br>
&gt; designing Cabal I thought that native packages would be the most common<br>
&gt; way that people would install Cabal packages, specifically because many<br>
&gt; systems already have a good package manager, and trying to bypass the<br>
&gt; system package manager would be a fundamental mistake.  It turned out<br>
&gt; that cabal-install would be a lot more useful than I imagined, but the<br>
&gt; two systems are complementary: native packages are for installing<br>
&gt; globally, and cabal-install is for installing packages in your home<br>
&gt; directory.<br>
&gt;<br>
<br>
</div>We also didn&#39;t know that Hackage would get so big, so quickly. So<br>
there&#39;s three levels of packages now:<br>
<br>
    1. absolutely vital: HP (now on every system)<br>
    2. native packaging of useful Haskell apps and libs (many on Debian, Arch, Gentoo, few elsewhere)<br>
    3. cabal-install: everything else, works everywhere.<br>
<br>
And it looks like many distros are learning towards just providing 1.<br>
natively. Those with more automation (Debian, Arch) do 2. as well,<br>
though it is less useful than we thought now that cabal-install is<br>
relatively stable.<br>
<br>
A new trend are tools like &#39;bauerbill&#39; on Arch, which has a --hackage<br>
flag, that converts hackage to native packages on the fly. That&#39;s like<br>
teaching apt to grok hackage.<br>
<br>
It&#39;s interesting how its all sorting out.<br>
<font color="#888888"><br>
-- Don<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>As such I think cabal-install is excellent in that it installs in the developer&#39;s home directory, because that&#39;s all I need in other environments as well.</div><div><br></div><div>It&#39;s quite practical.  People are obsessed with shared library support but I can not for the life of me figure out why.</div>
<div><br></div><div>Dave</div><div><br></div>