[arch-haskell] Issues with cabal2arch/AUR packages

[Rémy Oudompheng]

2011/3/28 Mathew de Detrich <deteego at gmail.com>:
> Of course, trying to force archlinux package management to have the same
> granularity as arch's is out of the question, which I guess made me come
> with my second idea. Wouldn't it just be smarter to have the archlinux
> haskell environment set up like this. Archlinux's package management is one
> that makes some sacrifices (in regards to having a rolling release system
> thats always up to date at the cost of granularity in certain areas)
> - ghc is an official package in the official repository
> - haskell-platform will be the same as it is currently (uses GHC, and
> cabal2arch packages from both the official repository and AUR). This is fine
> since the point of haskell-platform is the standard packages it uses are
> frozen for half a year. So the only haskell libraries on AUR would be the
> ones in haskell-platform (and arguably these should be in the official
> repository, as well as the base haskell-platform package)
> - All other libraries users would just install/update with cabal install and
> not through AUR/cabal2arch/bauerbill etc etc.
> - Haskell packages that provide binaries would check for their dependencies
> using cabal/ghc-pkg, ...

I don't really understand what you mean. Nothing prevents you from
using cabal to install packages. The point of the binary repositories
is to speed up the task by providing a set of pre-compiled packages
for common libraries. We do not intend to replace cabal as a package
management system, since obviously Archlinux package system is not
strong enough to express the full meaning the cabal dependencies.

My piont of view on this is
- archlinux provides GHC, haskell-platform (minus the OpenGL
packages), darcs and xmonad, + dependencies of common programs
- arch-haskell provides a suitably chosen version of several
additional libraries as binary packages or PKGBUILDs on AUR, and
having more libraries can't be a bad thing
- other packages (older versions of packages, etc.), that are
problematic for package management are really meant to be installed
through cabal.

And this is basically what you describe. And actually people can use
any tool they prefer to manage packages.

If an older version of a package (e.g. parsec 2) happens to be very
common and very needed, it is perfectly possible to provide a binary
package or a PKGBUILD for it with the correct "provides" fields so
that it can be used in a transparent manner by PKGBUILDs that need it.

All we have to do is to find a correct balance between no binary
package and too many binary packages.

The current situation looks good.

Rémy.