[Haskell-cafe] Hackage on Linux

[Ivan Lazar Miljenovic]

Andrew Coppin <andrewcoppin at btinternet.com> writes:

> 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.

Don has probably written a script to poll which packages are available
and write them to the required file.

>> (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.

The "convert everything in sight" approach.

>> 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.)

Well, Cabal is just a build library; cabal-install automates downloading
and building of Haskell packages but not fully, can't uninstall, can't
update, etc.

Part of this is that it has bugs, can be improved, etc. (uninstallation,
etc.).  However, I don't think a per-language build-tool like
cabal-install, rubygems, etc. can really be called a "package manager".

> 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.)

Well, Cabal (more specifically the actual .cabal file) tells you a few
things:

1) Metadata on the library (homepage, description, version, etc.).

2) A list of dependencies that the package needs; this is especially
   important when considering something like mtl vs monads-{fd,tf}:
   which library did you grab Control.Monad.State from?

3) Specification of available library and executables.

4) Available modules for libraries, as well as those not actually
   visible externally.

5) The ability to create tarballs for distribution (whilst VCS tools
   like darcs can also do this, you sometimes keep some files in version
   control that shouldn't be shipped with the release tarball).

6) Flags to change the behaviour and what to build, and the ability to
   do some auto-detection to be able to have different build options for
   Windows, etc.

All in all, Cabal serves two different aims:

* It provides metadata on what a Haskell package is.

* It's a very simplistic build system for Haskell packages.

> 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.

Right, and that's when tools like cabal-install can come in handy (but I
believe there is a new-ish attempt at writing a package manager for
Windows over mingw).

> 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...

Right, but again note the distinction: Cabal /= cabal-install; most
people call "cabal-install" a package manager; the distinction is
analogous to (but not quite the same as) RPM/deb vs yum/apt in
Fedora/Debian.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com