[Haskell-cafe] Hackage on Linux

[Brandon S Allbery KF8NH]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/22/2010 06:41 AM, 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.
>
> 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.

Last I heard, dons had a thing he ran that converted Cabal packages
into Arch Linux packages automatically.  I wouldn't be surprised if he
had something that automated the whole procedure from Hackage download
to Arch Linux upload.

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

So, remember your gripes elsethread about libcurl on Windows?  That's
what using a real package manager gets you:  the non-Haskell
dependencies are also handled and (assuming the packager isn't an
idiot) Just Work.

> 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

The answer is that it checks dependencies for you.  This is a mixed
blessing, however (see "cabal upgrade").

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

And the big problem with Windows is an utter lack of consistency in
package arrangement.  Linux has the FHS; *BSD and the OSX environments
(Fink and MacPorts) have mtree specifications; where did the Windows
library you just installed decide to stick its files?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxxTNgACgkQIn7hlCsL25UK3wCeMX/OySIyO3JXiDlijLEL1lM/
uesAn2LnchpzHqnbREYbrv347llLFkN6
=Ecxk
-----END PGP SIGNATURE-----