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 <gos...@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: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus
