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

[Thomas Dziedzic]

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