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 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]?

I would like to keep XMonad/XMobar in [community] it does seem to take up a big chunk of the haskell-* packages we have in our repos. But I've never ran into real big issues packaging haskell libraries, one minor issue is

On Wed, Apr 9, 2014 at 9:07 AM, Magnus Therning wrote: that the developers tend to oversplit packages for example haskell-data-default-* . This really makes packaging haskell libraries annoying. 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...

I would prefer that we don't package vim plugins or firefox extensions. Firefox has it's own extension manager and vim has a lot of solutions which work better then pacman.

...

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

...

which we would probably consider unsupported like bindings to packages

Change 3: Support users who are unable to install haskell packages that do 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?

How many haskell developers actually use our packages in the repos/aur rather then using caba-install?

-- Jelle van der Waa