[Haskell-cafe] Re: Problems with Haskell Platform
Ivan Lazar Miljenovic
ivan.miljenovic at gmail.com
Fri Jun 4 06:54:46 EDT 2010
Don Stewart <dons at galois.com> writes:
>> 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
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
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
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
More information about the Haskell-Cafe