Haskell libraries, pacman vs. cabal

beroal · 2009-11-28 22:48:39

Can you compare them? as tools for installing and maintaining libraries?

sr · 2009-11-29 14:06:04

pacman:
+ all users on your machine can share the same packages (very useful for things like X11 and xmonad)
+ uninstallation actually removes old package files when you upgrade

cabal:
+ useful if you hack your own packages
+ packages may be more up-to-date than found in AUR.
+ tweak your packages, use different optimization flags.
+ no root/sudo access required.

In summary: use pacman, unless you have a specific need to mess around with your packages, or are using a machine where you don't have root access. I've yet to find a clean solution to uninstall haskell packages installed through cabal (rm -rf .on the various directories gets tedious pretty quickly.)

beroal · 2009-11-29 18:56:14

Thanks.

sr wrote:

pacman:
+ all users on your machine can share the same packages (very useful for things like X11 and xmonad)

It seems that cabal as root with "--global" does the same.

Last edited by beroal (2009-11-29 19:12:58)

skottish · 2009-11-29 20:08:07

cabal2arch is an option that, as the name implies, creates Arch packages from cabal. It was created by the arch-haskell team for making all of their stuff in AUR.

vogt · 2009-11-30 01:50:48

The cabal2arch PKGBUILDs do note some C library dependencies that you woul have to manually get if you use cabal install.

But the current setup for PKGBUILDs is that you can only have one version of each library installed, while there is no such restriction if you use cabal install. This limitation only rules out a couple packages... one example is needing parsec-3 and parsec-2 installed, because they present slightly incompatible APIs, which isn't really possible when using cabal2arch PKGBUILDs.

Perhaps a better middle ground is to just use both: PKGBUILDs for libraries like the ones in the haskell platform, while cabal install for the rest (whose dependencies cannot be handled by pacman).

skottish · 2009-11-30 01:58:16

vogt wrote:

The cabal2arch PKGBUILDs do note some C library dependencies that you woul have to manually get if you use cabal install.
But the current setup for PKGBUILDs is that you can only have one version of each library installed, while there is no such restriction if you use cabal install. This limitation only rules out a couple packages... one example is needing parsec-3 and parsec-2 installed, because they present slightly incompatible APIs, which isn't really possible when using cabal2arch PKGBUILDs.
Perhaps a better middle ground is to just use both: PKGBUILDs for libraries like the ones in the haskell platform, while cabal install for the rest (whose dependencies cannot be handled by pacman).

The "one version of each library" point is something that I wasn't thinking about at all. Excellent post.

sr · 2009-11-30 04:33:14

parsec, QuickCheck, and OpenGL are probably the cases of needing multiple libraries most people will bump into (well, base-3/base-4 too, but that's covered by ghc.) It's more of a problem when people defensively specify <= dependencies in the .cabal files when there may not be a breaking api change.

beroal wrote:

It seems that cabal as root with "--global" does the same.

Yes, but it breaks arch's ability to keep system directories clean, which I'm not willing to give up without a significant reason.

cabal2arch sounds like a nice tool I didn't know of, thank you! Off-topic, but does pacman check for multiple packages having the same provides=() blocks? If not, that might be one way to handle multiple package versions.

beroal · 2009-11-30 22:45:07

vogt wrote:

Perhaps a better middle ground is to just use both: PKGBUILDs for libraries like the ones in the haskell platform, while cabal install for the rest (whose dependencies cannot be handled by pacman).

Does I correctly understand you if I say that I should use pacman for distributive-dependent libraries such as "gtk2hs" and cabal for other libraries such as "ivor"?

vogt · 2009-12-01 18:05:32

beroal wrote:

vogt wrote:
Perhaps a better middle ground is to just use both: PKGBUILDs for libraries like the ones in the haskell platform, while cabal install for the rest (whose dependencies cannot be handled by pacman).
Does I correctly understand you if I say that I should use pacman for distributive-dependent libraries such as "gtk2hs" and cabal for other libraries such as "ivor"?

Yes, in the case of gtk2hs and ivor (this requires gtk2hs, right?), pacman packages are easier, since gtk2hs isn't on hackage so cabal install can't get it for you. It doesn't look like ivor suffers from any of the limitations that cabal2arch generated PKGBUILDs have (mostly regarding versioning of depends), so why not just use the PKGBUILDs for that one?

Another limitation to consider for the PKGBUILDs is if you have to recompile a package without changing it's version, that the state of your libraries registered with ghc can be inconsistent:

A-1.1 -> B-1.1 -> C-1.1

The nature of ghc's cross-module optimization means that B and C need to be recompiled. It can happen that A is recompiled for whatever reason (you change the code, upgrade ghc...), and as far as I know, we don't have any automation to make sure that B and C are recompiled (in the case of binary packages), or have a packaging release bump (in the case of the aur packages):

A-1.2 -> ...????
(A-1.1 is removed) -> B-1.1 -> C-1.1

But cabal-install (or manually run Setup.hs installs) let you run into problems later on by allowing you to keep A-1.1 around (so B and C keep working):

A-1.1 -> B' -\
              C-1.1
A-1.2 -> B  -/

If C indirectly depends on two different versions of A (above), and those intermediate libraries (B and B') both export types defined in A, you will probably have a compile failure. Such a thing can happen with, say A being the bytestring library.

EDIT: clarify that A is commonly bytestring

Last edited by vogt (2009-12-01 18:06:43)

sr · 2009-12-02 04:47:47

I think I've seen that particular problem with AERN-* packages, too: never gotten them to work for me.

we don't have any automation to make sure that B and C are recompiled (in the case of binary packages), or have a packaging release bump (in the case of the aur packages):

ghc-pkg unregister does list the packages dependent on the package being upgraded, so it's possible to use the pre-install and post-install functions in the .install file to work around this. It's a flaky way of doing things, mind you, and I can see a lot of things that will go wrong.

And then there's the problem that if packages that are installed with ghc are updated, it's never a good idea to upgrade them (network bit me in a few earlier ghc versions, and Simon Marlow has a new, and more performant parallel library that's at least going to make it to the next version of ghc.)

Last edited by sr (2009-12-02 04:48:33)

beroal · 2009-12-02 07:30:49

Wow, vogt, that's really complex.

Let's Keep It Simple. Suppose that I am a modest end-user. I always use single version of a library, the latest stable version; I do not change source code of libraries. I think we can manage in pacman issues with recompilation: we change sub-version of a library after each recompilation. Is it correct?

vogt · 2009-12-04 00:36:14

Problem is, that you don't immediately know which sub-versions to bump in order to force recompilation up the dependency chain.

In short, somebody needs to write (or adapt) for arch, what the gentoo folks have: http://gentoohaskell.wordpress.com/2009 … l-updater/

I believe that to handle c library updates we must have some kind of scripts to make sure the .so versions match up, right?

beroal · 2009-12-04 01:02:32

Questions.
1. Is not that constraint solver for the diamond dependency problem already included in pacman? How pacman packages are different from Haskell packages with respect to dependencies?
2. Will recompilation of a Haskell package cause a problem if we just recompile without changing an interface of a package (i.e. signatures of exported names)?

Arch Linux

#1 2009-11-28 22:48:39

Haskell libraries, pacman vs. cabal

#2 2009-11-29 14:06:04

Re: Haskell libraries, pacman vs. cabal

#3 2009-11-29 18:56:14

Re: Haskell libraries, pacman vs. cabal

#4 2009-11-29 20:08:07

Re: Haskell libraries, pacman vs. cabal

#5 2009-11-30 01:50:48

Re: Haskell libraries, pacman vs. cabal

#6 2009-11-30 01:58:16

Re: Haskell libraries, pacman vs. cabal

#7 2009-11-30 04:33:14

Re: Haskell libraries, pacman vs. cabal

#8 2009-11-30 22:45:07

Re: Haskell libraries, pacman vs. cabal

#9 2009-12-01 18:05:32

Re: Haskell libraries, pacman vs. cabal

#10 2009-12-02 04:47:47

Re: Haskell libraries, pacman vs. cabal

#11 2009-12-02 07:30:49

Re: Haskell libraries, pacman vs. cabal

#12 2009-12-04 00:36:14

Re: Haskell libraries, pacman vs. cabal

#13 2009-12-04 01:02:32

Re: Haskell libraries, pacman vs. cabal

Board footer