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.