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

On Wed, Apr 9, 2014 at 9:07 AM, Magnus Therning <magnus@therning.org> 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

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

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

That would be correct.

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

This would also be correct. I believe that most people who use packages in our supported repos don't actually use the haskell libraries themselves, but rather the tools that depend on them. (e.g. xmonad) I am not against keeping these tools around and their dependencies if someone wants to maintain them, but I personally have no interest in maintaining them myself.

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

I am aware that the way we are packaging haskell packages is non optimal and could be automated away. I already have a tool that automates the rebuild of [extra] packages, but since I don't/want to maintain any packages that aren't dependencies of cabal-install, I haven't looked into automating those builds. I don't want to focus solely on this point though because I just felt like I should make people aware of this problem. This isn't the only reason why I want to move away from haskell packages in pacman. 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.

I agree. Cabal does lack even basic features that other people would expect from a package manager. For example, upgrades, removal. Although there are ways to have the same effect as upgrading since you can have multiple versions of the same package installed, you could just install the same package after a cabal update. That's why I suggested writing up a tip sheet on basic cabal usage for people who aren't as used to cabal as others.

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 that the languages you mentioned could be split up into 2 categories. Python and Perl have a large number of interested developers and trusted users maintaining those packages. Python has over 700 packages, and Perl has over 500 packages and so, there is a lot of interest in those languages. On the other hand, you have Haskell, Ruby, and Node.Js where they have a smaller following. Haskell has about 90 packages (including i686/x86_64), Ruby has about 60, and Node.Js has approximately none. The popular languages have a critical mass which I believe lets people get away with using the pacman package manager. So for languages like python and perl, it might make sense to use pacman. But for languages like haskell, ruby, and node.js I believe using the system package manager leaves a lot to be desired.

How do you envision this actually working?

I would like to officially announce that there are 2 paths of maintaining haskell packages on your system. One would be using cabal-install and I would encourage users to try using it. The other would be to use whatever is in the supported repositories. I would also like to officially announce that one or the other is supported, but they should be mutually exclusive.

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?

No. I believe that most users actually know what the correct path is. I just want to make it officially announced rather than having any potential confusion on which path to take and which paths are supported.

Doesn't every language with its own package manager have this problem? For example, Python. Is there a good solution? Users knowing about this issue and making their own decisions is the current solution on every distro I'm familiar with.

Aye. There are some upshots to allowing users to install software via either the system package manager or a language-specific one, instead of forcing them down a single path. For example, with ruby: tools such as bundler, rbenv and rvm provide users with some awesome capabilities, such as being able to install multiple versions of Ruby and multiple versions of gems, either system-wide, in a user's home directory or in a custom directory. That's very useful, and the user should have that option - but if the user wants a simpler, more straightforward option, they can use `gem` or `pacman`. (And the choice between gem and pacman has its own tradeoffs.) Couldn't the same be said of Haskell packages? Using pacman to manage haskell packages provides some niceties, such as automatic updates (whenever -Syu is performed), whereas cabal-install provides its own niceties, such as access to numerous packages. So... is there anything wrong with letting the user choose the tool that suits their needs?