[Haskell-cafe] Re: Problems with Haskell Platform

[Ivan Lazar Miljenovic]

Don Stewart <dons at galois.com> writes:

> allbery:
>> Supposedly a future Cabal extension will be to, instead of installing,  
>> write out a package for a vendor packaging system (yum, apt, yast, what 
>> have you).  Consider contributing to that effort.
>>
>
> However, we have tools for some distros that do this, and some distro
> tools support it directly (e.g. "bauerbill --hackage" on Arch Linux
> knows how to ask cabal2arch to translate the .cabal file).
>
> Contribut to yum to allow pulling from hackage, by calling cabal2yum?

In general, I think this is a bad idea.

I don't know how it is in Arch, but for Gentoo we need to do a lot of
QA'ing to make sure our ebuilds generated with hackport work properly
(which is one reason why we don't churn ebuilds out as fast as you
generate PKBUILDs).  Part of the problem is probably that hackport isn't
as polished as cabal2arch, but a few other concerns we need to take care
of are:

1) Gentoo has categories for packages; whilst for Haskell stuff we can
   usually correctly guess dev-haskell/ as the category, there are a few
   exceptions (e.g. pandoc is in app-text/).  This is an even bigger
   problem when dealing with C deps, etc.

2) Dealing with flags: in most cases, we expose the Cabal flags as USE
   flags, so we need to take care of getting all those dependencies
   right.

3) Multiple versions: we have to take care of supporting multiple
   versions of GHC, as well as different versions of QuickCheck, etc.
   It doesn't help that due to the limitations of portage, Gentoo
   ebuilds do not support proper ranged dependencies.  However, this is
   most probably not an issue for most distributions where users get
   given one version of a specific package and they'll shut up and
   accept it.

4) It has to build always: related to the above, because we don't
   provide binaries, we have to ensure that packages are built reliably
   in a multitude of situations.  We recently had the situation where
   for some reason GHC 6.12.2 would build for someone but then wouldn't
   actually run; we eventually tracked down the problem to his usage of
   ccache: as of 6.12.2, the GHC wrapper script hardcodes which C
   compiler it was built with, and as ccache was only used when building
   packages the path to the C compiler in the GHC wrapper script was
   incorrect (so all our hacks to get this new "feature" of GHC working
   properly when users bootstrap had to be scrapped as they made the
   situation even worse in this case).

Again, these situations are mainly Gentoo-specific due to the unique
nature of the distribution (though distributions without categories
still have to ensure the Cabal-package-name-to-distribution-package-name
mapping is consistent and correct).  I would, however, imagine that in
general having end users use their package manager attempt to
automagically integrate Hackage packages into system packages would be
fraught with peril.

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