[aur-general] GHC 7.8.1 packaging decisions for Arch Linux

[Magnus Therning]

Tom,

I might come across as very critical below, but I'm really not.  As
you probably realise I've also thought a bit about related questions
and I'm just really interested in your thoughts and answers.

On Wed, Apr 9, 2014 at 7:27 AM, Thomas Dziedzic <gostrc at gmail.com> wrote:
> 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:
[...]
> 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].

I'm guessing this means cabal-install now is the only package outside
of [community] that uses ghc to build.  Is that right?

Is the plan then that any future tools (i.e. non-libraries)
implemented in Haskell would go into [community]?

<devil advocate>
There is nothing that say one HAS to wait for a ghc upgrade in order
to provide newer versions of Haskell packages.  As you point all
that's needed is a rebuild of all the packages that depend on the
upgraded one.  If that's messy it sounds like you are using bad tools
to handle upgrading.  Are you really suggesting ArchLinux abandon
packaging a whole class of software just because the tools are
inadequate?
</devils advocate>

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

It should be noted that cabal-install isn't a package manager in the
true sense[1].  I'm not sure this is an argument against making the
change you propose, but it's worth noting.

There are quite a few other language/frameworks that have
language-specific build/package systems, Python, Ruby, Perl,
node.js...  Are Python developers on Arch pointed towards using pip to
install Python libs?

I think sometimes the right thing is to point users to another package
manager, e.g. packaging vim scripts for system wide installation is a
bit silly, since installing a vim script affects ALL users on the
system.  So doing that would require providing some sort of vim-script
manager to users.  Then there's very little difference compared to
just telling users to use Vundle/Pathogen/whatever directly instead.
However, this isn't the case for Haskell/GHC...

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

How do you envision this actually working?
The set of packages in [extra]/[community] is rather small today, in
the order of 3 dozen, so does this mean that users are already turning
to the Arch devs when they are having problems compiling Haskell
packages?

/M

[1]: http://is.gd/vzse5G-


-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus