[Haskell-cafe] Hackage on Linux

Ivan Lazar Miljenovic ivan.miljenovic at gmail.com
Tue Aug 24 23:59:59 EDT 2010


On 25 August 2010 13:40, Mathew de Detrich <deteego at gmail.com> wrote:
> It is automated in a manual way =D. By that I mean that there is a script
> which autobuilds packages with cabal2arch, however that script itself has to
> be manually run. In all honesty I believe the best policy is to have base
> packages (and other 'required') be installed through the package manager of
> the distro and libraries installed through cabal. Haskell binaries then use
> cabal to check dependencies to see if the binary can be built (that is what
> I do now and I have no issues with it)

Consider these scenarios:

1) You upgrade package foo; this breaks a large number of other
packages.  How do you deal with it?

2) You upgrade GHC.  You now have to manually re-build all packages
that you had built with the previous version of GHC.

3) You want to uninstall some Haskell packages.

4) You built a package with non-standard build options; cabal-install
keeps wanting to rebuild it with the defaults.

5) You don't want to wait for a package maintainer to loosen the
dependencies of a package you know works with a newer version of a
dependency.

6) You want to install package bar; it fails to build due to some
missing C library/build tool/etc.  You have to dig around and work out
which system package contains that C library/Haskell package contains
that build tool/etc. and install that first.

Now, some future version of cabal-install may in fact solve the first
four problems by automating them and keeping track of installed
packages itself rather than relying on ghc-pkg.  It will _never_ be
able to solve the latter two (OK, it might be that someone adds
functionality to add "tweaks" to a package at configure/build/etc.
time).

Note also that if there is some trivial failure with a package not
building against a newer version of a dependency or GHC (e.g. the last
monolithic release of gtk2hs built against GHC 6.12.1 but not 6.12.2),
then in many cases it's easier and faster for the person maintaining
the distribution's packages to apply a fix than wait for upstream to
release a new version.

If you think the Arch packages for Haskell are so bad/out of date, why
not do something about that and help maintain them rather than just
whinge?

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


More information about the Haskell-Cafe mailing list