[arch-dev-public] GHC 7.8.1 packaging decisions for Arch Linux

Thomas Dziedzic gostrc at gmail.com
Wed Apr 9 01:27:58 EDT 2014


Hello all,

With the arrival of ghc 7.8.1 [0], I would like to address the following
problems with a restructuring of how we treat haskell packages in archlinux:

Problem 1: Updating any haskell package has been delayed until we bump ghc.
Explanation: ghc is unable to produce a library that has a stable abi. In
other words, if a library gets rebuilt (even if it's the same exact
source), we will need to rebuild all package that depend on it, and this
would in turn a messy rebuild for any kind of rebuild.

Problem 2: Users are confused whether they should install packages from the
repos or using cabal-install. This in turn sometimes causes them to install
some packages from official repos, some from the aur, and some using
cabal-install
Explanation: Packages should ideally be installed from one place, either
using repos/aur or cabal-install. Said that, it is entirely possible to use
both repos/aur and cabal-install but for simplicity, one source is
preferred.

Problem 3: Our repos are unable to package every haskell package
Explanation: hackage has over 5000 haskell packages in it currently. There
is no way we will be able to support that many packages in our official
repos without some kind of automation. And even if it would be possible, it
would not necessarily be desirable. In addition, it is entirely possible to
have multiple versions of the same package installed at the same time.
Cabal has a very elaborate dependency solver in order to find versions that
will work for all package versions installed.

In addition, cabal-install 1.18 (the latest released) has added support for
sandboxes, meaning that when developing haskell programs, you are now able
to setup a sandbox environment that will only contain the haskell packages
you want.

I would like to propose the following changes to address the mentioned
problems and having the ability to use sandboxes to isolate development
environments.

Change 1: Move every haskell related package out of [extra] into
[community] except ghc and cabal-install. This includes the following 8
packages: haskell-http, haskell-mtl, haskell-network, haskell-parsec,
haskell-random, haskell-text, haskell-transformers, haskell-zlib
Explanation: These packages are only required to build cabal-install. Since
we converted the cabal-install package to use the bootstrap script that
comes with it, we no longer depend on these packages for anything in
[extra].

Change 2: Make a news item stating that cabal-install is now the
recommended way to install haskell packages. This wouldn't pollute the
filesystem since cabal-install installs packages to the ~/.cabal directory
by default. We might need to include a tip sheet about how you would handle
ghc updates since it requires extra user steps.

Change 3: Support users who are unable to install haskell packages that do
not compile under archlinux. This would require working with the user and
upstream to open up tickets and write patches for programs. At the very
least we can work with the user if they do not to open up upstream bug
reports and track them in our own bug tracker. There might be some packages
which we would probably consider unsupported like bindings to packages that
are not in the supported repos and packages that have no upstream activity
and ones that are effectively unmaintained.

Hopefully with the proposed changes, we can improve our user experience
with using official tools to maintain haskell packages.

I realize that some changes might be controversial especially change 3.
This is why I posted this here in order to discuss the possibilities. I
would also love to hear some opinions from vegai since he has some previous
experience package haskell and has had similar thoughts in the past. Also
if you're not a developer or trusted user, I would also like to hear your
opinion since it would affect you also.

Thanks for your time,
- Tom

[0] - https://github.com/ghc/ghc/releases/tag/ghc-7.8.1-release


More information about the arch-dev-public mailing list