[Haskell-cafe] Re: Hackage on Linux

[Simon Marlow]

On 22/08/2010 11:41, Andrew Coppin wrote:
> Ivan Lazar Miljenovic wrote:
>> Hackage has limited support for distro maintainers to state which
>> packages are available on the distribution. Last I checked, it required
>> distro maintainers to keep a text file somewhere up to date.
>>
>> Note that not all distributions bother.
>
> Yeah, I figured. I don't see any Debian or OpenSUSE anywhere, and I know
> they do have at least a few pre-built binary packages out there.
>
> It looks as if it's automated for Arch, however. Either that or somebody
> is spending an absurd amount of time keeping it manually up to date.
>
>> (in particular none of us
>> involved with packaging Haskell packages for Gentoo can be bothered;
>> we're slowly cutting back into only keeping packages that will actually
>> be used rather than all and sundry)
>
> Well, I guess you either manually select which packages to convert, or
> you have an automated system convert everything in sight.
>
> This whole observation came about because I noticed that some (but not
> all) of my own packages have ended up on Arch, despite being of almost
> no use to anybody. I was just curious as to how that happened.
>
>> As for why using your distro package manager for Haskell packages is
>> preferable:
>> http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/
>>
>
> Right. So Cabal isn't a package manager because it only manages Haskell
> packages? Not sure I agree with that definition. (It also has a laundry
> list of problems that can and should be fixed, but won't be.)
>
> I actually spent quite a while trying to figure out what the purpose of
> Cabal *is*. It's not like it's hard to download a bunch of Haskell
> source code and utter "ghc --make Foo". So why do we even need Cabal in
> the first place? The answer, as far as I can tell, is that registering a
> library manually is so excruciatingly hard that we actually need a tool
> to automate the process. (Obviously when I first started using Haskell,
> I was mainly interested in writing runnable programs, not libraries.)
> Cabal can also run Haddock for you, which is quite hard. But it wasn't
> until cabal-install came along that I even realised that Cabal could
> track and resolve dependencies. (The fact that it doesn't track
> installed executables is news to me.)
>
> If nothing else, I think that "what Cabal is" should be documented much
> more clearly. It took me a hell of a long time to figure this out.
>
> Now, you say it's preferable to use the native package manager where
> possible. I've got one word for you: Windows. You know, the most popular
> OS on the market? The one installed on 98% of all computers world-wide?
> Guess what: no native package manager.
>
> Actually, we have tools that automatically convert Cabal packages to
> Debian packages or RPMs or whatever. I think there could be some milage
> in a tool that builds Windows installers. (The problem, of course, is
> that you have to be able to *build* the library on Windows first!) You
> would of course then have all kinds of fun and games with dependency
> tracking...

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.

Even on systems without a package manager (i.e. Windows), it would make 
more sense when installing a package globally to build an MSI first, so 
that the system can track the installation and let you uninstall it later.

There was a prototype Windows Installer builder for Cabal, cabal2wix [2] 
but I think the project is currently dormant.


[1] http://www.haskell.org/cabal/proposal/
[2] http://www.haskell.org/pipermail/cabal-devel/2007-August/000740.html

Cheers,
	Simon