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

[Jelle van der Waa]

On Wed, Apr 9, 2014 at 9:07 AM, Magnus Therning <magnus at therning.org> wrote:

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

> 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?
>
> How many haskell developers actually use our packages in the repos/aur
rather then using caba-install?

-- 
Jelle van der Waa